Не забруднюйте таблицю параметрів WordPress

Я прихильник коротких циклів випуску. Залежно від проекту тривалість циклу буде різною, але для багатьох типів проектів, над якими я працюю, я прагну мати двотижневі цикли випуску.

Крім того, бувають моменти, коли я працюю над проектом для когось, де змінні середовища необхідні, щоб код знав, чи працює він у розробці, на етапі чи на виробництві.

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

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

Таблиця параметрів WordPress

Я хочу бути ясним: я не думаю, що таблиця параметрів повинна служити звалищем для налаштувань, коли вам більше нікуди розмістити інформацію. І це суть усієї цієї публікації.

Замість цього ви можете використовувати:

• конфігураційний файл,
• дані сесії (за необхідності),
• спеціальна таблиця бази даних,
• або щось інше.

Тож чому ми бачимо, що це відбувається так часто? Справа не в тому, що немає випадків, коли це має сенс використовувати. Я просто думаю, що ми цим зловживаємо. Але є причини чому.

Кодекс WordPress визначає такі параметри:

Параметри — це фрагменти даних, які WordPress використовує для зберігання різноманітних параметрів і параметрів конфігурації.

З таким визначенням легко зрозуміти, чому так багато хто буде використовувати його як місце для зберігання всього, що більше ніде не підходить.

Натомість я вважаю важливим поставити запитання:

Для якого типу сховища [ці дані] є найбільш актуальними?

Тобто, якщо це пов’язано з публікаціями, то чому б не зберегти її в метатаблиці публікацій? Те саме для метаданих термінів, коментарів чи будь-чого іншого.

Суть ось у чому:

Знайдіть найбільш логічне місце для зберігання даних і розмістіть їх там.

Іншими словами, не додавайте дані до таблиці параметрів WordPress, оскільки вони більше ніде не підходять. Це забруднює його. Натомість знайдіть – або створіть – найбільш логічне місце для нього. Ймовірно, це є доказом запаху коду та буде вагомою причиною переоцінити архітектуру вашого коду та спосіб представлення інформації.

Але як це може виглядати? Тобто, як ми можемо взяти певний фрагмент коду та змінити спосіб його представлення в базі даних.

На жаль, важко дати чітке рішення цього питання, коли існує так багато варіантів реалізації проблеми. Тож, можливо, доречна проста вказівка:

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

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