# WordPress ## Що це таке WordPress — це система керування вмістом із відкритим кодом: програма на PHP, яка зберігає записи, сторінки, медіафайли, користувачів і налаштування сайту в базі даних MySQL або MariaDB і складає з них кожну сторінку, коли її запитують. Назву часто скорочують до WP, і з цих самих літер починаються власні файли й теки системи (wp-config.php, wp-content, wp-admin). WordPress поширюється за ліцензією GPLv2 (або пізнішою), тож завантажити, запустити чи змінити його можна безкоштовно. Сайт на WordPress складається з трьох шарів. Ядро — це спільний код, який усі завантажують і оновлюють. Тема відповідає за вигляд, а плагіни додають поведінку; саме так їх розмежовує довідник із тем від самого проєкту. І теми, і плагіни звертаються до ядра через хуки (hooks), тобто іменовані місця в коді WordPress, де дозволено виконуватися іншому кодові. Хуки бувають двох видів: дії (actions) і фільтри (filters). Дія спрацьовує в певний момент, наприклад під час збереження запису, і нічого не повертає. Фільтр отримує значення, змінює його й віддає назад. Ось фільтр, що скорочує автоматичні уривки записів зі стандартних 55 слів до 30: ```php add_filter( 'excerpt_length', function ( $length ) { return 30; } ); ``` Теми з роками змінили форму. Класичні теми використовують шаблонну систему на PHP, що з'явилася у WordPress 1.5 у 2005 році, і досі дуже поширені. Блокові теми — нинішній підхід: їхні шаблони є HTML-файлами, складеними з блоків, які можна редагувати в Site Editor, а кольори, шрифти й відступи зберігаються у файлі theme.json. Гібридні теми — це класичні теми, які перейняли частину блокових можливостей. Вміст також залишає сайт у форматі JSON через REST API, на якому побудований і сам блоковий редактор. Запит на адресу сайту /wp-json/ повертає мапу всіх маршрутів, які той пропонує. Публічний вміст можна читати без входу, а все приватне потребує автентифікації. Будь-яка програма може отримати три найновіші записи так: ```sh 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 — одна відповідь із кількох, обрана свідомо. [Розповідь про сотню вебзастосунків](/uk/portfolio/developed-100-web-applications-using-html-html5-css-51/) охоплює 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: ```php define( 'DISALLOW_FILE_EDIT', true ); ``` Цей рядок закриває один шлях із кількох, і довідник прямо каже, що він не зупинить зловмисника, здатного завантажити шкідливі файли. Поєднуйте його з надійними паролями, двоетапною автентифікацією для кожного адміністратора і якомога меншою кількістю адміністраторських облікових записів. ### Сайт відстає від поточного випуску Панель керування місяцями показує банер про нову версію, а сайт тим часом працює на великому випуску чи версії PHP, що помітно відстали від поточних. Типово фонові оновлення встановлюють дрібні випуски й випуски безпеки, а кожен великий випуск чекає на клік, тож сайт може й далі латати себе сам, поки його основна версія та PHP відстають, аж доки плагін, від якого він залежить, не вимагатиме чогось новішого. Заплануйте великі оновлення в календарі, тоді ж звірте версію PHP зі сторінкою вимог проєкту й перевірте обидва оновлення на копії, перш ніж чіпати робочий сайт. ## Що почитати далі - [WordPress Documentation](https://wordpress.org/documentation/) — посібник проєкту з ведення сайту: від публікації й медіафайлів до встановлення та обслуговування. - [Requirements](https://wordpress.org/about/requirements/) — версії PHP, MySQL і MariaDB, які проєкт рекомендує сьогодні. - [Updating WordPress](https://wordpress.org/documentation/article/updating-wordpress/) — фонові оновлення, оновлення одним кліком і вручну, а також резервна копія, яку варто зробити спершу. - [Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/) — права на файли, права в базі даних, вимикач редактора файлів і лад із плагінами. - [Plugin Handbook: Hooks](https://developer.wordpress.org/plugins/hooks/) — як дії та фільтри дають кодові змінювати WordPress, не торкаючись ядра. - [REST API Handbook](https://developer.wordpress.org/rest-api/) — маршрути, кінцеві точки й автентифікація API, на якому побудовано блоковий редактор.