Не загрязняйте таблицу параметров WordPress

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

Кроме того, бывают случаи, когда я работаю над проектом для кого-то, где необходимы переменные среды, чтобы код знал, выполняется ли он в разработке, на стадии подготовки или в производстве.

И это может быть достигнуто по-разному в зависимости от потребностей проекта. Иногда будет работать файл конфигурации, иногда могут работать переменные строки запроса, а иногда я думаю, что разумно сохранить настройку в базе данных.

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

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

Я хочу внести ясность: я не думаю, что таблица параметров должна служить свалкой для настроек, когда вам больше некуда поместить информацию. И в этом суть всего поста.

Вместо этого вы можете использовать:

• файл конфигурации,
• данные сеанса (при необходимости),
• пользовательская таблица базы данных,
• или что-то другое.

Так почему же мы видим, что это происходит так часто? Дело не в том, что нет времени, когда имеет смысл его использовать. Я просто думаю, что мы злоупотребляем этим. Но тому есть причины.

Кодекс WordPress определяет такие параметры:

Параметры — это фрагменты данных, которые WordPress использует для хранения различных настроек и настроек конфигурации.

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

Вместо этого я считаю важным задать вопрос:

К какому типу хранилища наиболее подходят [эти данные]?

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

Дело вот в чем:

Найдите наиболее логичное место для хранения данных и разместите их там.

Другими словами, не забрасывайте данные в таблицу опций WordPress, потому что они больше нигде не подходят. Это загрязняет его. Вместо этого найдите — или создайте — наиболее логичное место для него. Вероятно, это свидетельствует о запахе кода и может послужить хорошей причиной для переоценки архитектуры вашего кода и способа представления информации.

Но как это может выглядеть? То есть, как бы мы взяли данный фрагмент кода и изменили его представление в базе данных.

К сожалению, трудно дать предписывающее решение этого вопроса, когда существует так много вариантов реализации проблемы. Так что, возможно, уместно простое руководство:

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

Я уверен, что есть и другие направляющие факторы, но лучше начать с этого, чем просто засорять таблицу параметров WordPress.