Stiamo aggiungendo la possibilità per gli utenti di regolare il proprio fuso orario in Wordpress in modo che la loro attività sul nostro sito venga visualizzata nell’ora locale. Mentre facciamo questo, abbiamo pensato che tanto vale far sì che anche quell’impostazione si applichi al forum, in modo che non debbano fare la stessa impostazione due volte. Attualmente gli utenti su Discourse impostano la propria posizione e il proprio fuso orario in preferenze/profilo, quindi vorremmo sovrascriverlo se possibile.
Sembra esserci un’impostazione di DiscourseConnect in “site_settings/category/login” chiamata “discourse connect overrides location”. Questo è solo per il campo “location” o si occupa anche del fuso orario? Quando questa casella è selezionata, da dove nel database di WP sta recuperando queste informazioni DiscourseConnect?
Cioè, se implementiamo un’impostazione simile della nostra, vogliamo assicurarci di memorizzarla nel posto giusto in modo che fluisca correttamente tramite DiscourseConnect quando attiviamo l’opzione “location”.
Dopo aver approfondito ulteriormente la questione, suppongo che la selezione dell’opzione “override location” in DiscourseConnect non acquisisca l’impostazione del fuso orario da WordPress e che, se lo desideriamo, il modo migliore sarebbe impostarlo tramite API ogni volta che l’utente modifica tali informazioni. Fatemi sapere se è corretto.
Tuttavia, non sono ancora sicuro da dove provenga la “location” dal lato WP, o anche se arrivi. Ad esempio, non vedo un token “location” nell’“ultimo payload” per il mio utente. Ma vedo avatar, bio, username, external_id e così via. In particolare, la bio arriva anche se non abbiamo attivato “override bio”, quindi presumibilmente dovrebbe arrivare anche la “location”?
Se hai un secondo @simon, credo che tu sia il mago dei plugin. Fammi sapere se hai qualche intuizione. Grazie!
Ehi @troygrady, scusa per la risposta lenta (gestisco le domande sul plugin WP Discourse). Affronterò le impostazioni del fuso orario e della posizione separatamente (sono scollegate).
Fuso orario
Potresti chiarire se intendi che l’attività dell’utente debba essere visualizzata a loro nel loro orario locale? Se è così, a differenza di Wordpress, questa è attualmente l’impostazione predefinita in Discourse (senza alcun uso di DiscourseConnect) e si aggiornerà automaticamente se non impostata dall’utente. Ad esempio, sono recentemente passato dal fuso orario Australia/Perth a Europe/Oslo. Non ho toccato l’impostazione del fuso orario nel mio profilo qui su meta, e ora dice
Puoi sincronizzare una posizione impostata in un profilo utente Wordpress con il campo posizione nel profilo utente su Discourse. Non si sincronizza per impostazione predefinita poiché non esiste un campo standard in Wordpress equivalente al campo posizione in Discourse. Devi aggiungere del codice qui. Nel file functions.php del tuo tema o in un altro punto in cui puoi aggiungere codice, devi aggiungere qualcosa di simile a quanto segue, la parte chiave utilizzando il filtro wpdc_sso_params.
Nota che dovrai sostituire ‘user_location_meta’ con qualsiasi campo meta utente venga utilizzato per memorizzare la posizione dell’utente nella tua istanza Wordpress (cioè, qualsiasi campo utilizzato dal plugin che stai utilizzando per aggiungere posizioni utente a Wordpress).
Nota anche che il campo posizione di Discourse è solo un campo “stringa”, il che significa che visualizzerà letteralmente qualsiasi cosa vi venga inserita. Non ha alcun effetto sul fuso orario dell’utente e non è una geolocalizzazione (cioè collegata in alcun modo alla mappatura).
Scusa per la confusione! Sì, fuso orario locale, e sì, il comportamento standard di Discourse è ottimo. Come stai sottolineando, non è Discourse il problema, è WP che non ha la capacità di consentire agli utenti di vedere il sito nel proprio fuso orario locale. Questo è ciò che vogliamo aggiungere. Se lasciamo che l’utente imposti il proprio fuso orario, allora ho pensato che dovremmo anche far sì che quella impostazione sovrascriva l’impostazione di Discourse in modo che siano sincronizzate. Questo è ciò che volevo sapere se DiscourseConnect lo fornisce. Sembra di no.
Quello che non avevo capito è che l’impostazione di Discourse è automatica. Se è così, potremmo semplicemente lasciarla così com’è. Ovvero, implementare il fuso orario locale in WP e non far sì che quel valore sovrascriva il valore di Discourse. Sì, potrebbero andare fuori sincrono, ma potrebbe non essere un vero problema per la maggior parte degli utenti.
Perfetto, questo è il pezzo mancante di informazione: non sapevo da dove DiscourseConnect dovesse recuperare i dati di posizione dal lato WP. Abbiamo implementato manualmente il nostro campo posizione, in usermeta, quindi possiamo semplicemente estrarre il valore da lì usando l’hook wpdc_sso_params.
Sono ottuso, quindi probabilmente l’ho trascurato. C’è documentazione per wpdc_sso_params da qualche parte? Ho trovato questa discussione, che sembra coprirla per ora:
No, non è possibile impostare i fusi orari tramite DiscourseConnect, e sconsiglierei anche di tentare di farlo, poiché la portabilità dei fusi orari multipiattaforma/standard è un po’ un campo minato (ci sono più elenchi “standard” di fusi orari con lievi differenze).
Non in senso strutturato. Sto rinnovando tutta la documentazione di WP Discourse e pubblicherò un elenco completo di azioni e filtri
Riguardo a wpdc_sso_params, vorremmo includere un link alla homepage della piattaforma dell’utente e visualizzarlo sulla sua scheda. Sembra che io possa impostarlo come campo personalizzato e poi passarlo tramite un hook simile. Ma voglio che sia per il nostro uso interno, cioè non voglio che appaia come qualcosa che l’utente può modificare. Poiché controlliamo tutte le registrazioni su Wordpress e l’account del forum viene gestito automaticamente, ciò potrebbe risolvere il problema? Cioè, creiamo il campo personalizzato, lo impostiamo come non modificabile dopo la creazione e poi lo aggiorniamo solo tramite sso in seguito. L’utente non vedrebbe mai una casella di modifica da nessuna parte?
Avere un campo personalizzato di WP contenente la “homepage della piattaforma dell’utente”.
Passare il campo personalizzato a Discourse utilizzando il filtro wpdc_sso_paramscome descritto qui.
Visualizzare il campo personalizzato di Discourse sulla scheda utente e non consentire all’utente di modificarlo nel proprio profilo Discourse (lasciando deselezionato “Modificabile dopo l’iscrizione”).
Se è corretto, dovrebbe funzionare, supponendo che tu non abbia caselle di modifica per il campo personalizzato di WP in WordPress stesso.
Nota che lo staff può sempre modificare i campi utente (cioè i campi personalizzati), anche se non selezioni “Modificabile dopo l’iscrizione”. Per vederlo in azione dovrai testarlo con un account non staff.
Il problema è che i campi utente personalizzati sembrano essere sempre modificabili nel modulo di registrazione utente di Discourse, anche se non si intende mai che siano accessibili dagli utenti. Non vogliamo mai che gli utenti modifichino l’URL della loro homepage della piattaforma poiché viene generato automaticamente dal sistema. Tuttavia, poiché i nostri utenti non vedono mai un modulo di registrazione di Discourse, questo potrebbe essere irrilevante.
Per dirla in altro modo, esiste un modo per creare campi personalizzati che siano solo per uso interno, ovvero che non appaiano mai in alcun tipo di modulo modificabile dall’utente in Discourse? Immagino che ci siano molti usi potenziali per questo in termini di integrazione di dati di WP o di altre piattaforme esterne nei display di Discourse.
Sì, ma non appariranno automaticamente sulla scheda utente, che è dove vuoi che i dati vengano visualizzati, giusto? Tuttavia, se è quello che vuoi, puoi semplicemente aggiungere qualsiasi campo arbitrario nel filtro wpdc_sso_params, ad esempio
Questo verrà memorizzato in Discourse nella tabella del database user_custom_fields, ma non sarà visibile da nessuna parte. Puoi interrogarlo utilizzando il plugin Data Explorer.
Bene, vorremmo visualizzare campi arbitrari sulla scheda utente, generati da WP, relativi all’account dell’utente sul sito principale, come l’URL della loro homepage e potenzialmente altri campi. Non sono destinati a essere forniti dall’utente, nemmeno durante la creazione dell’account. Sono solo destinati a essere visualizzati dall’utente. Nel nostro caso, sembra che un campo “utente” personalizzato sia l’approccio migliore poiché include già opzioni di visualizzazione per profilo e scheda. E l’utente non vede mai un modulo di registrazione.
Il caso limite sarebbe se non si utilizzasse l’SSO: l’utente vedrebbe quei campi nel modulo di registrazione, anche se non è destinato a compilarli. Suppongo che la soluzione alternativa sarebbe nasconderli tramite CSS?
Comunque, nel nostro caso, sembra che qui abbiamo la nostra soluzione (o le nostre soluzioni). Grazie!
