Стоит ли выбирать лучший хостинг для WordPress? Часть 1

Данная статья не про недостатки тем оформления, интерфейса панели администрирования, готовых плагинов для WordPress. Со всем этим у WordPress как раз все в порядке. Данная статья про код.

Стоит ли выбирать лучший хостинг для WordPress? Часть 1

Прежде чем выбирать лучший хостинг для WordPress

Итак вы решили найти украинский хостинг для WordPress. Но вначале почитайте это.

Глобальные переменные это классно, не так ли?

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

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

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

WordPress их использует для всего и везде. Например, The Loop. Применяя его, WordPress каждый пост обрабатывает для вывода на текущей страничке. Он может быть очень легко сломан внедрением такого кода:

global $post;
$post = null;

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

Стоит ли выбирать лучший хостинг для WordPress? Часть 1

А пригодился бы разработчикам полноценный слой абстракции БД?

Разумеется, да. В WordPress не применяется концепция моделей и каких-то сущностей. Как насчет ActiveRecord и ORM? Забудьте. Вся работа с БД устроена при помощи отдельных объектов для запросов, типа WP_User_Query и WP_Query. В придачу к ним идет очень много неэффективной логики для полноценной поддержки пагинации, санитайзинга, фильтрации, установки связей.

В довершение ко всему вышеперечисленному, каждый раз, когда выполняется запрос, он изменяет глобальный объект. Серьезно, почему результат запроса к БД вообще должен храниться глобально?

Разработчики также имеют полный доступ к таким функциям, как get_posts () и query_posts (). Вторая не рекомендуется к применению в официальных документах. И обе являются обычными обертками, которые внутри себя вызывают WP_Query.

function query_posts ($query) {
$GLOBALS['wp_query'] = new WP_Query ();
return $GLOBALS['wp_query']->query ($query);
}

Всех данных проблем могло бы не быть, в случае если бы под капотом у вас присутствовал какой-то адекватный слой абстракции БД. WordPress имеет глобальный объект wpdb, который лишь пытается подражать настоящему слою абстракции.

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

Стоит ли выбирать лучший хостинг для WordPress? Часть 1

WP3.8-ERD

Лучший хостинг для WordPress полагается на сущность Post, а также типы данных постов (post types). Здесь хорошо прослеживается наследие WordPress как изначально специального движка исключительно для блогов. По умолчанию у вас есть следующий перечень типов постов:

  • Post — запись в блоге, обычный пост.
  • Page — страничка.
  • Attachment — медиафайл (то есть картинка, загруженная и прикрепленная к посту при помощи кнопки «Добавить медиафайл», в терминологии WordPress это в свою очередь тоже пост).
  • Revision — различные редакции одного поста.
  • Nav_menu_item — определенный элемент меню (выходит, что ссылка в меню также является постом, отлично).

Если вы делаете расширение и вам необходимо объявить свою сущность, к примеру «выполненный проект», то вы регистрируете уже новый тип поста. Подобная возможность появилась лишь с версии 3.0 и называется Custom Post Types.

Все это храниться должно в одной таблице БД и ее название posts. Также у вас есть табличка Postmeta. Несложно догадаться о том, что там следует хранить всю мета информацию, которая относится к постам. Таблица под названием Options предполагает хранение разных настроек WordPress, а также всех установленных расширений. В результате, рано или поздно вы получите раздутые таблицы, сортировка или поиск по которым может стать настоящей проблемой.

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

Создавать для всего этого кастомные типы таксономий и постов это вовсе не решение данной проблемы, это сама проблема.

Маршрутизация при помощи mod_rewrite

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

В мире уже давно изобретены, хорошо известны и широко применяются подобные подходы к маршрутизации как у Symfony. Подавляющее большинство, если даже не все проблемы WordPress с маршрутизацией могли бы решены быть при помощи маршрутизатора, который работает на уровне PHP. Эти «полезные» функции типа is_page (), is_category () и is_single () стали бы просто ненужными, так как маршрутизатор отвечал бы за весь scoping и mapping.


Отзывы о хостинге:

Оставить комментарий



лучшие хостинги