Wordpress::Backup&Restore

WORDPRESS::Backup and Restore

Index
1.	Backup::Algemeen
		Script Backupwp-cron
		CRON
		Backup/Synchronisatie
		Script Backupwp
		Optie: Backup
		Optie: Synchroniseer
		Optie: Gebruikersinstructies
		Optie: User-Hacks
		Gebruikersinstructies Upgrade en Restore
		Tarball van de bestanden met de hacks
		Tarball van de originele bestanden
2.	Wordpress migreren met backup data

Backup

Algemeen

De Wordpress Blog Erica wordt regelmatig voorzien van nieuwe berichten en worden tevens foto's toegevoegd die niet noodzakelijkerwijs automatisch op de netwerkserver (fotoarchief en gallery) belanden.
Hiervan maken we dagelijks een backup naar een fysiek gescheiden harde schijf op de netwerk-bestandsserver. Tevens wordt de complete server, inclusief data, 2x per jaar weggeschreven naar een externe harde schijf.

Wordpress bestaat uit 3 elementen waarvan backups gemaakt moeten worden:

Het programma in de webroot ../blog. Dit gedeelte bevat geen date en bestaat uit het programma met thema en plugins. Dit gedeelte is onderhevig aan WP updates, plugin updates en eigen hacks.
De data (uploads) in /home/wpdata. Hier worden de eigen media (images, videos, muziek, etc) opgeslagen
De content in de MariaDB 'wordpress' met de eigen programma customisatie en vormgeving en al de blogcontent anders dan de media.

Het dagelijkse backup proces op de webserver wordt uitgevoerd met het script ‘backupwp-cron’ geplaatst op de webserver in /usr/local/bin/. Zie hiervoor ook de sectie Webserver: Utility Scripts

Naar Index

Script Backupwp-cron

In de scripts 'backupwp' en 'backupwp-cron' wordt een MySQL commando gebruikt dat een wachtwoord vereist. Deze is niet 'hard-coded' in het script opgenomen. Het script bevat een 'include' statement dat verwijst naar een verborgen bestand '.mysql_access' dat in dezelfde directory /usr/local/bin/ geplaats moet zijn als het 'backupwp' script.
Bekijk hier de template 'demo.mysql_access'. Kopieer en open dit bestand in een editor en vervang <MySQL-rootwachtwoord> en <MySQL-gallery2_ww> door de wachtwoorden ingevoerd in hoofdstuk 'Wordpress::Installeren' sectie 'Maak MariaDB database aan voor Wordpress'.
Sla het bestand op als '.mysql_access' en zet permissies naar root:root en chmod 400. Voor Wordpress is alleen de eerste regel in .mysql_access van belang.

MYSQL_PWD_R="<MySQL-rootwachtwoord>"

Gebruikersinformatie van het script 'backupwp-cron' wordt in het script gegeven. Het script kan hier bekeken en eventueel elders opgeslagen worden.
Het script resulteert in een backup van het geïnstalleerde Wordpress programma ../blog, een backup van de data directorie '/home/wpdata' en de bijbehorende MariaDB database 'wordpress'. Tevens wordt een bestandje aangemaakt met in de naam de datum en tijd van de backup.

#!/bin/bash
#*********************************************************************************************
#* BACKUPWP Version 1.0 Script voor automatische synchronisatie (backup) van Wordpress data  *
#* Ben Makkink 09 november 2016                                                              *
#*********************************************************************************************
#* BELANGRIJK: Dit script wordt gebruikt door CRON voor het dagelijks maken van een          *
#* automatische backup. CRON gebruikt echter per default 'sh' ipv 'bash'.                    *
#* Als script geschreven is in 'bash' werkt het mogelijk niet onder CRON. Corrigeer dit      *
#* door op de eerste regel van het script '#!/bin/bash' te plaatsen. Nu wordt het script     *
#* uitgevoerd is 'bash' ondanks dat het door CRON in 'sh' aangeroepen wordt.                 *
#* *******************************************************************************************
# * Verifieer dat de voor script 'backupwp' benodigde bestanden in /usr/local/bin
# * aanwezig zijn.
#
# * 1: 'mysql_access' met Mysql inloggegevens
clear;
ok="y";
if [ ! -f /usr/local/bin/.mysql_access ]
   then
         echo;
     echo "     Bestand 1 : '.mysql_access' mist in /usr/local/bin!";
         ok="n";
fi
# * 2: 'backupwp_readme' met 'backupwp' gebruikersinstructies
if [ ! -f /usr/local/bin/backupwp_readme ]
   then
         echo;
     echo "     Bestand 2 : 'backupwp_readme' mist in /usr/local/bin!";
         ok="n";
fi

# * Bericht als bestand(en) missen
if [ $ok == "n" ]
    then
        echo;
        echo "     ===============================================================================";
    echo "     Installeer eerst bovenstaande bestand(en), BACKUPWP heeft deze nodig!!";
        echo "     ===============================================================================";
        echo -n "     Druk <Enter> om verder te gaan: "; read foo;
        echo;
        exit;  #exit script omdat bestanden missen in /usr/local/bin/
fi

# *****************************************************************************************
# * Als alle benodigde bestanden in /usr/local/bin/ bestaan; start het script
# *****************************************************************************************

# include verborgen bestand met setting van de MYSQL wachtwoorden
# Als dit script door CRON gebruikt wordt mag het pad naar .mysql_access niet relatief zijn
# CRON werkt vanuit de root en het pad naar het 'include' bestand moet dus 'full' zijn.
. /usr/local/bin/.mysql_access

# Ga naar de root /
cd /;

# Geef hier aan waar het 'wordpress' programma zich bevindt
source_prog="/var/www/html/blog";

# Geef hier aan waar de buiten de webroot geplaatste 'wordpress data' zich bevinden
source_data="/home/wpdata"

# Geef hier aan waar synchronisatie backups opgeslagen moeten worden
storedir="/vault/wordpress/";

# Geef hier aan welk datumformaat gebruikt moet worden voor de bestandsnaam
datestamp=$(date +%Y%m%d);

# Maak dump van Wordpress database naar /home/wpdata
#===================================================
# Maak een dump (export) van de mysql database 'wordpress' genaamd 'wp-dump.sql' in
# /home/wpdata/dbase_dump
mysqldump -uroot -p$MYSQL_PWD_R --opt --databases wordpress > $source_data/dbase_dump/wp-dump.sql;

# De datum van synchronisatie houden we bij met de naam van een bestand (zonder inhoud)
# Verwijder laatste bestand
syncfile=$source_data"/synchronisatie*";
rm -rf $syncfile;

# Creeer nieuw bestand 'synchronisatiedatum'
touch $source_data"/synchronisatiedatum-"$datestamp;

# Backup alleen wordpress-programma naar $storedir
# Symbolic links worden gecopieerd en niet de achterliggende data
#=================================================================
rsync -avzh $source_prog $storedir;

# Backup 'wpdata'
rsync -avzh $source_data $storedir;

# Verwijder oude synchronisatiedatum bestanden uit 'storedir'
find $storedir -maxdepth 2 -mtime +7 -name synchronisatiedatum* -exec rm {} \;;

# ============================================================================================
# Zie BACKUPWP_README voor uitleg en restore instructies
# ============================================================================================

Naar Index

CRON

Het script 'backupwp-cron wordt middels een CRON elke dag uitgevoerd. Zie http://nl.wikipedia.org/wiki/Cronjob voor gedetailleerde uitleg over CRON, deze website Exploringlinux-Server-Processen met nadere praktijk-info, of #man crontab voor het maken en bewerken van de crontab bestanden.

Naar Index

WORDPRESS Backup/Synchronisatie

Bij de 'Backup' of 'Synchronisatie' worden nieuwe/gewijzigde bestanden naar de backupdisk geschreven.
Bij 'Synchronisatie worden als in de bron bestanden verwijderd zijn deze ook uit het doel verwijderd.
Bij 'Backup' blijven deze bestanden in het doel bewaard. De dagelijkse cron met het script 'backupwp' voert een 'Backup' uit.

Naar Index

Script Backupwp

Het script 'backupwp' wordt op de hand uitgevoerd met het commando aan de prompt': # backupwp
Bekijk hier het complete script inclusief inline uitleg.
'UTILS' Utilitiespakket: Het script ‘backupwp’ is op zijn beurt geïntegreerd in het in ClearOS7 Server::Utility Scripts beschreven pakket, met diverse scripts voor onderhoud, backup, etc. Deze bash scripts voorzien in menu's met de diverse keuzes en gebruikersinstructies.

Het 'backupwp' script opent een menu met de volgende opties:

Backup - Kopieer nieuwe/gewijzigde bestanden. Behoudt bestanden verwijderd uit bron
Synchroniseer - Kopieer nieuwe/gewijzigde bestanden. Verwijder indien alleen in doel
Gebruikersinstructies voor Wordpress RESTORE en automatisch backup met cron
Wordpress User-Hacks Backup

Naar Index

Optie: Backup
Kopieer nieuwe/gewijzigde bestanden. Behoudt bestanden verwijderd uit bron

Relevante regels in het script (zie Optie:Gebruikersinstructies voor meer detail):

# Geef hier aan waar het 'wordpress' programma zich bevindt
source_prog="/var/www/html/blog";

# Geef hier aan waar de buiten de webroot geplaatste 'wordpress data' zich bevinden
source_data="/home/wpdata"

# Geef hier aan waar wordpress-backups opgeslagen moeten worden
storedir="/vault/wordpress/";

# Maak de variabele met de datum en tijd van de vorige wordpress backup/synchronisatie
syncfile=$source_data"/synchronisatie*";
lastsync=$(date -r $syncfile +%d/%m/%Y-%X);

mysqldump -uroot -p$MYSQL_PWD_R --opt --databases wordpress > $source_data/dbase_dump/wp-dump.sql;
touch $source_data"/synchronisatiedatum-"$datestamp;
rsync -av $source_data $storedir;
rsync -av $source_prog $storedir;

Als eerste wordt er een dump vande database 'wordpress' gemaakt en geplaatst bij de data in /home/wpdata/dbase_dump
Vervolgens wordt er een bestandje met als naam de datum en tijd van het maken van de backup, deze wordt ook in /home/wpdata geplaatst.
Daarna wordt een backup gemaakt van de data van itmes 1 en 2 in /home/wpdata en weggeschreven naar de folder /vault/wordpress op een fysiek gescheiden schijf.
Als laatste wordt een backup gemaakt van het programma in de webroot onder ../blog en ook weggeschreven naar de folder /vault/wordpress.

Naar Index

Optie: Synchroniseer
Kopieer nieuwe/gewijzigde bestanden. Verwijder indien alleen in doel.

Relevante regels in het script (zie Optie:Gebruikersinstructies voor meer detail):

# Geef hier aan waar het 'wordpress' programma zich bevindt
source_prog="/var/www/html/blog";

# Geef hier aan waar de buiten de webroot geplaatste 'wordpress data' zich bevinden
source_data="/home/wpdata"

# Geef hier aan waar wordpress-backups opgeslagen moeten worden
storedir="/vault/wordpress/";

# Maak de variabele met de datum en tijd van de vorige wordpress backup/synchronisatie
syncfile=$source_data"/synchronisatie*";
lastsync=$(date -r $syncfile +%d/%m/%Y-%X);

mysqldump -uroot -p$MYSQL_PWD_R --opt --databases wordpress > $source_data/dbase_dump/wp-dump.sql;
touch $source_data"/synchronisatiedatum-"$datestamp;
rsync -av $source_data --delete $storedir;
rsync -av $source_prog --delete $storedir;

Als eerste wordt er een dump vande database 'wordpress' gemaakt en geplaatst bij de data in /home/wpdata/dbase_dump
Vervolgens wordt er een bestandje met als naam de datum en tijd van het maken van de backup, deze wordt ook in /home/wpdata geplaatst.
Daarna wordt een backup gemaakt van de data van itmes 1 en 2 in /home/wpdata en weggeschreven naar de folder /vault/wordpress op een fysiek gescheiden schijf. Maar worden bestanden die niet meer in de bron voorkomen ook verwijderd uit het doel (--delete)
Als laatste wordt een backup gemaakt van het programma in de webroot onder ../blog en ook weggeschreven naar de folder /vault/wordpress. Maar worden bestanden die niet meer in de bron voorkomen ook verwijderd uit het doel (--delete)

Naar Index

Optie: Gebruikersinstructies

De selectie van deze optie opent onderstaand tekstbestand met uitleg over de backup en restoreprocedures.
Klik hier om het bestand in de browser te openen en eventueel elders op te slaan.

backupwp_readme
*********************************************************************************************
* BACKUPWP Version 1.0 Script voor automatische synchronisatie (backup) van Wordpress data  *
* Ben Makkink 09 november 2016                                                              *
*********************************************************************************************
WERKING VAN HET SCRIPT EN RESTORE INSTRUCTIES

BELANGRIJK:
Het script 'backupwp' wordt gebruikt door CRON voor het dagelijks maken van een automatische
backup. CRON gebruikt echter per default 'sh' ipv 'bash'.
Als een script geschreven is in 'bash' werkt het mogelijk niet onder CRON. Corrigeer dit
door op de eerste regel van het script '#!/bin/bash' te plaatsen. Nu wordt het script
uitgevoerd in 'bash' ondanks dat het door CRON in 'sh' aangeroepen wordt.

HET SCRIPT BACKUPWP
1- Eerst wordt geverifieerd dat de voor script 'backupwp' benodigde bestanden in
   /usr/local/bin aanwezig zijn.
2- Vervolgens wordt een 'include' gedaan van het verborgen bestand .mysql_access met de
   setting van de MYSQL wachtwoorden. Als dit script door CRON gebruikt wordt mag het pad
   naar .mysql_access niet relatief zijn. CRON werkt vanuit de root en het pad naar het
   'include' bestand moet dus 'full' zijn, dwz: . /usr/local/bin/.mysql_access
3- Na een cd naar root '/', worden nog enkele variabelen gezet waarna het eigenlijke
   programma begint:
     Maak een dump (export) van de mysql database 'wordpress' genaamd 'wp-dump.sql'
     in /home/wpdata/dbase_dump
     # mysqldump -uroot -p$MYSQL_PWD_R --opt --databases wordpress >
                                               /home/wpdata/dbase_dump/wp-dump.sql;
4- De datum van synchronisatie houden we bij door een 'datestamp' te verwerken in de naam
   van een leeg bestand '/home/wpdata/synchronisatiedatum-yyyymmdd'
5- Nu maken we de backups van /var/www/html/blog en /home/wpdata naar /vault/wordpress:
   # rsync -avzh /var/www/html/blog /vault/wordpress;
   (symbolic link naar /home/wpdata/uploads wordt gekopieerd, niet de achterliggende data)
   # rsync -avzh /home/wpdata /vault/wordpress;
   (alle blogdata inclusief MySQL-dump van de 'wordpress' database)

BACKUP en geen SYNCHRONISATIE!
Bij de automatische geplande backup is het beter geen synchronisatie met de optie
'verwijder uit doel als niet meer in bron' uit te laten voeren, want voor je het weet is
ook alles in de backup weg.
Doe een synchronisatie met --delete alleen handmatig via het script 'backup' bijvoorbeeld
1 x per jaar. En dan alleen als je absoluut zeker bent dat de brondata compleet zijn.

CRON
Gebruik het backupwp script met een cron om bijvoorbeeld wekelijks uit te voeren.
Gebruik commando # crontab -e en voeg toe in /var/spool/cron/root:
  1 1 * * 0 /usr/local/bin/backupwp &> /dev/null
Bovenstaande betekent: 01:01 uur 's ochtends op 1e dag van de week
 of 1 1 * * * /usr/local/bin/backupwp &> /dev/null
zelfde tijden maar nu dagelijks.

===========================================================================================
WORDPRESS Blog restore:
===========================================================================================
1- Voor een restore is het beter te zorgen dat het oude bestand verwijderd is.
2- Als het BLOG programma zelf nog wel werkt is het niet nodig deze te vervangen door
   de backup.
3- Om een restore te doen van WORDPRESS BLOG is het voldoende de huidige lege of corrupte
   data directory /home/wpdata/uploads te verwijderen en te vervangen door zijn laatste
   backup in /vault/wordpress/wpdata
4- Vervolgens moet de Wordpress database hersteld worden.
   Voer onderstaande commando's uit voor het droppen van de oude MariaDB Wordpress dbase
   en het importeren van de sql-dump in de backup:
     a. cd naar /vault/wordpress/wpdata/dbase_dump met het bestand 'wp-dump.sql'
     b. # mysqladmin -uroot -p'<MySQL-rootwachtwoord>' drop wordpress
        (verwijdert de oude 'wordpress')
     c. # mysql -uroot -p'<MySQL-rootwachtwoord>' < wp-dump.sql
        (importeert de backup 'wordpress')
   Hiermee is Wordpress Blog weer hersteld naar de situatie van de laatste backup.

NOTE 1:
<MySQL-rootwachtwoord> is het rootwachtwoord gegeven bij de activering van MySQL

NOTE 2:
SYMBOLIC LINKS naar backups.
Het kopiëren van de bestanden van de backup naar /home/wpdata kan enige tijd duren.
Om snel in de lucht te zijn kunnen we in plaats van bovenstaande stap 3 eerst in
het wordpress blog programma de symbolic links naar de probleembestanden verwijderen en
deze vervangen met een symbolic link naar de backup.
Bijvoorbeeld voor ../blog/wp-content/uploads:
# cd /var/www/html/blog/wp-content
# unlink uploads
# ln -s /vault/wordpress/wpdata/uploads uploads
Nu gaan we verder met stap 4 en op deze manier is Wordpress Blog weer beschikbaar.

Nu kopiëren we het fysieke backupbestand naar /home/wpdata met een andere naam, bijvoorbeeld:
# cp -aR /vault/wordpress/wpdata/uploads /home/wpdata/bck-uploads

Vervolgens stoppen we wordpress en verwijderen we de symbolic link in ../blog/wp-content:
# unlink uploads
Als deze link verwijderd is hernoemen we het fysieke bestand:
# rename bck-uploads uploads bck-uploads
Herstel nu de symbolic link
# ln -s /home/wpdata/uploads uploads

Hiermee is Wordpress Blog weer hersteld naar de situatie van de laatste backup!

NOTE 3:
De backup kan ook gebruikt worden voor een (her)installatie van Wordpress Blog op een andere
server of nieuwe ClearOS installatie.

===========================================================================================
WORDPRESS BLOG PROGRAMMA restore
===========================================================================================
Mocht het BLOG programma corrupt zijn of het is in z'n geheel niet geinstalleerd, dan
volstaat het om uit de backup in /vault/wordpress de directory 'blog' te copieren naar
/var/www/html/ (# cp -a om permissies en owners te behouden
===========================================================================================

Naar Index

Optie: User-Hacks

Deze optie start het script 'wordpress-hacks' voor het samenstellen van tarballs van alle programmabestanden in Wordpress die gewijzigd zijn door de gebruiker (voor en na de eigen wijzigingen).
Op het moment van schrijven zijn de volgende drie programma bestanden 'gehackt' (Zie WORDPRESS::Aanpassen sectie Aanpassen met PHP Hacks)

../blog/wp-config.php
../wp-content/themes/allx-premium/functions.php
../wp-content/themes/allx-premium/category.php
../wp-content/themes/allx-premium/template-parts/content.php
../wp-content/themes/allx-premium/template-parts/content-page.php
../wp-content/themes/allx-premium/template-parts/content-search.php

Het script 'wordpress-hacks' opent met een menu met volgende keuzes:

Gebruikersinstructies RESTORE User Hacks
Maak 'wordpress-hacks' tarball (pre-upgrade hacks)
Maak 'wordpress-hacks-org' tarball (pre-upgrade originelen)

Naar Index

Keuze 1 opent een tekstbestand met onderstaande gebruikersinstructies.
Klik hier om het bestand in de browser te openen en eventueel elders op te slaan.

WORDPRESS-HACKS Gebruikers instructies
================================================================================
Voordat in Wordpress de eigen modificaties gemaakt worden, worden van de
betreffende bestanden kopien gemaakt van het origineel en voorzien met de
extentie .org. Deze bestanden zijn dus originelen zoals uit de doos.
Na een upgrade moet nu eerst vastgesteld worden of deze 'uit de doos' bestanden
niet gewijzigd zijn. Maak vóór een upgrade een tarball van deze .org files.
Gebruik eventueel het bestand wordpress-hacks-org.tar.gz om na de upgrade
deze pre-upgrade .org originelen terug te zetten.
Vergelijk nu de upgrade originelen met de pre-upgrade originelen met de extentie
.org.
Alleen als deze gelijk zijn kan wordpress-hacks.tar.gz gebruikt worden om
de eigen wijzigingen terug te zetten.
Als er verschillen zijn dan moeten van deze specifieke bestanden de eigen
wijzigingen in de upgrade op de hand uitgevoerd worden.

Vergelijken van bestanden (na de upgrade en voor terugzetten eigen wijzigingen)
=================================================================================
1 Maak een nieuwe directory ../temp aan
2 Kopieer alle bestanden .org en hun nieuwe tegenhangers naar deze ../temp
  directory.
3 Vergelijk de oude met de nieuwe dus bv. wp-config.php en wp-config.php.org
  # comm -13 file1 file2 > file3
  Hierbij is file1 de oude, file2 de nieuwe en file3 het output bestand
  -1 verberg regels uniek in file1
  -2 verberg regels uniek in file2
  -3 verberg regels die in beide gelijk zijn
  Bovenstaand commando resulteert in file3 met regels die in het nieuwe bestand
  niet meer voorkomen.
  # comm -23 file1 file2 > file3
  Resulteert in regels die alleen in het nieuwe voorkomen, dus toegevoegd.
=================================================================================
Alternatief
=================================================================================
Gebruik het Windows programma EXAMDIFF om beide bestanden te vergelijken. Als de
Windows PC Samba toegang heeft tot de webroot (website) dan zijn de beide
bestanden eenvoudig te openen en worden de verschillen duidelijk getoond.
=================================================================================

Alleen als er bij alle bovenstaande bestanden geen verschillen bestaan dan kunnen
de eigen bestanden in wordpress-hacks.tar.gz teruggezet worden. In dit
geval laten we de bestanden met .org extentie gewoon staan voor een
volgende upgrade.

Als er wel verschillen in een bestand zijn, dan moet na de upgrade van Wordpress
een kopie van dit bestand gemaakt worden met een .org extentie waarna het
origineel bewerkt moet worden met de eigen wijzigingen.
=================================================================================
MAAK DUS VOOR EEN UPGRADE EERST DE TARBALLS 'wordpress-hacks.tar.gz'
en 'wordpress-hacks-org.tar.gz'.

Naar Index

Keuze 2 maakt vóór de upgrade een tarball van de bestanden met de hacks
Relevante code:

      echo "     De volgende bestanden worden gearchiveerd.";
      echo "     ================================================================================"; 
      cd /var/www/html/blog;  #Ga naar de ../blog directory
        tar -cvf tmp.tar wp-config.php; #bestanden met eigen bewerkingen naar archief tmp.tar
        tar -rvf tmp.tar wp-content/themes/allx-premium/functions.php;
        tar -rvf tmp.tar wp-content/themes/allx-premium/category.php;
        tar -rvf tmp.tar wp-content/themes/allx-premium/template-parts/content.php;
        tar -rvf tmp.tar wp-content/themes/allx-premium/template-parts/content-page.php;
        tar -rvf tmp.tar wp-content/themes/allx-premium/template-parts/content-search.php;

      gzip tmp.tar;  # Comprimeer het bestand met gzip
     # Geef een fatsoenlijke naam en locatie aan het bestand
      mv tmp.tar.gz /home/wpdata/hacks/wordpress-hacks.tar.gz;

Naar Index

Keuze 3 maakt vóór de upgrade een tarball van de originele bestanden (als uit de doos)
Relevante code:

      echo "     De volgende bestanden worden gearchiveerd.";
      echo "     ================================================================================"; 
      cd /var/www/html/blog;  #Ga naar de ../blog directory
        tar -cvf tmp.tar wp-config.php; #bestanden met eigen bewerkingen naar archief tmp.tar
        tar -rvf tmp.tar wp-content/themes/allx-premium/functions.php.org;
        tar -rvf tmp.tar wp-content/themes/allx-premium/category.php.org;
        tar -rvf tmp.tar wp-content/themes/allx-premium/template-parts/content.php.org;
        tar -rvf tmp.tar wp-content/themes/allx-premium/template-parts/content-page.php.org;
        tar -rvf tmp.tar wp-content/themes/allx-premium/template-parts/content-search.php.org;

      gzip tmp.tar;  # Comprimeer het bestand met gzip
     # Geef een fatsoenlijke naam en locatie aan het bestand
      mv tmp.tar.gz /home/wpdata/hacks/wordpress-hacks-org.tar.gz;

Wordpress migreren met backup data

Voor het migreren van de Wordpress blog van de huidige server naar een nieuwe on-line server kunnen we de Wordpress backup gebruiken zoals omschreven in Gebruikersinstructies
Kopiëer hiervoor van de huidige server met rsync de meest recente backupdata in /vault/wordpress naar de vault van de nieuwe server en volg de Gebruikersinstructies
Zodra de nieuwe server on-line genomen wordt in domein www.makkink.eu is nu de Wordpress blog geheel operationeel.

Note:
Gebruik nooit een testserver backup om de online domeinserver te installeren en/of te herstellen. Het resultaat zal vanwege de permalinks in de errays een complete chaos opleveren.

Oude server met in de Wordpress-blog permalinks naar www.makkink.eu
Nadat de nieuwe server on-line gezet is in domein www.makkink.eu gebruiken we de oude server als testserver. Het is dus nuttig dat we een werkende versie van zowel Piwigo als Wordpress in stand houden.
Bij Piwigo is geen enkele wijziging nodig, alle links in dit programma en data zijn relatieve adressen, dus verwijzen allemaal naar de testserver zelf.
Bij Wordpress zijn echter alle links permalinks met het volledige pad met als root het domein www.makkink.eu

Het eerste probleem waar we tegen aan lopen begint al als we in willen loggen als beheerder om bijvoorbeeld al deze links te wijzigen.
De link voor het inloggen verwijst echter nog steeds naar www.makkink.eu, dus zelfs vanaf de testserver belanden we in de on-line webserver.
De settings voor o.a. in- en uitloggen kunnen we wijzigen in Wordpress > Dashboard > Instellingen > Algemeen, maar daar moeten we voor ingelogd zijn.

Edit Wordpress database met (phpMyAdmin) MySQL
De enige manier om hier een voet tussen de deur te krijgen is het in phpMyAdmin of aan de prompt bewerken van de databasetafel van wordpress.wp_options waarin de instellingen opgeslagen zijn.

Zie voor de diverse SQL commando's ook MySQL voorbeelden

Update wp_options URL's
Check in kolom option_value naar records met www.makkink.eu terwijl in kolom option_name: 'login_redirect_url','logout_redirect_url','home' of 'siteurl'

MariaDB [wordpress]> SELECT * FROM `wp_options`
WHERE option_name IN ('login_redirect_url', 'logout_redirect_url','home','siteurl')
AND option_value LIKE '%www.makkink.eu%';
+-----------+---------------------+-----------------------------+----------+
| option_id | option_name         | option_value                | autoload |
+-----------+---------------------+-----------------------------+----------+
|         2 | home                | https://www.makkink.eu/blog | yes      |
|       748 | login_redirect_url  | https://www.makkink.eu/blog | yes      |
|       747 | logout_redirect_url | https://www.makkink.eu/blog | yes      |
|         1 | siteurl             | https://www.makkink.eu/blog | yes      |
+-----------+---------------------+-----------------------------+----------+

Update in de de text in option_value van 'www.makkink.eu' naar '192.168.1.5'

MariaDB [wordpress]> UPDATE `wp_options` 
SET option_value=REPLACE(option_value,'www.makkink.eu','192.168.1.5')
WHERE option_name IN ('login_redirect_url', 'logout_redirect_url','home','siteurl')
AND option_value LIKE '%www.makkink.eu%';
Query OK, 4 rows affected (0.00 sec)
Rows matched: 4  Changed: 4  Warnings: 0

Na deze update kunnen we weer inloggen op Wordpress op de testserver

Note:
Er zijn meer permalinks met www.makkink.eu in de tafel wp_options, maar deze zijn nested in arrays.
Deze kunnen we alleen updaten met Wordpress > Dashboard > Weergave > Customizer door de layout geheel opnieuw op te bouwen.
Voor de testserver is dat niet nodig, te veel werk voor niets. Slechts enkele afbeeldingen zullen door de browser van de domeinserver www.makkink.eu gehaald worden.

Update wp_options records met e-mailadres erica@makkink.eu naar ben@makkink.eu

MariaDB [wordpress]> UPDATE `wp_options`
SET option_value=REPLACE(option_value,'erica@makkink.eu','ben@makkink.eu')
WHERE option_value LIKE '%erica@makkink.eu%'

Alle POSTS met permalinks
Posts met foto's bevatten alle permalinks en in ons geval opnieuw allemaal naar https://www.makkink.eu/. Ten tijde van dit schrijven praten we over zo'n 1650 permalinks die bewerkt moeten worden.
Dit gaat het beste met het editen met MySQL van de tafel wp_posts.
De permalink met 'www.makkink.eu' kan voorkomen in 2 kolommen zijnde wp_posts.post_content en/of wp_posts.guid

We voeren de volgende updates uit:

MariaDB [wordpress]> UPDATE `wp_posts`
SET post_content=REPLACE(post_content,'www.makkink.eu','192.168.1.5')
WHERE post_content LIKE '%www.makkink.eu%';
Query OK, 367 rows affected (0.06 sec)
Rows matched: 367  Changed: 367  Warnings: 0

MariaDB [wordpress]> UPDATE `wp_posts`
SET guid=REPLACE(guid,'www.makkink.eu','192.168.1.5')
WHERE guid LIKE '%www.makkink.eu%';
Query OK, 1279 rows affected (0.01 sec)
Rows matched: 1279  Changed: 1279  Warnings: 0

Verwijder onnodige adressen uit Email Subscriber

table wp_es_emaillist: alleen admin behouden met adres ben@makkink.eu
table wp_es_pluginconfig: alle voorkomens van erica@makkink.eu wijzigen naar ben@makkink.eu
table wp_ig_campaigns: alle voorkomens van erica@makkink.eu wijzigen naar ben@makkink.eu
table wp_ig_contacts: alle voorkomens van erica@makkink.eu wijzigen naar ben@makkink.eu
table wp_users: alle voorkomens van erica@makkink.eu wijzigen naar ben@makkink.eu

Naar Index

WORDPRESS Navigatie

WORDPRESS::Backup and Restore

Backup

Wordpress migreren met backup data