Hi Eva, I went over your code and there’s no errors that I can spot - and I totally get your frustration. If it hadn’t been for Simon Cossar I don’t know how I’d have resolved it myself.
So, taking it backwards: if the PHP is correct, then something else must be disconnected. (browniepoints for me, yay.)
But…
I don’t know enough about any of that to be able to give suggestions or help.
If you’ve got your forum parked with the boys from Discourse Hosting, you could ask Richard (his name tag won’t pop, but this is his profile: Profile - RGJ - Discourse Meta )
Or perhaps @simon might be able to provide you with the missing steps.
Keeping my fingers crossed for you.
edit:
p.s. these are all the related plug-ins i use (+ that PHP one)
(Memberpress Drip is email marketing, so not related to this)
groups are any and all: closed and opened (i don’t give access to hidden groups, come to think of it)
these are some of the group names as displayed in ‘Groups’ - and as you can see, the “NoSpacesNames” are the ones that coincide with the PHP settings
If by parameters you mean the following, then no:
nor in the actual group settings (where you create it, with name, owner, etc.), it’s all straight forward and not connected to accessing through SSO - so setting or not setting this as a person’s primary group is not relavant.
There is one webhook here on Discourse that I put in as instructed by the WP-Discourse plugin:
email verification technically goes via memberpress: they (my wp-instance) send the log-in details to the user. by clicking the log-in link the users verify their address.
i know for a fact that it’s not through Discourse, because for a while it ALSO went through discourse (glitch somewhere) and Richard sorted that for me.
Con questo metodo, è possibile assegnare agli utenti il livello di fiducia 2 in Discourse quando aprono un account pagando, e ridurlo al livello 1 se non pagano mensilmente?
Non ci ho dato un’occhiata da un po’, ma ciò di cui avresti bisogno è una comunicazione tra il codice di Discourse e quello del sistema di pagamento (nel mio caso: MemberPress).
Quindi, se una persona smette di pagare, MemberPress modifica il suo codice, e questo codice corrisponde a un diverso livello di gruppo.
Se non c’è alcun collegamento con il pagamento, il livello di gruppo non verrà aggiustato.
Ah, aspetta.
Rileggendo la tua domanda: non sono sicuro di come funzioni con i livelli di fiducia…
ma… se tutto il resto fallisce, puoi facilmente creare un GRUPPO impostato sul livello di fiducia 2 e un altro sul livello di fiducia 1, e far sì che il tuo plugin di membership assegni quei gruppi ai tuoi membri.
Spero che questo aiuti. Se no, dovrò riprendere in mano la questione. Funziona senza intoppi dalla conversazione precedente e non ci ho più dato un’occhiata da allora.
Questo è emerso in un altro post su Meta oggi, quindi ho dato un’occhiata al codice per confermare se il livello di fiducia di un utente possa essere ridotto aggiungendolo a un gruppo che imposta un livello di fiducia inferiore rispetto al gruppo attuale dell’utente. Dall’analisi del codice, vedo che ciò non è possibile:
def grant
if @user.trust_level < @trust_level
@user.change_trust_level!(@trust_level)
@user.save!
end
end
Se il livello di fiducia di un utente è inferiore al livello di fiducia concesso dal gruppo, l’aggiunta dell’utente al gruppo aggiornerà il suo livello di fiducia. Altrimenti, non ci sarà alcuna modifica al livello di fiducia dell’utente.
Sono un po’ arrugginito (inoltre, è tardi), ma il livello di fiducia non sarebbe davvero rilevante. Non uso affatto i livelli di fiducia. Il gruppo TL 2 ha accesso a ‘questo’ e il gruppo TL 1 no.
Il livello di fiducia effettivo non è in uso. Qualsiasi membro può essere di livello di fiducia 1 e ottenere comunque l’accesso (tramite pagamento) al gruppo TL 4, a condizione che io non imposti i permessi sui livelli di fiducia, ma solo sui gruppi.
Sì, l’approccio da seguire è utilizzare i gruppi e le autorizzazioni di sicurezza per le categorie. Non dovrebbe essere necessario fare affidamento sui livelli di fiducia.
@Dani1, grazie per aver condiviso qui le tue esperienze e le tue difficoltà; è molto utile per altri utenti di MemberPress come me.
Ha senso, ma mi chiedo cosa succede se l’abbonamento del membro scade e lui non si disconnette mai, continuando così ad accedere al gruppo… Hai riscontrato questo come un problema?
In tal caso, mi chiedo se esista un modo per forzare un aggiornamento o una disconnessione…
@RGJ Il codice sopra indicato come soluzione rimuove gli utenti dai gruppi, ma come ha osservato Dani1, l’effetto si verifica solo dopo che si sono disconnessi.
Se un utente viene aggiornato tramite il normale processo di accesso SSO, l’aggiornamento non avverrà finché non si disconnettono e non effettuano nuovamente l’accesso. L’esempio di codice sopra è il modo più semplice per affrontare il problema, ma probabilmente non è il metodo migliore per gestire l’appartenenza ai gruppi.
Il plugin WP Discourse dispone di alcune funzioni di supporto che vengono attivate quando WordPress funge da sito provider SSO per Discourse. Queste funzioni consentono di aggiornare l’appartenenza ai gruppi senza richiedere all’utente di disconnettersi da Discourse. Tali funzioni sono presenti nel tema a cui Richard ha fatto riferimento: Manage group membership in Discourse with WP Discourse SSO.
Il post a cui Richard ha fatto riferimento fornisce alcuni dettagli sui due approcci diversi. Aggiungerò questi dettagli al tema howto la prossima settimana. Per ora, sarebbe utile leggere il post.
(Ovviamente, tutto questo è molto manuale. Ho solo un piccolo gruppo di persone e so esattamente cosa sta facendo ciascuno. Non ho ancora provato la soluzione di Richard, ma è bello sapere che esiste!)
Potresti per favore aggiungere un link qui quando lo pubblichi? Grazie!
Certamente, l’argomento è qui: Manage group membership in Discourse with WP Discourse SSO. Descrive come utilizzare le funzioni add_user_to_discourse_group e remove_user_from_discourse_group di WP Discourse. Supponendo che il tuo sito WordPress sia configurato come sito provider SSO per Discourse, queste sono le funzioni che dovresti utilizzare per gestire le iscrizioni ai gruppi su Discourse.
L’esempio utilizzato in quell’argomento riguarda il plugin PaidMembershipsPro, ma un approccio simile dovrebbe funzionare con qualsiasi plugin di membership WordPress ben realizzato.
Aggiungerò alcuni dettagli all’argomento su come gestire le iscrizioni ai gruppi con i parametri SSO add_groups e remove_groups. Per la maggior parte dei casi, gestire le iscrizioni ai gruppi aggiungendo questi parametri al payload SSO non sarà l’approccio migliore, poiché richiede agli utenti di disconnettersi e riconnettersi a Discourse prima che la loro iscrizione ai gruppi venga aggiornata.
Spero che in un futuro prossimo esista una soluzione pronta all’uso per collegare Discourse a specifici plugin di membership WordPress. Attualmente può essere fatto solo aggiungendo una piccola quantità di codice personalizzato al tuo sito WordPress. Se non sei abituato a farlo, potresti aver bisogno di assumere uno sviluppatore per aiutarti.
Grazie per i dettagli. Vedrò se riesco a memorizzarli.
Sono d’accordo: preferirei che l’aggiunta/sottrazione dei gruppi venisse eseguita al volo piuttosto che al logout e al successivo login dell’utente.
Se non riesco a risolvere la questione, assumerò uno sviluppatore qui per farlo e condividerò il codice. Credo che ci siano un paio di persone che l’hanno già fatto nella sezione marketplace.
