WordPress

CMS, якою публікують більшу частину вебу

Що це таке

WordPress — це система керування вмістом із відкритим кодом: програма на PHP, яка зберігає записи, сторінки, медіафайли, користувачів і налаштування сайту в базі даних MySQL або MariaDB і складає з них кожну сторінку, коли її запитують. Назву часто скорочують до WP, і з цих самих літер починаються власні файли й теки системи (wp-config.php, wp-content, wp-admin). WordPress поширюється за ліцензією GPLv2 (або пізнішою), тож завантажити, запустити чи змінити його можна безкоштовно.

Сайт на WordPress складається з трьох шарів. Ядро — це спільний код, який усі завантажують і оновлюють. Тема відповідає за вигляд, а плагіни додають поведінку; саме так їх розмежовує довідник із тем від самого проєкту. І теми, і плагіни звертаються до ядра через хуки (hooks), тобто іменовані місця в коді WordPress, де дозволено виконуватися іншому кодові. Хуки бувають двох видів: дії (actions) і фільтри (filters). Дія спрацьовує в певний момент, наприклад під час збереження запису, і нічого не повертає. Фільтр отримує значення, змінює його й віддає назад. Ось фільтр, що скорочує автоматичні уривки записів зі стандартних 55 слів до 30:

add_filter( 'excerpt_length', function ( $length ) {
    return 30;
} );

Теми з роками змінили форму. Класичні теми використовують шаблонну систему на PHP, що з’явилася у WordPress 1.5 у 2005 році, і досі дуже поширені. Блокові теми — нинішній підхід: їхні шаблони є HTML-файлами, складеними з блоків, які можна редагувати в Site Editor, а кольори, шрифти й відступи зберігаються у файлі theme.json. Гібридні теми — це класичні теми, які перейняли частину блокових можливостей.

Вміст також залишає сайт у форматі JSON через REST API, на якому побудований і сам блоковий редактор. Запит на адресу сайту /wp-json/ повертає мапу всіх маршрутів, які той пропонує. Публічний вміст можна читати без входу, а все приватне потребує автентифікації. Будь-яка програма може отримати три найновіші записи так:

curl -s 'https://example.com/wp-json/wp/v2/posts?per_page=3'

Для роботи проєкт рекомендує PHP 8.3 або новіший, MySQL 8.0 або MariaDB 10.11 чи новіші та HTTPS, бажано на Apache або Nginx. Joomla і Drupal — системи керування вмістом того самого типу, а два інші шляхи, з якими WordPress варто зважувати, — це власний застосунок на фреймворку на кшталт Django і генератор статичних сайтів.

Чому це важливо

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

Ліцензія безкоштовна, а сайт — ні. GPL охоплює саму програму, а wordpress.org дотримується погляду, що плагіни й теми є похідними творами й успадковують ту саму ліцензію. Витрати переходять в інші місця: хостинг, що виконує PHP і тримає базу даних, години на вибір, налаштування й перевірку теми та постійна робота з оновлення ядра, плагінів, тем і версії PHP. Ця остання стаття витрат триває весь час, поки живе сайт, і в кошторисі має бути сказано, хто її несе.

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

Власна розробка пасує даним і робочим процесам, які зовсім не схожі на сторінки й записи, і зазвичай потребує розробника для кожної зміни. У статичній збірці нема чого латати під час показу сторінок, а її редактори зазвичай працюють через файли й крок збирання. WordPress покриває широку середину: досить типовий сайт, яким власники керуватимуть самі і де екрани редагування варті того догляду, якого вони вимагають. Залежність від платформи помірна, бо код поширюється за GPL, вміст лежить у звичайній SQL-базі, а REST API віддає записи, сторінки й таксономії у форматі JSON.

Як це виглядає на практиці

У роботі компанії WordPress — одна відповідь із кількох, обрана свідомо. Розповідь про сотню вебзастосунків охоплює 2003–2014 роки й формулює правило, за яким робився вибір. Коли клієнтові було потрібне щось нестандартне, його будували на HTML/HTML5, CSS/SCSS і Django. Коли клієнтові був потрібен типовіший сайт, яким він міг би опікуватися й сам, WordPress або Joomla доводили справу до кінця швидше й мали більше сенсу.

Розповідь цінує судження більше за інструмент. Частиною роботи було розрізняти ці два випадки: відрадити клієнта від індивідуальної розробки, яка йому не потрібна, і переконати в ній, коли потреба справжня.

Якщо звести це судження до запитань, на які покупець може відповісти ще до того, як просити кошторис, вийде ось що:

  • Чи редагуватимуть сайт щотижня люди без розробника, чи він змінюватиметься кілька разів на рік?
  • Чи вміщується вміст у сторінки, записи, категорії та медіафайли, чи йому потрібні власна модель даних і власні правила?
  • Хто оновлюватиме ядро, плагіни й PHP весь час, поки сайт працює?
  • Чи спиратиметься сайт на кілька доглянутих плагінів, чи на десятки, зшиті докупи, щоб імітувати застосунок?

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

Де виникають проблеми

Звичайне оновлення ламає сайт

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

Власні зміни зникають після оновлення чи редизайну

Правка, що працювала місяцями, зникає того дня, коли оновлюється тема, або функція, на яку покладається бізнес, пропадає, коли сайт отримує новий вигляд. У першому випадку хтось редагував файли чужої теми, і оновлення їх замінило; довідник із тем попереджає, що функція, додана просто у functions.php теми, зникне з наступним її оновленням. У другому випадку критична для сайту поведінка жила в темі й пішла разом із нею. Зміни до чужої теми кладіть у дочірню тему (child theme), а функції — у невеликий власний плагін, що під’єднується до ядра через хуки, щоб тема відповідала лише за вигляд.

Пароль адміністратора перетворюється на код на сервері

Той, хто вкраде пароль одного адміністратора, може перейти від редагування записів до запуску власного PHP, бо панель керування постачається з редактором файлів тем і плагінів. Один рядок у wp-config.php вимикає цей редактор, і це має той самий ефект, що й вилучення в усіх користувачів прав edit_themes, edit_plugins і edit_files:

define( 'DISALLOW_FILE_EDIT', true );

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

Сайт відстає від поточного випуску

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

Що почитати далі

  • WordPress Documentation — посібник проєкту з ведення сайту: від публікації й медіафайлів до встановлення та обслуговування.
  • Requirements — версії PHP, MySQL і MariaDB, які проєкт рекомендує сьогодні.
  • Updating WordPress — фонові оновлення, оновлення одним кліком і вручну, а також резервна копія, яку варто зробити спершу.
  • Hardening WordPress — права на файли, права в базі даних, вимикач редактора файлів і лад із плагінами.
  • Plugin Handbook: Hooks — як дії та фільтри дають кодові змінювати WordPress, не торкаючись ядра.
  • REST API Handbook — маршрути, кінцеві точки й автентифікація API, на якому побудовано блоковий редактор.

Словник