Критиките на WordPress: Гледната точка на разработчиците

Все повече и повече разработчици в крайна сметка използват CMS като WordPress, въпреки че не харесват платформата.

Опитните разработчици често предпочитат да използват персонализирани решения, особено когато сте разработчик, който е наистина добър в програмирането. С персонализирано решение можете да създадете много елегантни приложения, които работят много добре. Въпреки това разработчиците в крайна сметка използват CMS като WordPress, дори ако силно не харесват платформата.

Тази статия е насочена към тези разработчици и разглежда много от предизвикателствата, срещани при работа с WordPress (WP). Ще обясним какви са тези трудности и ще дадем предложение: помощта на Plesk, който предоставя WP инструментариум, който наистина помага да се вземат предвид някои от основните критични моменти на най-обичаната CMS в света: WordPress.

Защо разработчиците използват WordPress

Не се заблуждавайте, WordPress е най-популярната CMS на пазара по много добри причини. В този раздел описваме защо CMS е толкова популярен дори сред опитни разработчици, които всъщност могат да напишат свой собствен код.

Първо, WordPress е супер лесен за инсталиране. Всичко, от което се нуждаете, е стандартната LAMP/LEMP среда – ​​Linux, Apache/Nginx, PHP и MySQL/MariaDB като СУБД. Ако го имате, можете да започнете да инсталирате WordPress.

Персонализирането е също толкова лесно, тъй като WP CMS идва с огромен набор от добавки, включително теми за персонализиране на външния вид и усещане и плъгини, които добавят функционалност. Също така е възможно да създадете своя собствена тема и опитни разработчици също могат да направят свои собствени добавки, но този процес е по-сложен.

Може би най-голямата причина за популярността на WordPress е, разбира се, фактът, че е достъпен за нетехнически потребители. Веднъж инсталиран WP не изисква опит в кодирането или разбиране на софтуера, за да работи добре, начинаещите потребители могат да публикуват уебсайт и да настроят екземпляр на WordPress веднага след работа.

Какъв точно е проблемът с WordPress?

Е, най-популярната в света CMS има много проблеми, които трябва да бъдат разгледани. Нямаме намерение да вдигаме шум около проблемите с WordPress, но следното е откровена дискусия и се надяваме екипът за разработка зад тази невероятно популярна CMS да приеме следните точки като положителна критика. Ето защо смятаме, че WordPress е разочароващ за разработчиците:

Широко способен, но никога отличен

Първите стъпки с WordPress бяха лесни. WP е роден, за да бъде платформа за тези, които искат да пишат и публикуват блог. CMS се промени напълно през годините и сега не прилича на скромното си начало. Някои хора го използват като основна система за управление на цял сайт, като платформа за онлайн магазини и дори като начин за генериране на статични сайтове (лудост, но сме виждали и това през годините)

Това донякъде подчертава колко адаптивна е CMS и ние сме съгласни с това твърдение, но проблемът с това да бъдеш толкова гъвкав е, че става трудно да превъзхождаш във всяка отделна роля. Един от начините да разберете това е да надникнете през призмата на плъгина: хилядите налични плъгини за WordPress показват как хората се опитват да принудят WordPress да бъде нещо, което просто не е или по-лошо, да прави нещо, което не е в състояние да прави или ако го прави, го прави зле. Поради тази причина, когато използваме WordPress и го използваме често и с желание, никога не го зареждаме с плъгини, които не са строго необходими. В този момент предпочитаме да ги направим сами.

Ясно е, че WordPress е създаден за този „самоизработен“ подход и очевидно гъвкавостта има много предимства, без съмнение. Но без силна концентрация върху конкретна задача, CMS се бори много, за да предложи ясно решение. Този фокус върху опитите да бъдеш всичко за всички причинява огромни проблеми. Все пак трябва да го отбележим: WordPress все още работи добре като платформа за създаване на блогове и несложни уебсайтове и сайтове за електронна търговия.

Хакове и кракове: WordPress може да бъде отворена врата

Накратко, WordPress бива хакван денонощно и това е най-голямото оплакване, което сме чували от света на разработчиците. Не може да се отрече, CMS е пълен с дупки в сигурността, никога не свършва. Това е като късо одеяло: коригирате го от едната страна и то се разкрива от другата. Отчасти броят на хаковете се дължи на популярността на WordPress, но също и на това колко отворен код е WordPress.

Тъй като всеки може да види кода с отворен код на CMS, това позволява на хакерите да намерят слабости в кода. Не искаме да кажем, че кодът с отворен код е лош подход, но смятаме, че природата с отворен код на WordPress CMS допринася за безкрайните проблеми със сигурността.

Анализът показва, че WordPress сайтовете съставляват повече от една четвърт от интернет. Екипът на WordPress знае това и се опитва да направи всичко възможно, за да се увери, че CMS е защитен, но тъй като циклите на разработка са толкова бързи днес, може да е трудно да се защити напълно сложно приложение. И когато усилията за сигурност се провалят, милиони уебсайтове могат да бъдат изложени на риск.

Нямаме очевидно решение за предизвикателствата пред сигурността на WordPress, освен, разбира се, очевидното „актуализиране на вашия екземпляр на WordPress“. Дори тогава цикълът на пускане на WordPress носи със себе си уникални и безкрайни проблеми.

Много хора казват, че грижата за сигурността на WordPress е проста и това е вярно до голяма степен, но въпросът е защо трябва да се изисква от собствениците на сайтове да съставят списък със задачи, за да се уверят, че WordPress е защитен? Защо тази част за сигурността на WordPress не е готова?

• За някой е лесно да качи изпълним файл в WordPress и тази опция трябва да е ограничена по подразбиране. Нужен е само малко умен човек да качи файл със злонамерен код в PHP скрипт и вашият сайт е компрометиран.
• В момента опциите могат да бъдат конфигурирани във файловата система. Вместо това WordPress трябва да премахне това и да направи предположението, че файловата система е „само за четене“. Докато ядрото на WordPress прави това, плъгините не следват този модел на поведение. Ако попаднете на плъгин, който променя конфигурационния си файл, докато е активно в производство, спрете да го използвате. Това показва файлова система с възможност за запис и следователно лесен начин за извършване на злонамерени промени. Едно решение е да премахнете файла wp-config.php от корена на системата (WordPress работи така или иначе), но това не е пълна гаранция за сигурност и във всеки случай предотвратява правилното функциониране на много плъгини, написани от несъзнателни разработчици.
• По подразбиране WordPress позволява на потребителите да правят колкото се може повече опити за влизане. Това отваря вратата за атака с груба сила, при която хакерите продължават да опитват произволни пароли, докато влизането е успешно. WordPress CMS трябва да деактивира неограничените опити за влизане при инсталиране.

Това не е изчерпателен списък, това са само няколко точки. Очевидно голямо софтуерно решение, особено решение с отворен код, не може да бъде напълно неуязвимо за атака. Но нашата гледна точка е, че сериозните разработчици не са склонни да използват WordPress точно защото е толкова уязвим. Опитните разработчици биха предпочели да създадат чисто ново приложение, което елегантно отговаря на техните нужди и може да бъде строго защитено – без да се тревожат за неизвестни бъдещи уязвимости.

Или, като използвате по най-добрия начин настройките на PLESK и не зареждате WordPress с „не се препоръчва“ или още по-лошо „безплатни“ или още по-лошо, все още зле написани плъгини (имате нужда от опит в тази област, за да можете да правите преценки за това), все пак можете да направите WordPress отлична платформа и по отношение на сигурността. Но това вече не е управление "направи си сам", необходима е експертна ръка.

Добавките като източник на проблеми

Добрият разработчик не прибягва до плъгин първия път, когато се затрудни. Вместо това добрите разработчици се опитват да създадат просто и елегантно решение. Напротив, винаги да разчитате на плъгини, като ги търсите в интернет или разчитате на тези, предложени от Общността, е много погрешен начин на мислене.

В крайна сметка плъгинът улеснява добавянето на специфични функции към WordPress, което прави широката гама от плъгини, налични за WP, силна страна на CMS – но това също е риск. Колкото плъгините могат да направят нещата по-лесни и по-бързи, плъгините също така включват много рискове по отношение на сигурността и в същото време те ви принуждават да изберете версията на WP, която можете да използвате, и в същото време раздуват вашия екземпляр на WordPress извън всякаква устойчива мярка, обезсилвайки или подкопавайки вашето онлайн присъствие, скоростта на отваряне на сайта и по този начин достъпността и следователно правилното индексиране в търсачките.

Плъгини и сигурност

Първо, нека разгледаме проблемите със сигурността, които приставките създават. Един доклад предполага, че над половината от известните проблеми със сигурността на WordPress произтичат от плъгини. Разработчиците подлежат на всички добри практики, които създателят на плъгини следва – което може да не е толкова добро. Следователно, като разработчик трябва да тествате щателно плъгин, преди да го използвате. До известна степен този процес на проверка може да премахне времето, което спестявате с добавки, така че в този момент можете също така да обмислите разработването от нулата на необходимата функция, която да добавите към сайта.

Ограничения на WP версиите

Известни като „ограничение на версията“, плъгините могат да ограничат коя версия на WP CMS можете да стартирате. Сега WordPress е много агресивен с цикъла си на пускане, така че редовно пуска нова актуализация и всъщност често се случва платформата да пусне няколко малки версии или корекции през даден месец. Това е разбираемо, тъй като екипът на WP постоянно коригира вектори на атака. И все пак всички тези актуализации имат проблем: актуализация на WP може да счупи плъгин, което да накара сайта ви да спре да работи или да се срине.

Разбира се, трябва да поддържате своята CMS актуална, но ограниченията на версията, наложени от добавките, могат да затруднят тази работа. Някои разработчици на плъгини винаги тестват и актуализират своите плъгини, но този малък "свят" на премиум добавки не представлява мнозинството. Извън тези премиум плъгини съществува реален риск надграждане на WP версия буквално да счупи сайта.

Раздуване на плъгин

Да приемем, че повечето разработчици знаят, че е важно да се изграждат стройни проекти, които не използват излишен код. Сега някои плъгини отговарят на този принцип, но много плъгини са много раздути, защото тези плъгини се опитват да разрешат всеки проблем, който потребителят може да има. Обичайно е разработчикът да установи, че плъгинът решава един проблем, докато предлага решение на петдесет други проблема, които не са свързани с неговия сайт. (Да не говорим за темите и "строителите").

Приставките прекъсват вашия работен процес в WordPress

И накрая, друг често срещан проблем, който много плъгини създават, е фактът, че плъгинът може да попречи на потребителското изживяване в WordPress, това зависи уви от ефекта плъгини за подуване на WordPress. Например, плъгин може напълно да промени начина, по който публикацията се създава и разпространява в целия сайт.

Това води до проблем, с който разработчиците на WP много често се сблъскват, те се чувстват така, сякаш трябва да работят „около“ плъгин твърде много, вместо просто да използват приставката. Неизбежно разработчиците предприемат този процес на заобикаляне на плъгини, защото този плъгин може да изглежда, че решава проблем с процеса (който неизбежно не съществува).

Уеб архитектурата се разви

Вече споменахме, че WordPress съществува от доста време. Когато беше изграден, разработчиците приеха, че уебсайтът винаги ще използва един сървър, заедно с една файлова система. Разработчиците обаче все повече използват това, което се нарича архитектура на микросървър, която използва множество възли. Те правят това, защото този начин на работа е по-разширим и гъвкав. Но използването на WordPress на сложна архитектура може да създаде проблеми, например почти изключителното използване на FTP за актуализации на WP CMS.

Съвременните разработчици очевидно биха помислили, че актуализирането на кода чрез FTP е просто архаично. Разработчиците обикновено използват специфичен работен процес, така че потенциалните проблеми да могат да бъдат спрени, преди кодът да започне да функционира. Това означава, че разработката се извършва локално, кодът се контролира от версии и този код също се тества автоматично – всичко това чрез непрекъснат процес на интеграция. Така че просто зареждане на нов код в среда, която изпълнява кратки цикли, което означава, че има голяма вероятност нещата да се объркат.

По-голям от проблема с корекцията е просто предположението, че работим с една файлова система на един възел. Клъстерът от уеб сървъри с много възли подобрява както хардуерните повреди, така и производителността, поради което този подход все повече се възприема. WP обаче има пречка, тъй като инсталирането на актуализация на тема или плъгин чрез FTP означава, че само една файлова система може да бъде актуализирана наведнъж. Така че с клъстер с множество възли вие сте изправени пред извършването на тази актуализация за всеки възел.

Разработчиците могат да заобиколят този проблем, но той остава трудност, която не се разрешава лесно. Освен това, процесът изисква файловата система да може да се записва, което от своя страна създава сериозна загриженост за сигурността на базата данни, която е туптящото сърце на WordPress.

Осиротели данни и структура на данните като цяло

Първоначално структурата на данните на WordPress е проста. Скоро обаче се оказва, че има излишни таблици в базата данни на WP. Например, защо метаданните трябва да бъдат разделени на две таблици: една, наречена „wp_posts“ и една, наречена „wp_postmeta“? Не е ли по-добре да включите всички данни в една таблица? Същото важи и за таблицата с коментари, която има втора свързана таблица за своите метаданни.

Резултатът е, че в цялата база данни остават допълнителни данни. Да, WP включва някои функции, които помагат за намаляване на ефекта от осиротели данни, но функциите се провалят, когато трябва да манипулирате брой редове от хиляди редове. По принцип функциите на WordPress причиняват изчакване на сървъра и водят до изтичане на памет и просто не са ефективни.

Разбира се, можете да изберете просто да намалите осиротелите данни чрез директно писане на SQL заявки, за да направите това. Но трябва да разберете напълно как са свързани таблиците, за да можете да пишете правилните SQL заявки. Степента на разделяне на данните в базата данни на WordPress просто се оказва излишна.

Какво прави Plesk Toolkit за WordPress, за да подобри нещата

WordPress Toolkit на Plesk е лесен начин за настройка и персонализиране на екземпляр на WordPress, всичко това от един контролен панел. Можете да го използвате, стига да е инсталиран на вашия уебсайт. Ето няколко области, в които WordPress Toolkit помага да се грижим за WP:

Управление на сигурността

С инструментариума можете автоматично да затворите най-очевидните пропуски в сигурността. Например, можете да превключите обратно XML към RPC ping, да се уверите, че папката „wp-content“ е защитена и много повече. Инструментариумът показва състоянието на сигурността на вашия сайт и маркира проблеми с „опасност“ или „предупреждение“, което е препоръка за подобряване на сигурността.

Актуализиране на вашето WP копие

Налична като допълнителна функция в Toolkit 3.x и по-нови, функцията Smart Updates ви позволява да поддържате работещ производствен сайт и да го актуализирате едновременно, без риск от счупване на сайта. Инструментът проверява за проблеми, които могат да възникнат поради актуализацията, и ще ви каже дали има някакъв риск.

Клониране

Има много причини, поради които може да искате да направите копие на вашия WordPress сайт. Например, може да имате етапен сайт, където можете да тествате промените, преди да стартирате на живо. След като сте готови, бихте искали да копирате съдържанието на сайта.

Или може да имате публичен сайт и да искате да направите негово копие, до което не искате обществеността да има достъп. Друг пример са професионални разработчици, които имат моделно копие на инсталация на WordPress и просто искат да го клонират, включително теми и плъгини, автоматично.

Имаме и клиенти, които просто искат да направят няколко копия на сайт по различни причини, като например да демонстрират как един сайт може да изглежда различно с няколко промени.

Каквато и да е причината ви, инструментът за клониране в WordPress Toolkit улеснява копирането на всичко, включително файлове на сайта, база данни на сайта и всички настройки на WP CMS.

Синкронизация

Поради различни причини може да искате да се уверите, че два уебсайта на WordPress съвпадат. WP Toolkit ви позволява автоматично да синхронизирате WP база данни и всички WP файлове.

Ако имате етапно копие на вашия сайт, докато публичното ви копие работи другаде, може да искате да синхронизирате сайтовете, защото искате да копирате промените, които сте направили в етапния сайт, в сайта на WP live.

По същия начин може да искате да копирате някои данни от производствения сайт във вашия етапен екземпляр, за да можете да проверите дали промените, направени в етапната версия, се съчетават добре с живите данни. Или промените, които сте направили във вашия етапен сайт, са причинили промяна в таблиците на вашата база данни, в който случай инструментариумът ви позволява само да синхронизирате тези промени с вашата база данни, ако желаете.

Друг случай на използване на функцията за синхронизиране на WP Toolkit е, когато разработчик е актуализирал етапен сайт до версия на дребно на WordPress и иска да отразява промените на жив сайт.

Имате възможност да синхронизирате цялата WP CMS или само някои части от нея. Така че можете да дублирате файловете на вашия WP, неговата база данни или и двете. Предлага се допълнителна детайлност, тъй като можете да избирате между синхронизиране на цялата база данни или само таблици, или дори таблици, които са в източника, но не присъстват в дестинацията. Възможно е и огледално отразяване на отделни таблици.

Лов на грешки в WP

Plesk WordPress Toolkit също така позволява на разработчиците автоматично да откриват и поправят грешки в източника на уебсайта, като активират неговия режим за отстраняване на грешки.

Заключение.

След всичко казано по-горе става ясно, че става изключително важно да изберете не само програмиста, с който да работите или агенцията, която може да ви следва, но преди всичко хостинга, на който да хоствате вашия сайт в WordPress. Дори от тези неща разбираме какво означава да имаш тъмен сайт на професионален хостинг или не.

WordPress не е лесен за работа „обект“. Разбира се, чувствате се свободни, мислите, че нямате нужда от програмист или да не сте обвързани с агенция, смятате, че е прекрасно да можете да го направите сами, но в действителност истината казва друго и днес сигурността вече не е второстепенен, а основен въпрос също по силата на задълженията и отговорностите към трети страни.