Plama na WordPressie, czyli moje największe wpadki

WordPress zlecenia wpadki

Niedawno popełniłam wpis o tym, jak radzę sobie z problemami WordPressowymi klientów. Artykuł został dobrze przyjęty i widać jest zapotrzebowanie na wiedzę o WordPressie ilustrowaną przypadkami prosto z życia.

Dzisiaj case studies ciąg dalszy. Ale żeby nie było, że zawsze jestem szybka i zaradna, tym razem – dla równowagi – o moich WordPressowych wpadkach. Czyli o tym, jak równie dobrze potrafię być chaotyczna, impulsywna i doskonale wpisać się w wizerunek głupiutkiej blondynki.

Nie jest głupotą czegoś nie wiedzieć. Głupotą jest dobrze o czymś wiedzieć, a mimo wszystko postąpić inaczej.

Dokładnie tak zachowałam się podczas realizacji kilku zleceń dla klientów. Jeśli chcesz wiedzieć, jak można dać plamę nawet tam, gdzie wydaje się to niemożliwe, zapraszam do dalszej lektury.

Wszystkie opisane niżej przypadki są autentyczne, a zbieżność postaci ma jak najbardziej coś wspólnego nie tylko z rzeczywistym kolorem moich włosów, lecz również poziomem inteligencji, jakim się wówczas wykazałam.

Wpadka 1. – rutyna zabija…

Pytanie: Jak WP-blondynka zabezpiecza stronę klienta przed atakiem?
Odpowiedź: Ustawia automatyczny backup w taki sposób, że strona pada sama po kilku tygodniach życia.

Podstawowa zasada obrony strony przed atakiem mówi o tym, ze trzeba zadbać o backup (o pozostałych przeczytasz na blogu u Marka). No więc dbam. I instaluję u klienta wtyczkę, która kopie bezpieczeństwa zrobi za nas automatycznie, czyli BackWPUp. Po kilku tygodniach funkcjonowania witryny klient kontaktuje się ze mną twierdząc, że strona została zawieszona, bo przekroczono dozwoloną liczbę miejsca na dysku. Jakieś paręnaście giga…

W poszukiwaniu przyczyny…

Pierwsza myśl jaka przychodzi mi do głowy, to to że pomyłkowo składuję backupy w katalogu WordPressa, przez co backupują same siebie. Wchodzę w ustawienia wtyczki i widzę, że jest ok. Miejsce składowania kopii zapasowych ustawione jest prawidłowo: nie tylko poza katalogami WP, ale i w ogóle poza katalogiem public_html:

Ścieżka, gdzie mają być składowane kopie zapasowe (wtyczka BackWPUp)
Rys. 1.1. Ścieżka, gdzie mają być składowane kopie zapasowe (wtyczka BackWPUp)

Myślę sobie, albo katalog upload został zapchany olbrzymimi plikami albo w witrynie jest dużo bardzo dużych pluginów (wiem, wiem, trzeba się bardzo postarać, żeby nainstalować pluginów w rozmiarze idącym w setki megabajtów, ale wiecie jak to jest, mózg w sytuacjach stresowych i nie dających się sensownie wytłumaczyć podsuwa różne nieracjonalne wyjaśnienia).

W każdym razie trzeba po prostu sprawdzić, co tam się zbackupowało. Do shella nie mam dostępu, a na ściągniecie pojedynczego zip’a z „takim” backupem trzeba będzie „chwilkę” poczekać.

Jak sprawdzić przez ftp zajętość wybranego katalogu

Rys. 1.2a. Jak sprawdzić rozmiar katalogu przez ftp
Rys. 1.2a. Jak sprawdzić rozmiar katalogu przez ftp
Rozmiar kolejki z plikami w File Zilla
Rys. 1.2b. Rozmiar kolejki z plikami w File Zilla

Postanawiam sprawdzić rozmiar katalogu wp-content, bo teoretycznie on może puchnąć najszybciej. Zajętość folderu wp-content sprawdzam klientem ftp – ulubioną File Zillą. To trwa dość szybko, gdy skorzysta się z kolejki. Zobacz obrazki obok.

Kula w płot. Najbardziej podejrzany katalog wp-content okazuje się maleńki. Głupieję już całkiem. Decyduję się na założenie nowego joba w BackWPUp, zobaczymy co zbackup’uje tym razem. Odpalam zadanie backupowanie całości WP i ku mojemu zdziwieniu powstaje mały plik (standardowe parędziesiąt mega). Przez moment zaczynam wierzyć, że jestem świadkiem cudów, poczynań wrednej niewidzialnej ręki, lecz zdrowy rozsądek bierze górę i uciekam się po ostatnią metodę, jaka przychodzi mi wtedy do głowy, tak zwane porównywanie oczami.

I tu Cię mam!

W jednym oknie przeglądarki otwieram konfigurację tego nowego joba, w drugim – konfigurację feralnego zadania. Okna ustawiam obok siebie. I patrzę. I nie wierzę.

Błędna konfiguracja wtyczki BackWPUp
Rys. 1.3a. Błędna konfiguracja wtyczki BackWPUp
Prawidłowa konfiguracja wtyczki BackWPUp
Rys. 1.3b. Prawidłowa konfiguracja wtyczki BackWPUp

Konfiguracja obu zadań jest identyczna. Z maleńką, drobną różnicą. W tym starym zadaniu, pole include, które zawsze zostawiam puste, tym razem puste nie jest… Widnieje tam ścieżka do katalogu storowania backupu!

Po prostu popłynęłam się na rutynowym podejściu. Ścieżkę do katalogu gdzie mają być odkładane backupy wpisałam nie w to pole. Momentalnie przypominałam sobie dzień, kiedy pierwszy backup tej witryny nie wykonał się w ogóle. Wówczas grzecznie uzupełniłam ścieżkę we właściwym polu, dziwiąc się jeszcze, jak to możliwe, bo mogłabym dać uciąć sobie głowę, że ją już wpisywałam (racja, tylko nie w to pole…).

A więc jednak. Każdy kolejny backup zawierał już poprzedni. Rozmiary kolejnych backup’ów rosły w postępie geometrycznym! Nawet jeśli byłeś noga z matmy, po zaliczeniu takiej wpadki jak moja, do końca życia zapamiętasz, że takie ustawienie jest jak niewinne rzucenie kamyczka, które kończy się lawiną. A nawet śmiercią. W moim przypadku całej witryny.

Mądry Polak po szkodzie

Są też plusy takiej wpadki.

  • Nagle dostrzegłam fajne pole, którego nigdy wcześniej nie ustawiałam: Max backup files in folder (Oldest files will be deleted first) (Rys. 1.1 nieco wyżej). Gdy wpiszemy tam jakąś liczbę większą od zera, wtyczka sama wyczyści stare backupy.
  • Łatwiej przekonać klienta, że składowanie kopii zapasowych na tym samym koncie, gdzie działa witryna, nie jest najlepszym pomysłem. Bo jak odtworzyć z backupu stronę, gdy backup jest niedostępny?

Wpadka 2. – potęga mitu bywa silniejsza niż chęć pomyślunku…

Pytanie: Co robi WP-blondynka, gdy źle skonfiguruje WordPressa na subdomenie?
Odpowiedź: Pisze maila do hostingodawcy wytykając im ułomność serwisu.

Jak prawidłowo zainstalować WordPressa na subdomenie

Miałam postawić WorPressa w subdomenie. Robiłam to już wielokrotnie. Wykonuje się to tak:

    • Zakłada się poddomenę, korzystając z panelu zarządzania domenami. Jak konkretnie, to zależy od hostingodawcy. Zwykle jest zakładka subdomeny i przycisk „Dodaj subdomenę”. Na niektórych hostingach automatyczne powstanie katalog odpowiadający nazwie domeny. Na nie których nie. Wówczas trzeba założyć go samodzielnie ftp’ując się na serwer.
    • Do katalogu powiązanego z subdomeną wrzuca się pliki WordPressa.
    • Instaluje się WordPressa, podając ścieżkę do WordPressowej instalki w postaci poddomena.domena.pl/wp-admin/install.php

czyli np. testowa.webfaces.pl/wp-admin/install.php

Proste? Proste. Wydaje się, że tu nic nie można zepsuć. Wierzcie mi, że można.

Jak zepsuć instalację WordPressa na poddomenie

A było to tak: WordPress się zainstalował, po wpisaniu w przeglądarkę adresu subdomeny, pokazała się jak należy strona główna. Dokończam zatem konfigurację całej witryny, na koniec dostrzegam mały drobiazg. Chodząc po menu głównym, widzę, że wszystkie podstrony mają postać: domena.pl/poddomena/o-mnie, domena.p/poddomena/kontakt itd. zamiast: poddomena.domena.pl/o-mnie, poddomena.domena.p/kontakt!

WordPressa w poddomenie instalowałam nie pierwszy raz i nigdy nie było takiego problemu. Właściwie nie wiem, co mnie skłoniło, żeby napisać do supportu zamiast chwilę pomyśleć. Chyba wszystkie te krążące po sieci historie, że WordPress stawiany w home.pl to zmora deweloperów. A witryna klienta była właśnie na serwerach home’a.

No więc wysyłam maila do supportu z zapytaniem, co jest nie tak z tymi URL-ami. W odpowiedzi dostałam taką oto poradę:

Fragmnet korespondencji z supportem w home.pl w sprawie konfiguracji WordPressa na poddomenie
Rys. 2. Fragmnet korespondencji z supportem w home.pl w sprawie konfiguracji WordPressa na poddomenie

Gdybym i tym razem chwilę się zastanowiła, to powinnam się z tym zgodzić. Ale ja przecież instalowałam WordPressa w poddomenie dziesiątki razy i nigdy nie musiałam niczego zmieniać, tym bardziej w bazie mySQL!

Więc odpowiadam temu uprzejmemu Panu coś zupełnie nieuprzejmego (pozwolicie, że screenshota z mojego maila nie będę zamieszczać) i tuż po naciśnięciu „Wyślij” doznaję tak zwanego olśnienia!

W panelu admina w WordPressie, wchodzę w Ustawienia->Ogólne i patrzę na ekran, analogiczny do tego:

Jak nie należy konfigurować WordPressa na poddomenie
Rys 3a. Jak nie należy konfigurować WordPressa na poddomenie

No to pięknie! Taki zapis może świadczyć tylko o jednym. Z przyzwyczajenia „puściłam” instalkę WordPressa w formie: domena.pl/poddomena/wp-admin/install.php zamiast poddomena.domena.pl/wp-admin/install.php

Zmiana ustawień na http://poddomena.domena.pl pomogła (rysunek przykładowy niżej). Niesmak pozostał.

Jak prawidłowo postawić WordPressa na poddomenie
Rys 3b. Jak prawidłowo postawić WordPressa na poddomenie

Wpadka 3. – klient też coś wie o WordPressie…

Pytanie: W jaki sposób WP-blondynka przekonuje się, że klient działa szybciej niż programista?
Odpowiedź: Wykonując zmiany w skórce „na żywca” i licząc że uda się je przenieść do child theme’a szybciej niż klient zrobi aktualizację motywu.

Problem

Klient potrzebuje kilku zmian w szablonie, który pobrał gdzieś z sieci. Jego witryna oparta o ten motyw już działa i jest ogólnie dostępna.

Szybko, szybko, na motyw potomny przyjdzie pora…

Być może też tak masz, że chcesz szybko przekonać się, że Twój pomysł na rozwiązanie jest właściwy i zadziała. I aplikujesz zmiany na żywym organizmie, bo tak jest najszybciej. Klient jest pod wrażeniem Twojego tempa i skuteczności, podsyła jeszcze drugą i trzecią zmianę. Nawet nie zauważasz kiedy, zmodyfikowałeś ładny kawałek kodu i to w więcej niż w jednym pliku.

No i właśnie ja „tak mam”. Mimo że pisałam kiedyś, że robienie zmian na ogólnie dostępnej stronie, to jeden z grzechów głównych programistów. I mimo tego, że za każdym razem obiecuję sobie, że tylko ta jedna szybka zmiana i już zrobię to porządnie.

Porządnie, to znaczy z wykorzystaniem motywu potomnego, ponieważ:

  1. tak jest elegancko
  2. wszystkie Twoje zmiany są w jednym miejscu (w wydzielonym dla motywu potomnego katalogu)
  3. gdy klient zaktualizuje motyw do nowszej wersji, nie straci wykonanych zmian

Tyle że punkt 3. zdarza się szybciej niż się do tego zabierasz. Bo klient, który korzysta z WordPressa też chce się czymś wykazać. A Ty zapomniałeś mu powiedzieć, że pod żadnym pozorem ma nie robić aktualizacji do czasu zakończenia prac. I Twoje zmiany odlatują w siną dal, łącznie z dobrym wrażeniem, jakie zrobiłeś na kliencie…

Czy Tobie też zdarzają się wpadki podczas pracy z WordPressem?

Zapraszam do wygadania się.

Inne wpisy o podobnej tematyce:

17 komentarzy do “Plama na WordPressie, czyli moje największe wpadki”

  1. Oj, zdarzają się. Właśnie też z edytowaniem na żywca (i tak, też sobie obiecuję że to był ostatni, najostatniejszy raz).
    Zdarzyło mi się zapomnieć o aktualizacji jednego WordPressa. Skończyło się mocną infekcją. 🙁

    Fajnie, że zdecydowałaś się opublikować ten wpis 🙂

    1. Duży szacunek do autorki, że potrafi się przyznać i pisać o swoich błędach. Jest to doskonała sprawa być w stanie powiedzieć – pomyliłam się. Tak postawa pozwala na korektę błędów w przyszłości i osobisty rozwój, a jednocześnie wzbudza szacunek innych.

  2. Z backupem miałem podobny problem, tylko ja sobie zapchałem skrzynkę. Spakowane backupy przychodziły na e-maila, oczywiście trafiały do osobnego folderu oznaczane jako przeczytane. Kilka dni minęło zanim zauważyłem, że nowe wiadomości nie dochodzą 😉

  3. Mam nadzieję, że uniknę podobnych wpadek dzięki Twojemu wpisowi. Mam tylko takie pytanie, czy często pojawiają się problemy podczas przenoszenia bazy danych związane z kodowaniem znaków?

    1. Mi się nigdy nie zdarzyło, ale kojarzę podobny temat z forum, gdzie chłopak wykupił hosting gdzieś w USA i tam było inne kodowanie ustawione, nikomu to nie wcześniej nie przeszkadzało, bo w angielskim nie ma ogonków 🙂

  4. Ja co prawda wpadki nie zaliczyłem, ale stronę klienta oddałem innej osobie pod opiekę. Coś mnie podkusiło, żeby kilka miesięcy później wejść na tę stronę i o zgrozo backdoor trojan zainfekował pliki doklejając swój kod do plików php. Na szczęście szybka interwencja u osoby, która się tą stroną opiekowała, przywrócenie z backupu wszystkiego i natychmiastowa aktualizacja wtyczek i wordpress do najnowszej wersji. Nie mam do dziś pojęcia czemu tak się stało. Możliwe, że ta osoba nie aktualizowała wtyczek i worpdress i ktoś wykorzystał dziurę.

  5. Raz robiłem stronę i trzeba było wskazać właściwą domenę na katalog z plikami strony. Zrobiłem to i czekałem aż 3 dni na przypięcie domeny. Wciąż nie działało, więc napisałem do pomocy w tej sprawie. Okazało się, że wybrałem złą domenę. Były zarejestrowane 2 domeny, która jedna z nich była wykupiona przez klienta z błędną nazwą. Co lepsze sam zauważyłem tą literówkę i powiedziałem o tym klientowi. On zakupił drugą domeną z dobrą nazwą, a ja przypiąłem do katalogu tą ze złą nazwą. A już sobie w myślach mówiłem, jaki to beznadziejny hosting. A sam popełniłem błąd.

    U mnie to są początki tworzenia stron pod WordPressa dla klientów. Dopiero poznałem coś takiego jak motywy potomne. W jednym projekcie to zastosowałem, natomiast w innych nie. Rozumiem, że jeszcze można to poprawić i skopiować zmienione pliki do nowego katalogu motywu potomnego? Przyznam, że mam czasem problemy z motywem potomnym. Np. jak chciałem zmienić kod funkcji w pliku custom-functions.php w katalogu functions, to pomimo zmian WordPress pobierał dalej kod z oryginalnego pliku, a nie z tego, który umieściłem w katalogu motywu potomnego. Wiesz może jakie mogą być tego przyczyny, że nie działa?

    1. Paweł, dzięki za podzielenie się swoją historią. Z ciekawością przeczytałam.

      Jeśli chodzi o motywy potomne, to racja, czasami nie wszystko idzie jak po maśle. Jeśli chodzi o funkcje z functions.php to każdy przypadek może mieć zupełnie inną przyczynę, zależy czego dotyczy.

      Ja, gdy natykam się na coś specydicznego wrzucam hasła do google, dodając child theme i zwykle na stack overflow znajduję dobrą odpowiedź.

Dodaj komentarz

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