160 - Czym zaskoczył mnie Gutenberg przy migracji contentu?

Cześć, z tej strony Maciej Kuchnik. Witam Cię w podcaście Rób WordPressa. Jeśli korzystasz z WordPressa, to na pewno znajdziesz tu coś dla siebie. Cześć, witam Cię w 160 odcinku podcastu Rób WordPressa. Dzisiejszy odcinek będzie nieco bardziej programistyczny, będzie również o Gutenbergu i o tym, czym ostatnio zaskoczył mnie Gutenberg. I wbrew pozorom nie będzie to żaden temat związany z łatwością tworzenia stron, elastycznością czy tego typu rzeczami. Zanim przejdziemy do odcinka, wspomnę jeszcze, że wspiera mnie partner mojego podcastu, czyli marka Cyberfolks. W tym tygodniu mieliśmy okazję organizować wspólny webinar WordPress błędy, których nie chcesz popełniać.

Mówiłem tam o często spotykanych błędach i o tym, jak możemy zrobić pewne rzeczy lepiej, aby zapewnić sobie bezproblemową współpracę z naszym WordPressem. Nagranie z tego webinaru będzie na kanale Cyberfolks na YouTube, więc możesz tam zajrzeć i jeśli jeszcze go nie ma, to na pewno w ciągu kilku dni się tam pojawi. Na początku może nakreślę kontekst sytuacji, w której Gutenberg mnie zaskoczył. Są dwie strony. Stara strona, która jest taką stroną produkcyjną, zbudowaną w oparciu o Gutenberga i bloki Gutenbergowe, takie customowe, ale zbudowane w oparciu o ACF i ACF Blocks. Nie są tam natywne, reactowe bloki, tylko po prostu jest użyty ACF do tworzenia tych bloków.

No i jest nowa strona, która obecnie powstaje. I moim zadaniem było przygotowanie skryptów migracyjnych, które zmigrują nam content z jednego WordPressa ze starej strony, która jest na Gutenbergu z ACF-em do nowej strony, gdzie mamy już wszystkie bloki pisane w taki natywny, reactowy sposób. I tak z grubsza rzecz biorąc, sprawa wygląda tak, że w starym i w nowym systemie mamy podobne bloki, natomiast nie jest to 1 do 1 odpowiednik bloku z jednego do drugiego systemu. To znaczy, te bloki mają podobne funkcje, natomiast różnią się różnymi szczegółami. Czasem są niemal identyczne, ale czasem mają np. mniej pól.

Więc na pierwszy rzut poszło przygotowanie takiego skryptu, który załadował mi WordPressa. I że mam dostępne po prostu wszystkie komponenty WordPressa w tym moim skrypcie. W praktyce sprowadza się to do dołączenia pliku wp-load.php do naszego skryptu. I tutaj zaczyna się cała zabawa z danymi. Ze względu na to, że tych danych jest bardzo dużo, No to za źródło danych posłuży mi zupełnie inna baza, czyli tutaj będę operował na dwóch bazach danych. Jedna baza danych to jest oczywiście ta baza danych, na której pracuje WordPress, do którego migrujemy te bloki, czyli jest to ta nowa wersja systemu.

A druga baza danych to jest po prostu zrzut bazy danych z tego produkcyjnego serwisu, który jest obecnie online i z którego musimy się zmigrować do tego naszego nowego WordPressa. Tu w kontekście obsługi dwóch baz danych nie odkrywam żadnego koła na nowo, że tak powiem, bo korzystam oczywiście z tego, co WordPress daje mi w standardzie, czyli korzystam z klasy WPDB do otwarcia sobie drugiego połączenia do bazy danych i wtedy będę miał wszystkie metody dostępne, których będę potrzebował, czy to pod kątem przygotowywania zapytań, choćby metoda PREPARE, Get Results, Get Var, w zależności czego tam będę potrzebował, to wszystko po prostu sobie działa tak jakbyśmy operowali na tej lokalnej bazie WordPressa.

Natomiast tutaj się bardzo pozytywnie zaskoczyłem, no bo WordPress sam w sobie już daje nam sporo takich bardzo przydatnych funkcji. I oczywiście na pierwszy ogień poszła funkcja parseBlocks, gdzie jako argument podajemy po prostu zawartość tego pola postContent z bazy danych i on zwraca nam już elegancko tablicę, w której są zawarte wszystkie bloki z wszystkimi właściwościami. Krótko mówiąc, tutaj już na starcie dostałem jedną wielką tablicę. W której znalazły się dane wszystkich bloków, które były użyte na danej stronie. Oczywiście było tu jeszcze kilka takich trudności choćby pod kątem tego, że niektóre bloki były zagnieżdżone, jeden w drugim i tak dalej.

Jest po prostu funkcja, która przyjmuje tablicę, która jest wynikiem działania funkcji parseBlocks i finalnie generuje po prostu HTML-a z tymi wszystkimi JSON-ami, który jest zapisywany w kontencie w nowym WordPressie. I tutaj z pomocą przyszłymi dwie funkcje, w zasadzie klasa wp-block-parser-block. I tutaj podajemy wszystkie parametry danego bloku, czyli po pierwsze jego nazwę oczywiście, a oprócz tego wszystkie parametry, które mają być zachowane właśnie w tym JSON-ie plus strukturę HTML-ową, która ma zostać zapisana. Potem wynik działania tej klasy wrzucamy w funkcję serialize block i otrzymujemy już takiego HTML-a, którego możemy wrzucić do bazy danych i potem jeśli wejdziemy sobie w edycję takiego wpisu już w panelu edycji tego nowego WordPressa, mamy normalnie blok, tak jakbyśmy wyklikali go ręcznie i pododawali wszystkie parametry do niego.

I tutaj Gutenberg bardzo mnie zaskoczył tym, jak bardzo jest elastyczny i przyjazny w obrabianiu tych wszystkich informacji, które leżą sobie w bazie danych. Myślałem, że tutaj będę się musiał trochę więcej namęczyć, żeby sobie to tak przetwarzać z jednego bloku na drugi, a okazuje się, że to co WordPress i Gutenberg daje już w standardzie, daje bardzo duże możliwości. To poszło bardzo szybko i bardzo fajnie się pisało te kolejne bloki, które trzeba było migrować. Pewien problem pojawił się z grafikami, ponieważ raz, że trzeba było też zadbać o to, aby ze starego WordPressa wyciągnąć grafiki i zmigrować to do nowego WordPressa. I o ile to nie jest jeszcze jakimś tam wielkim problemem, no to problem pojawił się troszkę większy z tym, że wiele grafik było używanych w różnych miejscach.