Jak przywrócić usunięte emoji 🙋‍♂️

tl;dr: latin2→utf8mb4

Możemy narzekać, ale czasami emoji są skróconą, szybszą, łatwiejszą i bardziej międzynarodową formą wyrażania uniwersalnych znaczeń, w tym odczuć (emocji). Poza wtyczkami, emoji można skopiować poprzez schowek z wielu stron, np. Emojipedia, EmojiDB. Zobacz też pełną listę emoji (uwaga: strona otwiera się bardzo długo) na stronie Unicode.org (aktualnie v.15.1).

Spoiler: udało mi się przywrócić emoji, dlatego mogę je pokazać, np.

🙋‍♂️ 🌳 🎓 🌐 🖥️ ✌️ 📧 ✍🏻

🇵🇱 🇬🇧 🇺🇸 🇨🇦 🇦🇺 ➕.

Dlatego usuwanie emoji zamiast być pożądane (jak sugerują podpowiedzi wyszukiwarek internetowych i liczby wyników), może być również niepożądane jako niezgodne z zamiarem twórców treści.

Od niedawna wstawione lub wczytane do edytora (dowolnego rodzaju: wpis, strona, tag, kategoria, widżet, menu) emoji przy próbie publikacji lub aktualizacji jest w ukryty sposób usuwane, kasowane, pomijane… Konkretnie, tak działo się z najnowszymi znakami emoji, np. polską flagą. Nie groziło to starym treściom, chyba że były edytowane. Czyli nie działo się to przy odczycie bazy danych, lecz przy jej zapisie.

Zadziało się to przy którejś aktualizacji oprogramowania. W moim przypadku dotyczy to 4 witryn postawionych na systemie zarządzania treścią (CMS) WordPress=WP (v.6+) na PHP (v.8+) z serwerem bazy danych (DB) MySQL MariaDB (v.10+), poprzez rozszerzenie mysqli i klienta mysqlnd 8.2+. Celowo nie podaję dokładniejszych używanych teraz wersji.

Aby sprawdzić, jakimi wersjami oprogramowania (software) dysponujemy, w WP wybierz Kokpit → Stan witryny → Informacja → a tam: WordPress, Serwer i Stałe WordPressa. Ponadto możemy sobie zapisać, wgrać (FTP) i uruchomić zwykły plik  <?php phpinfo(); ?>. W phpMyAdmin (v.5+) wybierz bazę danych, by sprawdzić porównywanie znaków poszczególnych tabel.

 

Potraktowałem to metodycznie jako błąd (problem) do wyjaśnienia i rozwiązania (fix). Pozwolę sobie odtworzyć mój tok poszukiwań, może komuś się przyda. Jeśli się przydało, możesz zostawić komentarz😊. Jeśli namieszałem lub się nie przydało, hejt możesz sobie darować😊. Zastrzegam duże uproszczenia w poniższym opisie.

 

A. Problem mógłby być związany z przeglądarką internetową, w której się edytuje się treść witryny za pomocą WordPressie, gdyby ta nieprawidłowo wyświetlała emoji, ale nie dotyczy to np. Mozilla Firefox (wersji dziś najnowszej stabilnej). Ale przeglądarka jest niewinna.

 

B. Rozważałem, czy to błąd edytora klasycznego, czyli wtyczki WordPressa, zastępującej edytor blokowy (Gutenberg). Nie zauważyłem, aby zamiana edytorów przyniosła w tym zakresie skutek. W edytorze blokowym wręcz niemożliwe było zapisane treści z emoji, podczas gdy w edytorze klasycznym treść się zapisywała, tyle że bez emoji.

 

C. Jak twierdzą Colin Froggatt i Anthony Hortin (thank you!), problem pojawia się od wersji PHP 8.1, sugerują włączenie mysqlnd i wyłączenie mysqli, czyli rozszerzeń pośredniczących między PHP i MySQL. W interfejsie mojego hostingodawcy (serverpanel) nie widzę możliwości wyłączenia rozszerzenia mysqli a włączenia mysqlnd. Być może należy załatwić to przez php.ini danej wersji PHP. Pomijam w tej chwili używanie obiektowej bazy danych (PDO). Z tego co widzę, inni taką możliwość mają (np. w cPanel). U mnie chyba nie to było przyczyną, bowiem miałem zarówno PHP 8, jak i włączone mysqlnd, a do załatwienia sprawy potrzebne było poniższe rozróżnienie.

 

D. Oczywiście, downgrade do PHP 7 powinien pomóc, ale to tymczasowa prowizorka… W pliku .htaccess trzeba by wyedytować na <Files *.php> ForceType application/x-httpd-php74 </Files>. Stwierdziłem, że dopóki nie muszę, nie chcę w ten sposób zawieszać aktualizacji, aż naprawią błąd, bo może to nie jest po ich stronie…

 

E. Konkluzja. Nie wystarczy deklaracja nagłówkowa HTML <meta charset=”UTF-8” /> i takież kodowanie plików tekstowych HTML+PHP. Jak podpowiadają Alex czy Tomer Shay (thank you!), na głębszych poziomach również WordPress i baza danych MySQL muszą mieć ustawione:

• kodowanie zestawem znaków (charset) na utf8mb4 — nie powinno być tam: latin czy nasze latin2 (odpowiedniki środowoeuropejskiego ISO-8859-2), utf8 ani utf8mb3, albowiem najnowsze emoji są 4-bitowe;
• porównywanie znaków (collation) na utf8mb4_unicode_ci — nie powinno być tam: latin2_general_ci; proponowane utf8mb4_unicode_ci jest korzystniejsze w Polsce ze względu na prawidłowe sortowanie litery Ł, czego nie daje utf8_unicode_520_ci zrównujące Ł z L oraz utf8_general_ci sortujące szybciej, ale Ł wypada tam po Z.

 

Ustawienia te trzeba zmienić zarówno w konfiguracji:

• WordPressa — patrz poniżej pkt 6;
• serverpanel/cPanel — właściwe charset trzeba nadać przy tworzeniu bazy danych; mój hosting chyba uniemożliwia w MySQL (phpMyAdmin) dostęp do poleceń-zapytań (query) ALTER na poziomie DATABASE (mogę jedynie na niższym poziomie TABLE), dlatego przyjąłem poniżej w pkt 4 wariant z tworzeniem nowej bazy;
• phpMyAdmin — prawdopodobnie collation nie ma aż takiego znaczenia przy tworzeniu treści z emoji, natomiast zmiana collation (ALTER) tabeli/kolumn interfejsem graficznym (API) powoduje ich przepisanie nie tylko z collation, ale również z nowym nadrzędnym charset. I o to chodziło, można sobie ułatwić edycję (nie znać składni zapytań MySQL i nie używać zakładki SQL); poniżej pkt 2.

 

W moim przypadku okazało się, że unikodowe ustawienia nie były dość konsekwentne, bowiem bazę danych utworzyłem w roku 2008 jako… latin2. Mimo to WordPress, PHP i SQL do którejś wersji skutecznie obsługiwały emoji przy wp.config wskazującym dla bazy danych charset utf8. Od tamtego czasu wskazane części oprogramowania były aktualizowane, bazy danych się przepisywały, ale ja nie musiałem ingerować w bebechy (tak jak teraz). Aż do dziś. Najwyraźniej ustawienia propagowały się nierównomiernie i niekonsekwentnie i musiałem to teraz (oby raz) poprawić…

 

Tak to jako niefachowiec zrozumiałem.

 

Jak zmigrować WordPressa lub inną bazę danych do wersji zdolnej do przechowywania emoji? Jak przywrócić emoji? Co u mnie pomogło?

1. Wykonaj kopię zapasową przed poniższym edytowaniem poprzez eksport, w WordPress→Kokpit→Narzędzia→Eksport oraz w phpMyAdmin (patrz poniżej pkt 3, pierwszy raz przed edycją, drugi raz po edycji). Na wszelki wypadek.
2. Następnie w phpMyAdmin wybierz starą bazę danych nieobsługującą emoji, np. kodowaną w latin, w niej zakładkę Operacje, w nich na dole porównywanie znaków (Collation) ustaw na utf8mb4_unicode_ci (w miejsce starego np. latin2), zaznacz Zmień wszystkie tabele (Change all tables collations) oraz kolumny czyli komórki (Change all tables columns collations) i Uruchom (Go). W przypadku niepowodzenia z powodu zbyt długiego zapytania (możliwe przy wielu tabelach np. wtyczek, jak i zbyt długich nazwach czy zawartościach pól), zrób to na piechotę dla każdej z tabel/kolumn. Czasami trzeba rozwinąć strukturę plusem +. Następnie wróć do całej bazy danych. Finalnie w widoku struktury masz widzieć w kolumnie Porównywanie znaków (Collaction) wszystkie pozycje z utf8mb4_unicode_ci. Dla uproszczenia, nie wchodzę w to, które tabele i kolumny to powinny mieć, a które mogą mieć to po staremu (skoro np. ID czy IP raczej nie będzie 4-bitowy).
3. Dla bazy danych wejdź w zakładkę Eksport, tam Dostosuj (Custom). Upewnij się, że wszystkie tabele są zaznaczone. Być może musisz wyłączyć CREATE DATABASE, jeśli nie masz wystarczających uprawnień (bo nie wykona się przy imporcie), natomiast potrzebne będzie zaznaczenie i uprawnienia do CREATE TABLE. Wygenerowany plik .sql zapisz.
4. Utwórz nową bazę danych, wskazując kodowanie znaków na utf8mb4. W przypadku wykupionego hostingu zazwyczaj uczynisz to tylko przed (poza) phpMyAdmin, w interfejsie hostingu serwera, np. serverpanel→Serwer WWW→Bazy danych→Dodaj bazę→zmień kodowanie latin2 na utf8mb4 lub utf8 jeśli masz tylko to ostatnie (ponoć WP sam uzna to za utf8mb4, jeśli tylko będzie mógł). Po utworzeniu domyślnego pierwszego użytkownika, w kolumnie Kodowanie masz widzieć wybrane właśnie kodowanie. Użytkowników możesz teraz lub później zmieniać.
5. W phpMyAdmin użytkownika powiązanego z unikodową bazą danych z pkt 3 wybierasz tę nową, jeszcze pustą unikodową bazę danych, w niej zakładkę Operacje, w nich na dole porównywanie znaków (Collation) ustaw na utf8mb4_unicode_ci i zapisz (Go). Następnie wróć do bazy danych i poprzez zakładkę Import zaciągnij dane z zapisanego pliku .sql w pkt 3.
6. Nie zapomnij zaktualizować według potrzeb nazwę bazy danych, użytkownika i jego hasło w miejscu połączenia, np. wp-config.php → define(’DB_NAME’,’nazwa unikodowej bazy danych’); define(’DB_USER’,’nazwa użytkownika powiązanego z unikodową bazą danych’); define(’DB_PASSWORD’,’hasło użytkownika powiązanego z unikodową bazą danych’); define(’DB_CHARSET’, 'utf8mb4′); define(’DB_COLLATE’, 'utf8mb4_unicode_ci’); natomiast zazwyczaj bez zmian będzie define(’DB_HOST’,’host czyli IP lub domena serwera, np. mysql.ogicom.pl’); przetestuj tworząc lub edytując treść w WordPressie.

 

F. Podsumowując. Nie da się więc dosłownie przywrócić usuniętego emoji, jeżeli przez ustawienia oprogramowania nie zapisało się. Po jego przekonfigurowaniu możemy natomiast ręcznie wyedytować poszczególne treści, w których emoji się usunęło (nie zapisało), po prostu jeszcze raz ręcznie wstawiając poszczególne znaki…