Strony WWW | Pozycjonowanie

Menu
Menu

Czego unikniesz dzięki opiece WordPress? Historie tych, którzy jej nie mieli

Awaria strony internetowej to koszmar, którego każdy właściciel chciałby uniknąć i zarazem jeden z momentów, który realnie wzbudza strach i niepewność przed utratą danych. Wbrew pozorom, najczęściej dotyczy tych stron, których właściciele w mniejszym lub większym stopniu potrafią samodzielnie zarządzać witryną, więc dlaczego tak się dzieje? Odpowiedzią na to pytanie będą historie naszych klientów, którzy musieli się zmierzyć z kosztami awarii, które przy wsparciu specjalisty zostałyby zdiagnozowane i usunięte, albo w ogóle by się nie wydarzyły.

Historia 1. Dostosowanie strony do wyższej wersji PHP

Mamy do czynienia z dosyć częstą sytuacją, gdzie właściciel otrzymując z hostingu powiadomienie o zakończeniu wsparcia PHP postanawia samodzielnie dokonać zmian. W tym przypadku mowa o stronie, która składa się z kilku wtyczek i jest osadzona na motywie potomnym Astra z niewielką customizacją. Pełni rolę sprzedażową i służy głównie do generowania leadów, czyli zapytań o wykonanie usługi. Właściciel zgodnie z poleceniem hostingu wykonał kopię zapasową i zmienił wersję PHP z 7.x na 8.x. Po zapisaniu zmian witryna przestała działać, wyświetlając błąd krytyczny i tzw. ekran śmierci. Nie udało się zalogować do kokpitu ani przez link z e-maila, ani przez adres 'wp-admin’ lub 'wp-login.php’. Po przywróceniu strony do starszej wersji PHP znów stała się widoczna, ale formularz przestał przesyłać wiadomości. Po dwóch dniach otrzymaliśmy zgłoszenie i po szybkim audycie postanowiliśmy przywrócić kopię zapasową sprzed doby i wówczas strona zaczęła działać poprawnie.

Po sklonowaniu strony na osobnym serwerze z PHP 8.0 błąd się powtórzył, więc należało ręcznie wyłączyć wtyczki (dopisanie .old przed nazwą wtyczki) i na bieżąco testować dostępność witryny. W trakcie analizy okazało się, że błąd krytyczny wywołują dwie wtyczki: Forminator oraz WordFence i motyw potomny Astra. Ponadto pojawiły się problemy z zapytaniami w bazie SQL, bo instalacja została przygotowana na najwyższej wersji MySQL.

Forminator:

Pełni rolę formularza kontaktowego z kalkulatorem, który wycenia koszt potencjalnego zamówienia. Zawierał dużo dodatkowego css oraz zewnętrzną funkcję (PHP/JAVA) w formie kodu HTML, która była pobierana z motywu potomnego. Funkcja przestała działać przez kod, który nie był przystosowany do PHP 8.x.

WordFence:

Wtyczka odpowiedzialna za ochronę bezpieczeństwa strony, okazała się jedną z przyczyn błędu krytycznego. Analiza logów wykazała, że problem wynikał z:

– Zła konfiguracja wtyczki, poprzez niedostosowanie jej pod kątem SMTP, co doprowadziło do konfliktu z Forminatorem.
– Konfliktów z konfiguracją MySQL: Po aktualizacji bazy danych do najnowszej wersji MySQL, WordFence generował zapytania SQL, które były niepoprawnie interpretowane, co doprowadziło do przerwania działania strony.

Rozwiązanie wymagało optymalizacji jej ustawień, aby poprawnie współpracowała z nową wersją MySQL.

Motyw potomny:

Podczas analizy okazało się, że motyw potomny Astra został przygotowany wyłącznie do obsługi kilku dodatkowych funkcji, które można było wdrożyć w bezpieczniejszy sposób – na przykład poprzez CSS/JS wbudowany w WordPress. Problemy z motywem potomnym obejmowały:

– Źle napisany kod PHP: Funkcje zawarte w motywie korzystały ze starych metod, które nie były kompatybilne z PHP 8.x.
– Niepotrzebne obciążenie strony: Motyw potomny został zaimplementowany bez wyraźnej potrzeby, co zwiększyło ryzyko błędów podczas aktualizacji zarówno motywu głównego, jak i PHP.
– Niebezpieczne zależności: Kod motywu potomnego odwoływał się do funkcji zapisanych w plikach Forminatora, co spowodowało kaskadowe błędy w momencie wystąpienia problemów z wtyczką.

Funkcje zostały przepisane i osadzone bezpośrednio w plikach formularzy, a motyw potomny usunięty.

Łączny koszt naprawy wyniósł 1900 zł i obejmował:

– Diagnostykę i klonowanie strony na środowisko testowe.
– Usunięcie motywu potomnego oraz migrację niestandardowego kodu do formularzy.
– Konfigurację i optymalizację Forminatora wraz z kalkulatorami.
– Pełna konfiguracja wtyczki bezpieczeństwa WordFence.
– Optymalizację zapytań SQL, aby były kompatybilne z MySQL w najnowszej wersji.
– Testy i weryfikację działania witryny na PHP 8.x.
– Migracja dostosowanej witryny na docelowy adres.

Wnioski:

Motyw potomny, zamiast zwiększyć elastyczność, wprowadził dodatkowe ryzyko błędów i nie był potrzebny w takiej formie. Forminator pozwala na używanie niestandardowego kodu php/js/css, dlatego nie było potrzeby tworzenia dodatkowego motywu tylko dla funkcji, której zadaniem było zagnieżdżenie osobnego, drugiego formularza. W przypadku WordFence mieliśmy do czynienia ze starą, w dodatku niepełną konfiguracją, a sama wtyczka przed zmianą wersji PHP powinna zostać wyłączona.

Usterki zostały naprawione w ciągu 3 dni roboczych, jednak gdyby problemy zostały wcześniej zdiagnozowane w ramach regularnej opieki WordPress, naprawa przebiegłaby sprawniej i szybciej. Strona zostałaby przygotowana na przyszłe aktualizacje, aby uniknąć podobnych problemów. Kalkulator pełniący rolę formularza mógłby zostać zmodyfikowany w sposób prostszy, ograniczając kod do kilku linii, a cały proces mógłby zająć maksymalnie kilka godzin roboczych. Koszt naprawy byłby pokryty w ramach przypisanych godzin pracy specjalisty, czyli w cenie pakietu.

Na koniec warto dodać, że formularz nie działał jedynie przez 2 dni, a witryna straciła w tym czasie około 40 leadów. Teoretycznie po przywróceniu ostatniej kopii zapasowej strona mogłaby działać aż do zakończenia wsparcia PHP 7.x, ale to tylko odłożyłoby w czasie konieczność napraw – niekoniecznie w podanej tu cenie.

Historia 2. Gaszenie pożaru benzyną na obiekcie końcowym

Właściciel strony prezentującej portfolio fotograficzne postanowił przyspieszyć działanie witryny, aby poprawić wyniki w Google Page Speed Insights. O ile w wersji desktopowej działała dynamicznie, o tyle na urządzeniach mobilnych jej wydajność rzadko przekraczała 40 punktów. Zainstalował wtyczkę WP Rocket, która miała włączyć Lazy Load dla wszystkich zdjęć na stronie, aby znacznie zmniejszyć obciążenie serwera.

Na pierwszy rzut oka wszystko działało poprawnie – strona ładowała się szybciej, a wynik PageSpeed wzrósł o kilka punktów. Później klient zauważył, że po wybraniu zdjęcia w galerii pojawiało się puste okno. Miniaturki działały, ale podgląd pełnoekranowy przestał funkcjonować.

Działania klienta:

Właściciel próbował samodzielnie znaleźć rozwiązanie – najpierw wyłączył Lazy Load w ustawieniach wtyczki (Master Slider), ale to spowodowało spadek szybkości ładowania strony. Postanowił po kolei zmieniać ustawienia zarówno w WP Rocket, jak i wtyczce galerii, by w ostateczności zacząć instalować inny moduły do obsługi galerii, licząc, że któryś z nich rozwiąże problem. Brak doświadczenia doprowadził do tego, że na stronie znajdowało się kilka wtyczek jednocześnie, co spowodowało dodatkowe konflikty między skryptami Java. Zamiast testować nowe wtyczki na klonie strony, właściciel robił to na głównej domenie. W efekcie usterki zaczęły się mnożyć, a usunięcie wtyczek nie naprawiło sytuacji – część ich ustawień pozostała w bazie danych, prowadząc do dalszych konfliktów.

Podczas audytu strony odkryliśmy kilka głównych przyczyn problemu:

-Konflikt Lazy Load z galerią: Mechanizm opóźnionego ładowania zdjęć był aktywny również dla plików obsługujących podgląd galerii. Skrypt JavaScript odpowiedzialny za otwieranie zdjęć w oknie modalnym (np. Lightbox) nie był wczytywany.
– Zduplikowane skrypty: W wyniku instalacji kilku wtyczek, na stronie działały jednocześnie różne skrypty galerii, co powodowało błędy w funkcjonowaniu JavaScript.
– Brak aktualizacji wtyczki galerii: Wtyczka Master Slider nie była aktualizowana od ponad roku, co również mogło prowadzić do problemów z kompatybilnością i wyświetlaniem.

Łączny koszt naprawy wyniósł 1200 zł i obejmował:

– Wyłączenie Lazy Load dla galerii: W konfiguracji WP Rocket wykluczyliśmy galerie z mechanizmu Lazy Load. Dotyczyło to zarówno zdjęć, jak i skryptów JavaScript obsługujących galerie.
– Optymalizacja wtyczek: Usunęliśmy nadmiarowe wtyczki i pozostawiliśmy jedną wtyczkę galerii, która była kompatybilna z WP Rocket. Zaktualizowano ją do najnowszej wersji.
– Optymalizacja MySQL: Wyczyściliśmy bazę danych z pozostałości po usuniętych wtyczkach.
– Naprawa skryptów: Odtworzyliśmy brakujące skrypty Lightboxa, aby zdjęcia w galerii wyświetlały się poprawnie w trybie podglądu.
– Testy i optymalizacja: Przeprowadziliśmy testy szybkości ładowania strony, aby upewnić się, że zmiany w Lazy Load nie wpłynęły negatywnie na wynik w PageSpeed Insights.

Strona znów działała poprawnie, a galerie ładowały się szybko i były w pełni funkcjonalne. Wynik PageSpeed przekraczał 60 punktów na urządzeniach mobilnych, co przełożyło się na większy komfort z jej przeglądania.

Wnioski:

Testowanie nowych funkcji lub wtyczek bezpośrednio na głównej domenie to jak gaszenie pożaru benzyną – problemy mogą szybko narastać, a usunięcie wtyczki rzadko cofa wszystkie zmiany. Pozostające w bazie dane i konflikty między skryptami to „ukryte miny”, które mogą eksplodować w przyszłości i utrudnić dalszą pracę nad stroną.

W przypadku stałej opieki WordPress zadanie właściciela kończyłoby się na wydaniu polecenia optymalizacji galerii. Już podczas audytu wskazalibyśmy ten obszar jako priorytetowy do poprawy, a wdrożenie zmian byłoby wykonane na dedykowanej stronie testowej, bez ryzyka dla funkcjonowania witryny głównej. Instalacja, konfiguracja i testowanie zajęłyby około 2 godzin, a witryna od początku byłaby szybsza i bardziej przyjazna dla użytkowników mobilnych.

Co najważniejsze – Lazy Loading traktujemy jako wyposażenie standardowe w naszych usługach. Zawsze implementujemy je w sposób dostosowany do specyfiki witryny, co eliminuje ryzyko konfliktów z galeriami czy innymi funkcjami strony. Dzięki temu właściciel może być pewny, że jego witryna jest zoptymalizowana zarówno pod kątem wydajności, jak i użyteczności.

Historia 3. Zduplikowane zamówienia po wdrożeniu bramki płatności

Właściciel sklepu internetowego oferującego plany treningowe i żywieniowe oraz coaching, postanowił wdrożyć nową bramkę płatności – PayPal WooCommerce Payment Gateway, aby ułatwić klientom zakupy. Po zintegrowaniu systemu z WooCommerce i początkowej weryfikacji działania bramki, zdecydował się na natychmiastową aktualizację witryny, nie testując zmian na wersji testowej.

Zakupy były początkowo testowane przy użyciu zwykłej przeglądarki (bez stagingu), więc przez kilka pierwszych dni wszystko działało poprawnie. Po kilku tygodniach, po jednej z aktualizacji WooCommerce, zaczęły pojawiać się problemy – zamówienia zaczęły się dublować na etapie finalizacji, czyli po potwierdzeniu liczby produktów w koszyku, wybraniu metody płatności i podaniu danych zamawiającego, a jeszcze przed przejściem na stronę płatności PayPal. Innymi słowy – w koszyku mamy 1 produkt za 100 złotych, ale po wybraniu płatności przez PayPal, czyli na ostatniej stronie zamówienia, mamy już 2 produkty za 200 złotych.

Właściciel sklepu dostrzegł problem dopiero, gdy otrzymał zamówienie, a kilkanaście minut później ten sam klient zwrócił towar. Klient, który zgłosił zwrot, był oburzony, ponieważ zamiast zapłacić 350 zł, zapłacił podwójnie – 700 zł. Sprawa mogła przerodzić się w internetową „dramę”, ponieważ zamawiający był z polecenia YouTubera gdzie właściciel sklepu promuje swoją ofertę, a trudno o coś gorszego dla twórcy, niż oskarżenie o promowanie scamu.

Aby natychmiast usunąć ten błąd, właściciel wyłączył bramkę PayPal pozostawiając jedynie opcję przelewu tradycyjnego.

Działania klienta:

Początkowo właściciel próbował samodzielnie rozwiązać problem w ustawieniach wtyczki, ale brak wiedzy na temat konfiguracji webhooków, a także niepełne zrozumienie działania bramki spowodowały, że trafił do nas z polecenia innego klienta.

Podczas audytu odkryliśmy kilka głównych przyczyn problemu:

Brak wersji staging:

Zmiany wprowadzone bezpośrednio na stronie, bez testowania ich na stagingu (kopii witryny do testów) spowodowały, że niewidoczny błąd pojawił się dopiero po kilku tygodniach. Staging to środowisko testowe, w którym każdą nową funkcję należy weryfikować przed jej wdrożeniem na główną platformę.

Brak konfiguracji webhooków:

Webhooki to mechanizmy komunikacji między sklepem a zewnętrznymi platformami płatności, które automatycznie przekazują informacje o statusie transakcji. Problemy z konfiguracją webhooków w integracji PayPal spowodowały, że sklep nie otrzymywał właściwych informacji o statusie płatności. To z kolei prowadziło do traktowania zamówienia jako „nieopłacone”, mimo że płatność była już przetworzona, co skutkowało próbą ponownej płatności lub podwójną transakcją.

Błąd w konfiguracji Flexible Checkout Fields:

Po instalacji bramki płatności PayPal i aktualizacji WooCommerce, wtyczka Flexible Checkout Fields, służąca do personalizacji formularza zamówienia, zaczęła powodować konflikt. Została źle skonfigurowana, co po aktualizacji WooCommerce spowodowało, że dodatkowe pola na stronie finalizacji zamówienia były źle obsługiwane. Błąd pojawił się, ponieważ wtyczka nie była kompatybilna z nową wersją WooCommerce, a ustawienia pól formularza, które są wymagane podczas składania zamówienia, nie były prawidłowo przetwarzane. To doprowadziło do dublowania transakcji, ponieważ system nie mógł poprawnie zapisać zamówienia, a PayPal odbierał podwójne zapytania o płatność.

Brak dostosowania ustawień dla W3 Total Cache:

W3 Total Cache, wtyczka do cache’owania, została skonfigurowana w sposób, który blokował prawidłowe działanie systemu płatności. Cache’owanie miało na celu przyspieszenie ładowania strony, ale w tym przypadku prowadziło do przechowywania nieaktualnych danych na stronach związanych z płatnościami, co powodowało błąd.

Łączny koszt naprawy wyniósł 1500 zł i obejmował:

Wdrożenie strony stagingowej:

Przed wdrożeniem jakiejkolwiek nowej funkcji lub bramki płatności, wszystkie zmiany muszą być testowane najpierw na obiekcie roboczym, który stworzyliśmy w obrębie serwera na subdomenie sklepu na czas naprawy.

Konfiguracja webhooków:

Dokonaliśmy pełnej konfiguracji webhooków w PayPal WooCommerce Payment Gateway, aby zapewnić płynne przekazywanie danych o statusach zamówień. Dzięki temu sklep po otrzymaniu płatności, automatycznie je aktualizuje.

Naprawa ustawień wtyczki Flexible Checkout Fields:

Skonfigurowaliśmy wtyczkę FCF i stworzyliśmy nowe formularze zamówienia, aby zapewnić ich zgodność z bramką płatności PayPal oraz uniknąć konfliktów pomiędzy sobą. Warto dodać, że sklep wymagał 4 różnych formularzy dla czterech grup produktów.

Optymalizacja W3 Total Cache:

Wprowadziliśmy zmiany w konfiguracji W3 Total Cache, aby wyłączyć cache’owanie na stronach związanych z procesem płatności. Dzięki temu strona działa teraz zgodnie z rzeczywistym stanem zamówienia.

Optymalizacja bazy danych:

Usunęliśmy zbędne dane, które pochodziły z wcześniejszych wtyczek i błędnych konfiguracji. Przeprowadziliśmy optymalizację struktury bazy, co pozwoliło przyspieszyć działanie witryny i zapobiec gromadzeniu się niepotrzebnych informacji.

Wnioski:

Testowanie nowych funkcji na obiekcie roboczym oraz prawidłowa konfiguracja webhooków są absolutnie niezbędne, aby uniknąć tego typu problemów. Wdrożenie bramki płatności, która jest kluczowym elementem procesu zakupowego, wymaga dokładnych testów i zgodności z pozostałymi elementami systemu, takimi jak formularze zamówień czy mechanizmy cache’owania. Połączenie sklepu z systemem API i dostosowanie go do strony zamówienia to poważna i odpowiedzialna praca, która wymaga dobrej znajomości systemu WooCommerce, zwłaszcza, jeśli dotyczy najważniejszego etapu sprzedaży – płatności.

W ramach profesjonalnej opieki WordPress zadanie to byłoby realizowane przez specjalistów bez angażowania klienta. Instalacja, konfiguracja i testy bramki płatności odbyłyby się w ramach dostępnych godzin pracy, z uwzględnieniem pełnej zgodności z systemem WooCommerce. Dzięki temu sklep byłby w pełni funkcjonalny, a proces zakupowy bezpieczny i niezawodny – bez dodatkowych kosztów związanych z naprawą błędów.

Historia 4: Konflikt wtyczek i niewłaściwe wykorzystanie widgetów

Strona internetowa sklepu sprzedającego ramki (do zdjęć) przez lata działała sprawnie, umożliwiając klientom wybór opcji produktów, takich jak materiał, rozmiar i kolor. Witryna była dobrze zarządzana, a właściciel tworzył kopie zapasowe po każdej czynności oraz przed rozpoczęciem aktualizacji. Sklep w całości oparty na Elementorze wraz ze stronami produktów, co będzie miało znaczenie dla tej historii.

Po rutynowej aktualizacji wtyczek Variation Swatches, Elementor oraz WooCommerce, na stronach produktów zniknęła sekcja z wyborem parametrów oraz przycisk „dodaj do koszyka”. Witryna działała normalnie, a system nie zgłaszał żadnych problemów po aktualizacji. Po próbach włączania i wyłączania poszczególnych wtyczek, właściciel przywrócił kopię zapasową sprzed aktualizacji i atrybuty wróciły ale bez możliwości zaznaczenia, a co za tym idzie – bez koszyka.

Przyczyny awarii:

Wstępna analiza wykazała problem w sekcji „Elements”, który podkreślał błędnie wygenerowany kod pobierania danych produktu. Wszystkie strony produktu zostały osadzone na tym samym szablonie Elementor, gdzie nazwa, cena i dostępność były przypisane do właściwych widgetów, ale już wyświetlanie parametrów produktu wraz z przyciskiem „dodaj do koszyka” było w formie shortcode z parametrem ID konkretnego produktu.

W taki sposób: – numer ID jest przypisany do każdego produktu.

Sprawdziliśmy poprawność kodu na kilku stronach – był poprawny, ale nie wyświetlał przypisanego mu produktu. Pozwalał na to inny kod –

, ale nie mógł zostać użyty. Po zmianie shortcode na bezpośrednie wyświetlanie produktu, wszystko wróciło do normy. Gdzie zatem problem?

W bazie danych odkryliśmy pozostałości po wtyczce (YITH Variations) do zarządzania wariantami produktów, która była używana dwa lata wcześniej. Chociaż pliki wtyczki zostały usunięte, jej tabele w bazie danych pozostały i zawierały informacje o atrybutach produktów, które zostały skonfigurowane na stary sposób. W ciągu 2 lat miało miejsce wiele aktualizacji, ale najnowsza zawierała najwięcej poprawek, W jej trakcie Elementor, WooCommerce i Variation Swatches próbowały zaktualizować swoje dane, napotykając na konflikty z przestarzałymi wpisami w bazie.

Konflikt dotyczył przede wszystkim tabel przypisanych do atrybutów produktów (wp_postmeta) i wariantów (wp_woocommerce_attribute_taxonomies). Stare wpisy w tych tabelach nadpisały i zakłóciły nową strukturę, przez co ID produktów przestały być poprawnie mapowane na ich atrybuty. To sprawiło, że kod nie mógł odwołać się do wariantów, ponieważ baza nie rozpoznawała ich jako aktywnych.

Proces naprawy

Naprawa problemu wymagała przeprowadzenia szeregu działań, które obejmowały zarówno czyszczenie bazy danych, jak i dostosowanie sposobu wyświetlania produktów w Elementorze. Specjaliści musieli zidentyfikować źródło konfliktów, usunąć przestarzałe wpisy i przeorganizować szablony, aby zapewnić poprawne działanie sklepu. Proces ten był czasochłonny, ponieważ wymagał ręcznej edycji konfiguracji dla wszystkich produktów.

Wykonane kroki:

– Diagnostyka bazy danych: Przeanalizowano strukturę bazy danych w poszukiwaniu tabel i wpisów pochodzących z usuniętej wtyczki YITH Variations. Zidentyfikowano konflikty w tabelach wp_postmeta i wp_woocommerce_attribute_taxonomies.
– Czyszczenie pozostałości: Usunięto przestarzałe dane oraz zoptymalizowano bazę, aby usunąć konflikty i przywrócić poprawne mapowanie atrybutów produktów.
– Przebudowa szablonów: Zmieniono szablony stron produktów w Elementorze. Zastąpiono widget HTML z shortcode natywnymi widgetami „Product Variations” i „Add to Cart” dostępnych w Elementorze.
– Masowa edycja produktów: Dostosowano konfigurację dla 200 produktów, aby poprawnie wyświetlały warianty i przyciski koszyka.
– Testowanie funkcjonalności: Przeprowadzono dokładne testy w środowisku testowym, aby upewnić się, że produkty są poprawnie wyświetlane i w pełni funkcjonalne.

Wnioski:

Pozostawienie nieaktywnych tabel i wpisów w bazie danych po usunięciu wtyczek to częsty błąd, który może rozwijać się niezauważenie przez długi czas, aż do momentu, gdy kolejna aktualizacja wywoła konflikt. W przypadku tej strony problemu można było uniknąć, gdyby skanowano bazę danych po każdej zmianie w systemie. Warto również stosować rozwiązania zgodne z najnowszymi standardami – w tym przypadku zamiana shortcode’ów na widgety natywne wyeliminowało ryzyko związane z konfliktem danych i jest lepszą metodą wykorzystania Elementora jako szablonu produktu.

Gdyby strona była administrowana w ramach stałej opieki WordPress, administrator wykryłby potencjalny problem podczas rutynowego monitoringu bazy danych i zasugerował odpowiednie zmiany. W ramach przypisanych godzin pracy rozwiązano by konflikt w bazie, a także doradzono i wprowadzono przejście na natywne funkcje Elementora, eliminując problem z shortcode’ami. Dzięki temu taka awaria nie mogłaby się wydarzyć, a sklep uniknąłby przestoju i kosztownej naprawy.

Historia 5: Gdzie zniknęły rabaty ilościowe?

Właściciel sklepu internetowego, sprzedającego hurtowo akcesoria biurowe, od lat korzystał z wtyczki typu „Quantity Discounts”, która umożliwiała oferowanie zniżek w zależności od liczby zakupionych produktów. Było to kluczowe narzędzie jego strategii sprzedażowej, ponieważ większość klientów to małe firmy i biura zamawiające produkty w dużych ilościach. Funkcja ta nie tylko zwiększała sprzedaż, ale także pozwalała wyróżnić się na tle konkurencji.

Mimo że wtyczka działała bez zarzutu przez wiele lat, kilka miesięcy temu jej autor ogłosił zakończenie wsparcia i aktualizacji. Informacja ta pojawiła się zarówno w panelu WordPressa, jak i w e-mailu od twórcy. Niestety właściciel sklepu zignorował ostrzeżenia, wychodząc z założenia, że skoro funkcja działa, to nie ma potrzeby ingerencji.

Problemy zaczęły się po jednej z większych aktualizacji WooCommerce. Na stronach produktów przestały się wyświetlać tabele cen rabatowych, a same rabaty ilościowe przestały działać, co w efekcie zablokowało możliwość składania zamówień.

Powody awarii:

Problemy z działaniem rabatów ilościowych pojawiły się w wyniku niekompatybilności przestarzałej wtyczki „Quantity Discounts” z nowymi wersjami WooCommerce i WordPressa. Wtyczka, która od lat funkcjonowała poprawnie, nie była aktualizowana, co sprawiło, że jej kod przestał być zgodny z nowymi standardami platform. Dodatkowo, wtyczka korzystała z niestandardowych tabel w bazie danych, które nie były już wspierane przez najnowsze wersje WooCommerce. W wyniku tego, system nie mógł prawidłowo obsługiwać rabatów, ponieważ tabele te nie synchronizowały się z nowymi metodami przechowywania danych. Z powodu tych problemów kod wtyczki generował błędy PHP, co spowalniało działanie sklepu i powodowało brak wyświetlania zniżek na stronach produktów.

Znalezione usterki:

– Brak kompatybilności z nowymi wersjami WooCommerce i WordPressa: Wtyczka nie była aktualizowana, co spowodowało, że jej kod przestał działać z nowszymi wersjami systemów.
– Użycie niestandardowych tabel w bazie danych: Wtyczka korzystała z tabel, które były już nieaktualne i nie wspierane przez nowe wersje WooCommerce, co powodowało błędy synchronizacji.
– Błędy PHP: Przestarzały kod wtyczki generował błędy PHP, które spowalniały działanie sklepu.

Naprawa:

Usterka wymagała przede wszystkim skonfigurowania nowej wtyczki rabatowej, zgodnej z aktualnymi wersjami WooCommerce i WordPressa, oraz dokładnego wyczyszczenia strony z pozostałości po starej wtyczce. Usunęliśmy przestarzałą wtyczkę, a następnie zaktualizowaliśmy strukturę bazy danych, usuwając nieaktualne tabele, które powodowały konflikty. Po wymianie wtyczki konieczne było ręczne skonfigurowanie rabatów dla około 500 produktów, aby przywrócić pełną funkcjonalność sklepu.

Działania naprawcze:

– Analiza sytuacji i audyt: Zidentyfikowano dokładne problemy z wtyczką oraz niezgodności w bazie danych.
– Zastąpienie wtyczki: Wtyczka „Quantity Discounts” została usunięta, a na jej miejsce wdrożono nowe narzędzie zgodne z aktualnymi standardami WooCommerce.
– Rekonfiguracja produktów: Ze względu na różnice w strukturze tabel nowej wtyczki konieczna była ręczna edycja 500 produktów w sklepie, aby ponownie wprowadzić parametry rabatowe.
– Optymalizacja bazy danych: Usunięto przestarzałe tabele oraz ślady starej wtyczki, aby zapobiec przyszłym konfliktom.
– Prace nad przywróceniem pełnej funkcjonalności zajęły specjalistom łącznie 5 dni roboczych i kosztowały właściciela 3000 zł.

Wnioski:

Jeśli producent informuje o zakończeniu wsparcia dla wtyczki, zazwyczaj wynika to z jej niskiej popularności lub rosnącej podatności na awarie, co czyni dalszy rozwój nieopłacalnym. W takiej sytuacji kluczowe jest szybkie wdrożenie innego rozwiązania, co pozwala właścicielowi strony na bezpieczną migrację. Ignorowanie takich komunikatów, które pojawiają się zarówno w kokpicie WordPressa, jak i we wiadomościach e-mail, niesie ryzyko poważnych awarii – każda kolejna aktualizacja może wywołać błąd krytyczny.

Gdyby ten sklep korzystał z profesjonalnej opieki WordPress, administrator, po otrzymaniu informacji o zakończeniu wsparcia, zasugerowałby wdrożenie alternatywnego rozwiązania w ramach godzin pracy specjalisty. Dzięki temu strona uniknęłaby awarii i związanych z nią kosztów naprawy, a wszystkie działania zostałyby przeprowadzone proaktywnie i na czas.

Historia 6: Awaria po aktualizacji – cena za szybkie rozwiązania

Właściciel strony opartej na Elementorze zainstalował paczkę Essential Addons for Elementor, aby dodać efekt wyskakującego okienka popup z formularzem rezerwacji spotkań oraz licznik odmierzający czas do końca oferty. Mimo że używał edytora w wersji Pro, to wybrał instalację dodatku, ponieważ Elementor nie oferuje takich rozwiązań w formie dedykowanych widżetów. Przy okazji wtyczka została wykorzystana do stworzenia efektów wizualnych w obrębie karty rezerwacji, aby całość prezentowała się lepiej.

Witryna działała bez zarzutu przez kilka tygodni, aż po wspólnej aktualizacji Elementora i Essential Addons strona uległa awarii. Wszystkie zakładki się „rozlazły”, a sekcje zbudowane za pomocą Essential Addons przestały być wyświetlane. Wyłączenie wtyczki Essentials rozwiązało problem konfliktów, ale jednocześnie spowodowało utratę całej sekcji karty rezerwacji.

Powody awarii:

Awaria wynikała z wielu nakładających się elementów związanych z funkcjami oferowanymi zarówno przez Elementora, jak i wtyczkę Essentials . Właściciel strony, korzystając z obu narzędzi, używał podobnych funkcji oraz dedykowanych efektów wizualnych z Essential Addons w obrębie karty rezerwacji. Jednocześnie Elementor Pro obsługiwał podobne elementy na innych podstronach, co doprowadziło do konfliktów stylów CSS oraz skryptów JavaScript między tymi dwoma rozwiązaniami.

Dodatkowym problemem było zastosowanie różnych efektów wizualnych w tej samej sekcji – globalnych przejść między sekcjami z Elementora oraz dedykowanych rozmyć i podświetleń z Essential Addons. Różnice w sposobie renderowania przez te wtyczki, zwłaszcza obsługa modal popup przez Essential Addons, która działała niezależnie od metodologii Elementora, pogłębiły konflikty. W efekcie sekcje strony „rozjechały się,” zakładki przestały działać poprawnie, a wyłączenie Essential Addons skutkowało utratą treści utworzonych za jego pomocą.

Elementor Pro pozwala na osiągnięcie podobnych rezultatów przy użyciu minimalnej ilości kodu, co eliminuje potrzebę stosowania dodatkowych wtyczek i redukuje ryzyko konfliktów.

Znalezione usterki:

– Konflikty stylów CSS i skryptów JavaScript między Essential Addons a globalnymi stylami Elementora Pro.
– Różnice w sposobie renderowania okienka modal popup przez Essential Addons a reszty strony obsługiwanej przez Elementora Pro.
– Nakładanie się efektów wizualnych: globalne animacje Elementora Pro vs dedykowane efekty w sekcji karty rezerwacji stworzonej przy pomocy Essential Addons (np. podświetlenie, przejścia).
– Problemy z synchronizacją po aktualizacji obu wtyczek.
– Zależność karty rezerwacji od funkcji Essential Addons, co utrudniało jej funkcjonowanie po dezaktywacji tej wtyczki.

Naprawa:

Dalsze korzystanie z Essential Addons wiązałoby się z ryzykiem powrotu problemów w przyszłości, zwłaszcza przy kolejnych aktualizacjach Elementora. Zamiast tymczasowo usuwać konflikty, podjęliśmy decyzję o całkowitym wyeliminowaniu tej wtyczki i zastąpieniu jej funkcji rozwiązaniami natywnymi lub opartymi na kodzie. Naprawa wymagała edycji wszystkich zakładek, gdzie wykorzystano widżety z dodatków do Elementora.

Aby przywrócić stronę do działania:

– Przekodowaliśmy 30 sekcji w 14 zakładkach – każda sekcja została stworzona od nowa wraz z efektami wizualnymi przy użyciu Elementor Pro, eliminując zależność od Essential Addons.
– Napisaliśmy kod dla „modal popup” – zamiast korzystania z dodatkowej wtyczki, efekt ten został zrealizowany za pomocą prostego kodu CSS i JavaScript, a do obsługi formularza rezerwacji zastosowano shortcode. W tym celu użyto widgetu przycisku, który po kliknięciu otwierał ukrytą sekcję z formularzem w oknie pop-up wraz z przyciskiem zamknięcia okienka.
– Wyczyściliśmy bazę danych z pozostałości po Essentials – śmieci generowane przez dodatkową wtyczkę zostały usunięte, co poprawiło wydajność strony.
– Przetestowaliśmy stronę – wszystkie sekcje zostały dokładnie sprawdzone, aby upewnić się, że działają prawidłowo i są zgodne z responsywnym designem.

Całość prac zajęła ponad 8 godzin, a koszt naprawy wyniósł 1200 zł.

Wnioski:

Problemy wynikające z konfliktów wtyczek oraz niekompatybilności z aktualizacjami są często spotykane, gdy na stronie używane są różne narzędzia do realizacji podobnych funkcji. Instalacja paczki Essential Addons na stronie zbudowanej na Elementorze, mimo oferowania dodatkowych efektów, doprowadziła do poważnych problemów z wyświetlaniem treści oraz utratą funkcjonalności po jednej z aktualizacji, a naprawa wymagała czasu i kosztów związanych z przebudową strony. Należy unikać zewnętrznych wtyczek, które mogą kolidować z natywnymi funkcjami, zwłaszcza jeśli strona oparta jest na Elementorze w wersji PRO, który oferuje każde rozwiązanie przy odrobinie zaangażowania i pracy z dokumentacją wtyczki.

Gdyby strona była pod opieką WordPress, administrator już na etapie planowania wprowadziłby rozwiązania oparte na natywnych funkcjach Elementora, eliminując konieczność korzystania z dodatkowej wtyczki. Zamiast instalować Essentials, zaproponowałby stworzenie efektu modal box przy użyciu prostego kodu, co pozwoliłoby uniknąć konfliktów i związanych z nimi problemów. Wszystkie zmiany zostałyby wykonane w ramach godzin pracy specjalisty, co oznaczałoby brak dodatkowych kosztów oraz gwarancję stabilności i bezpieczeństwa strony.

Historia 7: Piracka wtyczka jako bomba z opóźnionym zapłonem

Strona firmy usługowej przez wiele lat działała na popularnej wtyczce Contact Form 7, a w zeszłym roku została rozbudowana o dedykowane formularze kontaktowe dla poszczególnych usług. Właściciel skorzystał z oferty freelancera, który zainstalował na stronie WPForms PRO i wykonał formularze zgodnie z wymaganiami właściciela. Po kilku tygodniach zaczęły pojawiać się problemy z aktualizacją wtyczki, ponieważ wtyczka nie oferowała dostępu do automatycznych aktualizacji – po wejściu do sekcji wtyczek nie było żadnych informacji o konieczności jej zaktualizowania. Z tego powodu właściciel nie zauważył problemu, sądząc, że wtyczka jest aktualna. To jednak nie wpływało na funkcjonowanie formularzy, więc zignorowano ten problem.

Z czasem strona zaczęła działać na coraz starszej wersji WPForms, a kolejne aktualizacje WordPressa oraz innych komponentów zaczynały powodować niekompatybilności z wtyczką. Po kilku miesiącach i jednej z większych aktualizacji WordPressa, wszystkie formularze na stronie przestały się wyświetlać.

Powody awarii:

Powodem awarii okazała się piracka wersja WPForms PRO, którą freelancer zainstalował na stronie. Wtyczka ta w ogóle nie oferowała dostępu do automatycznych aktualizacji, przez co pozostawała w wersji z dnia instalacji. Zmiany w WordPressie, nowe wersje PHP oraz aktualizacje innych wtyczek skutkowały narastającymi problemami z kompatybilnością. Ponadto, piracka wersja wtyczki nie była zabezpieczona przed potencjalnymi zagrożeniami, dlatego jej awaria była kwestią czasu.

Znalezione usterki:

– Brak dostępu do nowych funkcji w WPForms PRO po aktualizacji WordPressa.
– Uszkodzone formularze kontaktowe, szczególnie te dedykowane poszczególnym usługom.
– Zduplikowane wpisy w bazie danych generowane przez złośliwy kod.
– Brak kompatybilności formularzy z nowymi wersjami PHP i WordPressa.
– Spowolnienie działania strony przez procesy w tle związane z piracką wersją wtyczki.

Naprawa:

Pierwszym krokiem było usunięcie pirackiej wersji WPForms oraz oczyszczenie bazy danych z pozostałości po tej wtyczce, aby usunąć wszelkie nieautoryzowane wpisy i zapewnić poprawne działanie strony. Następnie wdrożyliśmy oryginalną wersję PRO wtyczki, która została skonfigurowana z uwzględnieniem dedykowanych formularzy dla różnych usług. Z uwagi na brak możliwości przeniesienia danych z pirackiej wersji, konieczne było stworzenie formularzy od nowa, aby zapewnić ich pełną funkcjonalność i kompatybilność z nową wersją wtyczki.

Działania naprawcze:

– Usunięcie pirackiej wersji wtyczki.
– Oczyszczenie bazy danych z złośliwych i nieautoryzowanych wpisów.
– Przeprowadzenie pełnego skanowania plików w poszukiwaniu malware.
– Zakup i instalacja oryginalnej wersji WPForms PRO.
– Stworzenie nowych formularzy dostosowanych do różnych usług firmy.
– Testy działania formularzy i strony po wdrożeniu wersji PRO.

Wnioski:

Używanie pirackich wersji wtyczek, zwłaszcza tych, które odpowiadają za kluczowe funkcje strony, to duże ryzyko. Brak możliwości automatycznych aktualizacji i dostępnych poprawek sprawia, że wtyczki stają się niekompatybilne z nowymi wersjami WordPressa i PHP, co prowadzi do awarii i problemów z bezpieczeństwem. Dodatkowo, pirackie wersje często zawierają złośliwy kod, który może prowadzić do uszkodzenia strony i utraty danych.

W tym przypadku freelancer zainstalował piracką wersję WPForms PRO, a właściciel strony, nieświadomy zagrożeń, korzystał z niej przez prawie rok. W ramach opieki WordPress taka sytuacja nie miałaby miejsca, ponieważ administrator doradziłby wybór wtyczki, a po zakupie by ją skonfigurował w ramach pakietu. Właściciel strony zapłacił freelancerowi 900 zł za wdrożenie rozwiązania opartego na pirackiej wtyczce, co finalnie wygenerowało koszty naprawy wynoszące dodatkowe 1400 zł. Łącznie, w ciągu 12 miesięcy, właściciel stracił 2300 zł – tyle, ile kosztuje roczna opieka nad stroną, w ramach której tego typu usprawnienie zostałoby wykonane bez dodatkowych opłat.

Historia 8: Jak często testujesz kopie zapasowe?

Wyobraź sobie, że prowadzisz WordPressa w sposób rutynowy, a wręcz nudny. Regularnie rozbudowujesz stronę i dodajesz treści. Przed każdą aktualizacją tworzysz kopię zapasową – tak samo po publikacji kolejnego wpisu. Twoja strona działa stabilnie od kilku lat i masz przekonanie, że nawet w przypadku awarii jej zawartość pozostanie bezpieczna. Podczas usuwania przestarzałych kopii zapasowych zdajesz sobie sprawę, że tworzysz je od 8 lat, a jeszcze nigdy nie testowałeś/aś ich przywracania. Postanawiasz wypróbować tę opcję i zlecasz przywrócenie kopii sprzed 5 dni. Twoja wtyczka rozpoczyna pracę, by po kilku minutach zatrzymać się na stanie ponad 90%, zwracając informację o niespodziewanym błędzie. Po odświeżeniu witryny pojawia się error połączenia z bazą danych, a co za tym idzie – brakiem możliwości przywrócenia strony z poziomu kokpitu. W tej sytuacji decydujesz się wykasować zepsutą instalację WordPress i postawienie nowej. Po kilku minutach masz gotową instalację i ponownie rozpoczynasz przywracanie kopii zapasowej. Ten sam błąd. Kolejny raz instalujesz nowego WordPressa i tym razem przywracasz starszą kopię zapasową. Znowu błąd, ale już na etapie 40%. Po kilku kolejnych próbach (i z niewielkimi nadziejami) ostatni raz instalujesz WordPressa i przywracasz kopię sprzed 12 miesięcy – działa!

Co robisz w tej sytuacji? Nie potrzebujesz wersji sprzed roku, więc prosisz hosting o przywrócenie najnowszej (ostatniej) kopii zapasowej, co kosztuje Cię 500 złotych i konieczność uzupełnienia strony o brakujące treści, bo jej wersja pochodzi sprzed miesiąca. Po przywróceniu strony przez hosting wszystko działa poprawnie, ale nadal nie wiesz dlaczego kopie zapasowe z ostatniego roku okazały się uszkodzone, dlatego zlecasz diagnozę oraz identyfikację przyczyny problemu

Powody awarii:

W stosunkowo krótkim czasie udało nam się ustalić ostatnią działającą kopię zapasową, która pochodziła sprzed 11 miesięcy. W odróżnieniu od aktualnej wersji, tamta nie była wyposażona we wtyczkę Database Cleaner, ale już kolejna (pierwsza niesprawna) ją posiadała. To oznacza, że problem zaczął występować od momentu instalacji nowego modułu. Konfiguracja wtyczek była poprawna, analiza bazy danych również nie wykazała usterek, więc postanowiliśmy zbadać konflikt wtyczki Database Cleaner z All in One WP Migration poprzez stworzenie 3 identycznych kopii zapasowych strony, gdzie:

– pierwsza kopia zawiera aktywną wtyczkę Database Cleaner,
– druga kopia posiada wyłączoną wtyczkę (nieaktywna)
– z trzeciej kopii została całkowicie usunięta.

Naszym obiektem roboczym jest czysta instalacja WordPress + wtyczka do migracji. Wgranie pierwszej kopii zakończyło się tym samym efektem, co dotychczas, ale drugą oraz trzecią udało się wgrać bez problemów. To oznacza, że konflikt polega na aktywności wtyczki Database Cleaner, którą przed utworzeniem kopii zapasowej należy wyłączyć.

Naprawa:

Pozostawienie tej wtyczki i pilnowanie, aby była wyłączona podczas tworzenia kopii zapasowych było niepraktyczne i ze względu na konflikt – niebezpieczne. Zamiast tego postanowiliśmy zastąpić Database Cleaner inną wtyczką, która nie tylko rozwiązywała problem, ale także zastępowała wcześniejsze rozwiązanie do cache’owania. Po przetestowaniu LiteSpeed Cache na obiekcie roboczym, gdzie wszystko działało poprawnie, wdrożyliśmy to rozwiązanie na stronie docelowej. Od tego momentu kopie zapasowe są tworzone i przywracane bez żadnych konfliktów.

Działania naprawcze:

– Czyszczenie bazy danych, usuwając pozostałości po wtyczce Database Cleaner, aby wyeliminować wszelkie niepotrzebne dane, które mogłyby powodować problemy z działaniem strony.
– Instalacja i konfiguracja LiteSpeed Cache, dostosowując jego ustawienia do specyfiki strony, aby zoptymalizować czas ładowania i zarządzanie pamięcią podręczną.
– Usunięcie starszej wtyczki do cache’owania – WP Super Cache, aby uniknąć konfliktu z nową konfiguracją LiteSpeed Cache i dublowania funkcji.
– Przeprowadzenie testów wydajnościowych i funkcjonalnych nowych konfiguracji, upewniając się, że proces tworzenia oraz przywracania kopii zapasowych działa poprawnie i bez zakłóceń.

Wnioski:

Choć regularne tworzenie kopii zapasowych jest standardową procedurą, nie mniej ważne jest ich testowanie. W tej historii brak testów doprowadził do problemów z przywróceniem strony, które miały swoje źródło w konflikcie wtyczek, a ich naprawa kosztowała stratę nerwów i pieniędzy. Z tego powodu każda witryna powinna posiadać obiekt zapasowy i testować kopie zapasowe co kilka miesięcy, aby upewnić się, że w razie awarii dane witryny są bezpieczne lub wykryć potencjalne usterki na wczesnym etapie.

Gdyby witryna była objęta administracją WordPress, to konflikt wtyczek zostałby szybko zidentyfikowany i naprawiony, ponieważ testowanie kopii zapasowych jest jednym ze stałych elementów opieki nad stroną.

Historia 9: Dlaczego sama wtyczka nie obroni Twojej strony przed zagrożeniami

WordFence i inne popularne wtyczki są wszechobecne i rzeczywiście sami go instalujemy w ramach opieki WordPress oraz projektowania stron internetowych. Jest przydatna w momencie, gdy strona jest wykonana prawidłowo, bo pozwala lepiej zabezpieczać proces logowania i wychwycić podejrzane aktywności oraz potencjalne zagrożenia wewnątrz WordPressa. Wiele stron korzysta z hostingów współdzielonych, gdzie klienci zazwyczaj nie mają dostępu do panelu phpMyAdmin i nie mogą samodzielnie dostosować zabezpieczeń. Wtyczka typu WordFence jest przydatna w codziennej administracji i jako dodatkowa warstwa ochrony, bo przekazuje ważne statystyki i pozwala zdiagnozować usterki w systemie, zanim staną się zagrożeniem dla strony.

I tu warto podkreślić, że żadna wtyczka tak naprawdę nie chroni strony, bo jest jedynie elementem jej wyposażenia. Może informować o zagrożeniach, skanować witrynę czy blokować podejrzane działania w obrębie WordPressa, ale za realną ochronę odpowiada serwer.

W tej historii mamy do czynienia z człowiekiem, który był święcie przekonany, że instalacja WordFence jest wystarczającym rozwiązaniem, aby zabezpieczyć stronę firmową przed próbami załączenia zainfekowanych plików w formularzach kontaktowych, a także przed spamem. Jednak wkrótce zaczął otrzymywać powiadomienia o zagrożeniach, a pierwsze wiadomości z formularzy zaczęły lądować do spamu. Ponadto, mimo ustawionych automatycznych aktualizacji, wtyczka Yoast SEO zaczęła opóźniać procesy aktualizacyjne o 7 dni, co prowadziło do upierdliwych powiadomień w kokpicie. W efekcie konieczny był audyt i pomoc specjalisty.

Powody awarii:

Do „jako takiej” awarii nie doszło, ale wtyczka Wordfence była źle skonfigurowana i znacznie opóźniała zadania CRON związane z automatycznymi aktualizacjami Yoast. W momencie wystąpienia aktualizacji, w kokpicie pojawiała się ikonka informująca o konieczności aktualizacji zamiast przeprowadzić ją z automatu, ale system opóźniał ten proces o 7 dni. Więc problem został zauważony w momencie, gdy kokpit w zasadzie cały czas informował o potrzebie aktualizacji tej wtyczki. Okazało się, że właściciel podczas edycji zadań Cron, ustawiając tworzenie automatycznych kopii zapasowych co 7 dni, omyłkowo zmienił parametr aktualizacji Yoast z „automatycznie wywołanie”, na „co 7 dni”. Z tego powodu wtyczka w momencie otrzymania aktualizacji nie mogła jej wywołać i w kokpicie pojawiała się ikonka informująca o konieczność aktualizacji.

Naprawa:

Zmieniliśmy ustawienia CRON, przez co Yoast zaczął się aktualizować bez opóźnienia. Od podstaw skonfigurowaliśmy WordFence, aby zabezpieczenia były zgodne z konfiguracją wtyczek. Zmieniliśmy także atrybuty w pliku .htaccess, aby odpowiednio ograniczyć poziom dostępu do kluczowych zasobów strony oraz zabezpieczyć przed nieautoryzowanym dostępem.

W przypadku spamu – nie da się całkowicie wyeliminować tego problemu, zwłaszcza, jeśli załączniki pełnią ważną rolę na stronie i są podstawowym elementem wiadomości kontaktowej. Żywa osoba będzie mogła podesłać spam. Wzmocniliśmy ochronę formularzy poprzez dodanie do nich grafiki z miejscem na odpowiedź, na pytanie – „co jest na obrazie?” z możliwością 3 odpowiedzi. Przy trzeciej pomyłce formularz zostaje zresetowany (znika załączony plik) i zamrożony na 5 minut. Następnie zostaje odblokowany i jeśli ponownie zostaną wprowadzone 3 błędne odpowiedzi, wówczas numer IP trafia na listę podejrzaną, formularz ponownie się resetuje i zamraża na 5 minut, a system wysyła powiadomienie do właściciela o podejrzanej aktywności. Jeśli przy trzecim podejściu podejrzany numer IP znów wprowadzi błędne odpowiedzi, wówczas zostaje zablokowany.

Dostosowanie formularza wymagało pracy programisty, aby ich reguły dostosować do WordFence, tak, aby powiadomienia o podejrzanej aktywności były natychmiast wychwytywane, a formularz mrożony tylko dla jednego numeru IP, by pozostali odwiedzający mogli swobodnie z niego korzystać.

Wnioski:

Poleganie wyłącznie na wtyczkach, takich jak WordFence, jest błędnym założeniem. Choć wtyczka ta może pełnić ważną rolę – informować o zagrożeniach, skanować witrynę, a nawet blokować podejrzane działania – to działa jedynie w obrębie WordPressa. Kluczowym elementem ochrony strony jest serwer, który stanowi główną zaporę przed atakami zewnętrznymi. Jego odpowiednia konfiguracja, obejmująca firewall, ochronę przed atakami DDoS, kontrolę dostępu do plików i regularne monitorowanie, pozwala maksymalnie wykorzystać potencjał wtyczek, zapewniając jednocześnie pełne bezpieczeństwo. Po tych zmianach witryna nie odnotowała już żadnych przypadków spamu, a Yoast przestał opóźniać aktualizacje.

Koszt napraw zamknął się w kwocie 1300 złotych, podczas gdy w ramach kompleksowej opieki WordPress tego typu prace mogłyby zostać wykonane w ramach przypisanych godzin pracy specjalisty, bez dodatkowych wydatków.

Historia 10: Jak zabezpieczyć stronę, aby samemu stracić do niej dostęp

Wtyczka lekiem na wszystko – z takiego założenia nadal wychodzi wielu amatorów WordPress, gdzie nieliczni mogą się pochwalić liczbą ponad 30 aktywnych dodatków, a wybitne jednostki dochodzą nawet do 50 instalacji. Wtyczki odpowiadają za wszystko. Potrzebujesz niestandardowej ikony w menu? Instalujesz wtyczkę. Chcesz, by Twoi użytkownicy mogli przy pomocy suwaka ustalać cenę produktu? Instalujesz wtyczkę. Cenisz sobie bezpieczeństwo i zamierzasz zagrać na nosie botom? Instalujesz WPS Hide Login i zmieniasz adres logowania z [/wp-admin/] na [/moje-logowanie/] doceniając własny spryt i przebiegłość. Aby mieć dostęp do katalogów strony bezpośrednio w kokpicie, instalujesz File Manager i od tego momentu nie musisz korzystać z FTP, aby mieć szybki dostęp do plików. Jeśli Twoja strona przedstawia dzieła z zakresu malarstwa, to jej wygląd nie może być przeciętny. Instalujesz zatem kilka wtyczek dynamicznej galerii, aby każda kategoria wyróżniała się własnym designem, podkreślając tym samym swoją kreatywność. Wiesz, że Twoja strona musi być dynamiczna, dlatego instalujesz DB Cleaner do optymalizacji bazy danych oraz Databse Manager, aby móc z poziomu kokpitu edytować tabele bazy w kilka chwil. Do tego obowiązkowo LiteSpeed Cache, aby na bieżąco opróżniać pamięć podręczną, a całość powinna podkreślać instalacja WordFence, która tak zabezpieczy witrynę, że nawet administrator hostingu nie będzie miał do niej dostępu.

Powyższa historia jest w 100% prawdziwa i strona artysty miała ponad 30 wtyczek, które z czasem spowodowały konflikt, aż witryna przestała działać. Tańszym rozwiązaniem okazało się stworzenie nowej strony, niż próba naprawy, bo 80% szablonu należało wyrzucić do kosza. Metodą wyłączania wtyczek udało się ją przywrócić i na czas tworzenia nowej pozwalała zapoznać się z portfolio i wysyłać wiadomości.

Powody awarii:

Poważny konflikt wtyczek był wynikiem nadmiaru aktywnych dodatków, które zostały zainstalowane bez dokładnego przemyślenia ich wzajemnej kompatybilności. Wtyczki, które miały zapewnić różne funkcje, zaczęły działać w sposób sprzeczny, powodując wzajemne zakłócenia. Przykładowo, File Manager i Database Manager zmieniały uprawnienia do plików i tabel bazy danych, co mogło wchodzić w konflikt z innymi dodatkami odpowiedzialnymi za bezpieczeństwo, takimi jak WordFence. Z kolei LiteSpeed Cache i DB Cleaner, które miały zoptymalizować działanie strony, w połączeniu z innymi wtyczkami wprowadzały zbyt dużą liczbę operacji w tle, powodując przeciążenie systemu i spowolnienie ładowania strony. Dodatkowo, zmiana ścieżki logowania za pomocą WPS Hide Login, choć zwiększała bezpieczeństwo, utrudniła dostęp do administracji strony, co stało się problemem w kontekście zarządzania dużą ilością wtyczek i plików. Niezgodności te doprowadziły do sytuacji, w której strona przestała działać prawidłowo, a właściciel nie miał do niej dostępu.

Naprawa:

W wyniku konfliktu wtyczek, zdecydowano się na restart całej strony. Zamiast próbować naprawiać każdy z osobna problematyczny dodatek, stworzyliśmy nową stronę od podstaw, korzystając z popularnego i stabilnego narzędzia, jakim jest Elementor. Zamiast wykorzystywać 30 wtyczek, zredukowaliśmy liczbę dodatków do 8, co pozwoliło na stworzenie strony o podobnym wyglądzie i funkcjonalności, ale bez ryzyka konfliktów. Ponadto, nowa instalacja zawierała tylko najważniejsze wtyczki, zoptymalizowane pod kątem współpracy. W przypadku bezpieczeństwa, zainstalowaliśmy tylko niezbędne dodatki, a wszystkie operacje na bazie danych i plikach zostały ograniczone do minimum, aby zredukować możliwość wystąpienia kolejnych problemów związanych z wydajnością i kompatybilnością.

Wnioski:

Choć WordPress oferuje ogromne możliwości dzięki dodatkom, ich nadmiar i nieprzemyślana konfiguracja zwykle prowadzą do konfliktów, spowolnienia działania strony lub jej całkowitego zablokowania. W tym przypadku próba rozwiązania wszystkich problemów za pomocą wtyczek przyniosła efekt odwrotny – strona stała się niestabilna, a jej naprawa była na tyle kosztowna i czasochłonna, że bardziej opłacało się stworzyć ją od nowa. Kluczowa zasada brzmi: mniej znaczy więcej. Ograniczenie liczby wtyczek do tych naprawdę niezbędnych pozwala lepiej zarządzać stroną i zapewnia jej stabilność.

Czy podobna sytuacja mogłaby wystąpić w ramach stałej administracji? Właściciel witryny, chcąc oszczędzić na pracy programisty, podjął ryzyko samodzielnego zarządzania stroną, co w efekcie kosztowało go ponad 2000 zł na jej rekonstrukcję. Administrator działający w ramach opieki nie dopuściłby do działań, które wcześniej czy później prowadzą do konfliktów. Zamiast tego zaproponowałby stabilne i bezpieczne rozwiązania w ramach godzin pracy specjalisty. W przypadku, gdyby właściciel chciał zlecić opiekę nad już „ubogaconą” witryną, jej stan techniczny wykluczyłby możliwość przyjęcia jej do kompleksowej administracji.

Historia 11: Przeniesienie strony na nowy hosting – problemy z motywem potomnym

Właściciel strony internetowej, która pełni rolę bloga firmowego z funkcjami e-commerce, postanowił przenieść swoją witrynę na nowy, szybszy hosting. Chciał poprawić czas ładowania strony oraz zwiększyć jej niezawodność, ponieważ stary hosting nie spełniał już oczekiwań. Witryna opierała się na motywie głównym Avada, a wszystkie dodatkowe modyfikacje były realizowane w motywie potomnym. Właściciel zlecił przeniesienie strony do nowego środowiska i zainstalowanie odpowiednich konfiguracji.

Po zakończeniu procesu migracji i uruchomieniu strony na nowym serwerze pojawiły się poważne problemy. Strona nie działała zgodnie z oczekiwaniami – część funkcji przestała działać poprawnie, a wygląd strony był rozmazany i niezgodny z projektem. Dodatkowo po próbie edycji strony w panelu administracyjnym, pojawiały się błędy PHP, które uniemożliwiały jakiekolwiek zmiany. Klient zgłosił problem do naszej firmy, licząc na szybką naprawę.

Przyczyny awarii:

Problemy wynikały z przestarzałego motywu potomnego, który został zaprojektowany 10 lat wcześniej z myślą o ówczesnych standardach. Wówczas PHP był w standardzie 7.x, a dzisiaj mamy do czynienia ze standardem 8.x. Z tego powodu funkcje w motywie potomnym przestały działać, a szablon się rozsypał i po uruchomieniu wyglądał na „surowy”.

W trakcie audytu zidentyfikowaliśmy następujące problemy:

– Motyw potomny niekompatybilny z nowym środowiskiem i nie był przystosowany do nowoczesnych standardów serwera, co powodowało błędy w funkcjonowaniu strony.
– Część wtyczek, które wcześniej działały poprawnie, nie były zgodne z nowym środowiskiem, co wpłynęło na prawidłowe ładowanie skryptów.
– Brak optymalizacji pod nowy serwer: Motyw nie był zoptymalizowany do pracy z nowym hostingiem, co spowodowało problemy z wydajnością i czasem ładowania strony.

Rozwiązanie:

Zależało nam na jak najszybszym przywróceniu strony do pełnej funkcjonalności. Przeprowadzanie napraw bezpośrednio na starym hostingu mogłoby opóźnić proces z powodu konieczności propagacji DNS, która zajęłaby dodatkowe 24 godziny. Z tego powodu postanowiliśmy przeprowadzić wszystkie naprawy na osobnym obiekcie testowym, który miał takie same parametry jak dotychczasowy serwer. Dzięki temu mogliśmy upewnić się, że strona będzie w pełni gotowa do migracji i uruchomienia w krótkim czasie.

Aby przywrócić stronę do pełnej funkcjonalności wykonaliśmy następujące kroki:

– Dostosowaliśmy kod PHP w motywie do wymagań nowego serwera i usunęliśmy przestarzałe funkcje.
– Zaktualizowaliśmy wszystkie wtyczki, które były powiązane z motywem potomnym. Usunęliśmy te, które były niekompatybilne z nowym środowiskiem, oraz zoptymalizowaliśmy te, które mogły wprowadzać opóźnienia w ładowaniu strony.
– Skonfigurowaliśmy serwer, aby działał bardziej efektywnie z nowym motywem i jego wymaganiami, szczególnie pod kątem obsługi PHP i MySQL. Upewniliśmy się, że wszystkie zasoby strony ładowały się szybko, a czas odpowiedzi serwera był optymalny.
– Po przeprowadzeniu poprawek, przetestowaliśmy stronę na różnych urządzeniach oraz przeglądarkach, aby upewnić się, że wszystkie funkcje działają prawidłowo.

Koszt naprawy wyniósł 1500 złotych, a prace zajęły 2 dni robocze, w których strona pozostawała w trybie konserwacji.

Wnioski:

Migracja strony na nowy hosting to z pozoru prosty proces, ale w rzeczywistości może prowadzić do nieoczekiwanych problemów – zwłaszcza, jeśli witryna opiera się na kilkuletnim motywie potomnym. Przed rozpoczęciem migracji zawsze należy zapoznać się ze środowiskiem i parametrami nowego hostingu, aby w razie potrzeby dostosować paczkę ze stroną do aktualnych standardów. Przestarzały motyw potomny może wywołać błędy, które jak w tej historii spowodują zablokowanie strony na kilka dni.

W przypadku stałej opieki, przeniesienie strony zostałoby poprzedzone testami zgodności z nowym hostingiem, który wykazałby konieczność dostosowania kodu do wyższej wersji PHP. Po jego edycji, strona zostałaby przetestowana na obiekcie roboczym nowego serwera i po weryfikacji poprawności funkcji zostałaby uruchomiona pod właściwym adresem. A to wszystko w cenie miesięcznego pakietu wsparcia specjalisty.

Opieka WordPress

Abonament

od 190 zł / netto

Szczegóły

Profesjonalna administracja WordPress, czyli regularna opieka oraz pomoc techniczna w przypadku problemów z funkcjonowaniem strony. Oferujemy gotowe plany, a także serwis, czyli naprawę stron WordPress.

Podsumowanie

Opieka nad WordPress to nie tylko naprawa błędów, ale przede wszystkim proaktywne działania, które zapewniają bezpieczeństwo, stabilność i widoczność Twojej witryny w sieci. Specjaliści z różnych dziedzin – programiści, graficy i administratorzy – wspólnie zadbają o rozwój strony, jej atrakcyjny wygląd i skuteczność w przyciąganiu klientów.

Inwestycja w profesjonalną opiekę to oszczędność czasu i pieniędzy, a także pewność, że Twoja strona działa bez zarzutu. Chcesz wiedzieć więcej? Skontaktuj się z nami – pomożemy Ci zadbać o sukces Twojej witryny!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Ostatnie wpisy:

Masz pytania związane
z tym tematem?

Zadzwoń lub napisz

  • +48 731 394 628
  • biuro@i-content.com.pl