Migracja WordPressa i WooCommerce na inny serwer - Design Cart Migration

Jak z pozornie prostego problemu z Better Search Replace narodziła się moja własna wtyczka do migracji WordPressa, obsługująca JSON, serializację PHP, inteligentną zamianę adresów oraz eksport gotowej bazy SQL.

Przenoszenie stron internetowych z lokalnego środowiska programistycznego na serwer produkcyjny jest częścią mojej codziennej pracy. Przez lata wykonałem wiele takich migracji. WordPress, WooCommerce, rozbudowane motywy, dziesiątki wtyczek, konfiguracje zapisane w bazie danych — każda strona ma swoją specyfikę, ale pewne problemy powtarzają się niemal zawsze.

Jednym z nich jest zamiana adresów URL po migracji WordPressa.

Przez długi czas korzystałem w tym celu z popularnej wtyczki Better Search Replace. To przydatne narzędzie, które sprawdza się w wielu sytuacjach. Nie zamierzam przekonywać, że jest złe albo że mój projekt jest pod każdym względem lepszy.

Problem polegał na czymś innym.

W przypadku niektórych rozbudowanych stron, szczególnie sklepów opartych na WooCommerce, po wykonaniu zamiany w bazie nadal znajdowałem odwołania do starego adresu. Najczęściej były to pozostałości po lokalnym środowisku developerskim.

Strona działała już pod właściwą domeną, ale gdzieś w ustawieniach wtyczki, zapisanym obiekcie JSON albo zagnieżdżonej tablicy nadal ukrywał się localhost .

Wtedy zaczynała się najmniej interesująca część pracy.

Trzeba było odnaleźć problematyczny rekord, sprawdzić sposób przechowywania danych, poprawić adres i upewnić się, że zmiana nie uszkodziła struktury. Niekiedy wystarczało kilka minut. Innym razem taka pozornie drobna poprawka potrafiła zabrać znacznie więcej czasu.

A przecież nie po to zajmuję się programowaniem, żeby ręcznie poprawiać coś, co powinien zrobić komputer. 🙂

Właśnie dlatego powstał Design Cart Migration — darmowa wtyczka WordPress, którą napisałem przede wszystkim po to, aby rozwiązać problem spotykany we własnej pracy.

Dzisiaj jest wręcz niezbędny przy tworzeniu stron internetowych dla firm. 

1. Dlaczego Better Search Replace nie zawsze wystarczał?

Żeby dobrze zrozumieć sens powstania Design Cart Migration, trzeba najpierw przyjrzeć się sposobowi, w jaki WordPress i WooCommerce przechowują informacje.

Na pierwszy rzut oka zamiana domeny wydaje się banalna.

Mamy stary adres:

http://localhost/posciel

I chcemy zastąpić go nowym:

https://www.mojsklep.pl

W zwykłym tekście wystarczy wykonać operację wyszukiwania i zamiany. Problem w tym, że baza WordPressa nie składa się wyłącznie ze zwykłego tekstu.

Adresy mogą występować w różnych postaciach, a część z nich znajduje się wewnątrz bardziej skomplikowanych struktur danych.

Problem pierwszy: adresy URL zapisane w JSON

WooCommerce i dodatkowe rozszerzenia korzystają między innymi z formatu JSON.

W takim przypadku adres URL może wyglądać następująco:

         {
  "product_url": "http:\/\/localhost\/posciel\/produkt"
} 

Zwróć uwagę na ukośniki.

Szukamy:

http://localhost/posciel

Tymczasem w surowej wartości zapisanej w bazie znajduje się:

http:\/\/localhost\/posciel

Dla człowieka to ten sam adres. Dla prostego wyszukiwania tekstowego są to dwa różne ciągi znaków.

W praktyce właśnie tego rodzaju przypadki pozostawały po niektórych migracjach, które wykonywałem.

Jak rozwiązałem ten problem?

W Design Cart Migration nie ograniczyłem się do wyszukiwania dosłownego tekstu.

Jeżeli wtyczka rozpozna poprawną strukturę JSON, może ją odczytać, przejść przez jej zawartość, wykonać zamianę i ponownie zapisać w formacie JSON.

Dzięki temu adres ukryty za escapowanymi ukośnikami nie musi pozostać niezauważony.

Co ważne, mechanizm uwzględnia również sposób zapisu ukośników w oryginalnym JSON.

Problem drugi: adres URL jako klucz tablicy

To jeden z ciekawszych przypadków, z którymi się zetknąłem.

Wyobraźmy sobie, że jedna z wtyczek przechowuje mapę adresów:

[
    'http://localhost/posciel' => [
        'enabled' => true,
        'type' => 'shop'
    ]
]

Stary adres nie jest tutaj wartością. Jest kluczem tablicy.

Niektóre mechanizmy zamiany lub sposoby przetwarzania struktur koncentrują się na wartościach, a klucze mogą zostać pominięte.

W efekcie po migracji można znaleźć strukturę, w której nowe adresy współistnieją ze starymi.

W Design Cart Migration zdecydowałem się uwzględnić zarówno wartości, jak i tekstowe klucze tablic.

Jeżeli adres jest kluczem mapy, również zostaje objęty mechanizmem zamiany.

To niewielka różnica w podejściu, ale w pewnych konfiguracjach potrafi wyeliminować bardzo irytujący problem.

Problem trzeci: serializacja PHP i zagnieżdżone struktury

WordPress intensywnie wykorzystuje serializację PHP.

Jest to sposób zapisywania tablic i innych struktur jako ciągów znaków, które później można odtworzyć.

Przykładowy zapis może wyglądać tak:

      
        a:1:{s:3:"url";s:22:"http://localhost/sklep";}
      
    

Długości tekstów są częścią tego formatu. Jeżeli wykonamy nieprawidłową zamianę i nie uwzględnimy zmiany długości adresu, możemy uszkodzić cały zapis.

Better Search Replace obsługuje dane serializowane i warto to jasno powiedzieć. Nie jest więc tak, że każda serializacja stanowi dla niego problem.

W moim przypadku trudności pojawiały się przy bardziej rozbudowanych kombinacjach: strukturach zagnieżdżonych, JSON-ie przechowywanym wewnątrz serializacji czy mapach wykorzystujących adresy jako klucze.

Dlatego we własnym silniku zastosowałem przetwarzanie rekurencyjne.

W uproszczeniu wygląda to następująco:

Nie trzeba więc zakładać, że wszystko znajdujące się w komórce bazy danych jest zwykłym tekstem.

Wtyczka próbuje rozpoznać strukturę i przetworzyć ją w sposób odpowiadający formatowi danych.

Oczywiście nie oznacza to obsługi każdego możliwego, niestandardowego formatu wykorzystywanego przez dowolną wtyczkę WordPress. Chodzi o wyeliminowanie problemów występujących w typowych strukturach JSON i serializacji PHP.

Problem czwarty: wiele wariantów tego samego adresu URL

Jedna domena może występować w bazie w różnych formach:

http://localhost/posciel
https://localhost/posciel
http://localhost/posciel/
https://localhost/posciel/

http:\/\/localhost\/posciel
https:\/\/localhost\/posciel

\/\/localhost\/posciel

Do tego dochodzą warianty z dodatkowymi znakami ucieczki czy adresy pozbawione jawnie wskazanego protokołu.

Wykonywanie osobnego wyszukiwania dla każdej postaci jest czasochłonne.

Dlatego przygotowałem mechanizm Smart URL.

Po podaniu starego i nowego adresu wtyczka buduje zestaw typowych wariantów, uwzględniając między innymi protokoły HTTP i HTTPS, ukośniki oraz zapisy escaped.

Zamiany wykonywane są z uwzględnieniem długości dopasowywanych ciągów — dłuższe warianty mają pierwszeństwo.

Dzięki temu nie trzeba ręcznie przygotowywać kilkunastu podobnych operacji.

Problem piąty: kolumna GUID w WordPressie

W tabeli wp_posts WordPress przechowuje między innymi pole guid .

Podczas migracji mogą w nim pozostać adresy starej domeny.

Postanowiłem udostępnić możliwość zamiany także tego pola. W przypadku eksportu i migracji opcja jest domyślnie włączona.

Tutaj jednak warto zaznaczyć ważną rzecz: GUID nie jest zwykłym adresem strony.

W WordPressie pełni rolę trwałego identyfikatora wpisu. Jego zmiana nie jest standardowo zalecana przy zwykłym przenoszeniu domeny, ponieważ może mieć konsekwencje między innymi dla czytników RSS i identyfikacji treści.

Dlatego w Design Cart Migration użytkownik może zdecydować, czy chce objąć tę kolumnę zamianą. Domyślne włączenie opcji wynika z przyjętego przeze mnie scenariusza przenoszenia środowiska developerskiego, ale przy migracji istniejącego, publicznego serwisu warto rozważyć jej wyłączenie.

2. Design Cart Migration — co właściwie potrafi?

Kiedy zacząłem projektować tę wtyczkę, szybko doszedłem do wniosku, że sama bardziej zaawansowana zamiana adresów nie wystarczy.

Chciałem zmienić również sposób przeprowadzania migracji.

Do tej pory częsty scenariusz wyglądał tak: eksport bazy danych, import na nowym serwerze, instalacja lub uruchomienie narzędzia do zamiany adresów, kilka testów i ewentualne ręczne poprawki.

A gdyby część tej pracy można było wykonać wcześniej, jeszcze na lokalnym komputerze?

Właśnie stąd wzięły się dwa główne tryby Design Cart Migration.

Oba tryby korzystają z tego samego mechanizmu przetwarzania struktur danych.

Dzięki temu niezależnie od tego, czy przygotowuję plik SQL na localhost, czy poprawiam już zaimportowaną bazę na serwerze, mogę korzystać z tych samych zasad zamiany adresów.

3. Instalacja Design Cart Migration

Wtyczka została przygotowana jako standardowe rozszerzenie WordPressa.

Nie wymaga korzystania z terminala ani ręcznego uruchamiania zapytań SQL, aby przeprowadzić podstawowe operacje.

Instalacja wygląda następująco:

1. Pobieramy archiwum ZIP z wtyczką Design Cart Migration.

2. W panelu WordPress przechodzimy do Wtyczki → Dodaj nową wtyczkę → Wyślij wtyczkę na serwer.

3. Wybieramy plik ZIP i uruchamiamy instalację.

4. Aktywujemy wtyczkę.

5. W lewym menu administracyjnym pojawi się pozycja Migration.

Po jej otwarciu uzyskujemy dostęp do kokpitu i dwóch głównych funkcji.

Wymagania techniczne

Projekt nie jest ograniczony wyłącznie do WooCommerce. Można wykorzystać go również przy migracji zwykłego bloga, strony firmowej czy serwisu korzystającego z innych rozszerzeń WordPressa.

WooCommerce był jednak jednym z powodów, dla których postanowiłem przygotować bardziej zaawansowany mechanizm zamiany.

4. Kokpit — centrum zarządzania migracją

Po wejściu do zakładki Migration → Kokpit zobaczymy panel przygotowany w stylistyce Design Cart.

Nie chciałem tworzyć kolejnego ekranu administracyjnego wypełnionego dziesiątkami ustawień, których przeznaczenie trzeba najpierw rozszyfrować.

Zależało mi na prostym podziale funkcji.

W kokpicie znajdują się dwa główne kafelki: Eksport SQL oraz Zamiana na żywo.

Kokpit pełni przede wszystkim funkcję nawigacyjną. Nie trzeba przechodzić przez kreator, zakładać projektu ani zapisywać osobnych profili migracji.

Wybieramy interesującą nas operację i przechodzimy do konfiguracji.

5. Zakładka Eksport SQL — przenoszenie bazy z gotowymi adresami

Migration → Eksport SQL

To funkcja, na której szczególnie mi zależało.

W tradycyjnym scenariuszu migracji najpierw eksportujemy bazę danych z localhost, następnie importujemy ją na serwer produkcyjny, a dopiero później wykonujemy zamianę adresów.

Design Cart Migration pozwala odwrócić tę kolejność.

Adresy zostają zamienione podczas przygotowywania pliku SQL, jeszcze przed jego importem na docelowy serwer.

Dzięki temu nie muszę uruchamiać dodatkowego narzędzia na produkcji wyłącznie po to, żeby zastąpić stare URL-e nowymi.

Sekcja „Adresy URL”

To pierwsza i najważniejsza część formularza eksportu.

Przykładowa konfiguracja:

Wtyczka przygotuje eksport z uwzględnieniem podanej pary adresów.

Co ważne, nie zamienia jedynie zawartości prostych pól tekstowych. W trakcie tworzenia zrzutu wykorzystuje silnik obsługujący również rozpoznane struktury JSON i serializacji PHP.

Sekcja „Tabele”

Przy rozbudowanych instalacjach WordPressa baza może zawierać kilkadziesiąt, a nawet kilkaset tabel.

WooCommerce zapisuje w nich informacje o produktach, zamówieniach, klientach, ustawieniach i dodatkowych funkcjonalnościach.

Nie każdą operację muszę przeprowadzać na całej bazie.

Dlatego w Design Cart Migration umieściłem listę tabel wraz z informacją o ich rozmiarach.

Tabele sortowane są od największych do najmniejszych, co pozwala szybko zorientować się, które z nich mogą wymagać najwięcej pracy.

Przy eksporcie produkcyjnym zazwyczaj zależy mi na kompletnej bazie danych. Natomiast podczas testów możliwość pominięcia największych tabel jest bardzo wygodna.

Przykładowo, mogę skoncentrować się na sprawdzeniu danych konfiguracyjnych, bez każdorazowego przetwarzania ogromnej tabeli zawierającej historię działania dodatkowej wtyczki.

Ważne: eksport wyłącznie wybranych tabel nie jest pełną kopią bazy. Taki plik należy traktować jako eksport częściowy.

Generowanie i pobieranie pliku SQL

Po uzupełnieniu pól i wybraniu tabel wystarczy kliknąć Pobierz dump SQL.

Wtyczka rozpoczyna przygotowywanie pliku.

Podczas pracy wyświetla okno postępu, w którym można obserwować stan eksportu. Operacja jest realizowana partiami, z wykorzystaniem AJAX.

Nie chciałem sytuacji, w której po kliknięciu przycisku widzimy tylko obracający się wskaźnik i nie wiemy, czy proces jeszcze działa.

Po zakończeniu eksportu wtyczka udostępnia plik SQL do pobrania. Pobieranie może rozpocząć się automatycznie, ale dostępny jest także osobny przycisk, gdyby przeglądarka nie uruchomiła go samodzielnie.

To również efekt praktycznych doświadczeń. Przy tworzeniu kolejnych wersji poprawiałem między innymi sposób pobierania plików, tak aby rozpoczęcie downloadu nie powodowało niepotrzebnych problemów z opuszczaniem strony.

Wygenerowany dump zawiera instrukcje SQL pozwalające odtworzyć eksportowane tabele i ich dane.

Trzeba przy tym pamiętać o istotnej rzeczy: Design Cart Migration eksportuje bazę danych, a nie pliki WordPressa.

Katalog wp-content/uploads , motywy, wtyczki oraz pozostałe pliki witryny trzeba przenieść osobno.

6. Zakładka Zamiana na żywo — poprawianie adresów w istniejącej bazie

Migration → Zamiana na żywo

Nie każda migracja przebiega według tego samego scenariusza.

Czasami otrzymuję od klienta stronę, która została już przeniesiona na nowy serwer. Pliki znajdują się we właściwym miejscu, baza została zaimportowana, WordPress działa, ale w ustawieniach nadal występują stare adresy.

Innym razem muszę zmienić domenę już działającej witryny albo poprawić pozostałości po poprzedniej migracji.

W takich sytuacjach eksport SQL nie zawsze jest potrzebny.

Dlatego przygotowałem drugi tryb — Live Replace.

Pozwala on bezpośrednio przetwarzać dane w aktualnej bazie WordPressa.

Sekcja „Stary → nowy adres”

Dry-run — sprawdzenie przed wykonaniem zmian

To jedna z opcji, które szczególnie doceniam przy pracy na cudzych stronach.

W operacjach dotyczących bazy danych nie zawsze możemy pozwolić sobie na eksperymenty.

Przypadkowa zamiana niewłaściwego fragmentu adresu albo nieprawidłowo skonfigurowany zakres może spowodować problemy z działaniem strony.

Dlatego tryb Dry-run jest domyślnie aktywny.

W tym trybie Design Cart Migration przechodzi przez dane i sprawdza, jakie zmiany należałoby wykonać, ale ich nie zapisuje.

Możemy więc przeanalizować zakres operacji, zanim zdecydujemy się na rzeczywistą modyfikację bazy.

Po zakończeniu otrzymujemy raport podsumowujący wyniki.

Raport z przeprowadzonej operacji

Raport zawiera informacje o liczbie zmienionych komórek i zaktualizowanych wierszy.

Dane prezentowane są także z podziałem na tabele.

Dzięki temu łatwiej ocenić, gdzie znajdowały się stare adresy.

Przykładowo, jeśli większość zmian dotyczy tabeli opcji, może to sugerować, że problem leży przede wszystkim w zapisanych ustawieniach.

Z kolei liczne zmiany w metadanych wpisów lub produktów mogą wskazywać na adresy zapisane przez motywy, kreatory stron lub dodatkowe rozszerzenia.

Rzeczywista zamiana adresów

Po przeprowadzeniu symulacji i sprawdzeniu wyników możemy wyłączyć Dry-run i uruchomić właściwą operację.

Wtyczka wyświetla dodatkowe potwierdzenie, ponieważ tym razem dane zostaną zmodyfikowane.

Warto wcześniej przygotować kopię zapasową bazy danych.

To rozwiązanie ma przede wszystkim ułatwiać świadomą pracę z danymi, a nie zastępować standardowe procedury bezpieczeństwa.

Wybór tabel w Live Replace

Podobnie jak podczas eksportu SQL, również tutaj możemy wybrać tabele do przetworzenia.

Dostępne są te same funkcje: zaznaczanie wszystkich tabel, odznaczanie, pomijanie tabel o rozmiarze co najmniej 10 MB oraz indywidualny wybór.

W aktualnej wersji kodu brak zaznaczonych tabel interpretowany jest jako wybór wszystkich. Dlatego przed uruchomieniem zamiany warto sprawdzić, czy zaznaczono właściwy zakres.

Operacja przetwarza rekordy partiami po 500 wierszy.

Interfejs informuje o trwającym procesie, a po jego zakończeniu wyświetla raport. W odróżnieniu od eksportu SQL aktualna ścieżka Live Replace nie pokazuje szczegółowego, procentowego postępu aktualizowanego po każdej partii — mimo że mechanizm obsługi pojedynczych partii AJAX jest już obecny w kodzie.

7. Eksport SQL czy Live Replace — który tryb wybrać?

Obie funkcje rozwiązują podobny problem, ale przeznaczone są do nieco innych scenariuszy.

W mojej codziennej pracy najbardziej przydaje się eksport SQL, ponieważ często przygotowuję strony lokalnie, a dopiero po zakończeniu prac przenoszę je na serwer klienta.

Live Replace traktuję jako drugi sposób wykorzystania tego samego narzędzia — szczególnie przy poprawkach już działających instalacji.

8. Przykład migracji WordPressa i WooCommerce — od localhost do produkcji

Pokażę teraz, jak wygląda przykładowy proces.

Załóżmy, że przygotowuję sklep WooCommerce pod adresem:

http://localhost/posciel

Docelowo sklep ma działać pod domeną:

https://www.mojsklep.pl

1. Przygotowuję lokalną instalację

   Kończę prace nad sklepem, sprawdzam produkty, strony, ustawienia WooCommerce i działanie dodatkowych wtyczek. Przygotowuję również kopię bezpieczeństwa.

2. Uruchamiam Design Cart Migration

   W panelu administracyjnym wybieram Migration → Eksport SQL i wpisuję nowy adres domeny.

3. Konfiguruję zamianę

   Pozostawiam aktywne Smart URL, wybieram odpowiednie tabele i podejmuję decyzję dotyczącą kolumny GUID.

4. Generuję zrzut SQL

   Wtyczka przygotowuje bazę z nowymi adresami, uwzględniając także rozpoznane struktury serializowane i JSON.

5. Przenoszę pliki i bazę na serwer

   Kopiuję pliki strony, w tym katalog mediów, importuję SQL oraz konfiguruję połączenie WordPressa z bazą.

6. Sprawdzam działanie sklepu

   Testuję stronę główną, produkty, koszyk, zamówienia, elementy multimedialne oraz ustawienia zależne od domeny. W razie potrzeby odświeżam permalinki i czyszczę pamięć podręczną.

9. Co Design Cart Migration robi inaczej niż Better Search Replace?

Wrócę jeszcze na chwilę do narzędzia, od którego zaczęła się cała historia.

Nie chcę przedstawiać Better Search Replace jako wtyczki wykonującej wyłącznie prostą operację str_replace() . To byłoby nieuczciwe. Narzędzie obsługuje serializację PHP, oferuje Dry-run i od lat pomaga użytkownikom WordPressa.

Różnica polega przede wszystkim na zakresie, jaki postanowiłem objąć własnym rozwiązaniem.

W Design Cart Migration skoncentrowałem się na problemach, które spotykałem przy rzeczywistych migracjach sklepów internetowych.

Nie jest to ranking jakości obu wtyczek ani pełne porównanie wszystkich funkcji Better Search Replace. To zestaw możliwości, które uznałem za istotne podczas projektowania własnego narzędzia.

Najważniejszą zmianą jest dla mnie możliwość przygotowania bazy z docelowymi adresami, zanim trafi ona na produkcję.

Nie muszę już wykonywać całego procesu tylko po to, aby później uruchomić kolejny etap zamiany URL-i.

10. Bezpieczeństwo — o czym należy pamiętać?

Wtyczka pracująca bezpośrednio na bazie danych musi być traktowana z odpowiednią ostrożnością.

Dlatego Design Cart Migration korzysta z mechanizmów kontroli uprawnień administracyjnych WordPressa, weryfikacji nonce oraz walidacji tabel, które mogą zostać przetworzone.

Dodatkowo:

• Tryb Dry-run pozwala ocenić zmiany bez ich zapisywania.

• Przed rzeczywistą operacją Live Replace wyświetlane jest potwierdzenie.

• Można ograniczyć zakres przetwarzanych tabel.

• Silnik uwzględnia strukturę serializowanych danych zamiast wykonywać bezwarunkową zamianę we wszystkich bajtach zapisu.

• Raport informuje o przeprowadzonych zmianach i zgłoszonych błędach.

Mimo tych zabezpieczeń zawsze zalecam utworzenie kopii bazy przed rzeczywistą zamianą.

Żadna wtyczka nie jest w stanie przewidzieć każdego niestandardowego sposobu zapisywania informacji, jaki może pojawić się w ekosystemie WordPressa.

Trzeba również pamiętać, że wygenerowany plik SQL może zawierać poufne dane, w tym informacje o użytkownikach i klientach WooCommerce. Nie należy udostępniać takiego pliku publicznie ani pozostawiać go w ogólnodostępnym katalogu serwera.

11. Dla kogo przygotowałem Design Cart Migration?

Przede wszystkim dla osób, które regularnie przenoszą strony WordPressa między środowiskami.

Nie trzeba prowadzić agencji ani zajmować się programowaniem zawodowo, żeby skorzystać z tego narzędzia, ale podejrzewam, że to właśnie developerzy najłatwiej zrozumieją problem, który chciałem rozwiązać.

Szczególnie przydatne może być dla:

• Developerów WordPressa, przygotowujących strony lokalnie i publikujących je na serwerach klientów.

• Twórców sklepów WooCommerce, którzy pracują z bardziej rozbudowanymi strukturami danych.

• Agencji interaktywnych, wykonujących regularne migracje i wdrożenia.

• Administratorów serwisów, którzy muszą zmienić domenę albo poprawić adresy po przeniesieniu strony.

• Freelancerów, którzy chcą ograniczyć liczbę ręcznych czynności podczas wdrożeń.

Nie projektowałem tej wtyczki jako kompletnego systemu klonowania WordPressa jednym kliknięciem. Nie przenosi ona plików, nie zakłada automatycznie bazy na nowym serwerze ani nie konfiguruje usług hostingowych.

Jej zadaniem jest coś bardziej konkretnego: przygotować lub poprawić dane w bazie WordPressa podczas zmiany adresu witryny.

I właśnie tę czynność chciałem maksymalnie uprościć.

12. Pobieranie Design Cart Migration

Design Cart Migration jest projektem udostępnianym na licencji GPLv2 lub nowszej.

Wtyczkę przygotowałem w taki sposób, aby można było zainstalować ją standardowo z archiwum ZIP, bez konieczności ręcznego kopiowania pojedynczych plików PHP.

Design Cart Migration

WordPress • Wersja 1.0.4 • GPLv2+

Eksport SQL, Smart URL, Live Replace i Dry-run.

0

Rozwój projektu

Wersja 1.0.4 jest efektem kilku kolejnych poprawek.

Pierwsza wersja wprowadziła podstawowe funkcje eksportu i zamiany. Później rozbudowałem mechanizmy JSON i serializacji, dodałem obsługę postępu eksportu, poprawiłem sposób pobierania gotowych plików i rozwinąłem interfejs wyboru tabel.

Nie ukrywam, że część tych zmian powstała po prostu dlatego, że podczas testów napotykałem kolejne niewygodne sytuacje.

To naturalna droga rozwoju narzędzia, którego sam zamierzam używać.

13. Dlaczego napisałem kolejną wtyczkę, skoro istnieją już podobne?

To pytanie, które sam sobie czasami zadaję.

Ekosystem WordPressa jest ogromny. Na wiele problemów istnieje już kilka, kilkanaście albo kilkadziesiąt rozwiązań.

Nie zawsze jest sens pisać własne.

Ale bywa też tak, że używając istniejącego narzędzia przez kilka lat, zaczynamy bardzo dokładnie dostrzegać jego ograniczenia w naszym konkretnym sposobie pracy.

Tak było w przypadku migracji.

Better Search Replace przez długi czas pomagał mi przy wdrożeniach i nadal uważam go za przydatne narzędzie.

Po prostu w pewnym momencie zmęczyło mnie ręczne szukanie pozostałości po starych adresach.

Zwłaszcza że były to problemy przewidywalne.

Wiedziałem, że adres może znajdować się w JSON-ie. Wiedziałem, że może być kluczem tablicy. Wiedziałem, że ten sam URL może zostać zapisany z escapowanymi ukośnikami albo wewnątrz serializowanej struktury.

Skoro te sytuacje powtarzają się podczas kolejnych migracji, dlaczego nie przygotować mechanizmu, który spróbuje obsłużyć je automatycznie?

Nie chodziło o stworzenie najbardziej rozbudowanego migratora WordPressa na rynku.

Chodziło o oszczędzenie czasu.

Czasu, który znacznie chętniej poświęcam na programowanie nowych funkcjonalności, projektowanie interfejsów czy rozwiązywanie ciekawszych problemów niż ręczne poprawianie tych samych adresów w bazie danych.

14. Podsumowanie

Design Cart Migration powstał z bardzo praktycznej potrzeby.

Chciałem uprościć przenoszenie WordPressa i WooCommerce między środowiskami, a przede wszystkim ograniczyć liczbę sytuacji, w których po migracji trzeba jeszcze ręcznie naprawiać adresy zapisane w nietypowych strukturach.

Dlatego w jednym narzędziu połączyłem zaawansowaną zamianę URL-i, obsługę JSON i serializacji PHP, mechanizm Smart URL, eksport SQL oraz możliwość modyfikacji bieżącej bazy z wcześniejszą symulacją Dry-run.

Czy oznacza to, że od tej pory każda migracja WordPressa przebiegnie bez najmniejszego problemu?

Oczywiście, że nie.

WordPress to ogromny ekosystem, a każda dodatkowa wtyczka może wprowadzać własne sposoby przechowywania informacji.

Mam jednak nadzieję, że Design Cart Migration pomoże wyeliminować przynajmniej część tych drobnych, powtarzalnych problemów, które potrafią zabrać zaskakująco dużo czasu.

Dla mnie to przede wszystkim kolejny krok w automatyzowaniu własnej pracy.

A jeżeli przy okazji przyda się innym developerom, tym lepiej. 🙂