Kolega DM używa wordpressa na nazwa.pl. Dostawca do czerwca kazał mu zmienić system z Ubuntu 16 na 20 udostępniając stosowny guziczek w panelu https://admin.nazwa.pl/. Po wciśnięciu guziczka z Ubuntu 20 wordpress przestał działać. Trzeba było czterech listów do dostawcy żeby uruchomić WP w Ubuntu 20. A w sumie chodziło o jeden wiersz w konfiguracji (chyba):

/** The name of the database for WordPress */
define('DB_NAME', 'danmarszal_test');
/** MySQL database username */
define("DB_USER", 'danmarszal_test');

W starym systemie nie było deklaracji DB_USER; nie było--to niepotrzebna pomyślałem; a góffno się okazało, że potrzebna i to wcale nie username tylko ma zawierać to samo co DB_NAME. Helpdesk nazwa.pl nie potrafił nam tego wytłumaczyć; ani nie było to jasno napisane w ich (beznadziejnej) dokumentacji.

Teraz dobrze by było zaktualizować WP, bo kolega używa jakiejś prehistorycznej wersji 4.9. Na szczęście jest zainstalowane wp-cli. Dla bezpieczeństwa połączyłem się z nazwa.pl przez sshfs; skopiowałem wsio do siebie i dopiero teraz:

wp core update 

Bezproblemowo zadziałało. Przejście na nowsze PHP znowu skończyło się błędem PHP. Ręcznie z panela WP uaktualniłem pluginy i wtedy aktualizacja PHP też się powiodła. Kolega ma teraz WP6+PHP8. Najnowsze.

Na przyszłość warto wypróbować full-upgrade za pomocą wp-cli, żeby nie klikać:

## najpierw eksport potem upgrade
wp db export && \
wp core update && wp plugin update --all &&\
wp core language update

Zainstalowałem wreszcie WP na raspberry (celem testowania) i to od razu z dostępem z zewnątrz nie żadne tam localhost. Że mam dwa komputerki, które robią za serwery WWW (a router jeden), to sobie wymyśliłem, że będę je rozpoznawał po porcie. W tym celu w Tomato dopisałem jeden wiersz w części port forwarding:

## nafisa.blogsite.org:8080
## Dopisać linijkę w tomato (port forwarding)

## Najpierw: systemctl stop nginx
## Potem wg: https://www.makeuseof.com/tag/host-wordpress-raspberry-pi/

apt install apache2 -y
apt install php -y
apt install mariadb-server-10.0 php-mysql -y

wget http://wordpress.org/latest.tar.gz

Teraz konfigurowanie apache'a: dodane nafisa_blogsite.conf (musi być .conf!) do katalogu /etc/apache2/sites-available/. Następnie:

ln -s /etc/apache2/sites-available/nafisa_blogsite.conf \
  /etc/apache2/sites-enabled/nafisa_blogsite.conf

## wpisanie Listen 8080 do
vi /etc/apache2/ports.conf

systemctl start apache2

Instalowanie mysql/mariadb:

sudo mysql_secure_installation
sudo mysql -uroot -p

create database wordpress;
GRANT ALL PRIVILEGES ON wordpress.* TO 'root'@'localhost'
  IDENTIFIED BY 'PASSWORD';

FLUSH PRIVILEGES;

Teraz mi to beznadziejnie zawisło i nie mogłem się zalogować; do tego nie mogłem też zatrzymać demona mysql. W końcu zabiłem dziada za pomocą kill -9, a po starcie magicznie wszystko zadziałało.

Konfigurowanie WP

Wpisałem z palca do wp-config.php
define( 'DB_NAME', 'wordpress' );
define( 'DB_USER', 'root' );
define( 'DB_PASSWORD', '????' );

Potem uruchomiłem http://nafisa.blogsite.org:8080/wp-admin:

Nazwa bloga: pinkaccordions
User: tomek

## Plugins
## NextGen do tworzenia galerii zdjęć
https://pluginarchive.com/wordpress/nextgen-gallery
https://downloads.wordpress.org/plugin/nextgen-gallery.3.5.0.zip

## Nie podoba mi się ten Gutenberg
## Classic editor vs Gutenberg
https://downloads.wordpress.org/plugin/classic-editor.1.6.zip

Nextgen nie działa (dokładniej upload z dysku nie działa), bo brakuje mu dwóch modułów:

sudo apt-get install php-xml php-gd
sudo service apache2 restart

Gotowe i działa tutaj

Problem jest oto taki, że chcę przenieść kopię bloga (oryginał jest/był na serwerze nazwa.pl) na Sheevaplug (taki rodzaj NAS), która byłaby dostępna przez Internet. Pierwszy krok do likwidacji bloga na nazwa.pl, bo drogo BTW.

Na Sheevaplug jest zainstalowany Debian w wersji Stretch i nie ma WordPressa.

Rozpocząłem od pobrania narzędzia wp-cli ze strony wp-cli.org/. Zainstalowałem toto (prawie) w sposób opisany na ww. stronie, tj.:

https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar ~/bin/wp

Heurystycznie ustaliłem, że treść tego konkretnego klonowanego bloga znajduje się bazie mysql (teksty) oraz w katalogu wp-content, w którym to w szczególności są zdjęcia (wp-content/gallery) oraz filmy i chmara jakiś plików .gif (wp-content/wp-uploads). Oprócz tego są jeszcze katalogi themes, upgrade, plugins, ngg oraz languages. Uprzedzając wydarzenia wszystko kopiuję jak leci ze starej instalacji (w obu jest/będzie ta sama wersja WP). Natomiast teksty z bazy eksportuję (do pliku SQL):

 wp db export

Można też to zrobić logując się do URL-BLOGA/wp-admin. Teraz wszystko ściągam korzystając z rsync (/media/WP-SITE/ oraz /media/WPSQL/ to oczywiście przykłady):

rsync -avzP -e "ssh" USER@BLOG:PATH-TO-WP/wp-content/* /media/WPSITE/
rsync -avzP -e "ssh" USER@BLOG:PATH-TO-WP/_sqldump_/* /media/WPSQL/

Zamiast rsync można użyć ftp albo:

scp -r USER@BLOG:path/to/files/

Teraz pobrałem archiwum WP ze strony wordpress.org/download/ i rozpakowałem je (Uwaga: być może można skopiować po prostu całą starą instalację WP na nowy komputer i będzie działać, ale ja tak nie robiłem.):

wget https://wordpress.org/latest.tar.gz
tar -zxvf latest.tar.gz

Za pomocą klienta mysql stworzyłem użytkownika pn. wordpress, który otrzymał stosowne uprawnienia. Utworzyłem następnie bazę pn. wordpress:

  mysql> CREATE USER 'user'@'localhost' IDENTIFIED BY 'password';
  mysql> CREATE DATABASE wordpress;
  Query OK, 1 row affected (0.00 sec)
 
  mysql> GRANT ALL PRIVILEGES ON wordpress.* TO 'user'@'localhost'
  -> IDENTIFIED BY '*password*';
    Query OK, 0 rows affected (0.00 sec)

Następnie wstawiłem stosowne wpisy do wp-config.php

define('DB_NAME', 'wordpress');
define('DB_USER', '**USER**');
define('DB_PASSWORD', '**PASSWORD**');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');

Teraz zaimportowałem treść bloga do bazy:

wp db import kopia-bazy.sql --path='/var/www/html/'

Doczytałem, że trzeba zmienić URLe ze starych na nowe:

wp search-replace 'STARY-URL' 'NOWY-URL' --dry-run

Konkretnie w moim przypadku:

  wp search-replace 'http://nazwabloga.nazwa.pl/' 'http://oberon.pinkaccordions.org/' \
  --path='/var/www/html/' --dry-run
  ## --dry-run nic nie zmienia ale wyświetla raport
  ## jeżeli wszystko jest OK:
    wp search-replace 'http://nazwabloga.nazwa.pl/' 'http://oberon.pinkaccordions.org/' \
     --path='/var/www/html/'

Sprawdzam i nie działa, ale wypisuje, że nie ma jakiegoś theme. No to kopiuję jak leci ze starej instalacji katalogi themes, upgrade, plugins, ngg, languages, o czym już pisałem. Teraz działa.

Jeszcze został problem udostępnienia tego w Interncie poprzez DynDNS. Sprawę komplikuje to, że mam już dwa zarejestrowane serwisy a Tomato wydaje się obsługiwać tylko dwa hosty. Okazuje się wszakże że pole host niekoniecznie musi zawierać pojedynczy wpis, może zawierać listę oddzielonych przecinkami nazw hostów. No to dopisałem następny host z puli, którą mam oraz dopisałem co trzeba w Tomato.

Dodatkowa komplikacja jest taka, że chcę ten sklonowany blog udostępnić na innym komputerze. Konkretnie do tej pory udostępniałem jeden komputer, a teraz będą dwa. Na taką okoliczność oprócz dopisania nazwy hosta do listy trzeba także zmodyfikować wpis w części port forwarding (por. rysunek). Drugi komputer wymaga mianowicie zadeklarowania innego ExPort-u.)

Po tym wszystkim nadal działa:-)

Kol. DM pisze sobie bloga używając WordPressa. Trochę go to kosztuje więc pojawiła się koncepcja żeby przeszedł na bezpłatnego Bloggera. Początkiem tej koncepcji jest oczywiście konwersja WP do formatu Bloggera.

Wpisy kol. DM zawierają tekst i dużo zdjęć oraz innych rysunków. Nie mam bladego pojęcia nt. WordPressa, ale dość szybko ustaliłem, że można wyeksportować treść posługując się stosowną funkcją dostępną z Kokpit→Narzędzia→Eksport (powstaje plik w formacie WordPress eXtended RSS -- WXR).

Plik WXR zapisujemy na dysku. Można go zamienić do formatu Bloggera korzystując z konwertera dostępnego tutaj. Jest wprawdzie napisane, że konwerter obsługuje pliki nie większe niż 1Mb, ale mój miał 4Mb i też poszło.

Plik kolegi DM zawiera tekst oraz prawidłowe linki do niektórych rysunków. Inne rysunki są wstawiane sprytnym czymś co nazywane jest shortcode (cf Shortcode API.) Nie wchodząc w szczegóły, zamiast rysunków w treści postu jest umieszczone np. coś takiego:

[nggallery id=506]

506 z kolei jest identyfikatorem zbioru rysunków, które fizycznie są przechowywane w katalogu:

wp-content/gallery

Każda galeria jest w oddzielnym katalogu, ale nazwami katalogów nie są identyfikatory typu 506 ale coś innego. Logując się do phpMyAdmin byłem w stanie ściągnąć całą bazę (w formacie SQL), w której siedzi WordPress. W jednej z tabel bazy znalazłem przypisanie id_galerii→nazwa-katalogu-z-plikami

INSERT INTO `wp_ngg_gallery` (`gid`, `name`, `slug`, 
`path`, `title`, `galdesc`, `pageid`, `previewpic`, `author`) VALUES
(17, 'gottardo_2', '', 'wp-content/gallery/gottardo_2', '', '', 0, 0, 1),
(16, 'gottardo_1', '', 'wp-content/gallery/gottardo_1', '', '', 0, 0, 1),
(15, 'nufenen', '', 'wp-content/gallery/nufenen', NULL, NULL, 0, 0, 1),
... itd ...

Czyli zawartość czegoś, co w treści wygląda jak:

[nggallery id=15]

Znajduje się w katalogu wp-content/gallery/nufenen.

Teraz ściągnąłem cały katalog wp-content na dysk lokalny wykorzystując ncftp

ncftp -u USER -p PASS HOST
get -R -T wp-content

Następnie zamieniłem nazwy plików w następujący sposób:

nr_galerii__nazwa_pliku

Pliki wysłałem na google za pomocą skryptu. Istotne jest to, że skrypt po załadowaniu, zwraca URL zdjęcia pod którym jest ono dostępne na koncie googla:

100__fra_07063.jpg http://lh5.ggpht.com/-26SgLqsS1vM/UhdwT-Q62CI/AAAAAAAAABQ/k_ipaT4SNsE/100__fra_07063.jpg
100__fra_07064.jpg http://lh4.ggpht.com/-1kWivWwiZW4/UhdwU4vZWPI/AAAAAAAAABY/XxuIGrIPj8Q/100__fra_07064.jpg
itd...

Czyli zdjęcie 100__fra_07063.jpg (oryginalnie należące go galerii o identyfikatorze równym '100') jest dostępne pod adresem:

http://lh5.ggpht.com/-26SgLqsS1vM/UhdwT-Q62CI/AAAAAAAAABQ/k_ipaT4SNsE/100__fra_07063.jpg

Uwaga: Album ze zdjęciami na koncie googla może zawierać maksymalnie 1000 zdjęć. Jeżeli zdjęć jest więcej trzeba utworzyć więcej albumów.

Skryptem Perla (wyrażenia regularne/regułowe) zamieniam każde [nggallery id=506] na stosowny ekwiwalent. Przykładowo:

<div id='gid_g509'>
<span>< a href="http://lh5.ggpht.com/-NZ_dEAq8qZI/Uhf_OPG9jiI/AAAAAAAADp8/BtBx9DwVgs4/509__1106_016.jpg" 
 imageanchor="1" style="margin-bottom: 1em; margin-right: .1em;">
<img border="0" src="http://lh5.ggpht.com/-NZ_dEAq8qZI/Uhf_OPG9jiI/AAAAAAAADp8/BtBx9DwVgs4/s128/509__1106_016.jpg" 
  height='85' /></a>
</span>
 ... itd ...

Pozostałe zdjęcia mają `prawdziwe URLe' (a nie jakieś shortcody), ale oczywiście URLe te są złe bo wskazują na starego hosta. Zdjęcia te (z `prawdziwymi URLami') są przechowywane w katalogu ./wp-content/uploads. Ze zdjeciami postępuję, tak jak w przypadku zdjęć z galerii: 1) wysyłam na konto google skryptem; 2) zmieniam oryginalne URLe na URLe z konta google (skryptem Perla).

Przed importem do Bloggera warto sprawdzić czy plik, który ma być zaimportowany jest well-formed:

xmllint plik-do-zaimportowania.xml