Conectando WP Discourse a uma Instância local do Discourse rodando uma versão específica

Dev
1

Acabei de tentar instalar este plugin no WordPress 6.7.2 com php-fpm-8.3.17-1.fc41.x86_64, mas não funciona. Recebo o seguinte erro no log quando clico em “Salvar Opções”.

[2025-02-21 17:15:13] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Uma resposta inválida foi retornada do Discourse","http_code":"","http_body":""}

Existem erros correspondentes em /var/log/php-fpm/www-error.log:

[21-Feb-2025 17:14:42 UTC] PHP Warning:  Undefined array key "url" in /wordpress/wp-content/plugins/wp-discourse/lib/discourse.php on line 301

Vejo que o mesmo erro está sendo relatado no “teste de fumaça” em Report - WP-Discourse 2.5.9 - PluginTests.com.

Editar: Deixe para lá o erro de url indefinida. Parece que foi apenas um erro inicial de antes de o formulário da web ser preenchido. No entanto, ainda estou recebendo o wpdc_response_error repetidamente, toda vez que clico no botão Salvar Opções.

Editar2: Estou vendo um 403 forbidden no lado do discourse, mas não está claro para mim por que a conexão do meu site WordPress está sendo proibida. Posso usar a mesma chave de API com sucesso com curl.

Completed 403 Forbidden in 33ms (Views: 0.3ms | ActiveRecord: 15.1ms (2 queries, 0 cached) | GC: 2.2ms)

Estou executando o Discourse 3.5.0.beta1-dev em modo de desenvolvimento.

Editar3: Descobri que existem permissões especiais do WordPress para a chave de API nesta versão do Discourse. Usar “Granular” em vez de “Global” e marcar as caixas em WordPress removeu os erros 403 Forbidden. No entanto, ainda estou recebendo respostas vazias/inválidas enviadas para o WordPress.

Delivering messages [] to client d9fbb33f11ed404bbc361c459802c87d for user 1 (chunked)

Acho que preciso usar uma versão mais antiga do Discourse com o plugin do WordPress. Qual é a versão mais recente com a qual ele funciona?

2

Olá @Gregory_Bartholomew, vamos ver se conseguimos resolver seu problema.

Funciona com a versão mais recente do Discourse.

Quando você diz que está executando o Discourse “em modo de desenvolvimento”, você quer dizer que está executando localmente? Se não, em qual ambiente você o está executando?

Antes de tentar usar uma chave com permissões granulares, você poderia tentar usar uma chave global, como mostrado no vídeo na primeira postagem.

3

Obrigado. Estou tentando reinstalar o Discourse agora. Baixei a versão 3.3.0 para teste.

Estou tentando instalar o Discourse localmente em vez de usar o contêiner Docker devido a um bug no ZFS que impede a construção bem-sucedida do contêiner Docker em sistemas de arquivos ZFS (pnpm issue 7024). Se eu instalar o Discourse localmente, posso contornar o bug do ZFS adicionando package-import-method=hardlink ao .npmrc antes de executar pnpm install.

Quero dizer que tive RAILS_ENV=development. Vou tentar novamente com RAILS_ENV=production agora.

Além disso, estou tentando refazer o guia que linkei acima para funcionar no Fedora Linux.

Editar: Não estou tendo muita sorte com a versão 3.3.0.

$ pnpm install
 WARN  O campo "workspaces" em package.json não é suportado pelo pnpm. Crie um arquivo "pnpm-workspace.yaml" em vez disso.
 ERR_PNPM_INVALID_SELECTOR  Não é possível analisar o seletor "**/unset-value"

Acho que vou tentar novamente com a versão 3.4.0 e ver como isso vai. :confused:

4

Bem, reinstalei o Discourse na versão 3.4.0:

image
image1086×447 32.2 KB

No entanto, não consegui fazê-lo funcionar em modo de produção. Não tenho certeza do porquê. Apenas dizia “Oops…” e não havia muito que eu pudesse ver nos logs. Acho que o problema pode ter sido algo relacionado a algumas configurações de proxy, mas não tenho certeza.

De qualquer forma, redefini o RAILS_ENV para “development” e ele iniciou. No entanto, ainda estou recebendo o mesmo erro ao tentar me conectar do WordPress:

[2025-02-21 22:11:06] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Uma resposta inválida foi retornada do Discourse","http_code":"","http_body":""}

No entanto, consigo ver as consultas chegando ao Discourse, então não entendo por que não está funcionando.

GET "/site.json" para 000.123.456.789 em 2025-02-21 16:11:05 -0600
10:11 pm
Processando SiteController#site como JSON
10:11 pm
ApiKey Load (9.0ms) SELECT "api_keys".* FROM "api_keys" WHERE (revoked_at IS NULL) AND "api_keys"."key_hash" = '3f27a89fedae42123b9ad596fae6c06d36748f53bd241213941083af49cf5e46' ORDER BY "api_keys"
10:11 pm
ApiKeyScope Load (10.6ms) SELECT "api_key_scopes".* FROM "api_key_scopes" WHERE "api_key_scopes"."api_key_id" = 1
10:11 pm
User Load (8.1ms) SELECT "users"."id", "users"."username", "users"."created_at", "users"."updated_at", "users"."name", "users"."last_posted_at", "users"."active", "users"."username_lower", "users".
10:11 pm
UserOption Load (6.1ms) SELECT "user_options"."user_id", "user_options"."mailing_list_mode", "user_options"."email_digests", "user_options"."external_links_in_new_tab", "user_options"."enable_quoti
10:11 pm
Group Load (8.6ms) SELECT "groups"."id", "groups"."name", "groups"."flair_icon", "groups"."flair_upload_id", "groups"."flair_bg_color", "groups"."flair_color" FROM "groups" ORDER BY groups.name ASC
10:11 pm
(7.0ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = FALSE
10:11 pm
(10.7ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."read_restricted" = TRUE
10:11 pm
Topic Count (4.1ms) SELECT COUNT(*) FROM (SELECT 1 AS one FROM "topics" WHERE "topics"."deleted_at" IS NULL LIMIT 16) subquery_for_count
10:11 pm
(6.1ms) SELECT "users"."id" FROM "users" INNER JOIN "user_auth_tokens" ON "user_auth_tokens"."user_id" = "users"."id" WHERE "users"."admin" = TRUE AND (users.id > 0) ORDER BY user_auth_tokens.crea
10:11 pm
(8.5ms) SELECT "categories"."id" FROM "categories" WHERE "categories"."topic_featured_link_allowed" = TRUE
10:11 pm
ColorScheme Load (6.8ms) SELECT "color_schemes".* FROM "color_schemes" WHERE (color_schemes.id NOT IN (SELECT color_scheme_id FROM theme_color_schemes)) AND "color_schemes"."id" = 1 LIMIT 1
10:11 pm
ColorSchemeColor Load (7.8ms) SELECT "color_scheme_colors".* FROM "color_scheme_colors" WHERE "color_scheme_colors"."color_scheme_id" = 1 ORDER BY id ASC
10:11 pm
(6.0ms) SELECT "group_users"."group_id" FROM "group_users" WHERE "group_users"."user_id" = -1
10:11 pm
(8.0ms) SELECT "category_users"."category_id", "category_users"."notification_level" FROM "category_users" WHERE "category_users"."user_id" = -1
10:11 pm
UserField Load (9.5ms) SELECT "user_fields"."id", "user_fields"."name", "user_fields"."created_at", "user_fields"."updated_at", "user_fields"."editable", "user_fields"."description", "user_fields".
10:11 pm
Completed 200 OK em 256ms (Views: 0.3ms | ActiveRecord: 116.4ms (15 queries, 0 cached) | GC: 94.6ms)

Acho que vou fazer uma pausa nisso por um tempo, mas se você tiver alguma ideia sobre o que pode estar dando errado, agradeceria algumas dicas. :slightly_smiling_face:

5

Movi esta conversa para um tópico independente, pois os problemas com os quais você está lidando podem confundir outras pessoas que executam configurações padrão.

Ok, então, para recapitular:

  1. Você está executando o Discourse em sua máquina local.
  2. Você está executando versões específicas. Atualmente, você está executando a 3.4.0.
  3. Você está tentando conectar sua instância local a uma instância remota do WordPress.

Algum desses pontos está incorreto? Além disso, você poderia esclarecer o seguinte:

  1. Como você está se conectando à instância remota do WordPress a partir de sua máquina local? Você está usando ngrok?
  2. Por que você está executando versões específicas do Discourse em vez da versão mais recente?
  3. Qual é o seu objetivo geral aqui?
2 curtidas
6

Sim.

Sim.

Minha instância de teste do WordPress também está sendo executada localmente.

Não, tudo está local. Tenho duas instâncias do httpd em execução e escutando em endereços IP diferentes (uma para o WordPress e outra para o Discourse). A instância do WordPress está sendo executada diretamente no meu sistema host e a instância do Discourse está sendo executada em um contêiner systemd-nspawn. Tanto o sistema host quanto o contêiner estão executando o Fedora Linux 41.

Inicialmente, tentei a instância Docker, mas ela não compilou em minha máquina de teste. Pesquisar a mensagem de erro me levou a um relatório de bug aberto indicando que o problema era com o sistema de arquivos ZFS. Não sei como modificar a imagem Docker para aplicar a solução alternativa, então encontrei instruções para clonar o repositório de origem e compilar o Discourse com isso.

Inicialmente, compilei a versão mais recente (3.5.0.beta1-dev), mas o comportamento parecia diferente do que seu vídeo estava mostrando. Eu via 403 Forbidden nos logs do Discourse quando o WordPress tentava se conectar com a chave de API (quando as permissões estavam definidas como “Global”). Alterar as permissões para “Granular” e marcar todas as caixas para o WordPress permitia que as consultas prosseguissem, mas o WordPress recebia respostas vazias/inválidas. Em seguida, notei em https://blog.discourse.org/ que a versão mais recente promovida era a 3.4, então concluí que alguns dos problemas que eu estava encontrando poderiam ter sido porque eu estava tentando executar uma pré-lançamento. Tentei git checkout v3.3.0 pensando que seria antiga o suficiente para ser totalmente compatível com o plugin do WordPress que estou tentando testar, mas ela não compilou no meu sistema, então fiz o checkout da versão 3.4.0 e isso parece estar funcionando (embora em modo “development”).

Na verdade, eu só quero experimentar e me familiarizar com o plugin Discourse para WordPress. Eu realmente não me importo com o Discourse. Eu só preciso de algo para testar. Assim que eu me sentir confortável com o funcionamento de tudo, talvez eu tente instalar o plugin em um site de produção (fedoramagazine.org) e redirecionar os comentários para a instância de produção do Discourse em discussion.fedoraproject.org.

1 curtida
7

Essa é a coisa mais triste que já li neste fórum! :lolsob:

1 curtida
8

O problema terá a ver com a sua configuração local e rede. Não será devido à versão do Discourse, nem à diferença entre chaves globais e granulares. Será difícil para mim depurar os problemas de interconexão da sua aplicação local, especialmente devido à variedade de formas e ambientes em que pode executar o WordPress e o Discourse localmente. Aqui ficam algumas dicas para o ajudar.

  1. Execute sempre a versão mais recente do Discourse, do WordPress e do plugin WP Discourse.
  2. Utilize a porta 3000 em vez da porta 4200 no URL do Discourse local no WP Discourse.
  3. Certifique-se de que a chave que cria pode ser utilizada pelo nome de utilizador administrador que definiu como Nome de Utilizador de Publicação.

Este é o aspeto da minha configuração local com o meu WordPress e Discourse locais ligados um ao outro. Utilizo o MAMP Pro para executar o WordPress localmente.

Screenshot 2025-02-23 at 15.16.46
Screenshot 2025-02-23 at 15.16.461920×1203 134 KB

Screenshot 2025-02-23 at 15.17.00
Screenshot 2025-02-23 at 15.17.002940×1188 302 KB

3 curtidas
9

Funcionou!!!

image
image573×158 8 KB

Obrigado pela dica de conectar diretamente à porta 3000. Isso parece ter feito a diferença.

Uma coisa a notar (pelo menos na minha configuração local) é que eu também precisei definir ALLOW_EMBER_CLI_PROXY_BYPASS=1 antes de iniciar o ember-cli.

proxy-bypass
proxy-bypass794×257 30.1 KB

3 curtidas