Migrace WordPressu bez výpadku

Migrace WordPressu má čtyři kroky: zkopírovat soubory, přesunout databázi, přepsat URL webu všude, kde je uložená, a nakonec nasměrovat DNS na novou adresu. Pokud je uděláš v tomhle pořadí, den předem snížíš TTL a web otestuješ přes záznam v souboru hosts dřív, než se změní cokoli veřejného, návštěvníci žádné přerušení nezaznamenají. V jiném pořadí uvidí napůl přesunutý web, dokud si ho jejich resolver pamatuje.

Nebezpečná část není technická. Při přepnutí běží obě kopie zároveň, takže cokoli, co se na starém webu zapíše po tvém posledním exportu - komentář, objednávka, koncept - pak neexistuje nikde. Všechno níže je uspořádané tak, aby se toto okno zmenšilo na pár minut a abys přesně věděl, co do něj spadne.

Co vlastně přesouváš#

Pět věcí a z migračního pluginu vypadnou jen první dvě.

• Soubory. wp-content je ta část, která je tvoje: themes, plugins, uploads a často i složka mu-plugins, o které nikdo neví. Jádro (core) si na cílovém místě klidně stáhneš čerstvé z wordpress.org - není důvod kopírovat 60 MB souborů, které získáš za vteřinu.
• Databáze. Každá tabulka s tvým prefixem. Příspěvky, nastavení, uživatelé a všechny tabulky, které vytvořily pluginy - e-shop nebo fórum má většinu dat v tabulkách, o kterých core nic neví.
• `wp-config.php`, který zkopíruješ pro referenci a potom přepíšeš. Přihlašovací údaje k databázi budou na novém hostingu jiné a použití starých je nejčastější důvod, proč čerstvě přesunutý web hlásí chybu připojení k databázi.
• Věci mimo WordPress. Pravidla přesměrování v .htaccess nebo v konfiguraci serveru, cron úlohy, které za tebe spouštěl starý hosting, ručně upravený robots.txt, povolené seznamy IP adres, klíč SMTP API v nastavení pluginu.
• DNS a certifikát. Kdo drží zónu, ten ji drží dál; mění se jen záznamy. Pokud byl starý hosting zároveň tvým poskytovatelem DNS nebo registrátorem, vyřeš to před dnem migrace, ne během něj - nameservery versus DNS záznamy vysvětluje, kterého ze tří účastníků vlastně přesouváš.

Sepiš si ten seznam. Migrace, která selže o týden později, selhává téměř vždy na čtvrté položce.

Vyber metodu a nejdřív zjisti velikost webu#

Před volbou zjisti dvě čísla: velikost wp-content a velikost databáze. V panelu nebo přes SFTP je to velikost složky a údaj o velikosti tabulek v phpMyAdminu.

Migrační pluginy jsou na malých webech opravdu dobré a na velkých opravdu nespolehlivé, z nudného důvodu: pracují uvnitř požadavku PHP, takže platí max_execution_time a memory_limit a 3 GB složka uploads se do 30sekundového požadavku nevejde. Selhání bývá tiché - archiv je useknutý, ale vypadá kompletně. Pokud je tvůj web velký, udělej to ručně; ruční postup níže nemá limit velikosti, který by stál za zmínku.

Naplánuj okno a sniž TTL#

DNS záznamy mají time to live, který resolverům říká, jak dlouho si mají odpověď pamatovat. Pokud má tvůj záznam A TTL 86 400 sekund, některé resolvery budou posílat návštěvníky na starý server celý den po tom, co ho změníš.

1. Dva dny předem: sniž TTL u záznamů, které budeš měnit - apex a www - na 300 sekund. Musíš to udělat dost dlouho dopředu, aby starý dlouhý TTL všude vypršel.
2. Ověř, že se to projevilo. dig +noall +answer example.com vypíše záznam se zbývajícím TTL. Mělo by odpočítávat od 300, ne od většího čísla.
3. Vyber hodinu. Nejklidnější hodinu v časovém pásmu svých návštěvníků, ne svém. Podívej se do analytiky, nehádej.
4. Rozhodni, co se zmrazí. U blogu nic: ztracený komentář se přežije. U e-shopu nebo členského webu dej starý web na deset minut mezi posledním exportem databáze a změnou DNS do režimu údržby a napiš to na stránku.
5. Starý hosting nech zaplacený ještě dva týdny. Je to plán zpětného kroku a stojí míň než incident.

Pokud ti něco z toho není povědomé, vysvětlení DNS záznamů popisuje, co který typ záznamu dělá, a www versus apex domény je tu důležité, protože obě jména musí skončit na novém hostingu společně.

Zkopíruj soubory#

Když máš shell na obou koncích, archivuj na straně serveru a přenášej jeden soubor:

$ cd /var/www/example.com$ tar -czf /tmp/wp-content.tar.gz wp-content$ scp /tmp/wp-content.tar.gz user@new-host:/tmp/

Bez shellu udělej totéž přes správce souborů: vytvoř na starém hostingu archiv wp-content, stáhni jediný soubor, nahraj ho na nový hosting a rozbal na místě. Stahování 40 000 malých souborů přes SFTP trvá hodiny; stažení jednoho archivu o velikosti 800 MB trvá minuty a celý trik je v tomhle rozdílu. Podrobnosti o připojení jsou v článku SFTP a správce souborů.

Vynech, co nepotřebuješ:

• Adresáře cache: wp-content/cache, wp-content/et-cache, cokoli, co vygeneroval cachovací plugin. Všechno se vygeneruje znovu a zastaralé soubory cache jsou dobrý způsob, jak po přesunu servírovat staré URL.
• Archivy zálohovacích pluginů uvnitř wp-content. Bývají to největší věci na disku a jsou to kopie webu, který už kopíruješ.
• Soubory error_log, které mohou být obrovské a na novém serveru ti nic neřeknou.

Potom na novém hostingu stáhni čistou kopii core, rozbal ji a wp-content vrať navrch. Máš aktuální soubory core a vlastní obsah, bez šance přenést něco, co někdo upravil, když ses nedíval.

Přesuň databázi#

S přístupem do shellu proveď dump a načtení:

$ mysqldump --single-transaction --default-character-set=utf8mb4 \    --add-drop-table -u olduser -p olddb > site.sql$ gzip site.sql

Na novém hostingu nejdřív vytvoř databázi a uživatele, potom importuj. V phpMyAdminu je to samé Export, pak Custom, volba gzip a na druhém konci Import. O čistotě importu rozhodují tři detaily:

• `utf8mb4` od začátku do konce. Exportuj a importuj se stejnou znakovou sadou, jinak diakritika a emoji dorazí jako změť znaků. Dodatečné hledání a nahrazování to neopraví.
• `--single-transaction` vytvoří konzistentní snímek bez zamykání webu, což je důležité, když dumpuješ vytíženou databázi.
• Limity velikosti importu. Importy v phpMyAdminu procházejí přes PHP, takže platí upload_max_filesize, post_max_size i max_execution_time. Dump zkomprimovaný gzipem bývá čtyřikrát až osmkrát menší a často rozhodne o tom, jestli to funguje. Pokud se pořád nevejde, dump rozděl nebo zvyš limity - které, popisuje nastavení php.ini, na kterých záleží, a stranu panelu průvodce importem a exportem v phpMyAdminu.

Na RE:NODE mají webové tarify dva sloty pro databáze vytvářené z panelu s vygenerovaným hostem, uživatelem a heslem. Tlačítko Open in phpMyAdmin tě přihlásí jednorázovým tokenem, který po šedesáti sekundách vyprší, takže dump naimportuješ v kartě prohlížeče, aniž by se přihlašovací údaje musely psát do formuláře. Do wp-config.php dej tyto nové údaje, ne staré.

Search and replace, krok, který rozbíjí weby#

Databáze je plná absolutních URL: siteurl a home v tabulce options, každé src obrázku v obsahu příspěvků, nastavení widgetů a šablony i konfigurace pluginů. Pokud se mění doména nebo přecházíš z http na https, musí se to všechno přepsat.

Nedělej to přes SQL. Je to nejškodlivější jednotlivá chyba při migraci WordPressu:

-- Do not do this. It corrupts every serialised setting in the table.UPDATE wp_options SET option_value = REPLACE(option_value, 'old.com', 'new.com');

WordPress ukládá pole a objekty jako serializované řetězce PHP, které si pamatují délku každé hodnoty v bajtech. Změň old.com na newsite.com uvnitř některého z nich a uložená délka už nesedí, takže PHP to nedokáže deserializovat a plugin nebo widget se tiše vrátí k výchozím hodnotám. Mizí nastavení šablony, menu se vyprázdní, slidery se rozbijí - a škoda se projeví za dny, dlouho poté, co jsi přestal migraci podezírat.

Použij nástroj, který serializaci chápe. S WP-CLI:

$ wp search-replace 'https://old.example.com' 'https://example.com' \    --all-tables --precise --dry-run$ wp search-replace 'https://old.example.com' 'https://example.com' --all-tables

Nejdřív proveď dry run, přečti si tabulku s počty a teprve pak to spusť naostro. Bez přístupu do shellu dělá stejnou práci z administrace plugin Better Search Replace, který má také dry-run režim. Funguje i samostatný skript Search Replace DB, s jedním pravidlem: smaž ho, jakmile skončíš. Skript, který přepisuje tvoji databázi a leží na uhádnutelné URL, je úplné napadení čekající na objevení.

Pokud se změnila i cesta v souborovém systému - z /home/olduser/public_html na něco jiného - hledej i starou cestu. Několik pluginů ukládá absolutní cesty a když už neexistují, selhávají matoucím způsobem.

Otestuj, než sáhneš na DNS#

Nový web si můžeš prohlédnout pod jeho skutečným doménovým jménem, aniž bys cokoli veřejného měnil, tím, že svému počítači řekneš, kam se má dívat. Přidej jeden řádek do souboru hosts - C:\Windows\System32\drivers\etc\hosts ve Windows, /etc/hosts v macOS a Linuxu:

203.0.113.25    example.com www.example.com

Tvůj prohlížeč teď překládá doménu na nový server, zatímco zbytek světa pořád chodí na starý. Je to správný způsob testování, protože web vidí svou kanonickou doménu: žádné přesměrování zpět na starý hosting, žádné napůl přepsané URL, žádné dočasné jméno hostitele uložené v databázi.

Projdi skutečný checklist, nekoukni se jen na úvodní stránku:

• Úvodní stránka, příspěvek, archiv kategorie, stránka s formulářem a výsledky vyhledávání.
• /wp-admin: přihlas se, načti obrazovku pluginů a ověř, že nic nehlásí chybějící tabulku.
• Trvalé odkazy: otevři libovolnou URL, která není úvodní. Chyba 404 na každé stránce kromě úvodní znamená, že pravidla přepisu ještě nejsou na místě.
• Obrázky: otevři příspěvek s médii a ověř, že se soubory načítají z nového hostingu.
• E-shop: košík, pokladna až do kroku platby a jedna testovací objednávka v sandboxu platební brány.
• Cokoli plánovaného: spusť ručně jednu cron událost a zjisti, že doběhne.

Až skončíš, záznam v hosts odstraň. Když ho tam necháš, budeš za měsíce jediný člověk na světě, který nevidí, že web nejede.

Samotné přepnutí#

S TTL na 300 sekundách a otestovaným novým webem je přepnutí krátké.

1. Dej starý web do režimu údržby, nebo prostě přijmi riziko, pokud se nic nezapisuje.
2. Znovu exportuj databázi a naimportuj ji přes kopii na novém hostingu. Tento druhý průchod zabere obvykle pár minut a zachytí vše, co se zapsalo od první kopie. Stejným způsobem synchronizuj nové uploady.
3. Na čerstvém importu znovu spusť search-replace. Je to nová kopie dat; staré URL jsou v ní zpátky.
4. Změň záznam A pro apex i pro www na novou adresu. V zóně neměň nic jiného: záznamy MX zůstávají, kde jsou, a právě to udrží poštu v provozu.
5. Sleduj konzoli nebo access log nového hostingu. Provoz by se měl objevit do minuty či dvou a růst, jak resolvery ztrácejí platnost svých uložených odpovědí.
6. Starý web nech v režimu údržby, nemaž ho. Je to tvůj plán zpětného kroku a brání opozdilcům zapisovat do databáze, kterou opouštíš.

U certifikátu čeká problém s pořadím, s kterým je dobré počítat. Vydání ověřuje, že jméno opravdu míří na server, který o certifikát žádá, takže certifikát pro example.com na novém hostingu obvykle nejde vydat, dokud DNS na něj už neukazuje. Mezi změnou záznamu a objevením se certifikátu je okno vteřin až minut, během kterého může návštěvník vidět varování. Na RE:NODE to řeší proxy slot: nasměruj záznam A na adresu z té karty a certifikát se vydá, jakmile se jméno přeloží, a pak se sám obnovuje v rámci svého 21denního okna. Samotné ověřování popisuje HTTPS a Let's Encrypt vysvětleně.

Po přepnutí a co se kazí#

V první hodině: znovu ulož trvalé odkazy v Nastavení, aby se vygenerovala pravidla přepisu, ověř HTTPS na několika URL, pošli zkušební e-mail z kontaktního formuláře a zkontroluj, že se spouštějí naplánované příspěvky a cron události. V prvním týdnu: sleduj chyby 404 z URL, o kterých jsi nevěděl, a znovu zkontroluj search console kvůli chybám procházení.

Opakující se selhání a co každé znamená:

Error establishing a database connection. wp-config.php pořád obsahuje přihlašovací údaje starého hostingu, nebo je DB_HOST nastavený na localhost tam, kde potřebuje skutečné jméno hostitele.

Web přesměrovává na starou doménu. siteurl a home v tabulce options nebyly přepsány. Dočasně je přepiš pomocí WP_HOME a WP_SITEURL v wp-config.php a pak řádně oprav databázi.

Varování o smíšeném obsahu. V obsahu příspěvků jsou pořád staré URL s http://. Spusť search-replace znovu pro schéma, ne jen pro jméno hostitele.

Prázdná menu, resetovaná nastavení šablony. Serializovaná data poškozená prostým nahrazením v SQL. Obnov databázi ze stavu před tímto krokem a udělej to znovu pořádným nástrojem. Částečná oprava neexistuje.

Obrázky vrací 404, příspěvky jsou v pořádku. Složka uploads se nezkopírovala celá, nebo vlastnictví souborů brání webovému serveru je číst. Porovnej velikosti složek u obou hostingů, nespoléhej na přenos.

Přestane chodit e-mail. Pošta nesleduje webový server. Záznamy MX zůstávají u poskytovatele pošty a transakční pošta z webu potřebuje SMTP plugin namířený na poskytovatele, který tě ověří - RE:NODE poštu nehostuje, tak s tím počítej, ať to neobjevíš až později. Proč na záznamech i po přesunu záleží, vysvětluje SPF, DKIM a DMARC vysvětleně.

Všechno funguje, ale web je pomalý. Čerstvá instalace bez cache stránek a OPcache je pořád studená. Znovu nainstaluj cachovací plugin a nastav ho, než vyvodíš závěry - pořadí kroků je v článku rychlost WordPressu a cachování.

FAQ#

Jak dlouho migrace WordPressu trvá?

Příprava zabere hodinu až dvě, většinou kopírování souborů. Samotné přepnutí trvá pět až patnáct minut. Doznívání DNS - opozdilci, kteří pořád chodí na starý server - trvá tak dlouho, jak velký byl starý TTL v okamžiku, kdy jsi ho změnil, a proto je jeho předchozí snížení to nejužitečnější, co můžeš udělat.

Bude web při přesunu nedostupný?

Ne, pokud běží obě kopie a DNS změníš až na konci. Návštěvníci se dostanou na jeden nebo druhý funkční web. Přijít můžeš o zápisy na starý web po posledním exportu, proto na krátkém okně údržby záleží u e-shopu a u blogu ne.

Mohu migrovat bez změny domény?

Ano, a je to snadný případ: pro jméno hostitele není potřeba search-replace, jen pro schéma, pokud zároveň přecházíš na HTTPS. Otestuj to záznamem v souboru hosts a web se bude chovat přesně tak, jak se bude chovat po přepnutí.

Mám použít migrační plugin, nebo to udělat ručně?

Plugin pro malý, jednoduchý web; ručně pro cokoli nad zhruba půl gigabajtu, cokoli s velkou databází nebo cokoli, kde potřebuješ řídit přesný okamžik přepnutí. Pluginy běží uvnitř požadavků PHP a selhávají na týchž limitech, kvůli nimž jsou velké weby velké.

Co se starým hostingem?

Nech ho zaplacený a v režimu údržby dva týdny. První den je to tvůj plán zpětného kroku a následující dva týdny tvoje reference, když objevíš cron úlohu nebo pravidlo přesměrování, o kterém jsi nevěděl. Než ho zrušíš, udělej poslední úplnou kopii.

Musím vyhledávačům oznámit, že se web přestěhoval?

Pokud se doména nezměnila, ne - nevšimnou si toho a nemají si toho všimnout. Pokud se doména změnila, nech starou doménu naživu s přesměrováním 301 na odpovídající URL na nové a drž je alespoň rok.