Migracja JEvents z Joomla! 1.5 na 2.5 lub 3.0 – metodą ręczną

Pewnie wiele osób spotkało się z koniecznością przebudowy starej strony postawionej na systemie Joomla! 1.5 pod nowe standardy wersji 2.5 lub 3.0 i idącą za tym migracją wydarzeń w komponencie JEvents. Problem pojawia się jednak wtedy, gdy stara strona stoi na innym serwerze, niż aktualna oraz nie mamy możliwości postawienia testowej wersji na tym samym serwerze, przez co nie jest możliwe użycie skryptu automatycznej migracji dołączonego przez producenta. Niestety twórcy zadbali tak mocno, aby był on intuicyjny dla wszystkich, że w większości przypadków albo nie działa, albo po prostu nie jest możliwe jego użycie. Przenoszenie eventów przy pomocy eksportu i importu iCal również jest wątpliwie wygodne przy dużej ilości kalendarzy oraz przedstawia niezbyt wysoką jakość migracji, gdy posiadamy bardziej rozwinięte treści (lubi ucinać zawartość). Z tego tez powodu najwygodniejsza staje się zwykle migracja ręczna, dlatego chciałem tutaj (najprościej jak potrafię) opisać jak tego dokonać. Osoby posługujące się dobrze bazami już na starcie przepraszam za taką „łopatologię”, jednak stwierdziłem, że jeżeli ktoś dobrze porusza się po nich będzie potrafił wykonać to sam, dlatego bardziej kierowałem go bardziej w stronę tzw. „laików”.

Screen: Daniel 'zoNE’ Gabryś

Co będzie nam potrzebne?

• Dostęp do bazy danych nowej i starej strony
• Narzędzie phpMyAdmin lub podobne – jeżeli nie posiadasz takiego u siebie porozmawiaj z administratorem serwera lub zainstaluj dostępny na stronie https://www.phpmyadmin.net/ zgodnie z dostępną tam instrukcją
• Konto administratora na nowym portalu
• Zainstalowana najnowsza wersja JEvents na naszej Joomli 2.5/3.0 wraz ze wszystkimi używanymi na starej stronie jej modułami
• Program Notepad++ lub inny edytor tekstu pokroju notatnika pozwalający na masowe zastępowanie wyszukiwanej treści
• BACKUP BAZY NOWEJ I STAREJ STRONY W RAZIE, GDYBY COŚ SIĘ ZEPSUŁO W CZASIE MIGRACJI
• Przynajmniej podstawowa wiedza czym jest baza danych i jak działa

Przygotowania do prac

W celu przygotowania naszego środowiska do pracy pierwszą rzeczą, jaką zrobimy będzie przekopiowanie ze starej bazy danych (starej strony) kilku tabel z danymi do nowej bazy. Aby tego dokonać logujemy się do naszego panelu phpMyAdmin, z listy po lewej stronie wybieramy interesującą nas bazę, a następnie przy pomocy checkboxa zaznaczamy kilka tabel, które wypiszę poniżej i poprzez opcję „With selected:” na dole strony wybieramy „export”.

Screen: Daniel 'zoNE’ Gabryś

Tutaj lista tabel, które będą nam potrzebne do pracy (gdzie staryprefix_ oznacza kilka znaków które nasza stara Joomla! ustaliła jako prefiks):

• staryprefix_jevents_catmap
• staryprefix_jevents_exception
• staryprefix_jevents_icsfile
• staryprefix_jevents_repetition
• staryprefix_jevents_rrule
• staryprefix_jevents_vevdetail
• staryprefix_jevents_vevent

Na stronie, która się pojawi wybieramy opcję „Custom – display all possible options”, a następnie „Compression:” ustawiamy na zipped lub gzipped (zależnie od dostępności) i klikamy Go. Wygenerowany plik zapisujemy na naszym dysku.

Gdy już tego dokonamy logujemy się w ten sam sposób do bazy danych nowej strony, wybieramy interesującą nas bazę z lewej strony oraz pozycję „Import”, aby wczytać to, co właśnie wyeksportowaliśmy. Upewnijmy się jednak wcześniej, że prefiksy tabel w nowej bazie nie są takie same jak staryprefix_. Jeżeli są identyczne, to wyszukujemy plik, który pobraliśmy i przed importem zmieniamy zapisane w nim prefiksy. W przeciwnym wypadku nie musimy tego robić, jednak dla spójności przewodnika będę stosował nazewnictwo takie, jakbyśmy tego dokonali zgodnie z opisem poniżej. Po zmianie wczytujemy plik przez opcję importu oraz wciskamy Go.

Zmiana prefiksów bazy w wyeksportowanym pliku – tylko gdy są takie same w nowej i starej bazie

Do tego zadania będzie nam potrzebny program Notepad++ lub podobny (ja preferuję ten). Rozpakowujemy pobrany plik *.zip lub *.gzip (zależnie od wybranego formatu pakowania) na dowolnej lokalizacji dysku. Paczka zawiera plik *.sql z kopią naszej bazy danych, którą możemy uruchomić przy pomocy jakiejkolwiek aplikacji notatniko-podobnej. Jeżeli robimy to przy pomocy Notepad++, to z menu wybieramy [Search -> Replace…] (w polskiej wersji [Szukaj -> Zmień…]), a następnie w miejscu na wyszukiwaną frazę wpisujemy staryprefix_ – gdzie staryprefix_, to prefiks stosowany przez naszą starą Joomlę! Natomiast w polu „Replace with:” (pol. Zmień na:) wpisujemy „backup_” – oczywiście bez cudzysłowów i klikamy Replace All (Zmień wszystkie). W efekcie zamiast staryprefix_jevents_catmap winniśmy otrzymać backup_jevents_catmap itd.

Screen: Daniel 'zoNE’ Gabryś

Po wprowadzeniu zmian zapisujemy plik i pakujemy do tego samego formatu, dalej postępujemy tak samo, jak wyżej. W ostateczności otrzymamy 2 zestawy tabel takich, jak na zrzucie ekranu poniżej (gdzie xshf_ to przykładowy prefiks tabel nowej bazy).

Screen: Daniel 'zoNE’ Gabryś

Tworzenie kategorii wydarzeń na nowej stronie

Z powodu, iż JEvents używa domyślnych kategorii Joomli najwygodniejszym sposobem, jeżeli nie jest ich wiele w naszym kalendarzu będzie zrobienie tego przy pomocy panelu administracyjnego (aby nie pomieszały i nie nadpisały nam się np. kategorie artykułów). W tym celu logujemy się do panelu administracyjnego nowej strony, z menu wybieramy [Components (Komponenty) -> JEvents -> Manage Categories (Kategorie) -> New (Nowy)] i tworzymy wszystkie tak, jak było to na starej stronie. Kiedy już utworzymy wszystkie powinniśmy zwrócić uwagę na liście kategorii na kolumnę „ID” i zapisać sobie na kartce lub w notatniku ID przypisane do odpowiednich kategorii na starej i nowej stronie – będzie nam to niedługo potrzebne.

*Estetyka bazy i zmiana kolejności kolumn

To najtrudniejsza część całej migracji, bo wymagająca analizy, ale myślę, że z poniższym opisem sobie z nią poradzicie. Z przyczyn czysto estetycznych wprowadzimy kilka zmian w kolejności występowania kolumn w naszej bazie, gdyż nowa instalacja JEvents tworzy tabele z nieco zmienioną kolejnością kolumn. Zmiany nie będą duże, u mnie były to tylko 4 kolumny. Jeżeli chcemy sprawdzić jakie zmiany nastąpiły w strukturze bazy wystarczy, że w jednej zakładce przeglądarki uruchomimy skopiowaną ze starej bazy tabelę z prefiksem backup_ z wybraną zakładką Structure, a w następnej odpowiadającą jej tabelę o tej samej nazwie z prefiksem używanym przez nową Joomlę. W odniesieniu do mnie różnice były tylko w 4 tabelach:

• backup_jevents_icsfile – przeniesienie kolumny ignoreembedcat z pozycji 16 na 7, tuż po isdefault
• backup_jevents_vevdetail – przeniesienie kolumny modified z pozycji 30 na 27, tuż po state
• backup_jevents_vevent – przeniesienie kolumny access z pozycji 14 na 16, tuż po author_notified (na sam koniec)
• backup_jev_defaults – przeniesienie kolumny id z pozycji 7 na 1

Screen: Daniel 'zoNE’ Gabryś

Gdy już spiszemy sobie wszystkie zmiany, jakie wykonamy przyda nam się komenda dzięki której tego dokonamy. Nie bez powodu wypisałem sobie po której kolumnie występują te przez nas wymienione, gdyż przyda się nam ta dana przy ich przenoszeniu. Użyjemy tutaj polecenia:

• ALTER TABLE backup_nazwatabeli MODIFY przenoszona_kolumna varchar(100) not null AFTER kolumna_przed_nowa_pozycja

Gdzie backup_nazwatabeli to nazwa naszej tabeli (np. backup_jevents_vevent), przenoszona_kolumna to nazwa przenoszonej kolumny (np. access), varchar(100) to typ danych (zamiast tego wpisujemy taki typ, jaki jest podany jako Type przy naszej kolumnie – na screenie zaznaczone numerem 1) oraz kolumna_przed_nowa_pozycja to nazwa kolumny która występuje jako ostatnia przed nową pozycją naszej kolumny (np. author_notified). Dla powyższego przykładu, jak na zrzucie będzie to wyglądało następująco:

• ALTER TABLE backup_jevents_vevent MODIFY access int(11) not null AFTER author_notified

Aby wykonać to polecenie otwieramy interesująca nas bazę w phpMyAdmin (tam, gdzie zaimportowaliśmy nasz backup), wchodzimy w zakładkę SQL, wklejamy powyższe odpowiednio zmodyfikowane polecenie i klikamy Go.

Screen: Daniel 'zoNE’ Gabryś

Jeżeli polecenie się wykona przechodzimy do zakładki Structure i uważnie sprawdzamy, czy parametry kolumny z tabeli naszego backupu oraz te na nowej stronie się zgadzają (w szczególności Type, Attributes, Null, Default, Extra) – po przeniesieniu będą puste. Jeżeli coś się nie zgadza w tabeli z prefiksem backup_ przy wybranej kolumnie wybieramy opcję Change i zmieniamy na takie, jakie powinny być. Przy braku pewności co wybrać możemy uruchomić to samo dla tabeli odpowiadającej jej na nowej stronie i przepisać wartości.

Na koniec w tym przykładzie powinniśmy dostać:

Screen: Daniel 'zoNE’ Gabryś

To samo robimy dla pozostałych tabel, aż otrzymamy identyczne struktury w tabelach z prefiksem backup_, jak w tych na nowej stronie.

Uzupełnianie tabel oraz podmiana starych wartości

Pamiętacie, jak tworzyliśmy kategorie wydarzeń oraz zapisywaliśmy sobie ich ID? Teraz się nam one przydadzą, ponieważ będziemy musieli podmienić w bazie stare ID kategorii przypisane do wydarzeń na nowe. Poza tymi zmianami czeka nas jeszcze zmiana uprawnień przy wyświetlaniu wydarzeń i to właściwie koniec naszej migracji.

Przypisanie wydarzeń do kategorii

Zacznijmy od przypisania kategorii, gdyż jeżeli nie przypiszemy wydarzeń do odpowiednich kategorii, to nie pokażą się one nawet w panelu administracyjnym. Będę się tutaj posługiwał poniższym przykładem kategorii:

• Kategoria: Szkolenia Polskie, Stare ID: 7, Nowe ID: 10
• Kategoria: Szkolenia Zagraniczne, Stare ID: 8, Nowe ID: 11
• Kategoria: Informacje Portalu, Stare ID: 9, Nowe ID: 12

Tu również przyda się nam odpowiednie polecenie, tym razem będzie to UPDATE:

• UPDATE nazwa_tabeli SET kolumna = REPLACE (kolumna, 'Szukany ciąg znaków’, 'Nowy ciąg znaków’);

Gdzie nazwa_tabeli to nazwa tabeli na której będziemy pracowali, kolumna to nazwa kolumny w której ma szukać danego ciągu znaków, a następnie w odpowiednich miejscach poszukiwany przez nas ciąg znaków oraz nowy ciąg znaków, który ma trafić na jego miejsce. Dla przykładu:

• UPDATE backup_jevents_vevent SET catid = REPLACE (catid, 7, 10);

Powyższa komenda zmienia w tabeli backup_jevents_vevent ID kategorii przypisanej do szkolenia na 10, jeżeli poprzednio była do niego przypisana kategoria nr 7.

Polecenie musimy wykonać dla dwóch tabel:

• backup_jevents_vevent
• backup_jevents_catmap

Poniżej znajduje się przykład, jak będzie to wyglądało w moim przypadku:

• UPDATE backup_jevents_vevent SET catid = REPLACE (catid, 9, 12);
• UPDATE backup_jevents_catmap SET catid = REPLACE (catid, 9, 12);
• UPDATE backup_jevents_vevent SET catid = REPLACE (catid, 8, 11);
• UPDATE backup_jevents_catmap SET catid = REPLACE (catid, 8, 11);
• UPDATE backup_jevents_vevent SET catid = REPLACE (catid, 7, 10);
• UPDATE backup_jevents_catmap SET catid = REPLACE (catid, 7, 10);

Screen: Daniel 'zoNE’ Gabryś

Komendy możemy puścić wszystkie jednocześnie, pamiętajmy jedynie o tym, że muszą być oddzielone średnikiem oraz musimy zachować konsekwencję co do ich kolejności. Jeżeli damy najpierw, aby zmienił ID 17 na 18, a następnie 18 na 19, to wszystkie które na początku miały ID 17 oraz 18 będą miały teraz ID 19, gdyż najpierw zmieni 17 na 18, a później wszystkie 18 zmieni na 19.

Przypisanie poprawnych uprawnień

To samo będziemy musieli zrobić, aby przypisać poprawne uprawnienia do wydarzeń oraz kalendarzy. Jeżeli byśmy ich nie zmienili wydarzenia nie pokazałyby się na naszej stronie. Użyjemy tej samej komendy jednak tabelami na których będziemy teraz pracowali będą:

• backup_jevents_vevent
• backup_jevents_icsfile

W starej Joomli uprawnienia miały nieco inną numerację, gdyż zaczynała się ona od 0. W nowej Joomli numeracja ta zaczyna się od 1 i jest to kolejno:

• Public, Stare ID: 0, Nowe ID: 1
• Registered, Stare ID: 1, Nowe ID: 2
• Special, Stare ID: 2, Nowe ID: 3

Chyba, że wprowadzaliśmy zmiany, wtedy możemy to sprawdzić w panelu administratora w zakładce [Users (Użytkownicy) -> Access Levels (Poziomy dostępu)].

Poniżej przykładowy kod jakiego możemy użyć, gdy nie zmienialiśmy niczego z domyślnymi uprawnieniami Joomli:

• UPDATE backup_jevents_vevent SET access = REPLACE (access, 2, 3);
• UPDATE backup_jevents_icsfile SET access = REPLACE (access, 2, 3);
• UPDATE backup_jevents_vevent SET access = REPLACE (access, 1, 2);
• UPDATE backup_jevents_icsfile SET access = REPLACE (access, 1, 2);
• UPDATE backup_jevents_vevent SET access = REPLACE (access, 0, 1);
• UPDATE backup_jevents_icsfile SET access = REPLACE (access, 0, 1);

Screen: Daniel 'zoNE’ Gabryś

Zakończenie prac, czyli podmiana tabel

By sfinalizować nasze prace jedyne co musimy zrobić, to usunąć kilka tabel komponentu JEvents z nowej strony (ówcześnie oczywiście robiąc ich kopię podobnie, jak w pierwszym kroku robiliśmy kopię tabel ze starej strony – przydadzą nam się jeżeli coś źle zrobiliśmy i JEvents przestanie działać) oraz zmienić nazwy naszych tabel z prefiksem backup_.

Usuwanie zbędnych tabel

Nasze tabele, które będziemy musieli usunąć (zaznaczając, że prefiks xshf_ to prefiks tabel utworzonych przez komponent JEvents na nowej stronie – te, z których czerpaliśmy dane, gdy zmienialiśmy kolejność kolumn w tabelach backup_) będą to:

• xshf_jevents_catmap
• xshf_jevents_exception
• xshf_jevents_icsfile
• xshf_jevents_repetition
• xshf_jevents_rrule
• xshf_jevents_vevdetail
• xshf_jevents_vevent

Aby tego dokonać w panelu phpMyAdmin z listy przy pomocy checkboxów zaznaczamy interesujące nas tabele i na dole strony z „With selected:” wybieramy opcję „drop” potwierdzając przyciskiem Yes.

Screen: Daniel 'zoNE’ Gabryś

Poza tymi tabelami istnieją jeszcze dwie, których nie ruszamy. Mianowicie są to:

• xshf_jev_users
• xshf_jev_defaults

Zmiana nazw tabel backup_

Pozostaje nam już tylko zmiana prefiksów w nazwach tabel poprzedzonych słowem backup_ na odpowiadające im w nowej Joomli (w powyższym przykładzie jest to xshf_). Zrobimy to poleceniem RENAME TABLE. Przykład poniżej:

• RENAME TABLE stara_nazwa TO nowa_nazwa;

Oto jak powinno to wyglądać:

• RENAME TABLE backup_jevents_catmap TO xshf_jevents_catmap;
• RENAME TABLE backup_jevents_exception TO xshf_jevents_exception;
• RENAME TABLE backup_jevents_icsfile TO xshf_jevents_icsfile;
• RENAME TABLE backup_jevents_repetition TO xshf_jevents_repetition;
• RENAME TABLE backup_jevents_rrule TO xshf_jevents_rrule;
• RENAME TABLE backup_jevents_vevdetail TO xshf_jevents_vevdetail;
• RENAME TABLE backup_jevents_vevent TO xshf_jevents_vevent;

Oczywiście „xshf_” zamieniamy na takie prefiksy, jakie odpowiadają naszej nowej Joomli 2.5/3.0 oraz wszystkie komendy powinny być zakończone średnikiem. Polecenia możemy wywołać poprzez wiersz poleceń znajdujący się w zakładce SQL głównego widoku naszej nowej bazy.

Screen: Daniel 'zoNE’ Gabryś

Potwierdzamy przy pomocy przycisku Go i sprawdzamy, czy wszystko na naszej nowej stronie oraz w komponencie JEvents działa poprawnie.

Autor: Daniel 'zoNE’ Gabryś