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

Why-Wordpress-Autograph-Media

Вторая часть статьи о том, почему WordPress не панацея.

Why Wordpress Autograph Media Стоит ли выбирать лучший хостинг для Wordpress? Часть 2

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

Файловая архитектура

Релиз CMS WordPress был в 2003 году, более одиннадцати лет назад. Архитектура MVC тогда не была еще широко известна, таким образом WordPress разбит на много отдельных файлов, которые разложены по каким-то папкам, в типичном ключе для разработчика PHP того далеко времени.

Данный подход свое отражение находит в общем устройстве шаблонов оформления, в которых странички с конкретными ролями имеют соответствующие файлы PHP: archive.php, index.php, single.php — вместо использования нормальной маршрутизации.

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

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

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

Что если вы хотите применять CSS, задействовать сборщик, конкатенирующий, минифицирующий и укладывающий весь код CSS куда-то в файл app.css в директории build? Окей, однако от Style.css в корневой папке вам все равно так просто точно не избавиться.

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

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

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

Стандартные класс, либо функция CMS WordPress могут найдены быть в папке Wp-includes в одном из многочисленных файлов, что, разумеется, служит определенной организации кода. По крайней мере они все же попытались.

Пускай архитектура и не сильно хороша, но шаблонизация работает просто отлично

Лучший хостинг для WordPress и шаблонизация? Нет, здесь никаких шаблонизаторов точно не используется. Вы станете возражать, ведь PHP является шаблонизатором сам по себе и вообще задумывался вначале как язык-шаблонизатор. Это так, однако он тут не используется так, как используют обычно шаблонизаторы. Я о том, что здесь нет никаких Layout'ов, автоматического экранирования и переиспользуемых частей (partials).

WordPress существует уже более одиннадцати лет. Smarty больше двенадцати лет. Twig больше четырех лет. Не вижу причины почему нельзя было применять стороннюю библиотеку, либо даже придумать что-нибудь свое. Сам факт того, что в шаблонах нужно использовать все эти get_sidebar (), get_header () и get_footer () — просто жалок.

Механизм filter и action хуков — достаточно удобный и мощный

Давайте не обращать внимания на то, что все данные экшены, фильтры по своей сути — это фактически одно и то же, вот только по-разному называется.

function add_action ($tag, $function_to_add, $priority = 10, $accepted_args = 1) {
return add_filter ($tag, $function_to_add, $priority, $accepted_args);
}

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

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

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

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

Оба данных нюанса часто приводят к кошмару в процессе отладки.

bac wordpress security chain lock Стоит ли выбирать лучший хостинг для Wordpress? Часть 2

Обработка ошибок

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

Что еще смешнее — некоторые опции принимают аргумент, который позволяет выбрать что она станет возвращать при ошибке — WP_Error, либо же False.

Зато у этой CMS есть много классных шаблонов оформления и плагинов!

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

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

С каждым новым расширением вы также увеличиваете шанс следующего развития событий: «Критическая уязвимость в известном плагине FancyBox for CMS WordPress». Плагин с больше 500000 скачиваний.

Любой мог запросто отправить составленный конкретным образом анонимный Post-запрос CMS WordPress'у, как угодно изменяя тем самым опции уязвимого расширения, среди которых есть функция вывода дополнительного содержания. Итак, XSS готов.

Стандарты написания кода

Вместо того, чтобы поддержать PHP мир в применении стандартов PEAR и PSR, создатели CMS WordPress решили написать собственный стандарт, во многом противоположный вышеупомянутым.

Псевдо Cron задачи

Вместо того, чтобы применять полноценный планировщик Cron, для CMS WordPress создали собственный, функционирующий на уровне php. Он сохраняет все ссылки на колбэки в базу данных, а затем с помощью php запускает их при конкретных событиях. Он само собой не работает в фоновом режиме.

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

В итоге можно найти множество заметок, как отключить Wp_cron и затем подключить настоящий.

laptop 593673 640.jpg Стоит ли выбирать лучший хостинг для Wordpress? Часть 2

Нарезка картинок

При загрузке картинок в библиотеку CMS WordPress нарезает его на различные размеры. По умолчанию здесь жестко заданы три размера: миниатюра — 150 х 150, средний размер — 300 х 300, крупный размер — 1024 х 1024.

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

Представьте, что вы установили тему оформления, создатель которой добавил описанный ниже код в файл темы под названием Functions.php, где предлагается описывать дополнительные опции для работы темы, а также устанавливать различные параметры главного ядра CMS WordPress:

add_action ( 'after_setup_theme', 'foo_theme_setup' );
function foo_theme_setup () {
add_image_size ( 'category-thumb', 400, 400, true );
add_image_size ( 'homepage-thumb', 220, 180, true );
}

Загрузите, например, фото foobar.jpg с размером 1600 х 1600. В полной независимости от каких-то ваших желаний и не предоставляя возможности выбора, CMS WordPress создаст в папке wp-uploads такие файлы: foobar.jpg (загруженный вами файл), foobar-150 x 150.jpg, foobar-220 x 180.jpg, foobar-300 x 300.jpg, foobar-1024 x 1024.jpg, а также foobar-400×400.jpg. То есть по шесть файлов на одну загруженную картинку, даже если вы просто собирались вставить на страничку оригинальную картинку и вам не нужна вся прочая нарезка.

Когда вы загрузите еще, к примеру, 300 изображений, то файлов будет уже целых 1800. Большинство из них никогда не будет использоваться, поэтому будет пылиться на вашем винчестере. А если у вас еще установлены специальные плагины, которые добавляют собственные размеры? То сколько же тогда файлов создаваться будет на одну картинку?

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

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


Поделитесь с друзьями



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

apteka mujchine for man ukonkemerovo woditely driver.