A WordPress kritikus pontjai: A fejlesztői perspektíva

Egyre több fejlesztő használ olyan CMS-t, mint a WordPress, még akkor is, ha nem szeretik a platformot.

A képzett fejlesztők gyakran előszeretettel használnak egyedi megoldásokat, különösen akkor, ha Ön olyan fejlesztő, aki nagyon jó a kódolásban. Egyedi megoldással nagyon elegáns, nagyon jól működő alkalmazásokat hozhat létre. A fejlesztők azonban végül olyan CMS-t használnak, mint a WordPress, még akkor is, ha nagyon nem szeretik a platformot.

Ez a cikk ezeknek a fejlesztőknek szól, és a WordPress (WP) használata során felmerülő számos kihívással foglalkozik. Elmagyarázzuk, mik ezek a nehézségek, és egy javaslatot is adunk: a Plesk segítségét, amely egy olyan WP-eszközkészletet biztosít, amely valóban segít a világ legkedveltebb CMS-jének, a WordPressnek a legfontosabb kritikusainak figyelembevételében.

Miért használják a fejlesztők a WordPress-t?

Tévedés ne essék, a WordPress a legnépszerűbb CMS a piacon, ennek nagyon jó okai vannak. Ebben a részben leírjuk, miért olyan népszerű a CMS még a tapasztalt fejlesztők körében is, akik valóban képesek saját kódot írni.

Először is, a WordPress telepítése rendkívül egyszerű. Csak a szabványos LAMP/LEMP környezetre van szüksége – Linux, Apache/Nginx, PHP és MySQL/MariaDB DBMS-ként. Ha megvan, elkezdheti a WordPress telepítését.

A testreszabás ugyanilyen egyszerű, mert a WP CMS rengeteg kiegészítőt tartalmaz, beleértve a kezelőfelület kinézetének testreszabásához szükséges témákat, valamint a funkciókat bővítő beépülő modulokat. Lehetőség van saját téma létrehozására is, és a tapasztalt fejlesztők is elkészíthetik saját beépülő moduljaikat, de ez a folyamat bonyolultabb.

A WordPress népszerűségének talán legnagyobb oka természetesen az a tény, hogy elérhető a nem műszaki felhasználók számára. A WP telepítése után a megfelelő működéshez nincs szükség kódolási tapasztalatra vagy a szoftver megértésére, a kezdő felhasználók munka után azonnal közzétehetnek egy webhelyet, és beállíthatnak egy WordPress-példányt.

Pontosan mi a probléma a WordPress-szel?

Nos, a világ legnépszerűbb CMS-je számos kérdést megfontolandó. Nem áll szándékunkban felhajtást csapni a WordPress-problémák miatt, de a következő egy őszinte megbeszélés, és reméljük, hogy a hihetetlenül népszerű CMS mögött álló fejlesztőcsapat pozitív kritikaként veszi a következő pontokat. Ezért gondoljuk, hogy a WordPress frusztráló a fejlesztők számára:

Széles körben képes, de soha nem kiváló

A WordPress kezdete egyszerű volt. A WP azért született, hogy platform legyen azok számára, akik blogot szeretnének írni és közzétenni. A CMS teljesen megváltozott az évek során, és mára már nem hasonlít a szerény kezdetekhez. Vannak, akik alaprendszerként használják egy teljes webhely kezeléséhez, online boltok platformjaként, sőt statikus webhelyek létrehozására is (őrültség, de ezt is láttuk az évek során)

Valahogy rávilágít arra, hogy a CMS mennyire alkalmazkodóképes, és egyetértünk ezzel az állítással, de a rugalmasság problémája az, hogy nehéz egyetlen szerepkörben sem kitűnni. Ennek felismerésének egyik módja a beépülő modulok lencséjén keresztül történő szemlélés: a több ezer elérhető WordPress beépülő modul megmutatja, hogyan próbálják az emberek olyasmire kényszeríteni a WordPress-t, ami egyszerűen nem az, vagy ami még rosszabb, olyasmire, amire nem képes. megteszi, fáj. Emiatt amikor a WordPress-t használjuk, és gyakran és szívesen használjuk, soha nem töltjük be olyan bővítményekkel, amelyek nem feltétlenül szükségesek. Ilyenkor inkább magunk készítjük el őket.

Nyilvánvaló, hogy a WordPress ehhez a „saját készítésű” megközelítéshez készült, és a rugalmasságnak kétségtelenül számos előnye van. De egy adott feladatra való erős összpontosítás nélkül a CMS sokat küzd azért, hogy egyértelmű megoldást kínáljon. Hatalmas problémákat okoz ez az összpontosítás arra, hogy mindenki számára minden legyen. Mindazonáltal le kell szögeznünk: a WordPress továbbra is jól működik platformként blogok és nem bonyolult webhelyek és e-kereskedelmi webhelyek létrehozásához.

Hackek és repedések: A WordPress nyitott ajtó lehet

Röviden: a WordPress éjjel-nappal feltörik, és ez a legnagyobb panasz, amit a fejlesztői világtól hallottunk. Tagadhatatlan, a CMS tele van biztonsági résekkel, soha nem ér véget. Olyan, mint egy rövid takaró: az egyik oldalon megigazítod, a másikon kinyílik. A feltörések száma részben a WordPress népszerűségének, de annak is köszönhető, hogy mennyire nyílt forráskódú a WordPress.

Mivel bárki megtekintheti a CMS nyílt forráskódját, ez lehetővé teszi a hackerek számára, hogy megtalálják a kód gyenge pontjait. Nem azt akarjuk mondani, hogy a nyílt forráskódú kód rossz megközelítés, de úgy gondoljuk, hogy a WordPress CMS nyílt forráskódú természete hozzájárul a végtelen biztonsági problémákhoz.

Az elemzés azt mutatja, hogy a WordPress webhelyek az internet több mint egynegyedét teszik ki. A WordPress csapata tudja ezt, és mindent megtesz annak érdekében, hogy megbizonyosodjon a CMS biztonságáról, de mivel a fejlesztési ciklusok manapság olyan gyorsak, nehéz lehet egy összetett alkalmazást teljesen biztonságossá tenni. Ha pedig a biztonsági erőfeszítések kudarcot vallanak, webhelyek milliói kerülhetnek veszélybe.

A WordPress biztonsági kihívásaira természetesen nincs más kézenfekvő megoldásunk, mint a nyilvánvaló „frissítse a WordPress példányát”. A WordPress kiadási ciklusa még ekkor is egyedi és végtelen problémákat hoz magával.

Sokan azt mondják, hogy a WordPress biztonságáról gondoskodni egyszerű, és ez nagymértékben igaz is, de a kérdés az, hogy miért kell a webhelytulajdonosoknak egy teendőlistát készíteni, hogy megbizonyosodjanak a WordPress biztonságáról? Miért nincs a WordPress biztonsági része a dobozból?

• Valaki könnyen feltölthet futtatható fájlt a WordPress-re, és ezt a lehetőséget alapértelmezés szerint korlátozni kell. Csak egy kicsit okos ember kell egy rosszindulatú kódot tartalmazó fájlt feltölteni egy PHP-szkriptbe, és a webhelye veszélybe kerül.
• Jelenleg a beállítások a fájlrendszerben konfigurálhatók. Ehelyett a WordPressnek ezt ki kell vetnie, és azt kell feltételeznie, hogy a fájlrendszer „csak olvasható”. Míg a WordPress magja ezt teszi, a beépülő modulok nem követik ezt a viselkedési mintát. Ha olyan beépülő modullal találkozik, amely megváltoztatja a konfigurációs fájlját, miközben aktív éles állapotban van, hagyja abba a használatát. Ez írható fájlrendszert jelez, és ennek következtében a rosszindulatú módosítások egyszerű módja. Az egyik megoldás a wp-config.php fájl eltávolítása a rendszer gyökeréből (a WordPress egyébként működik), de ez nem garantálja a biztonságot, és mindenesetre megakadályozza számos, az öntudatlan fejlesztők által lejegyzett plugin helyes működését. .
• A WordPress alapértelmezés szerint annyi bejelentkezési kísérletet tesz lehetővé a felhasználóknak, amennyit csak akarnak. Ez megnyitja az ajtót egy brute force támadás előtt, ahol a hackerek addig próbálkoznak véletlenszerű jelszavakkal, amíg a bejelentkezés sikeres lesz. A WordPress CMS-nek le kell tiltania a korlátlan bejelentkezési kísérletet a telepítéskor.

Ez nem egy teljes lista, csak néhány pont. Nyilvánvaló, hogy egy nagy szoftveres megoldás, különösen egy nyílt forráskódú megoldás, nem lehet teljesen sebezhetetlen a támadásokkal szemben. De a lényeg az, hogy a komoly fejlesztők éppen azért nem szívesen használják a WordPress-t, mert az annyira sebezhető. A képzett fejlesztők szívesebben építenének egy vadonatúj alkalmazást, amely elegánsan megfelel az igényeiknek, és szigorúan védhető – anélkül, hogy az ismeretlen jövőbeli sebezhetőségek miatt kellene aggódniuk.

Vagy ha a lehető legjobban használja ki a PLESK beállításait, és nem tölti be a WordPress-t „nem ajánlott”, rosszabb esetben „ingyenes”, vagy rosszabb, de rosszul megírt bővítményekkel (a területen szerzett tapasztalat szükséges ahhoz, hogy ítéletet tudjon hozni róla), továbbra is hogy a WordPress kiváló platform legyen a biztonság szempontjából is. De ez már nem "csináld magad" menedzsment, szakértő kézre van szükség.

A beépülő modulok, mint problémák forrása

Egy jó fejlesztő nem folyamodik pluginhez, amikor először elakad. Ehelyett a jó fejlesztők megpróbálnak egyszerű és elegáns megoldást felépíteni. Éppen ellenkezőleg, mindig a bővítményekre támaszkodni úgy, hogy rájuk keresünk az interneten, vagy a Közösség által javasoltakra hagyatkozunk, nagyon rossz gondolkodásmód.

Végső soron egy beépülő modul megkönnyíti bizonyos funkciók hozzáadását a WordPresshez, ami a WP számára elérhető bővítmények széles skáláját a CMS erősségévé teszi – de ez egyben kockázatot is jelent. A beépülő modulok bármennyire megkönnyíthetik és felgyorsíthatják a dolgokat, a beépülő modulok sok biztonsági kockázatot is jelentenek, ugyanakkor arra kényszerítik Önt, hogy válassza ki a WP melyik verzióját használja, ugyanakkor hihetetlenül felfújja a WordPress-példányt. fenntartható. mérje meg az online jelenlét frusztrálásával vagy válságba hozásával, az oldal megnyitásának sebességét és ezáltal az elérhetőséget, és ebből következően a megfelelő indexelést a keresőkben.

Pluginok és biztonság

Először nézzük meg a beépülő modulok által létrehozott biztonsági problémákat. Egy jelentés azt sugallja, hogy a WordPress ismert biztonsági problémáinak több mint fele a beépülő modulokból ered. A fejlesztőkre vonatkoznak minden bevált gyakorlat, amelyet a beépülő modulgyártó követ – ami nem biztos, hogy olyan jó. Ezért fejlesztőként alaposan tesztelnie kell a beépülő modult használat előtt. Ez az ellenőrzési folyamat bizonyos mértékig csökkentheti a beépülő modulokkal megtakarított időt, így ezen a ponton akár megfontolhatja a szükséges funkció újbóli fejlesztését, amelyet hozzáadhat a webhelyhez.

Korlátok a WP verziókra

A „verziókényszerként” ismert beépülő modulok korlátozhatják, hogy a WP CMS melyik verzióját futtathatja. A WordPress most nagyon agresszív a megjelenési ciklusával, ezért rendszeresen ad ki új frissítést, sőt gyakran előfordul, hogy a platform egy adott hónapban több kisebb verziót vagy javítást ad ki. Ez érthető, hiszen a WP csapata folyamatosan javítja a támadási vektorokat. Ennek ellenére mindegyik frissítésnek van egy problémája: a WP-frissítések feltörhetnek egy bővítményt, aminek következtében a webhely leáll, vagy összeomlik.

Természetesen naprakészen kell tartania a CMS-t, de a bővítmények által támasztott verziókorlátok megnehezíthetik ezt a munkát. Egyes bővítmények fejlesztői folyamatosan tesztelik és frissítik bővítményeiket, de ez a kis "világ" prémium bővítmények nem a többséget képviseli. Ezeken a prémium bővítményeken kívül fennáll annak a veszélye, hogy a WP-verzió frissítése szó szerint összetörheti a webhelyet.

Bloat pluginok

Tegyük fel, hogy a legtöbb fejlesztő tudja, hogy fontos olyan lean projekteket építeni, amelyek nem használnak felesleges kódot. Mostanában néhány plugin megfelel ennek az elvnek, de sok beépülő modul nagyon fel van duzzadva, mert ezek a bővítmények megpróbálnak megoldani minden problémát, ami a felhasználónak felmerülhet. Gyakran előfordul, hogy a fejlesztő azt tapasztalja, hogy egy beépülő modul megold egy problémát, miközben ötven másik, a webhelye szempontjából nem releváns problémára kínál megoldást. (A témákról és az "építőkről" nem is beszélve).

A beépülő modulok megszakítják a WordPress munkafolyamatát

Végül egy másik gyakori probléma, amelyet sok beépülő modul hoz létre, az a tény, hogy egy bővítmény akadályozhatja a felhasználói élményt a WordPressben, ez sajnos a hatástól függ. bloat pluginok a WordPress. Például egy beépülő modul teljesen megváltoztathatja a bejegyzés létrehozásának és a webhelyen való terjesztésének módját.

Ez egy olyan problémához vezet, amellyel a WP-fejlesztők nagyon gyakran szembesülnek, úgy érzik, hogy túl sokat kell „megkerülniük” egy bővítményt, ahelyett, hogy csak azt használnák. A fejlesztők elkerülhetetlenül magukra vállalják a beépülő modulok megkerülésének folyamatát, mert úgy tűnhet, hogy ez a beépülő modul egy folyamatproblémát old meg (ami elkerülhetetlenül nincs meg).

A webarchitektúra fejlődött

Már említettük, hogy a WordPress már jó ideje létezik. Amikor létrehozták, a fejlesztők azt feltételezték, hogy egy webhely mindig egyetlen szervert használ egyetlen fájlrendszer mellett. A fejlesztők azonban egyre gyakrabban használják az úgynevezett mikroszerver-architektúrát, amely több csomópontot használ. Azért teszik ezt, mert ez a munkamódszer jobban méretezhető és rugalmasabb. A WordPress bonyolult architektúrán való használata azonban problémákat okozhat, például az FTP szinte kizárólagos használata a WP CMS-frissítésekhez.

A modern fejlesztők nyilvánvalóan azt gondolnák, hogy a kód FTP-n keresztüli frissítése pusztán archaikus dolog. A fejlesztők általában egy adott munkafolyamatot használnak, így a lehetséges problémákat még a kód működésbe lépése előtt le lehet állítani. Ez azt jelenti, hogy a fejlesztés helyben történik, a kód verzió vezérelt, és ezt a kódot is automatikusan tesztelik – mindezt egy folyamatos integrációs folyamaton keresztül. Tehát csak új kódot kell betölteni egy olyan környezetbe, amely rövid hurkokat futtat, ami azt jelenti, hogy nagy a valószínűsége annak, hogy a dolgok rosszul sülnek el.

A javítási problémánál nagyobb egyszerűen az a feltételezés, hogy egyetlen fájlrendszerrel, egyetlen csomóponton dolgozunk. A több csomópontból álló webszerver-fürt javítja a hardverhibákat és a teljesítményt egyaránt, ezért ezt a megközelítést egyre inkább alkalmazzák. A WP-nek azonban van egy akadálya, hogy a téma vagy a bővítmény frissítésének FTP-n keresztüli telepítése azt jelenti, hogy egyszerre csak egy fájlrendszer frissíthető. Tehát egy több csomópontból álló fürt esetén minden csomóponton meg kell tennie ezt a frissítést.

A fejlesztők megkerülhetik ezt a problémát, de ez továbbra is olyan nehézség marad, amelyet nem lehet könnyen megoldani. Ezenkívül a folyamat megköveteli, hogy a fájlrendszer írható legyen, ami viszont komoly biztonsági problémát jelent az adatbázisban, amely a WordPress dobogó szíve.

Árva adatok és adatstruktúra általában

Eleinte a WordPress adatszerkezete egyszerű. Hamarosan azonban kiderül, hogy redundáns táblák vannak a WP adatbázisban. Például miért kell a metaadatokat két táblára szétválasztani: az egyiket "wp_posts" és egy "wp_postmeta" táblára? Nem jobb, ha minden adatot egy táblázatba foglal? Ugyanez vonatkozik a megjegyzéstáblázatra is, amelynek van egy második társított táblája a metaadatokhoz.

Az eredmény az, hogy az adatbázisban extra adatok maradnak. Igen, a WP tartalmaz néhány olyan funkciót, amelyek segítenek csökkenteni az árva adatok hatását, de a funkciók meghiúsulnak, ha több ezer sorból álló sorszámot kell módosítani. Alapvetően a WordPress szolgáltatásai a szerver időtúllépését okozzák, memóriaszivárgáshoz vezetnek, és egyszerűen nem hatékonyak.

Természetesen dönthet úgy is, hogy egyszerűen csökkenti az árva adatokat, ehhez közvetlenül SQL-lekérdezéseket ír. De alaposan meg kell értenie a táblák összekapcsolását, hogy meg tudja írni a megfelelő SQL-lekérdezéseket. A WordPress adatbázisban az adatok szétválasztásának mértéke egyszerűen feleslegesnek bizonyul.

Mit tesz a Plesk Toolkit for WordPress a dolgok jobbá tételéért?

A Plesk WordPress Toolkit segítségével egyszerűen beállíthat és testreszabhat egy WordPress-példányt, mindezt egyetlen vezérlőpultról. Mindaddig használhatja, amíg telepítve van a webhelyén. Íme néhány terület, ahol a WordPress Toolkit segít a WP gondozásában:

Biztonsági menedzsment

Az eszközkészlettel automatikusan bezárhatja a legszembetűnőbb biztonsági réseket. Például átállíthatja az XML-t RPC-ping vissza, ellenőrizze, hogy a „wp-content” mappa biztonságos-e, és még sok más. Az eszközkészlet megjeleníti a webhely biztonsági állapotát, és a problémákat „veszély” vagy „figyelmeztetés” jelzéssel jelzi, ami a biztonság javítására vonatkozó ajánlás.

A WP példány frissítése

A Toolkit 3.x és újabb verzióiban kiegészítő funkcióként elérhető Intelligens frissítések funkció lehetővé teszi a termelési telephely folyamatos működését és egyidejű frissítését a webhely feltörésének kockázata nélkül. Az eszköz ellenőrzi a frissítés miatt esetlegesen felmerülő problémákat, és jelzi, ha fennáll valamilyen veszély.

Klónozás

Rengeteg oka van annak, hogy miért szeretne másolatot készíteni a WordPress webhelyéről. Például lehet, hogy van egy állomáshelye, ahol tesztelheti a változtatásokat az éles indítás előtt. Ha készen áll, át szeretné másolni a webhely tartalmát.

Vagy lehet, hogy van egy nyilvános webhelye, és szeretne róla másolatot készíteni, amelyhez nem szeretné, hogy a nyilvánosság hozzáférjen. Egy másik példa a professzionális fejlesztők, akik rendelkeznek egy WordPress-telepítés mintapéldányával, és csak azt szeretnék automatikusan klónozni, beleértve a témákat és a bővítményeket is.

Vannak ügyfeleink is, akik különféle okokból csak néhány másolatot szeretnének készíteni egy webhelyről, például annak bemutatására, hogyan nézhet ki egy webhely néhány változtatással.

Bármi legyen is az oka, a WordPress Toolkit klónozó eszköze megkönnyíti az összes másolást, beleértve a webhelyfájlokat, a webhely adatbázisát és az összes WP CMS-beállítást.

Szinkronizálás

Különféle okok miatt érdemes megbizonyosodni arról, hogy két WordPress-webhely egyezik. A WP Toolkit lehetővé teszi a WP-adatbázis és az összes WP-fájl automatikus szinkronizálását.

Ha rendelkezik a webhely átmeneti példányával, miközben a nyilvános másolata máshol fut, érdemes lehet szinkronizálni a webhelyeket, mert át szeretné másolni az átmeneti webhelyen végzett módosításokat a WP élő webhelyére.

Hasonlóképpen érdemes átmásolni néhány adatot a termelési helyről az átmeneti példányba, hogy ellenőrizhesse, hogy az állomásoztatási verzióban végrehajtott módosítások megfelelően működnek-e az élő adatokkal. Vagy az átmeneti webhelyen végrehajtott módosítások változást okoztak az adatbázistáblákban, amely esetben az eszközkészlet csak akkor teszi lehetővé, hogy ezeket a változtatásokat az adatbázissal szinkronizálja, ha kívánja.

A WP Toolkit szinkronizálási funkciójának másik felhasználási esete az, amikor egy fejlesztő frissített egy átmeneti webhelyet a WordPress kiskereskedelmi verziójára, és a változásokat egy élő webhelyen szeretné tükrözni.

Lehetősége van szinkronizálni a teljes WP CMS-t, vagy csak egyes részeit. Tehát tükrözheti a WP fájljait, adatbázisát vagy mindkettőt. A kínálat további részletessége, hogy választhat a teljes adatbázis vagy csak a táblák szinkronizálása között, vagy akár a forrásban található, de a célhelyen nem található táblák között. Lehetőség van az egyes táblázatok tükrözésére is.

Hibavadászat a WP-ben

A Plesk WordPress Toolkit lehetővé teszi a fejlesztők számára, hogy automatikusan észleljék és kijavítsák a webhely forrásában lévő hibákat a hibakeresési mód engedélyezésével.

Következtetés.

A fentiek után nyilvánvaló, hogy rendkívül fontossá válik, hogy ne csak a fejlesztőt, vagy az Önt követni tudó ügynökséget válasszuk ki, hanem mindenekelőtt azt a tárhelyet, amelyen webhelyét WordPress-ben tárolja. Még ezekből a dolgokból is megértjük, mit jelent egy sötét webhely egy professzionális tárhelyen vagy sem.

A WordPress nem egy könnyen kezelhető „objektum”. Persze, szabadnak érzi magát, úgy gondolja, hogy nincs szüksége fejlesztőre, vagy nem kötődik ügynökséghez, úgy gondolja, hogy csodálatos, ha egyedül csinálhatja, de a valóságban az igazság mást mond, és ma a biztonság az a téma, már nem másodlagos, hanem elsődleges a harmadik személyekkel szembeni kötelezettségek és felelősségek miatt is.