Un utente ha chiesto informazioni su Developing with WordPress di Wordpress

WordPress DevOps – Ambienti

Un utente ha chiesto 👇

Ciao,

nella mia azienda vogliamo utilizzare WordPress su Docker. Il nostro obiettivo è fornire un ambiente “stage” in cui gli utenti / editor possono apportare modifiche, aggiornare plugin / temi, scrivere pagine / articoli, ecc….

Vogliamo dare una “panoramica” della versione in scena e utilizzarla nell’ambiente di produzione, dove vogliamo disabilitare l’area wp-admin (per motivi di sicurezza).

Questo può sembrare a me, ma stiamo affrontando un problema con la gestione dei plugin. Per la fase e la produzione, il database può essere molto vario e sappiamo tutti che WP salva i percorsi completi, quindi dobbiamo sostituire il dominio.

Il problema è che le impostazioni del plug-in possono risiedere in tabelle diverse poiché non tutti i plug-in salvano le cose in wp_option. Quindi il problema è capire come vengono apportate le modifiche ai plug-in sullo stage e distribuirle per selezionare la produzione senza costruire tutto il DB.

C’è qualche esperienza di questa situazione disponibile nella comunità?
Qualcuno ha provato ad avere più ambienti con Worpdress su Docker?
Stiamo usando Rancher per l’orchestra.

(@bcworkz)

2 anni, 9 mesi fa

Non ho familiarità con Docker oltre a sapere di cosa si tratta. Ma forse la mia esperienza ti ispirerà a trovare una soluzione simile all’interno di Docker. Sviluppo spesso su localhost. In modo che non sia necessario modificare tutti gli URL nella SS durante l’esportazione sul server dell’host di destinazione, inserisco il dominio di destinazione nel file dell’host locale. Per WP, è già su quel dominio e tutti gli URL sono corretti. L’unico inconveniente è che posso accedere al sito reale del dominio solo tramite un indirizzo IP.

Spero che Docker abbia un meccanismo simile per gli alias di dominio che puoi utilizzare. Nei casi in cui gli URL devono ancora essere modificati nel DB quando si spostano i siti, mi affido all’interconnessione / sì Cerca e sostituisci attrezzo. Hai ragione, non si sa dove i diversi moduli inseriranno gli URL. Questo strumento è abbastanza buono per trovarli tutti. L’unica volta che ha fallito è stato un tema che memorizzava URL con codifica base64! Non riesco nemmeno a immaginare perché lo abbiano fatto.

Ho diverse installazioni WP sul sito locale. Il mio file root .htaccess pubblico reindirizza il traffico alla sottocartella corretta in base all’alias di dominio richiesto. Non era affatto un problema. La sottocartella sembra essere la radice pubblica del dominio.

Spero che questo ti dia alcune idee su cosa fare con Docker.

Lanciatore di thread

(@jahanzaibasharat)

2 anni, 9 mesi fa

Grazie per il feedback. Le tue soluzioni coprono la parte URL del problema, ma ho bisogno di affrontare gli ambienti (dev, stage, prod). In questo contesto cerco consigli, esperienze …

(@jointbyte)

2 anni, 9 mesi fa

Consiglio vivamente di stare lontano da qualsiasi tipo di flusso (ad esempio: Docker), il che significa che c’è un notevole divario di tempo tra un plugin che viene aggiornato da un fornitore e implementato sul tuo sito web. Soprattutto in produzione, considerando quanto possono essere importanti le patch di sicurezza.

I dati vengono memorizzati in tutti i modi (come hai notato sopra con la tabella delle opzioni, ce ne sono anche molti altri da nominare!)

Se il tuo obiettivo è distribuire dal tuo ambiente di sviluppo alla fase, o passare dalla fase alla produzione, allora puoi seguire quale processo non ha mai più senso per te. Detto questo, il mio team tende a fare quanto segue quando crea soluzioni basate su WordPress:
– Creiamo i nostri ambienti di sviluppo, stage e lancio da un’installazione WordPress vuota.
– Manteniamo sempre aggiornati i plugin utilizzando l’autoupdater integrato in WordPress. Nel momento in cui notiamo che un plug-in può essere aggiornato, lo faremo.
– Installiamo plugin personalizzati con FTP e ogni volta che uno dei nostri sviluppatori si aggiorna, sono responsabili della prima fase di aggiornamento e dell’aggiornamento della produzione non appena hanno testato le modifiche.
– Per l’importazione e l’esportazione dei dati, di solito utilizziamo pratiche integrate: https://codex.wordpress.org/Tools_Export_Screen
– Per quanto sopra (importazione / esportazione di dati), a condizione che i tuoi sviluppatori utilizzino correttamente l’API di WordPress, dovresti essere a posto. Se i tuoi sviluppatori creano tabelle che non richiedono cose come i normali tipi di lavoro, potresti voler scuotere il dito contro di loro per rendere il tuo lavoro molto più difficile.
– Se abbiamo bisogno di modificare un plugin che non è il nostro, usiamo WordPatch per patchare e chiamarlo un giorno. Ogni volta che WordPress aggiorna uno o più plugin, la patch viene riapplicata e non dobbiamo preoccuparci di perdere le nostre modifiche.

Spero che questo aiuti.

Was this helpful?

0 / 0

Lascia un commento 0

Your email address will not be published. Required fields are marked *