Критичні моменти 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 дозволяє користувачам робити скільки завгодно спроб входу. Це відкриває двері для атаки грубої сили, коли хакери намагаються ввести випадкові паролі, доки вхід не буде успішним. CMS WordPress має вимкнути необмежену кількість спроб входу після встановлення.

Це не вичерпний список, це лише кілька пунктів. Очевидно, що велике програмне забезпечення, особливо рішення з відкритим кодом, не може бути повністю невразливим до атак. Але ми вважаємо, що серйозні розробники не бажають використовувати WordPress саме тому, що він дуже вразливий. Кваліфіковані розробники віддадуть перевагу створенню абсолютно нової програми, яка елегантно відповідає їхнім потребам і може бути надійно захищена, не турбуючись про невідомі майбутні вразливості.

Або, найкращим чином використавши налаштування PLESK і не завантажуючи WordPress із «не рекомендованими» або, що ще гірше, «безкоштовними», чи ще гіршими, але погано написаними плагінами (вам потрібен досвід у цій галузі, щоб мати можливість робити висновки про це), ви все одно можете зробити WordPress чудовою платформою також з точки зору безпеки. Але це вже не управління «зроби сам», потрібна рука фахівця.

Плагіни як джерело проблем

Хороший розробник не вдається до плагіна в перший раз, коли він застряг. Натомість хороші розробники намагаються створити просте та елегантне рішення. Навпаки, завжди покладатися на плагіни, шукаючи їх в Інтернеті або покладаючись на ті, які пропонує Спільнота, є дуже неправильним способом мислення.

Зрештою, плагін дозволяє легко додавати певні функції до WordPress, що робить широкий спектр плагінів, доступних для WP, сильною стороною CMS, але це також ризик. Наскільки плагіни можуть зробити роботу легшою та швидшою, плагіни також створюють багато ризиків для безпеки, і в той же час вони змушують вас вибирати, яку версію WP ви можете використовувати, і в той же час вони роздувають ваш екземпляр WordPress до неймовірного. Вимірюйте швидкість відкриття сайту, а отже, доступність і, як наслідок, правильну індексацію в пошукових системах.

Плагіни та безпека

Спочатку розглянемо проблеми безпеки, які створюють плагіни. В одному звіті стверджується, що більше половини відомих проблем безпеки WordPress виникають через плагіни. Розробники підпорядковуються будь-яким хорошим практикам, яких дотримується розробник плагінів, але це може бути не дуже добре. Тому, як розробник, ви повинні ретельно протестувати плагін перед його використанням. Певною мірою цей процес перевірки може зменшити час, який ви економите за допомогою плагінів, тому на цьому етапі ви також можете розглянути можливість розробки з нуля необхідної функції для додавання на сайт.

Обмеження версій WP

Плагіни, відомі як «обмеження версії», можуть обмежувати, яку версію WP CMS можна запускати. Тепер WordPress дуже агресивний щодо свого циклу випусків, тому він регулярно випускає нові оновлення, і насправді часто трапляється, що платформа випускає кілька невеликих версій або патчів протягом місяця. Це зрозуміло, оскільки команда WP постійно виправляє вектори атак. Однак у всіх цих оновленнях є проблема: оновлення WP може порушити роботу плагіна, через що ваш сайт перестане працювати або завершить роботу.

Звичайно, вам потрібно підтримувати свою CMS в актуальному стані, але обмеження версії, накладені плагінами, можуть ускладнити цю роботу. Деякі розробники плагінів постійно тестують і оновлюють свої плагіни, але цей маленький «світ». преміум плагіни воно не представляє більшість. За межами цих преміум-плагінів існує реальний ризик того, що оновлення версії WP може буквально зламати сайт.

Роздуття плагіна

Припустімо, що більшість розробників знають, що важливо створювати економічні проекти, які не використовують надлишок коду. Тепер деякі плагіни відповідають цьому принципу, але багато плагінів дуже роздуті, оскільки ці плагіни намагаються вирішити будь-яку проблему, яка може виникнути у користувача. Зазвичай розробник виявляє, що плагін вирішує одну проблему, водночас пропонуючи рішення п’ятдесяти інших проблем, не пов’язаних із його сайтом. (Не кажучи вже про теми та «будівельники»).

Плагіни переривають робочий процес WordPress

Нарешті, ще одна поширена проблема, яку створюють багато плагінів, полягає в тому, що плагін може перешкоджати взаємодії з користувачем у WordPress, на жаль, це залежить від ефекту плагіни bloat 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 від Plesk — це простий спосіб налаштувати та налаштувати екземпляр WordPress за допомогою однієї панелі керування. Ви можете використовувати його, якщо його встановлено на вашому веб-сайті. Ось кілька областей, де WordPress Toolkit допомагає піклуватися про WP:

Управління безпекою

За допомогою набору інструментів ви можете автоматично закривати найбільш очевидні діри в безпеці. Наприклад, ви можете повернути запит XML на RPC, переконатися, що папка «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 – це непростий «об’єкт» для обробки. Звичайно, ви відчуваєте себе вільним, ви думаєте, що вам не потрібен розробник або не прив’язані до агентства, ви думаєте, що це чудово мати можливість зробити це самостійно, але насправді правда говорить інакше, і сьогодні безпека є темою, яка вже не вторинним, а основним також через зобов’язання та відповідальність перед третіми особами.