Sto esplorando la possibilità di creare un forum condiviso per due siti web separati, il mio blog e il mio portfolio. Il concetto è avere un unico database del forum che serva entrambi i siti, consentendo agli utenti e agli argomenti di essere condivisi tra le due community. Tuttavia, vorrei che il forum fosse stilizzato diversamente a seconda del sito che l’utente sta visitando, in modo che ogni community si senta distinta pur facendo parte di uno spazio condiviso più ampio.
Ho un background nello sviluppo web, anche se non lavoro su un progetto importante come questo da un po’ di tempo. Sono disposto a immergermi di nuovo e imparare ciò che è necessario per far funzionare questo progetto, ma apprezzerei una guida sulla fattibilità con Discourse.
Nello specifico, mi chiedo:
Discourse supporta temi o stili distinti in base al dominio o all’URL di riferimento?
È possibile configurare Discourse per visualizzare branding personalizzati (loghi, colori, ecc.) mantenendo un database utenti e un pool di argomenti condivisi?
Esistono plugin o estensioni che potrebbero facilitare l’implementazione?
Qualche consiglio su sfide o limitazioni da considerare quando si persegue questo tipo di configurazione?
Questo progetto è ancora in fase concettuale e ho in programma di iniziare la costruzione verso la fine dell’anno. Voglio assicurarmi che Discourse sia la piattaforma giusta per questa visione prima di impegnarmi.
Grazie in anticipo per qualsiasi intuizione, suggerimento o risorsa che potete fornire!
Non mi è ancora molto chiaro.
Quindi il dominio a punta al forum e il dominio b punta allo stesso forum/a un forum diverso con lo stesso database? Se è così, forse un forum diverso con lo stesso database? Allora lo stile può essere diverso.
Facendo una rapida ricerca qui non sono sicuro che potrebbe essere fatto troppo facilmente.
Un percorso forse più semplice potrebbe essere usare un interruttore collegato al gruppo primario e avere 2 gruppi che passando dal gruppo A al gruppo B cambiano i temi e magari usano qualcosa come il componente Theme component Pagina iniziale personalizzata per i gruppi? O forse usa Modern Category+group boxes installati due volte (usati nel tema air) con personalizzazioni basate sul tema/gruppo primario
Anche se non lo so da solo. Mi chiederei se avere 2 installazioni di discourse potrebbe rischiare di corrompere il database? Sebbene alcuni abbiano siti di staging, ma penso che il sito di staging venga regolarmente sottoposto a backup da quello principale?
Quindi, se un utente apre il sito A, va al forum dal sito A, viene applicato il tema A.
Quindi lo stesso utente apre il sito B, va al forum dal sito B e vede il tema B?
Cosa succede se all’utente viene applicato il tema A, va al sito B e aggiorna la pagina del forum? Viene applicato il tema B o viene mantenuto il tema A?
La mia ipotesi è che tu possa eseguire più motori (installazioni di Discourse) sulla stessa base di dati (quindi hai bisogno di un database separato). Eseguirei solo 1 sidekiq, però. Altrimenti due di loro inizierebbero a litigare per i lavori. Per il resto penso che Discourse sia un’app stateless, quindi non dovrebbe importare quanti ne stai eseguendo.
Ora una domanda alla radice di tutto il problema: Perché? E non è contro le regole SEO? Penso che Google non gradisse se trovasse lo stesso contenuto su più siti.
In realtà, alcune cose potrebbero non funzionare come previsto, ad esempio gli aggiornamenti dell’interfaccia utente in tempo reale (se qualcuno aggiornasse un articolo in modo che si riproduca magicamente mentre lo stai leggendo). Penso che i due siti non si direbbero nulla, quindi dovresti fare affidamento sull’utente che aggiorna il proprio browser. Potrebbe esserci altro. Come se cambiassi le impostazioni del sito su un sito, immagino che anche l’altro sito non se ne accorgerebbe e potresti dover riavviare l’altro.
Basandomi su Scaling up and sidekiq, mi sembra che questo sia effettivamente risolvibile. Sidekiq sembra gestirlo e il resto sarebbe una questione di configurare correttamente Redis.
È un po’ fuori tema e non voglio deviare la conversazione, ma vorrei aggiungere il mio semplice apprezzamento.
Penso che siamo in un’era di internet in cui bisogna pensare alla SEO o ai propri utenti.
E non ho dubbi che Discourse self-hosted sarà utilizzato da coloro che scelgono i propri utenti.
Stavo cercando questa funzionalità perché ho progetti personali con lo stesso pubblico e target. Multisite con SSO era la cosa più vicina ma non sono arrivato da nessuna parte perché è lento e non conveniente.
Discourse non è stateless e tutte le informazioni sono nel database. Quindi, se esegui più istanze sopra un singolo database, esse apparirebbero automaticamente uguali e le modifiche in una si rifletterebbero immediatamente nell’altra.
Si tratterebbe “solo” di cambiare temi. Forse sfruttare la logica esistente di anteprima dei temi e far sì che un plugin guardi solo il nome host invece del parametro URL.
Ospitare lo stesso forum sotto due URL potrebbe essere la parte più difficile qui, specialmente per quanto riguarda la SEO. Ti porterebbe in tutti i tipi di problemi di contenuto duplicato e URL canonici.
Puoi chiarire questo punto? Sarebbe davvero interessante sapere un po’ di più su come funziona. Penso che le tue due frasi si contraddicano? Penso che riflettere tutto sia in realtà ciò che l’OP ha chiesto. Ma come potrebbe accadere se l’altra istanza non viene notificata di una modifica apportata dalla prima istanza? È memorizzato nel database, sì, ma non c’è nessuna notifica.
Quindi, solo un db = stateless. Ogni volta che fai una richiesta, chiedi di nuovo al database - non c’è stato in memoria. O c’è?
Altrimenti, mi piace molto l’idea di un plugin. Concordo sul fatto che questa sarebbe la strada da percorrere e penso ancora che la SEO non sia qualcosa che si sceglie di fare, ma in qualche modo si deve fare per ottenere un pubblico. La duplicazione sarebbe un modo per realizzarla. Anche dal punto di vista dell’utente potrebbe essere sospetto se vedessi qualcosa che ho scritto su un sito, magari collegato su un altro sito di cui non avevo idea, sarei davvero turbato. La duplicazione dei contenuti è tipicamente un metodo utilizzato da siti di bassa qualità. Ecco perché ottiene un declassamento SEO. Ma questo sarebbe più un argomento per la categoria Community.
Penso che qui ci sia una confusione di definizioni. Il codice lato server di Discourse è (in un certo senso*) stateless, ma l’intera istanza di Discourse (client web, codice lato server, Redis, file memorizzati nella cache, database) non lo è.
L’altra faccia della medaglia è che - dato che il codice lato server è stateless - questa configurazione non può realizzare ciò che l’OP desidera, poiché non c’è un posto dove memorizzare le informazioni su quale URL e tema debbano essere serviti. La configurazione che stai descrivendo è in realtà ciò che accade in una configurazione di bilanciamento del carico in cui ci sono più contenitori web e una singola istanza di database/Redis. È un sito singolo.
* Dico “in un certo senso” perché ci sono molti livelli di caching in vari posti
Capisco. Anche l’URL del sito principale è memorizzato nel database? Quindi non è una questione di configurazione dell’istanza locale? In tal caso sarebbe chiaro che entrambe le istanze tenterebbero comunque di servire la stessa cosa.
E hai ragione sul fatto che la configurazione a due server non aiuta comunque Discourse a scegliere il tema giusto.
Ora mi ricordo che ci sarebbe anche un problema con il contenuto. Se incolli un link in Discourse, questo pubblica l’intero URL. Quindi qualcuno che legge un argomento scritto dall’altro sito verrebbe indirizzato lì quando clicca su un link. Lo stesso vale per i caricamenti, vedi Uploads Path Should Update When URL Changes in app.yml During Container Rebuild.
Un altro problema potrebbero essere le e-mail? Da quale dominio verrebbero inviate le e-mail di notifica? Un altro problema: i plugin social (Facebook ecc.) o il login di Google reindirizzerebbero a un sito errato (o forse rifiuterebbero l’accesso).
Arrivando inaspettatamente, una soluzione molto più semplice sarebbe avere un’unica istanza con 2 categorie: una per ciascuno dei siti padre. Questo aggirerebbe tutti i problemi menzionati sopra.
C’è ampio spazio per stilizzare categorie e argomenti all’interno di quella categoria tramite semplice CSS utilizzando la classe category-category_slug.
Se si desidera rendere uno o l’altro il ‘predefinito’ o la home per un gruppo di utenti, allora Custom Homepage for Groups sarebbe lo strumento di cui hai bisogno.
