O último commit no plugin WP-Discourse está fazendo com que todas as postagens personalizadas (feitas através do Plugin EventON) sejam atribuídas ao usuário system, apesar de o usuário existir tanto no Discourse quanto no WordPress.
Se voltarmos para a versão 2.3.7, funciona como esperado, mas a atualização para a versão 2.3.8 causa este bug.
Recebemos este erro por e-mail:
Motivo da falha:
Um código de resposta 400 foi retornado do Discourse.
param está faltando ou o valor está vazio: post
Você quis dizer? post
post[raw]
controller
title
Pensei que isso poderia ser útil para identificar a causa provável.
[2022-02-21 08:07:11] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""}
[2022-02-21 08:07:11] publish.INFO: create_post.body_valid {"wp_title":"[Please Ignore] Test Event","wp_author_id":"3958","wp_post_id":126070,"discourse_post_id":""}
A postagem foi vinculada corretamente à minha conta de usuário tanto no WordPress quanto no Discourse com a versão 2.3.7.
v2.3.8:
[2022-02-21 08:10:15] publish.INFO: create_post.post_success {"wp_title":"[Please Ignore] Another test event","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}
[2022-02-21 08:10:15] publish.INFO: create_post.body_valid {"wp_title":"[Please Ignore] Another test event","wp_author_id":"3958","wp_post_id":126071,"discourse_post_id":""}
A postagem foi vinculada ao meu usuário no WordPress e ao usuário do sistema no Discourse na versão 2.3.8.
Você pode apenas confirmar algumas coisas para mim?
Seus tipos de postagem personalizados (ou seja, os eventos) estão sendo publicados no Discourse com sucesso?
Você nunca viu o erro 400 antes?
Que tipo de usuários (cujos nomes de usuário do Discourse você espera que sejam usados) estão publicando posts (ou seja, eles são administradores ou não)?
Que tipo de chave de API você está usando para conectar o WordPress ao Discourse?
Sim, as postagens estão sendo publicadas com sucesso, mas o usuário incorreto (sistema) está sendo atribuído com a v2.3.8
Não, não vimos nenhum erro 400 em nenhuma versão anterior do plugin wp-discourse.
Esses usuários são usuários registrados não administradores no WordPress e, até agora, funcionou para nós. Qualquer usuário foi corretamente vinculado no Discourse.
Estamos vendo o mesmo problema com a versão 2.3.9 e estamos voltando para a 2.3.7, desabilitando a atualização automática deste plugin daqui para frente.
Desculpe o incômodo, meu problema parece ter sido corrigido no WordPress 5.9.1 e WP Discourse 2.3.9
Mas, parece que o Discourse está agora a fazer algum trabalho extra em cada post publicado e a propriedade está a ser transferida do utilizador do Sistema para o utilizador que publica após o facto?
Olá @orenwolf, sinto muito que você ainda esteja com um problema. Você poderia confirmar que os usuários que você espera que publiquem em seu próprio nome têm um Nome de Usuário do Discourse no perfil do Wordpress?
Geralmente, pessoal, obrigado pela paciência. Em meus próprios testes em vários sites (e nos testes de unidade do próprio plugin), o recurso Nome de Usuário do Discourse agora está funcionando como esperado em 2.3.9. Se você ainda estiver com um problema, confirme se está na versão mais recente do plugin e se o usuário que você espera ser o autor da postagem tem um Nome de Usuário do Discourse.
Você pode estar se perguntando por que esse problema surgiu. Acho que será útil se eu der um pouco de contexto (que também responderá à sua pergunta @itsbhanusharma). Anteriormente, a maneira como esse recurso funcionava era usando usuários diferentes no cabeçalho Api-Username (veja aqui). A razão pela qual isso foi considerado necessário foi porque o endpoint relevante no Discourse não suporta a definição de um criador da postagem diferente do usuário que realiza a solicitação da API.
O resultado disso foi que a única maneira de esse recurso funcionar seria se você tivesse uma chave de API “Todos os Usuários” com um escopo “Global”. Apenas observo que, por algum tempo, as instruções padrão para criar uma chave de API para o plugin WP Discourse são as seguintes:
Se você ainda não criou uma chave de API, clique em ‘Nova Chave de API’, defina o Nível de Usuário como ‘Usuário Único’, defina ‘Usuário’ para uma conta de administrador, selecione ‘Chave Global’ e clique em ‘Salvar’. Copie e cole a chave de API aqui.
Seguir essas instruções significaria que esse recurso (não documentado) não funcionaria, e isso causou problemas para vários sites.
Além disso, por várias razões de segurança, tenho feito progressivamente alterações no plugin para permitir o uso de chaves de API muito mais específicas. Isso exigirá uma alteração no Discourse e (quando for mesclado) permitirá que os administradores do plugin emitam para si mesmos uma nova chave de API muito mais limitada. Farei um anúncio sobre isso quando chegar a hora.
Sim @itsbhanusharma, a maneira como o recurso funciona agora é fazendo uma segunda solicitação para alterar o proprietário da postagem após sua criação (se um Nome de Usuário do Discourse estiver presente). Essa é, na verdade, a única maneira adequada de definir arbitrariamente o proprietário de uma postagem via API do Discourse (sem precisar usar o Api-Username e uma Chave Global de Todos os Usuários da maneira descrita acima). Considerando o tipo de operação que é, isso não deve ser uma preocupação de desempenho.
Não é uma preocupação de desempenho, apenas um incômodo para explicar a pessoas menos experientes que o ícone de lápis no topo de sua postagem é normal e que é assim que vai ser.
Levará algum tempo, mas eventualmente nos acostumaremos com isso.
É um tanto desagradável que as postagens sejam mostradas como editadas, mas tudo bem, desde que tudo funcione.
No entanto, é um problema que as notificações estejam erradas. Elas mostram a nova postagem sendo criada pelo usuário do sistema.
Até agora, isso parece apenas uma solução improvisada, não uma solução. Certamente é um grande passo para trás não poder simplesmente postar como o usuário correto automaticamente. Não tenho certeza do que causou essa falha em primeiro lugar.
A versão curta é que tenho alterado lentamente a forma como o plugin lida com todas as suas solicitações ao Discourse por vários motivos, particularmente testes e segurança. O contexto completo e a justificativa para as alterações são muito longos para serem discutidos aqui. Agradeço que, no contexto desta funcionalidade em particular, possa parecer “se não está quebrado, não conserte”, no entanto, há um contexto mais amplo aqui.
Essas alterações estão ocorrendo há algum tempo (meses), no entanto, o motivo pelo qual estão vindo à tona agora é porque cometi um erro na versão 2.3.8. Então, incluí a alteração que deveria estar nessa versão na 2.3.9.
Dito isso, @jtbayly@itsbhanusharma, ouço o feedback de vocês sobre a abordagem diferente para esta funcionalidade em particular. Entendo que pode parecer um hack. Não é. No entanto, dado o feedback de vocês, adicionarei a maneira existente de volta ao plugin por trás de uma configuração que vocês podem usar, se desejarem (ela entrará em vigor na 2.4.0). Darei um acompanhamento com uma nota quando isso for mesclado nos próximos dias.
Espero poder remover essa abordagem inteiramente quando tiver abordado as questões que vocês dois levantaram, muito provavelmente com algumas alterações adicionais em discourse/discourse. Como mencionado, farei um anúncio maior sobre as alterações na forma como o plugin lida com as chaves de API no próximo mês (dependendo de quando as alterações forem mescladas em discourse/discourse), o que cobrirá aspectos disso.
Quando eu disse isso, foi para reconhecer que eu não tinha certeza se havia alguma outra maneira de seguir em frente. Não foi um comentário do tipo “por que você foi e quebrou isso!”.
Muito grato pelo seu trabalho em manter o plugin do WP funcionando com um core Discourse atualizado. E muito feliz que existam (provavelmente) mudanças futuras no core que permitirão melhorias nesta área.
