Collegamento di WP Discourse a un'istanza Discourse locale con una versione specifica

Ho appena provato a installare questo plugin su WordPress 6.7.2 con php-fpm-8.3.17-1.fc41.x86_64, ma non funziona. Ricevo il seguente errore nel log quando clicco su “Salva Opzioni”.

[2025-02-21 17:15:13] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"Una risposta non valida è stata restituita da Discourse","http_code":"","http_body":""} 

Ci sono errori corrispondenti in /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

Vedo che lo stesso errore viene segnalato nel “smoke test” su Report - WP-Discourse 2.5.9 - PluginTests.com.

Modifica: Lascia perdere l’errore url non definito. Sembra che fosse solo un errore iniziale da prima che il modulo web fosse completato. Tuttavia, continuo a ricevere ripetutamente il wpdc_response_error ogni volta che clicco sul pulsante Salva Opzioni.

Modifica2: Vedo un 403 forbidden dal lato discourse, ma non mi è chiaro perché la connessione dal mio sito WordPress venga bloccata. Posso usare la stessa chiave API con successo con curl.

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

Sto eseguendo Discourse 3.5.0.beta1-dev in modalità di sviluppo.

Modifica3: Ho scoperto che ci sono permessi WordPress speciali per la chiave API in questa versione di Discourse. Usare “Granulare” invece di “Globale” e selezionare le caselle sotto WordPress ha eliminato gli errori 403 Forbidden. Tuttavia, continuo a ricevere risposte vuote/non valide inviate a WordPress.

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

Suppongo che debba usare una versione precedente di Discourse con il plugin WordPress. Qual è l’ultima versione con cui funziona?

Ciao @Gregory_Bartholomew, vediamo se riusciamo a risolvere il tuo problema.

Funziona con l’ultima versione di Discourse.

Quando dici che stai eseguendo Discourse “in modalità di sviluppo”, intendi che lo stai eseguendo localmente? Se no, su quale ambiente lo stai eseguendo?

Prima di provare a usare una chiave con permessi granulari, potresti provare a usarne una globale come mostrato nel video nel primo post.

Grazie. Sto provando a reinstallare Discourse ora. Ho scaricato la versione 3.3.0 per testare.

Sto provando a installare Discourse localmente invece di usare il container Docker a causa di un bug in ZFS che impedisce al container Docker di compilare correttamente sui file system ZFS (pnpm issue 7024). Se installo Discourse localmente, posso aggirare il bug di ZFS aggiungendo package-import-method=hardlink a .npmrc prima di eseguire pnpm install.

Intendo che avevo RAILS_ENV=development. Ora proverò di nuovo con RAILS_ENV=production.

Inoltre, sto provando a rielaborare la guida che ho linkato sopra per farla funzionare su Fedora Linux.

Modifica: Non sto avendo molta fortuna con la versione 3.3.0.

$ pnpm install
 WARN  Il campo "workspaces" in package.json non è supportato da pnpm. Crea invece un file "pnpm-workspace.yaml".
 ERR_PNPM_INVALID_SELECTOR  Impossibile analizzare il selettore "**/unset-value"

Suppongo che riproverò con la 3.4.0 e vedrò come va. :confused:

Ho reinstallato Discourse alla versione 3.4.0:

Tuttavia, non sono riuscito a farlo funzionare in modalità di produzione. Non sono sicuro del perché. Diceva solo “Oops…” e non c’era molto che potessi vedere nei log. Penso che il problema potesse essere legato ad alcune impostazioni del proxy, ma non ne sono sicuro.

Comunque, ho reimpostato RAILS_ENV su “development” e ha funzionato. Tuttavia, sto ancora riscontrando lo stesso errore quando provo a connettermi da WordPress:

[2025-02-21 22:11:06] connection.INFO: check_connection_status.failed_to_connect {"error":"wpdc_response_error","message":"An invalid response was returned from Discourse","http_code":"","http_body":""}

Vedo però le query che raggiungono Discourse, quindi non capisco perché non funzioni.

GET "/site.json" for 000.123.456.789 at 2025-02-21 16:11:05 -0600
10:11 pm
Processing by SiteController#site as 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 in 256ms (Views: 0.3ms | ActiveRecord: 116.4ms (15 queries, 0 cached) | GC: 94.6ms)

Penso che mi prenderò una pausa da questo per un po’, ma se hai qualche idea su cosa potrebbe andare storto, apprezzerei qualche suggerimento. :slightly_smiling_face:

Ho spostato questa conversazione su un argomento indipendente poiché i problemi che stai riscontrando potrebbero confondere altre persone che utilizzano configurazioni standard.

Ok, per riassumere:

  1. Stai eseguendo Discourse sulla tua macchina locale.
  2. Stai eseguendo versioni specifiche. Attualmente stai eseguendo la 3.4.0.
  3. Stai cercando di connettere la tua istanza locale a un’istanza remota di WordPress.

Qualcosa di tutto ciò è errato? Inoltre, potresti chiarire quanto segue:

  1. Come ti stai connettendo all’istanza remota di WordPress dalla tua macchina locale? Stai usando ngrok?
  2. Perché stai eseguendo versioni specifiche di Discourse invece dell’ultima versione?
  3. Qual è il tuo obiettivo generale qui?
2 Mi Piace

Sì.

Sì.

Anche la mia istanza di test WordPress è in esecuzione in locale.

No, è tutto locale. Ho due istanze di httpd in esecuzione e in ascolto su indirizzi IP diversi (una per WordPress e l’altra per Discourse). L’istanza WordPress è in esecuzione direttamente sul mio sistema host e l’istanza Discourse è in esecuzione in un container systemd-nspawn. Sia il sistema host che il container eseguono Fedora Linux 41.

Inizialmente ho provato l’istanza Docker, ma non si compilava sulla mia macchina di test. La ricerca del messaggio di errore mi ha portato a un bug report aperto che indicava che il problema era con il filesystem ZFS. Non so come modificare l’immagine Docker per applicare la soluzione, quindi ho trovato istruzioni per clonare il repository sorgente e compilare Discourse con esso.

Inizialmente ho compilato l’ultima versione (3.5.0.beta1-dev), ma il comportamento sembrava diverso da quello che mostrava il tuo video. Vedevo 403 Forbidden nei log di Discourse quando WordPress tentava di connettersi con la chiave API (quando i permessi erano impostati su “Globale”). Modificando i permessi in “Granulare” e selezionando tutte le caselle per WordPress, le query procedevano ulteriormente, ma WordPress riceveva risposte vuote/non valide. Ho quindi notato su https://blog.discourse.org/ che l’ultima versione promossa era la 3.4, quindi ho concluso che alcuni dei problemi che stavo riscontrando potrebbero essere dovuti al fatto che stavo cercando di eseguire una pre-release. Ho provato git checkout v3.3.0 pensando che fosse abbastanza vecchia da essere completamente compatibile con il plugin WordPress che sto cercando di testare, ma non si compilava sul mio sistema, quindi ho effettuato il checkout della versione 3.4.0 e sembra che funzioni (sebbene in modalità “sviluppo”).

In realtà voglio solo sperimentare e familiarizzare con il plugin WordPress Discourse. Non mi interessa affatto Discourse. Ho solo bisogno di qualcosa contro cui testare. Una volta che sarò a mio agio con il funzionamento, potrei provare a installare il plugin su un sito di produzione (fedoramagazine.org) e reindirizzare i commenti all’istanza Discourse di produzione su discussion.fedoraproject.org.

1 Mi Piace

Questa è la cosa più triste che abbia mai letto su questo forum! :lolsob:

1 Mi Piace

Il problema avrà a che fare con la tua configurazione locale e la tua rete. Non sarà dovuto alla versione di Discourse, né alla differenza tra chiavi globali e granulari. Mi sarà difficile eseguire il debug dei problemi di interconnessione della tua app locale, in particolare a causa della varietà di modi e ambienti in cui puoi eseguire sia Wordpress che Discourse localmente. Ecco alcuni suggerimenti per aiutarti.

  1. Esegui sempre l’ultima versione di Discourse, Wordpress e del plugin WP Discourse.
  2. Usa la porta 3000 invece della porta 4200 nell’URL Discourse locale in WP Discourse.
  3. Assicurati che la chiave che crei possa essere utilizzata dall’username dell’amministratore che hai impostato come Publishing Username.

Questo è ciò che appare la mia configurazione locale con il mio Wordpress e Discourse locali collegati tra loro. Uso MAMP Pro per eseguire Wordpress localmente.


3 Mi Piace

Ha funzionato!!!

Grazie per il suggerimento di connettersi direttamente alla porta 3000. Sembra che sia questo che ha fatto la differenza.

Una cosa da notare (almeno nella mia configurazione locale) è che ho anche dovuto impostare ALLOW_EMBER_CLI_PROXY_BYPASS=1 prima di avviare ember-cli.

3 Mi Piace