Czy WordPress to na pewno najlepsze rozwiązanie dla Twojej strony?

Tytułowe pytanie brzmi dziwnie gdy jest zadane przez człowieka, który od 5 lat jeździ po kraju i opowiada o możliwościach WordPressa. Jednak wbrew pozorom jest w interesie tego CMS-a.

O ostatnim festiwalu hakowania WordPressów przez lukę załataną w WP 4.7.2 na pewno słyszeliście. Teraz przez najbliższe 2-3 lata na każdej prezentacji poświęconej bezpieczeństwu będzie slajd, który będzie wspominał przełom stycznia i lutego 2017 roku jako piękny dowód czym kończy się brak aktualizowania WordPressa 😉

Moim zdaniem to w wielu wypadkach dowód na to, że ludzie wybrali sobie nieodpowiednie narzędzie do publikowania treści w sieci.

WordPress to oprogramowanie Open Source – oznacza to ni mniej ni więcej, że za darmo dostajemy efekt kilkuset tysięcy roboczogodzin programistów z całego świata z całym dobrodziejstwem inwentarza. Dlatego trzeba liczyć się z tym, że gdy ktoś znajdzie poważną lukę w WordPressie (i nie chodzi o to czy znajdzie ale kiedy) to powinniśmy w ciągu kilkunastu godzin zareagować i zaktualizować swoją witrynę. WordPress potrafi robić to automatycznie, ale i tak warto sprawdzić czy akurat tym razem coś nie padło, bo skrypt samoaktualizacji też nie musi być doskonały.

Krótko mówiąc – instalując WordPressa na serwerze niejako zobowiązujesz się dbać o jego właściwe utrzymanie – bez tego, prędzej czy później Twoja strona zostanie zamieniona w nośnik cudzej propagandy lub siedlisko malware’u.

Ilość stron zaatakowanych poprzez ostatnią lukę pokazuje, że całkiem sporo osób:

  • zapomniało o utrzymaniu albo
  • wyłączyło automatyczne aktualizacje w obawie, że coś zepsują na ich stronie (jeszcze inna opcja to zła konfiguracja WordPressa/serwera uniemożliwiająca automatyczną aktualizację).

Mnóstwo osób pewnie dopiero za jakiś czas odkryje, że ich strona nie do końca wygląda tak jak sobie wymarzyli. Dlaczego? Bo nie mają czasu interesować się swoją stroną 3 razy w tygodniu i nikomu nie zapłacili by robił to za nich.

Patrząc na to co ludzie po tych atakach wypisują (a wypisują czasem rzeczy, których po rozsądnych ludziach w życiu bym się nie spodziewał) trzeba powiedzieć jasno – dla WordPressa to wizerunkowa klapa. Niby był czas by zaktualizować strony, ale jak widać dla wielu za krótki. Prawdziwy jak nigdy staje się jeden ze slajdów z mojej prezentacji:

Każda strona na WordPressie pozostawiona sama sobie może niszczyć jego reputację

Tworząc nową stronę zastanów się nad tymi kwestiami:

  • Ile będę mógł poświęcić jej czasu?
  • Jak często zamierzam publikować?
  • Czy stać mnie na usługę administracji i zarządzania WordPressem?
  • Czy jeżeli pojawi się luka to będę w stanie szybko zareagować?

Jeżeli odpowiedzi na nie zamykają się w zbiorze: („mało”, „rzadko”, „nie”) to warto zastanowić się czy WordPress na własnym serwerze jest dla nas najlepszym rozwiązaniem. Są trzy opcje, które warto wtedy rozważyć:

  1. WordPress.com – czyli platforma blogowa bazująca na WordPressie,
  2. Inne platformy do blogowania,
  3. Strona statyczna.

Prosty przykład – strona łódzkiego WordUpa. Szok i niedowierzanie – nie stoi na WordPressie 😉 Ale wynika to z czystego pragmatyzmu – ta strona jest aktualizowana góra raz na kwartał. Dzięki temu, że umieszczona jest na Github Pages jedyne o czym muszę pamiętać to przedłużenie domeny 🙂

Gorąco polecam to podejście – szczególnie w sytuacji gdy ilość czasu jaką jesteśmy w stanie przeznaczyć na utrzymanie danej witryny (zarówno techniczne jak i publikacje) jest znikoma.

 

Share on Facebook21Tweet about this on TwitterShare on Google+0Email this to someonePrint this page
  • Pamiętam jak byłeś na lubelskim wordup chyba z grubo ponad rok temu i powiedziałeś wtedy, że nie zawsze warto stawiać strony na WordPressie. Bardzo długo wtedy analizowałem to co powiedziałeś i doszedłem do jeszcze dalej idących wniosków. Ja akurat dbam o wszystkie WordPressy moich klientów i aktualizuje je 2 razy dziennie dzięki InfiniteWP, które sprawdza wszystkie podpięte do niego strony i je aktualizuje. Problemem są jednak proste strony onepage które teoretycznie nie zmieniają się wcale lub 1-2 razy w roku. Czasami bywa tak ze po aktualizacji szablonu lub wtyczki coś zaczyna się rozjeżdżać, niektóre sekcje nie działają jak trzeba i musze to niestety poprawiać, często za przysłowiowe piwo. Nawet moja strona firmowa kilka razy się rozjechała bo była postawiona na rzadko aktualizowanym motywie i po aktualizacjach core WP lub wtyczek coś się sypało. Doszedłem więc do podobnych wniosków. Lepiej postawić stronę na HTML5+CSS3 opartą o jakiś framework (bootstrap lub bulma.io) i mieć święty spokój lub dalej męczyć się z aktualizacjami i poprawkami stron opartych o WP. Dodam jeszcze jedną kwestię – szybkość działania stron, większa kontrola nad kodem (nie jestem programistom php, znam jedynie podstawy), i dużo lepsza optymalizacja strony. To wszystko przekłada się na sporo szybsze czasy wczytywania strony i lepsze wyniki pozycjonowania w Google. Co nieco pisałem o tym w Grudniu na moim blogu: https://blog.nayma.pl/czy-zawsze-warto-budowac-strony-na-wordpress/
    Tak czy inaczej dzięki Tobie zdałem sobie już dawno temu sprawę, że WordPress mimo iż jest fajny i przyjemny to z czasem może być bardzo uciążliwy i często szybciej jest poprawić coś w HTML i dodać nowe treści niż przez cały rok męczyć się z dbaniem o WP 🙂 Pozdrawiam.

    • Miło słyszeć, że wnioski idące z mojej prezentacji mają potwierdzenie w prawdziwym życiu 🙂

      Ja osobiście WordPressa bardzo lubię i używam na wiele różnych sposobów, ale ślepa miłość powodowałaby zbędną pracę 🙂 Dlatego staram się używać go rozsądnie 🙂

      • Ja póki co też 90% jeszcze tworze dalej na WP, ale od tego roku właśnie starać się będę większość małych projektów, gdzie nie będzie aktualności, blogów, i zaawansowanych funkcji tworzyć jednak w czystym HTML. Największym dla mnie problemem jest odpowiednia optymalizacja pracy – uczę się właśnie min GULPa i SASS 🙂 Myślę, że to troszkę przyspieszy proces tworzenia stron. Inna rzecz, że w sieci jest naprawdę sporo dobrze napisanych darmowych szablonów HTML i wystarczy troszkę posiedzieć żeby uzyskać ciekawy efekt przy naprawdę niedużym nakładzie pracy. I taka stronka działa później bezobsługowo. A z WP wiadomo – trzeba dbać o bezp, aktualizować dziennie, sprawdzać, dodatkowe backupy plików i bazy danych (np BackWpUp) itp, itd 😉 Tak czy inaczej dzięki za ciekawe wskazówki.

        • Ja generalnie poszedłem ze stronami statycznymi o krok dalej i w ramach tzw. projektu pobocznego współtworzę: https://getpublii.com/ – by rozwiązać problem stron statycznych, które chcą raz na 2 miesiące aktualizować klienci 🙂 Gulp i SASS – z pewnością ułatwią życie. Do tego zestawu jeszcze dodałbym dobre poznanie GIT aby sobie skrócić proces deploymentu. Fajny workflow też jest pokazany w mojej prezentacji z użyciem hostingu netlify.

  • Zdefiniuj „rzadko” w kontekście aktualizacji 🙂

    • @gajanna – najczęściej „rzadko” oznacza wtedy gdy wchodzisz do kokpitu napisać nowy wpis a tam 5-10 wtyczek czeka na aktualizację 😉

      Według mnie „rzadko” w tym wypadku oznacza wpis raz na miesiąc lub rzadziej. Ale tak naprawdę jeżeli strona jest rozbudowana i zależna od wielu wtyczek to nawet wpis raz na dwa tygodnie to „rzadko” 🙂

      Na przykład mój blog powoli zaczyna się prosić o przenosiny na stronę statyczną – bo mam rzuty pisania a potem jak ugrzęznę w jakimś większym projekcie to potrafię nie pisać przez pół roku i mnie wtedy powiadomienia o aktualizacjach tylko irytują 😀

      • Uff… Czyli nie jest ze mną aż tak źle 🙂

        Tak w ogóle to super wpis, po cichu liczę na częstsze publikacje z Twojej strony 🙂

        • 🙂

          Staram się powoli wrócić do częstszego publikowania – nie mogę nic obiecać, ale zacząłem stosować na swoim trello różnej maści motywatory by wpisy pojawiały się częściej.

          Natomiast ostatnio w ramach rozgrzewki do cięższych tematów, zacząłem tworzyć bloga dla początkujących WordPressowców: http://podstawy-wp.pl/ – aczkolwiek niektóre porady są prawdopodobnie przydatne dla wszystkich 😉

          • Trzymam kciuki za powrót do blogowania 🙂
            Na pewno będę odwiedzać bloga dla początkujących.

            Pozdrawiam!

  • Ja tam gdzie mi zależy mam wtyczkę, która mi posyła maila z info o aktualizacji: https://pl.wordpress.org/plugins/wp-updates-notifier/ więc przez ostatnie pół roku wchodziłem na swojego bloga jak musiałem 😉

  • Wbrew wszystkiemu, zgadzam się Tomasz. Czy ten WP Updates Notifier to na pewno dobry, ostatnie wsparcie 8 mies. temu… instalować to?

  • Wszystko zależy od celu i projektu. Ale WP wspierają miliony użytkowników, dlatego na pewno to jest nie najgorsze rozwiązanie 🙂

  • Marek Aleszczyk

    Strony, które rzadko się zmieniają, można cache’ować, wtedy przynajmniej na froncie nic się nie rozjedzie, czy dobrze myślę ?

    • Cache służy głównie do odciążenia serwera przy generowaniu podstron, no i cache nie chroni przed lukami bezpieczeństwa 😉

      • Marek Aleszczyk

        Jest przecież możliwość ustawienia cacheowania również dla strony głównej, nie tylko podstron. Strona może być generowana przez WordPress tylko dla zalogowanych administratorów, użytkownikom generowane są pliki html, bez dotykania php. Przed lukami to nie uchroni, ale uchroni przed tym żeby ktokolwiek doświadczył efektów tych luk, poza zalogowanym administratorem. NIe rozjedzie się też nic samo po aktualizacji wtyczek lub motywu, dopóki nie zostanie odświeżony cache. Uważam że to dużo wygodniejsze niż stawianie strony statycznej, bo co prawda rzadko na stronie coś zmieniamy, ale jednak…, możemy te treści po ludzku edytować, mamy te wszystkie shortcodes, widgety i inne takie… 🙂

        • No niestety to tak nie działa. Nawet jeżeli cache generuje stronę do plików HTML to nadal na serwerze mamy kod PHP do którego atakujący może się dobrać. I teraz wystarczy luka, która pozwala dobrać się do kokpitu i atakujący może wyczyścić cache. Przewaga stron statycznych polega na tym, że nie mają żadnego kodu PHP na serwerze co ogranicza znacząco liczbę wektorów ataku – choć oczywiście nawet stronę statyczną da się złamać jeżeli np. jej autor nie zabezpieczy odpowiednio kont FTP itp.

          • Marek Aleszczyk

            Hmm, może czegoś nie rozumiem, ale z tego co mi wiadomo, to kod PHP oczywiście istnieje, w postaci plików w folderze z WordPressem, ale żaden z tych plików nie może zostać zinterpretowany, jeśli są dobrze ustawione rewrite rules, więc jedyne do czego może dobrać się pan hakier, to luka w serwerze Apache lub jego module rewrite, co jest tak samo prawdopodobne przy stronie statycznej. Dobrze kombinuję czy powinienem się jeszcze doszkolić ?;) No fakt, mogłaby to być luka w plikach php, w folderze WP-ADMIN. Ale skrypt logowania do kokpitu to chyba najbardziej sprawdzona część kodu WordPressa ? Mam taką nadzieję…;)

          • Przyjmijmy hipotetycznie, że nie da się z poziomu WWW odpalić żadnego pliku PHP WordPressa – na upartego pewnie da się tak ustawić .htaccess.

            Tylko jak wtedy będzie działał kokpit? A jeżeli będzie działał to już mamy punkt wejścia do systemu dla atakującego. Inna sprawa, że takie założenie – a mogą mi zaatakować stronę, cache mnie obroni jest bardzo złe, bo mogą np. wyciec dane osobowe albo dostępy do usług spiętych z naszym WordPressem – polecam: http://podstawy-wp.pl/bezpieczenstwo/podawanie-danych-dostepowych-innych-uslug-wordpressie-robic/

            Trzeba kombinować i cudować – i tu jest właśnie przewaga stron statycznych – może dłużej je się robi (czasem), ale zwraca się to w utrzymaniu późniejszym 😉

          • Marek Aleszczyk

            Dlaczego zakładać że skrypt logowania do kokpitu jest mniej bezpieczny niż np. skrypt logowania do panelu hostingu na którym mamy naszą super bezpieczną stronę statyczną ? Zgadzam się że przyjmowanie założenia że cache mnie obroni jest złe, bo nie obroni. Przyjąłem tylko założenie że obroni oczy odbiorców strony przed ujrzeniem ,np napisu „Hacked by” itd, czyli przed utratą wizerunku :). Twój wpis jest o prostych stronach, na których nie ma zbyt wiele wrażliwych danych.

          • „Dlaczego zakładać że skrypt logowania do kokpitu jest mniej bezpieczny niż np. skrypt logowania do panelu hostingu na którym mamy naszą super bezpieczną stronę statyczną ?”

            Bo kod skryptu logowania do kokpitu jest open source, a kod panelu hostingu już niekoniecznie? 😉

            „Przyjąłem tylko założenie że obroni oczy odbiorców strony przed ujrzeniem ,np napisu „Hacked by” itd, czyli przed utratą wizerunku :). Twój wpis jest o prostych stronach, na których nie ma zbyt wiele wrażliwych danych.”

            Już ustaliliśmy w sumie, że cache nawet przed tym nie obroni jeżeli ktoś się włamie do kokpitu – bo po prostu wyczyści sobie cache 😉

          • Marek Aleszczyk

            Słyszałem już wiele dyskusji na temat, czy open source, jest bezpieczniejszy, czy mniej bezpieczny, i wydaje się że ten spór nie jest definitywnie rozstrzygnięty, bo obie strony mają wiele racjonalnych argumentów. Co prawda każdy potencjalny haker może go przestudiować, ale z drugiej strony każdy człowiek, który może i chce, przyczynić się do poprawy jego bezpieczeństwa także. No i przecież panele hostingów też czasem opierają się o kod open source, więc trzeba szukać odpowiedniego hostingu czyli kombinować i cudować. No ale to już jest pewnie temat na osobny wpis…Pozdrawiam i już nie zawracam głowy. 🙂

  • Paweł Knapek

    Przecież te WordPressy takie proste i łatwe miały być, to to trzeba aktualizować? Panie, ja nie mam czasu ani ochoty na jakieś aktualizacje, kto by o tym pamiętał? – żem myślał, że to takie zainstaluj i zapomnij ;p A poza tym, to po co aktualizować skoro dobrze działa? ….jeszcze coś się popsuje i co ja zrobię? xD Ech, samo życie.

    Niestety, mało tego, że sporo użytkowników tak do tego podchodzi, to jeszcze „eksperci” dokładają swoją cegiełkę. Nie tak dawno spotkałem się z przypadkiem, że pewna agencja strzeliła wdrożenie stronki z autorskim motywem … wyłączyli AU i przekazali klientowi, by pod żadnym pozorem niczego nie aktualizował, bo się może coś popsuć ( w sumie to prawda była, bo wychodząca wówczas na dniach aktualka WP rozkładała stronę na łopatki) 😡 -Bez komentarza.