Kritikat e WordPress: Perspektiva e një Zhvilluesi

Gjithnjë e më shumë zhvillues përfundojnë duke përdorur një CMS si WordPress, edhe nëse nuk u pëlqen platforma.

Zhvilluesit e aftë shpesh preferojnë të përdorin zgjidhje të personalizuara, veçanërisht kur jeni një zhvillues që është vërtet i mirë në programim. Me një zgjidhje të personalizuar mund të krijoni aplikacione shumë elegante që funksionojnë shumë mirë. Sidoqoftë, zhvilluesit përfundojnë duke përdorur një CMS si WordPress edhe nëse nuk e pëlqejnë fort platformën.

Ky artikull u drejtohet këtyre zhvilluesve dhe adreson shumë nga sfidat që hasen gjatë punës me WordPress (WP). Ne do të shpjegojmë se cilat janë këto vështirësi dhe gjithashtu do të japim një sugjerim: ndihmën e Plesk, e cila ofron një paketë veglash WP që vërtet ndihmon për të marrë parasysh disa nga kritikat kryesore të CMS-së më të dashur në botë: WordPress.

Pse zhvilluesit përdorin WordPress

Mos bëni gabim, WordPress është CMS-ja më e njohur në treg për arsye shumë të mira. Në këtë seksion ne përshkruajmë pse CMS është kaq popullor edhe në mesin e zhvilluesve me përvojë, të cilët në fakt mund të shkruajnë kodin e tyre.

Së pari, WordPress është shumë e lehtë për t'u instaluar. Gjithçka që ju nevojitet është mjedisi standard LAMP/LEMP – Linux, Apache/Nginx, PHP dhe MySQL/MariaDB si DBMS. Nëse e keni, mund të filloni të instaloni WordPress.

Përshtatja është po aq e lehtë sepse WP CMS vjen me një gamë të madhe shtesash, duke përfshirë tema për të personalizuar pamjen dhe ndjesinë e pjesës së përparme dhe shtojca që shtojnë funksionalitetin. Është gjithashtu e mundur të ndërtoni temën tuaj dhe zhvilluesit me përvojë mund të bëjnë gjithashtu shtojcat e tyre, por ky proces është më kompleks.

Ndoshta arsyeja më e madhe për popullaritetin e WordPress është, natyrisht, fakti që është i arritshëm për përdoruesit jo teknikë. Pasi të instalohet WP nuk kërkon përvojë kodimi ose kuptim të softuerit për të funksionuar mirë, përdoruesit fillestarë mund të publikojnë një faqe interneti dhe të krijojnë një shembull të WordPress menjëherë pas punës.

Cili është saktësisht problemi me WordPress?

Epo, CMS-ja më e njohur në botë ka shumë çështje për t'u marrë parasysh. Ne nuk kemi ndërmend të bëjmë bujë rreth çështjeve të WordPress, por në vijim është një diskutim i sinqertë dhe shpresojmë që ekipi i zhvillimit që qëndron pas këtij CMS tepër popullor t'i marrë pikat e mëposhtme si një kritikë pozitive. Ja pse mendojmë se WordPress është zhgënjyese për zhvilluesit:

Shumë të aftë, por kurrë të shkëlqyer

Fillimi i WordPress ishte i thjeshtë. WP lindi për të qenë një platformë për ata që donin të shkruanin dhe publikonin një blog. CMS ka ndryshuar plotësisht me kalimin e viteve dhe tani nuk është aspak si fillimet e tij modeste. Disa njerëz e përdorin atë si një sistem bazë për të menaxhuar një faqe të tërë, si një platformë për dyqanet online dhe madje si një mënyrë për të gjeneruar faqe statike (të çmendur, por ne e kemi parë këtë gjatë viteve)

Ai thekson se sa i adaptueshëm është CMS dhe ne pajtohemi me këtë deklaratë, por problemi me të qenit kaq fleksibël është se bëhet e vështirë të shkëlqesh në çdo rol të vetëm. Një mënyrë për ta kuptuar këtë është të shikosh përmes thjerrëzave të shtojcave: mijëra shtojca të disponueshme të WordPress tregojnë se si njerëzit po përpiqen ta detyrojnë WordPress të jetë diçka që thjesht nuk është ose më keq, të bëjë diçka që nuk është në gjendje ta bëjë ose nëse e bën, e bën keq. Për këtë arsye, kur përdorim WordPress dhe e përdorim shpesh dhe me dëshirë, nuk e ngarkojmë kurrë me shtojca që nuk janë rreptësisht të nevojshme. Në atë moment, ne preferojmë t'i bëjmë ato vetë.

Është e qartë se WordPress është krijuar për këtë qasje "të bërë vetë" dhe padyshim që fleksibiliteti ka shumë përparësi, pa dyshim. Por pa përqendrim të fortë në një detyrë të caktuar, CMS lufton shumë për të ofruar një zgjidhje të qartë. Ky fokus në përpjekjen për të qenë gjithçka për të gjithë po shkakton probleme të mëdha. Sidoqoftë, duhet ta theksojmë: WordPress ende funksionon mirë si një platformë për ndërtimin e blogjeve dhe faqeve të internetit jo komplekse dhe faqeve të tregtisë elektronike.

Hacks dhe Cracks: WordPress mund të jetë një derë e hapur

Me pak fjalë, WordPress hakerohet gjatë gjithë kohës dhe është ankesa më e madhe që kemi dëgjuar nga bota e zhvilluesve. Nuk mund të mohohet, CMS është plot me vrima sigurie, nuk mbaron kurrë. Është si një batanije e shkurtër: e rregulloni në njërën anë dhe zbulohet nga ana tjetër. Pjesërisht numri i hakimeve është për shkak të popullaritetit të WordPress, por edhe për shkak të asaj se sa është WordPress me burim të hapur.

Meqenëse çdokush mund të shikojë kodin me burim të hapur të CMS, kjo u lejon hakerëve të gjejnë dobësi në kod. Nuk duam të themi se kodi me burim të hapur është një qasje e keqe, por mendojmë se natyra me burim të hapur të WordPress CMS po kontribuon në çështjet e tij të pafundme të sigurisë.

Analiza tregon se faqet e WordPress përbëjnë më shumë se një të katërtën e internetit. Ekipi i WordPress e di këtë dhe përpiqet të bëjë gjithçka që mundet për t'u siguruar që CMS është i sigurt, por me ciklet e zhvillimit që janë kaq të shpejta sot, mund të jetë e vështirë të sigurohet plotësisht një aplikacion kompleks. Dhe kur përpjekjet e sigurisë dështojnë, miliona faqe interneti mund të jenë në rrezik.

Ne nuk kemi një zgjidhje të qartë për sfidat e sigurisë së WordPress, përveç, natyrisht, "përditësoni shembullin tuaj të WordPress". Edhe atëherë, cikli i lëshimit të WordPress sjell me vete probleme unike dhe të pafundme.

Shumë njerëz thonë se kujdesi për sigurinë e WordPress është i thjeshtë, dhe kjo është e vërtetë në një masë të madhe, por pyetja është pse duhet t'u kërkohet pronarëve të faqeve të bëjnë një listë detyrash për t'u siguruar që WordPress është i sigurt? Pse kjo pjesë e sigurisë e WordPress nuk është jashtë kutisë?

• Është e lehtë për dikë që të ngarkojë një skedar të ekzekutueshëm në WordPress dhe ky opsion duhet të jetë i kufizuar si parazgjedhje. Duhet vetëm një person paksa i zgjuar për të ngarkuar një skedar me kod me qëllim të keq në një skript PHP dhe faqja juaj komprometohet.
• Aktualisht, opsionet mund të konfigurohen në sistemin e skedarëve. Në vend të kësaj, WordPress duhet ta heqë këtë dhe të supozojë se sistemi i skedarëve është "vetëm për lexim". Ndërsa thelbi i WordPress e bën këtë, shtojcat nuk ndjekin këtë model sjelljeje. Nëse hasni një shtojcë që ndryshon skedarin e konfigurimit ndërsa është aktivisht në prodhim, ndaloni përdorimin e tij. Të bësh këtë tregon një sistem skedari të shkruajtur dhe, rrjedhimisht, një mënyrë të thjeshtë për të bërë ndryshime me qëllim të keq. Një zgjidhje është heqja e skedarit wp-config.php nga rrënja e sistemit (WordPress funksionon gjithsesi), por nuk është një garanci totale e sigurisë dhe në çdo rast parandalon funksionimin korrekt të shumë shtojcave të shkruara nga zhvilluesit e pavetëdijshëm.
• Si parazgjedhje, WordPress i lejon përdoruesit të bëjnë sa më shumë përpjekje për hyrje sa të duan. Kjo hap derën për një sulm me forcë brutale ku hakerët vazhdojnë të provojnë fjalëkalime të rastësishme derisa identifikimi të jetë i suksesshëm. WordPress CMS duhet të çaktivizojë përpjekjet e pakufizuara të hyrjes pas instalimit.

Kjo nuk është një listë shteruese, është vetëm disa pika. Natyrisht, një zgjidhje e madhe softuerike, veçanërisht një zgjidhje me burim të hapur, nuk mund të jetë plotësisht e paprekshme ndaj sulmit. Por qëllimi ynë është se zhvilluesit seriozë hezitojnë të përdorin WordPress pikërisht sepse është kaq i prekshëm. Zhvilluesit e aftë do të preferonin të ndërtonin një aplikacion krejt të ri që plotëson në mënyrë elegante nevojat e tyre dhe mund të mbrohet në mënyrë rigoroze – pa u shqetësuar për dobësitë e panjohura të së ardhmes.

Ose, duke shfrytëzuar sa më mirë cilësimet e PLESK dhe duke mos ngarkuar WordPress me shtojca "të pa rekomanduara" ose më keq "falas" ose më keq akoma me shkrim të keq (ju duhet përvojë në këtë fushë për të qenë në gjendje të gjykoni për të) ju mund ta bëni WordPress një platformë të shkëlqyer edhe përsa i përket sigurisë. Por nuk është më një menaxhim “bëje vetë”, duhet një dorë eksperti.

Pluginat si burim problemesh

Një zhvillues i mirë nuk përdor një shtojcë herën e parë që ngec. Në vend të kësaj, zhvilluesit e mirë përpiqen të ndërtojnë një zgjidhje të thjeshtë dhe elegante. Përkundrazi, të mbështetesh gjithmonë në shtojca duke i kërkuar ato në internet ose duke u mbështetur në ato të sugjeruara nga Komuniteti është një mënyrë shumë e gabuar e të menduarit.

Në fund të fundit, një shtojcë e bën të lehtë shtimin e funksioneve specifike në WordPress, gjë që e bën gamën e gjerë të shtojcave të disponueshme për WP një fuqi të CMS – por është gjithashtu një rrezik. Aq sa shtojcat mund t'i bëjnë gjërat më të lehta dhe më të shpejta, shtojcat gjithashtu përfshijnë shumë rreziqe për sa i përket sigurisë dhe në të njëjtën kohë ju detyrojnë të zgjidhni versionin e WP që mund të përdorni dhe në të njëjtën kohë të fryni shembullin tuaj të WordPress përtej çdo mase të qëndrueshme, duke anuluar ose minuar praninë tuaj në internet, shpejtësinë e hapjes së faqes dhe rrjedhimisht aksesueshmërinë dhe rrjedhimisht indeksin e saktë të motorit të kërkimit.

Plugins dhe siguria

Së pari, le të shohim shtojcat e çështjeve të sigurisë që krijojnë. Një raport sugjeron se mbi gjysma e çështjeve të njohura të sigurisë së WordPress rrjedhin nga shtojcat. Zhvilluesit i nënshtrohen çdo praktike të mirë që ndjek një krijues i shtojcave – të cilat mund të mos jenë aq të mira. Prandaj, si zhvillues, duhet të provoni plotësisht një shtojcë përpara se ta përdorni. Në një farë mase ky proces verifikimi mund të heqë kohën që kurseni me shtojcat, kështu që në atë moment ju gjithashtu mund të konsideroni zhvillimin nga e para të veçorisë së nevojshme për të shtuar në sajt.

Kufizimet në versionet WP

Të njohura si "version lidhja", shtojcat mund të kufizojnë versionin e WP CMS që mund të ekzekutoni. Tani, WordPress është shumë agresiv me ciklin e tij të lëshimit, kështu që lëshon rregullisht një përditësim të ri dhe në fakt shpesh ndodh që platforma të lëshojë disa versione të vogla ose arnime në çdo muaj të caktuar. Kjo është e kuptueshme pasi ekipi i WP po ​​rregullon vazhdimisht vektorët e sulmit. Megjithatë, të gjitha këto përditësime kanë një problem: një përditësim i WP mund të prishë një shtojcë, duke bërë që faqja juaj të ndalojë së punuari ose të rrëzohet.

Sigurisht që ju duhet ta mbani të përditësuar CMS-në tuaj, por kufizimet e versionit të vendosura nga shtojcat mund ta bëjnë këtë punë të vështirë. Disa zhvillues të shtojcave janë gjithmonë duke testuar dhe përditësuar shtojcat e tyre, por kjo "botë" e vogël shtojca premium nuk përfaqëson shumicën. Jashtë këtyre shtojcave premium ekziston një rrezik real që një azhurnim i versionit WP mund të prishë fjalë për fjalë faqen.

Plugin fryrje

Le të supozojmë se shumica e zhvilluesve e dinë se është e rëndësishme të ndërtohen projekte të liga që nuk përdorin kod të tepërt. Tani, disa shtojca përputhen me këtë parim, por shumë shtojca janë shumë të fryra sepse këto shtojca përpiqen të zgjidhin çdo problem që mund të ketë një përdorues. Është e zakonshme që një zhvillues të zbulojë se një shtojcë zgjidh një problem ndërsa ofron një zgjidhje për pesëdhjetë probleme të tjera që nuk lidhen me faqen e tij. (Për të mos përmendur temat dhe "ndërtuesit").

Shtojcat ndërpresin rrjedhën tuaj të punës në WordPress

Së fundi, një problem tjetër i zakonshëm që krijojnë shumë shtojca është fakti që një shtojcë mund të pengojë përvojën e përdoruesit në WordPress, kjo varet mjerisht nga efekti shtojcat e fryrjes e WordPress. Për shembull, një shtojcë mund të ndryshojë plotësisht mënyrën se si krijohet dhe shpërndahet një postim në të gjithë sitin.

Kjo rezulton në një problem me të cilin përballen shumë shpesh zhvilluesit e WP, ata mendojnë se duhet të punojnë shumë "rreth" një shtojce, në vend që të përdorin thjesht shtojcën. Në mënyrë të pashmangshme, zhvilluesit marrin përsipër këtë proces të anashkalimit të shtojcave sepse ajo shtojcë mund të duket se po zgjidh një problem procesi (i cili në mënyrë të pashmangshme nuk është aty).

Arkitektura e uebit ka evoluar

Ne kemi përmendur tashmë se WordPress ka qenë rreth e rrotull për mjaft kohë. Kur u ndërtua, zhvilluesit supozuan se një faqe interneti do të përdorte gjithmonë një server të vetëm, së bashku me një sistem skedar të vetëm. Sidoqoftë, zhvilluesit po përdorin gjithnjë e më shumë atë që quhet arkitekturë mikro-server që përdor nyje të shumta. Ata e bëjnë këtë sepse kjo mënyrë e punës është më e shkallëzueshme dhe fleksibël. Por përdorimi i WordPress në një arkitekturë të ndërlikuar mund të krijojë probleme, për shembull, përdorimi pothuajse ekskluziv i FTP për përditësimet WP CMS.

Zhvilluesit modernë padyshim do të mendonin se përditësimi i kodit përmes FTP është thjesht arkaik. Zhvilluesit zakonisht përdorin një rrjedhë pune specifike në mënyrë që problemet e mundshme të ndalohen përpara se kodi të bëhet funksional. Kjo do të thotë që zhvillimi bëhet në nivel lokal, kodi kontrollohet nga versioni dhe ai kod gjithashtu testohet automatikisht – të gjitha përmes një procesi të vazhdueshëm integrimi. Pra, vetëm ngarkimi i kodit të ri në një mjedis që ekzekuton cikle të shkurtra, që do të thotë se ka një probabilitet të lartë që gjërat mund të shkojnë keq.

Më i madh se problemi i korrigjimit është thjesht supozimi se ne jemi duke punuar me një sistem skedari të vetëm në një nyje të vetme. Një grup serverësh me shumë nyje përmirëson si dështimet e harduerit ashtu edhe performancën, kjo është arsyeja pse kjo qasje po miratohet gjithnjë e më shumë. WP ka një pengesë, megjithatë, në atë që instalimi i një azhurnimi teme ose shtojce përmes FTP do të thotë që vetëm një sistem skedari mund të përditësohet në të njëjtën kohë. Pra, me një grup me shumë nyje do të përballeni me kryerjen e këtij përditësimi për çdo nyje.

Zhvilluesit mund ta zgjidhin këtë problem, por ai mbetet një vështirësi që nuk zgjidhet lehtë. Për më tepër, procesi kërkon që sistemi i skedarëve të jetë i shkrueshëm, i cili nga ana tjetër sjell një shqetësim të madh sigurie në bazën e të dhënave, e cila është zemra rrahëse e WordPress.

Të dhënat jetime dhe struktura e të dhënave në përgjithësi

Në fillim, struktura e të dhënave të WordPress është e thjeshtë. Megjithatë, së shpejti del se ka tabela të tepërta në bazën e të dhënave WP. Për shembull, pse duhet të ndahen meta të dhënat në dy tabela: njëra e quajtur "wp_posts" dhe tjetra e quajtur "wp_postmeta"? A nuk është më mirë të përfshihen të gjitha të dhënat në një tabelë? E njëjta gjë vlen edhe për tabelën e komenteve, e cila ka një tabelë të dytë të lidhur me të për metadatat e saj.

Rezultati është se ka mbetur të dhëna shtesë në të gjithë bazën e të dhënave. Po, WP përfshin disa veçori që ndihmojnë në zvogëlimin e efektit të të dhënave jetime, por funksionet dështojnë kur ju duhet të manipuloni një numër rreshtash me mijëra rreshta. Në thelb veçoritë e WordPress shkaktojnë ndërprerje kohore të serverit dhe çojnë në rrjedhje të kujtesës dhe thjesht nuk janë efektive.

Sigurisht, ju mund të zgjidhni thjesht të reduktoni të dhënat jetime duke shkruar drejtpërdrejt pyetje SQL për ta bërë këtë. Por ju duhet të kuptoni plotësisht se si lidhen tabelat në mënyrë që të mund të shkruani pyetjet e sakta SQL. Shkalla e ndarjes së të dhënave në bazën e të dhënave WordPress thjesht rezulton të jetë e tepërt.

Çfarë bën Plesk Toolkit për WordPress për t'i përmirësuar gjërat

Plesk's WordPress Toolkit është një mënyrë e thjeshtë për të konfiguruar dhe personalizuar një shembull të WordPress, të gjitha nga një panel i vetëm kontrolli. Mund ta përdorni për sa kohë që është i instaluar në faqen tuaj të internetit. Këtu janë disa fusha ku Paketa e veglave të WordPress ndihmon për t'u kujdesur për WP:

Menaxhimi i sigurisë

Me paketën e veglave, ju mund të mbyllni automatikisht vrimat më të dukshme të sigurisë. Për shembull, mund të ktheni përsëri ping XML në RPC, sigurohuni që dosja "wp-content" të jetë e sigurt dhe shumë më tepër. Paketa e veglave shfaq statusin e sigurisë së faqes tuaj dhe shënon problemet me "rrezik" ose "paralajmërim" që është një rekomandim për të përmirësuar sigurinë.

Përditësimi i shembullit WP

I disponueshëm si veçori shtesë në Toolkit 3.x dhe më vonë, veçoria Smart Updates ju lejon të mbani në punë një faqe prodhimi dhe ta përditësoni atë në të njëjtën kohë, pa rrezikun e prishjes së sajtit. Mjeti kontrollon për probleme që mund të ndodhin për shkak të përditësimit dhe do t'ju tregojë nëse ekziston një rrezik i një lloji.

Klonimi

Ka shumë arsye pse mund të dëshironi të bëni një kopje të faqes suaj të WordPress. Për shembull, mund të keni një sajt skenik ku mund të testoni ndryshimet përpara se të dilni drejtpërdrejt. Pasi të jeni gati, dëshironi të kopjoni përmbajtjen e faqes.

Ose, mund të keni një sajt publik dhe mund të dëshironi të bëni një kopje të tij në të cilën nuk dëshironi që publiku të ketë akses. Një shembull tjetër janë zhvilluesit profesionistë të cilët kanë një kopje model të një instalimi të WordPress dhe thjesht duan ta klonojnë atë, duke përfshirë temat dhe shtojcat, automatikisht.

Ne kemi gjithashtu klientë që thjesht duan të bëjnë disa kopje të një sajti për arsye të ndryshme, si për të demonstruar se si një sajt mund të duket ndryshe me disa ndryshime.

Cilado qoftë arsyeja juaj, mjeti i klonimit në WordPress Toolkit e bën të lehtë kopjimin e gjithçkaje, duke përfshirë skedarët e faqes, bazën e të dhënave të faqes dhe të gjitha cilësimet e WP CMS.

Sikronizazhoni

Për arsye të ndryshme, mund të dëshironi të siguroheni që dy uebfaqe të WordPress përputhen. WP Toolkit ju lejon të sinkronizoni automatikisht bazën e të dhënave WP dhe të gjithë skedarët WP.

Nëse keni një kopje skenike të sajtit tuaj, ndërsa kopja juaj publike po ekzekutohet diku tjetër, mund të dëshironi të sinkronizoni sajtet sepse dëshironi të kopjoni ndryshimet që keni bërë në sitin e skenës në sajtin e drejtpërdrejtë të WP.

Në mënyrë të ngjashme, mund të dëshironi të kopjoni disa të dhëna nga faqja e prodhimit në shembullin tuaj të skenës, në mënyrë që të mund të kontrolloni nëse ndryshimet e bëra në versionin e skenës luajnë mirë me të dhënat e drejtpërdrejta. Ose, ndryshimet që keni bërë në faqen tuaj të vendosjes shkaktuan një ndryshim në tabelat tuaja të bazës së të dhënave, në këtë rast paketa e veglave ju lejon t'i sinkronizoni këto ndryshime me bazën tuaj të të dhënave vetëm nëse dëshironi.

Një rast tjetër përdorimi për veçorinë e Sinkronizimit të WP Toolkit është kur një zhvillues ka përditësuar një sajt skenik në një version me pakicë të WordPress dhe dëshiron të pasqyrojë ndryshimet në një sajt të drejtpërdrejtë.

Ju keni mundësinë të sinkronizoni të gjithë WP CMS, ose vetëm disa pjesë të tij. Pra, mund të pasqyroni skedarët e WP-së tuaj, bazën e të dhënave të tij ose të dyja. Ofrohet një hollësi e mëtejshme në atë që ju mund të zgjidhni midis sinkronizimit të të gjithë bazës së të dhënave ose thjesht tabelave, apo edhe tabelave që janë në burim, por jo të pranishme në destinacion. Është gjithashtu e mundur të pasqyrohen tabela individuale.

Gjuetia e insekteve në WP

Plesk WordPress Toolkit gjithashtu lejon zhvilluesit të zbulojnë dhe rregullojnë automatikisht gabimet në burimin e faqes së internetit duke aktivizuar modalitetin e korrigjimit të tij.

konkluzioni.

Pas gjithë sa më sipër, është e qartë se bëhet jashtëzakonisht e rëndësishme të zgjidhni jo vetëm zhvilluesin me të cilin do të punoni ose agjencinë që mund t'ju ndjekë, por mbi të gjitha hostin në të cilin do të presë faqen tuaj në WordPress. Edhe nga këto gjëra kuptojmë se çfarë do të thotë të kesh një faqe të errët në një hosting profesional ose jo.

WordPress nuk është një "objekt" i lehtë për t'u trajtuar. Sigurisht, ndihesh i lirë, mendon se nuk ke nevojë për një zhvillues ose të mos jesh i lidhur me një agjenci, mendon se është e mrekullueshme të mund ta bësh vetë, por në realitet, e vërteta thotë të kundërtën dhe sot siguria nuk është më një çështje dytësore, por parësore edhe për shkak të detyrimeve dhe përgjegjësive ndaj palëve të treta.