Estamos adicionando a capacidade para os usuários ajustarem seu fuso horário no Wordpress para que sua própria atividade em nosso site seja exibida no horário local. Enquanto fazemos isso, pensamos que poderíamos fazer com que essa configuração também fosse aplicada ao fórum, para que eles não precisem fazer a mesma configuração duas vezes. Atualmente, os usuários do Discourse definem sua própria localização e fuso horário em preferências/perfil, então gostaríamos de substituir isso, se possível.
Parece haver uma configuração do DiscourseConnect em “site_settings/category/login” chamada “discourse connect overrides location”. Isso é apenas para o campo “location” ou também cuida do fuso horário? Quando esta caixa está marcada, de onde no banco de dados do WP o DiscourseConnect está extraindo essas informações?
Ou seja, se implementarmos uma configuração semelhante própria, queremos ter certeza de que a armazenaremos no lugar certo para que flua corretamente através do DiscourseConnect quando ativarmos a opção “location”.
Depois de investigar um pouco mais, vou arriscar um palpite de que marcar a opção “substituir localização” no DiscourseConnect não utiliza a configuração de fuso horário do WordPress e que, se quisermos isso, a melhor maneira seria defini-la via API sempre que o usuário editar essa informação. Me avisem se isso estiver correto.
No entanto, ainda não tenho certeza de onde a “localização” está vindo do lado do WP, ou mesmo se ela está sendo transferida. Por exemplo, não estou vendo um token de “localização” no “último payload” para o meu usuário. Mas estou vendo avatar, bio, nome de usuário, id_externo, e assim por diante. Notavelmente, a bio está sendo transferida mesmo que não tenhamos “substituir bio” ativado, então presumivelmente “localização” também deveria ser transferida?
Se tiver um segundo, @simon, acredito que você seja o mago dos plugins. Me avise se tiver alguma ideia. Obrigado!
Olá @troygrady, desculpe pela demora na resposta (eu cuido das perguntas no plugin WP Discourse). Abordarei as configurações de fuso horário e localização separadamente (elas não estão conectadas).
Fuso horário
Você poderia apenas esclarecer se quer que a atividade do usuário seja exibida para ele em seu horário local? Se sim, ao contrário do Wordpress, esse é atualmente o padrão no Discourse (sem qualquer uso do DiscourseConnect) e será atualizado automaticamente se não for definido pelo usuário. Por exemplo, recentemente mudei do fuso horário Australia/Perth para Europe/Oslo. Não toquei na configuração de fuso horário no meu perfil aqui no meta, e agora aparece
Você pode sincronizar uma localização definida em um perfil de usuário do Wordpress com o campo de localização no perfil do usuário no Discourse. Não sincroniza por padrão, pois não há um campo padrão no Wordpress que seja equivalente ao campo de localização no Discourse. Você precisa adicionar algum código aqui. No arquivo functions.php do seu tema ou em outro local onde você pode adicionar código, você precisa adicionar algo como o seguinte, com a parte principal usando o filtro wpdc_sso_params.
Note que você precisará substituir ‘user_location_meta’ por qualquer campo de meta de usuário que esteja sendo usado para armazenar a localização do usuário em sua instância do Wordpress (ou seja, qualquer campo que esteja sendo usado pelo plugin que você está usando para adicionar localizações de usuário ao Wordpress).
Observe também que o campo de localização do Discourse é apenas um campo de “string”, o que significa que ele exibirá literalmente o que for inserido nele. Não tem efeito no fuso horário do usuário e não é geolocalização (ou seja, conectado com mapeamento de alguma forma).
Desculpe pela confusão! Sim, fuso horário local, e sim, o comportamento padrão do Discourse é ótimo. Como você está apontando, não é o Discourse que é o problema, é o WP que não tem a capacidade de permitir que os usuários vejam o site em seu fuso horário local. É isso que queremos adicionar. Se permitirmos que o usuário defina seu fuso horário, então imaginei que também deveríamos ter essa configuração para substituir a configuração do Discourse para que eles estejam sincronizados. É sobre isso que eu queria saber se o DiscourseConnect fornece. Parece que não.
O que eu não percebi é que a configuração do Discourse é automática. Se for esse o caso, podemos deixá-la como está. Ou seja, implementar o fuso horário local no WP e não ter esse valor substituindo o valor do Discourse. Sim, eles podem ficar dessincronizados, mas isso pode não ser realmente um problema para a maioria dos usuários.
Perfeito, esta é a peça de informação que faltava — eu não sabia de onde o DiscourseConnect deveria obter os dados de local do lado do WP. Implementamos nosso próprio campo de local manualmente, em usermeta, então podemos apenas extrair o valor de lá usando o hook wpdc_sso_params.
Eu sou lerdo, então provavelmente ignorei. Existe alguma documentação para wpdc_sso_params em algum lugar? Encontrei este tópico, que parece cobri-lo por enquanto:
Não, você não pode definir fusos horários via DiscourseConnect, e eu também recomendaria contra tentar, pois a portabilidade de fuso horário entre plataformas/padrões é um pouco complicada (existem várias listas “padrão” de fusos horários com pequenas diferenças).
Não de forma estruturada. Estou no processo de reformular toda a documentação do WP Discourse e publicarei uma lista abrangente de ações e filtros
Sobre o tópico de wpdc_sso_params, gostaríamos de incluir um link para a página inicial da plataforma do usuário e exibi-lo em seu cartão. Parece que posso configurar isso como um campo personalizado e, em seguida, passá-lo por meio de um hook semelhante. Mas eu quero que isso seja para nosso uso interno, ou seja, eu realmente não quero que apareça como algo que o usuário possa editar. Como controlamos todas as inscrições no WordPress e a conta do fórum é tratada automaticamente, isso potencialmente resolveria esse problema? Ou seja, criamos o campo personalizado, definimos como não editável após a criação e, em seguida, apenas atualizamos os dados por meio do sso posteriormente. O usuário nunca veria uma caixa de edição em lugar nenhum?
Ter um campo personalizado do WP contendo a “página inicial da plataforma do usuário”
Passar o campo personalizado para o Discourse usando o filtro wpdc_sso_params conforme descrito aqui.
Exibir o campo personalizado do Discourse no cartão do usuário e não permitir que o usuário o edite em seu perfil do Discourse (deixando “Editável após o cadastro” desmarcado)
Se isso estiver correto, deve funcionar, assumindo que você não tenha nenhuma caixa de edição para o campo personalizado do WP no próprio WordPress.
Apenas uma observação de que a equipe sempre pode editar campos de usuário (ou seja, campos personalizados), mesmo que você não selecione “Editável após o cadastro”. Para ver isso em ação, você precisará testar com uma conta não-membro da equipe.
O problema é que os campos de usuário personalizados sempre parecem editáveis no formulário de inscrição de usuário do Discourse, mesmo que você nunca pretenda que eles sejam acessíveis pelos usuários. Nunca queremos que os usuários editem a URL de sua página inicial da plataforma, pois ela é gerada automaticamente pelo sistema. No entanto, como nossos usuários nunca veem um formulário de inscrição do Discourse, isso pode ser irrelevante.
Para colocar isso de outra forma, existe uma maneira de criar campos personalizados que são apenas para uso interno, ou seja, que nunca aparecem em nenhum tipo de formulário editável pelo usuário no Discourse? Eu imaginaria que existem muitos usos potenciais para isso em termos de integração de dados do WP ou de outras plataformas externas nos displays do Discourse.
Sim, mas eles não aparecerão automaticamente no cartão do usuário, que é onde você deseja que os dados sejam exibidos, certo? No entanto, se é isso que você deseja, você pode adicionar qualquer campo arbitrário no filtro wpdc_sso_params, por exemplo:
Isso será armazenado no Discourse na tabela do banco de dados user_custom_fields, mas não será visível em nenhum lugar. Você pode consultá-lo usando o Plugin Data Explorer.
Certo, gostaríamos de exibir campos arbitrários no cartão do usuário, gerados pelo WP, relacionados à conta do usuário no site principal — como a URL da página inicial dele e, potencialmente, outros campos também. Eles não se destinam a ser fornecidos pelo usuário, mesmo durante a criação da conta. Eles se destinam apenas a serem exibidos pelo usuário. No nosso caso, parece que um campo “usuário” personalizado é a melhor abordagem, pois ele já inclui opções de exibição para perfil e cartão. E o usuário nunca vê um formulário de inscrição de qualquer maneira.
O caso extremo seria se você não estivesse usando SSO — o usuário veria esses campos no formulário de inscrição, embora não se destine a preenchê-los. Suponho que a solução alternativa seria apenas ocultá-los via CSS?
De qualquer forma, para o nosso caso, parece que temos nossas soluções aqui. Obrigado!
