Migratie (WordPress)

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Hoe migreer je een bestaande WordPress-site naar een andere locatie? Bv. van ontwikkelomgeving naar productie-omgeving? Kan dit mbv. de CLI?

Wat ik meestal zoek

  1. Bronlocatie: Maak een databasedump
  2. Bronlocatie: Zet de site in onderhoudsmodus
  3. Kopiëer alle bestanden naar de doellocatie
  4. Doellocatie: Importeer de database
  5. wp-config.php; Werk db-string bij
  6. Controleer wp-config.php op hard-coded site-URL's
  7. Indien mogelijk: Bekijk met MySQL Workbench of mysql-client in tabel wp_options wat precies de oude URL is
  8. wp search-replace oudeurl nieuweurl
  9. Browser: Wis afgelopen uur - Ctrl-Shift-Del in Firefox
  10. Configureer force direct download, Zet define('FS_METHOD', 'direct'); in wp-config.php Update WordPress-installatie

Extra

  • Instellingen UpdraftPlus bijwerken?
  • https configureren?

Blijft-ie terugspringen naar de oude URL?

  • Controleer tabel wp_options - Is de URL correct aangepast?

Inventaris

  • WordPress kent iets dat WXR-bestanden heet. Daar heb je oa. een plugin voor, en bijbehorende wp cli-commando's. Maar dit betreft vermoedelijk de migratie van content, en niet van complete sites. [1], [2]
  • De Codex-hoofdpagina lijkt te suggereren dat je nooit vanuit WordPress zelf een db-backup kunt maken, maar dat je dat altijd extern moet doen [3]
  • Het lijkt erop, dat dit voornamelijk handwerk is [4]
  • Duplicator is een migratie-plugin. Ziet er indrukwekkend uit.

Migratie & CLI

Dit artikel laat zien dat gemakkelijk kan via bash. In het voorbeeld hieronder migreer ik example.com van de ontwikkelomgeving (=mijn laptop) naar een VPS.

Bronlocatie 

cd /var/www/example.com

# db-export
###########
#
mysqldump <db_name> > export_bestand.sql

# Kopiëer naar VPS
##################
#
# Inpakken is niet nodig: Het gaat snel genoeg. "in1" is een map voor binnenkomende bestanden
#
scp -r * vps12:in1

Doellocatie

  • Domeinnaam aanmaken
  • Database aanmaken
  • cd /var/www/example.com
  • mv ~in1/* .
  • mysql example_database < db_dump.sql
  • Nieuwe database-credentials invoeren in wp-config.php
  • Search-&-replace - Test: wp search-replace example.com newexample.com --dry-run
  • Search-&-replace - Echt: wp search-replace example.com newexample.com
  • SQL-bestanden opruimen in ~/in1 en example.com
  • Maprechten bijwerken?

Gebruikerslocatie

Cash legen. Op Firefox kan dat met de toetscombinatie Ctrl-Shift-Del.

Migratie van https naar http

Wanneer ik een site verhuis van productie- naar ontwikkelomgeving, houdt dat vaak ook een verhuizing van https naar http in. Het lijkt erop, dat de procedure precies hetzelfde is. Zie ook SSL & WordPress.

Storingen db-import

Oorzaak: Server-versie = 5.5, werstation-versie = 5.7. Zie Upgrade MySQL voor de oplossing.

Archiefbestand in gebruik nemen - Een lijstje

Dit betreft een situatie waarin ik een backup van een site kreeg als een archiefbestand, inclusief een backup van de databae.

  • Db-connection string aanpassen in wp-config.php
  • Variabelen WP_HOME en WP_SITEURL aanpassen in wp-config.php:
define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');
  • Inloggen in admin-account
  • .htaccess-bestanden aanpassen?
  • Browsercache legen ivm. eventuele redirects!!!

Een lijstje dat ik van iemand kreeg:

  • database inladen
  • aanpassen van wp-config file naar je lokale database
  • database strings aanpassen naar je lokale url
  • inloggen
  • permalinks Resetten. Kwestie van gewoon een keer de permalinks instellingen opslaan.
  • daarna zou je de taal van wordpress kunnen aanpassen.

... Wordt vervolgd.

Casus: Archiefbestand in gebruik nemen (maart 2017)

  • Bestanden & database verplaatst
  • wp-config.php: db-string, wp_home & wp_siteurl aangepast
  • Ingelogd in wp-admin
  • Permalinks paar keer ververst (Settings » Permalinks) - Ze stonden al goed
  • Browsercache geleegd - Dit bleek cruciaal te zijn
  • Site bezocht - Klaar.

Casus: Archiefbestand in gebruik nemen (april 2017)

  • Bestanden & database verplaatst
  • wp-config.php: Database-string aangepast
  • wp-config.php: wp_home & wp_siteurl toegevoegd: Ze stonden er nog niet in, maar de site redirecte wel steeds naar de oorspronkelijke locatie
  • Bestandsrechten fixen map backup-guard ivm. foutmelding SGExceptionForbidden: Permission denied. Directory is not writable: /var/www/example.com/wp-content/uploads/backup-guard/
  • Inloggen in wp-admin

Casus: Site klonen & redirects (okt. 2017)

Betreft klonen van een site van test1.example.com naar test2.example.com. Er was een probleem met redirecting: Hij bleef naar de oude site terugkeren:

  • Bestanden & database geklooned
  • In wp-config.php database-string aangepast
  • wp search-replace test1.example.com test2.example.com - Site bleef redirecten van test2.example.com naar test1.example.com
  • Browsercache geleegd (gewoon alles van het afgelopen uur verwijderd) - Probleem opgelost.

Casus: MySQL-fouten (okt. 2017)

Het bleek dat de ontwikkelomgeving een nieuwere versie van MySQL heeft, dan de externe testversie. Oplossing: 

cd /var/www/example.com

# db-export & aanpassen
#######################
#
# * Dankzij "cd"-commando hierboven, belandt sql-dump in root van installatie - Da's handig!
# * Mysqldump gebruiken in compatibiliteitsmodus
# * Dump aanpassen: Find & replace: "TYPE=InnoDB" vervangen door "Engine=InnoDB"
#
mysqldump --compatible=mysql4 <db_name> > export_bestand.sql

Casus: Site schakelt steeds naar https (nov. 2017)

Een site is geklooned naar http://example.com. Als ik 'm oproep, springt-ie gelijk naar https://example.com (dus met de -s- van secure). Ook http://example.com/wp-admin doet hetzelfde.

Oplossing: Op database-niveau in tabel wp_options de waardes voor siteurl en home aanpassen. Klaar.

Casus: Migratie https naar http (mei 2018)

Toepassing wp search-replace waarbij oa. siteurl en home worden aangepast - Oude situatie
Toepassing wp search-replace waarbij oa. siteurl en home worden aangepast - Nieuwe situatie

Dit betreft een migratie van een productie- naar een ontwikkelomgeving, waarbij de productie https was, en de ontwikkelomgeving http.

Acties:

Casus: js_composer ontbreekt na migratie (sep. 2018)

Oorzaak: Binnen de ontwikkelomgeving is gebruiker strompf de eigenaar van alles, maar op de externe omgeving is dit een ander account. Resultaat: Map js_composer was niet leesbaar voor de webserver.

Oplossing: 

cd plugins
chmod o+rwX js_composer
cd js_composer
chmod -R o+rX *

Casus: Rechten belemmeren migratie (mei 2021)

Een migratie lukte niet:

Eerste probleem: rsync kon voortdurend mappen niet aanmaken, waaronder de meeste mappen onder wp-content/plugins

Tweede probleem: Sommige bestanden (wo. afbeeldingen die vermoedelijk via de site zijn geüpload) hadden als eigenaar en groep beiden www-data en die kon ik niet lezen (ik zit in groep www-admin).

Oorzaak

De vermoedelijke oorzaak van het eerste probleem:

  • Bron-locatie: Webserver is eigenaar, beheerder zit in groep' - Webserver kan niet schrijven, beheerder wel
  • Doel-locatie: Beheerder is eigenaar, webserver zit in groep - Beheerder kan niet schrijven → Inhoud van mappen wordt niet gekopiëerd.

Dit probleem kwam ik al eerder tegen: Rsync#Keep permissions - p-switch.

Achterliggende oorzaak van beide problemen: De manier waarop ik rechten heb geconfigureerd, wijkt te zeer af van hoe de rest van de wereld dit doet (Mappen, bestanden & rechten - 2020 (WordPress)).

Oplossing - Quick & dirty

Dit is een quick-and-dirty-oplossing, zodat ik verder kan:

  1. Bronlocatie:
    1. sudo chmod -R ug+rw .
    2. sudo chgrp -R www-admin *
  2. Doellocatie: Verwijder alle bestanden van een eventuele eerdere poging
  3. Opnieuw kopiëren.

Waarom dit quick-and-dirty is: De instellingen van rechten op de bronlocatie, klopt nu niet meer. Sois. Daar heb ik een script voor plus dat nu de site is gemigreerd, dit vermoedelijk niet meer boeit.

Oplossing - Koninklijke weg

Een oplossing die minstens zo grondig als tijdsrovend is: Op hoofdlijnen

  • Maak op de bron-webserver een tijdelijke kopie van de site - Dit kan een lastig proces zijn
  • Pas de rechten op deze kopie aan, zoals op de doellocatie
  • Kopiëer vervolgens deze kopie naar de doellocatie.

Casus: Migratie lukt niet vanwege caching (2023.01)

Dit betreft de migratie van een site waar nogal veel aan caching wordt gedaan. Zelfs wp search-replace werkt niet. Eerst moeten een paar dingen worden uitgezet:

  • Verwijder de inhoud van de map Must-use plugins
  • ?

Zie ook

Bronnen

Https » http

Overgenomen van "https://wiki.devliegendebrigade.nl/index.php?title=Migratie_(WordPress)&oldid=33148"