WordPress — не идеальная система, но пользователям это не мешает

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

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

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

Общие принципы

Перед тем, как мы перейдем к конкретным проблемам, давайте сгруппируем их по смыслу. Я считаю, что критика WordPress касается трех сторон.

Большинство проблем связано со следующими областями:

• Проблемы с плагинами/темами
• Субъективные причины
• Пользовательская лень

Плагины и темы

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

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

Реализация стандартизированного механизма разработки плагинов помогла бы добиться высокого качества плагинов в хранилище.

Таким образом, когда я говорю: «Это не вина WordPress, это проблема с кривым плагином», я всегда подразумеваю: «Однако разработчики WordPress могли бы реализовать это лучше». Я считаю, что даже в таких ситуациях вина является совместной.

Субъективные причины

Я думаю, что всегда полезно дискутировать с собой и думать о тех причинах, почему вы можете быть неправыми. Многочисленная критика WordPress обычно напоминает фразу: «Моя Киа медленная».

Во-первых, «медленная» — относительное понятие. Оно ничего не значит, пока вы не определите систему отсчета. Если вы хотели сказать: «Моя Киа медленная, потому что ее максимальная скорость – 140 миль в час», то в таком случае вы просто заблуждаетесь. 140 миль в час – вполне себе достаточная скорость для повседневного использования; даже, я бы сказал, слишком высокая.

Если вы имели в виду: «Моя Киа медленная, когда я нахожусь на гоночной трассе», ваше мнение верно, но, позвольте, какого хрена вы делаете со своей Киа на гоночной трассе?

Если вы полагали: «Моя Киа медленная, потому что максимальная скорость составляет всего 50 миль в час», вы совершенно правы – что-то не так с вашим автомобилем, и вы должны показать его автомеханику.

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

Пользовательская лень

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

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

WordPress – это не панацея от любой болезни. Глупо ждать, что каменщики будут отделывать вашу спальню.

Безопасность и взлом

Эта – проблема номер один, о которой я вижу частые упоминания. Эта проблема попадает в категорию проблем с плагинами/темами, что я и хочу прояснить.

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

Единственная проблема, которая связана с безопасностью WordPress – это пользовательская лень.

Если вы не торопитесь с обновлением WordPress, считая, что это не столь важно, не стоит обвинять WordPress в своей лени.

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

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

Давайте рассмотрим в качестве примера Jetpack.

Вот некоторые причины, которые повлияли бы на меня в пользу выбора данного плагина:

• Он установлен более чем на 1 миллионе сайтов.
• Он разработан компанией Automattic, т.е. код – 100% безопасный и отвечающий стандартам WP.
• Плагин имеет много пятерок, что является хорошим знаком.
• Он обновлялся примерно 10 дней назад (на момент написания записи), и изучение журнала изменений показывает, что он обычно обновляется раз в месяц.
• Средняя оценка 3.9 заставляет задуматься. Она не такая ужасная, но она достаточно низкая, поэтому заставляет прочесть несколько отзывов.
• Стоит также помнить, что любые продукты, выпущенные крупными компаниями (то, что достаточно популярно), получают непропорционально высокое количество необоснованных негативных комментариев. Таким образом, влияющий фактор в оценке 3.9 – то, что плагин является популярным и то, что он выпущен крупной компанией.
• Большинство комментариев с единицами вообще не имеют никакого отношения к Jetpack. «Я потерял все свои данные» — вряд ли это можно назвать истиной. Ведь всегда найдутся пользователи, которые теряют самообладание из-за 500 ошибочных страниц. Это не означает, что не существует вполне понятных опасений, однако самое печальное то, что многие проблемы являются надуманными.
• Я изредка заглядываю в код плагина, чтобы понять, насколько хорошо он структурирован и организован. Это является прекрасным мерилом профессионализма разработчика. Я понимаю, что не все могут проанализировать код, однако если вы можете это сделать – вы легко сможете избавиться от плохих плагинов.

Как всегда, многое зависит от вас самих. Если вы переживаете по поводу безопасности, вы можете установить корректные пароли, никому не передавать их, и т.д. Обратите внимание на такие плагины, как iThemes Security, которые предлагают разные уровни защиты, читайте статьи по поводу защиты WordPress.

Итог: да, безопасность – проблема WordPress. В такой же степени, как и проблема Drupal, Joomla, произвольных сайтов, Facebook, Twitter, Google, вашего онлайн-банкинга, PHP и MySQL, а также вашего настольного компьютера. Безопасность – проблема, касающаяся всего; и WordPress здесь не является исключением.

Ядро WordPress является безопасным, однако вы всегда должны смотреть на используемые вами темы и плагины. Если вы применяете некоторые инструменты для контроля над своим сайтом, вы минимизируете возможности атак вашего ресурса.

Проблемы со скоростью работы сайта

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

Во многом эта проблема подобна моему примеру с Киа. «Медленно» — это субъективное понятие, и вы должны принимать во внимание ваши условия. Насколько крупной, массивной является представленная страница вашего сайта?

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

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

В некоторых случаях вина лежит на разработчиках. Это ненормально, если тема имеет ссылки на 15-20 отдельных JS- и CSS-файлов. Это значительно влияет на время загрузки страниц и может быть решено относительно быстро.

В грамотно написанных темах и плагинах все стили и скрипты сжаты и объединены в один файл. Это позволяет сохранить свободное место и может существенно снизить время загрузки.

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

Было бы неплохо, если бы все эти файлы – полученные от разных продуктов – были бы объединены и минифицированы в самой системе WordPress. Для этого имеются плагины, такие как MinQueue, однако они работают с переменным успехом. Стандартизированный способ создания стилевых таблиц и файлов JS, наряду с внутренней конкатенацией, позволил бы решить некоторые из этих проблем.

Наконец, вы можете самостоятельно ускорить работу сайта при помощи нескольких инструментов. Вы можете использовать Regenerate Thumbnails для регенерации ваших изображений в оптимальных размерах. Вы можете использовать W3 Total Cache для кэширования, что позволит вам значительно ускорить работу сайта.

Вы можете также рассмотреть CDN, как, к примеру, Amazon Cloudfront. Передав ваши изображения в Amazon S3 и используя Cloudfront для их вывода, вы можете заметно ускорить загрузку ваших изображений.

Перенос сайта – огромная проблема

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

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

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

Если вы решили поменять свой URL с “mydomain.com” на “mywebsite.com”, после чего вы сделали поиск и замену этого URL в своей базе данных, ничего работать не будет вследствие сериализации. Вы должны де-сериализировать все сериализированные строки, после чего выполнить поиск и замену, а затем уже сериализировать их снова (это может делать WP-CLI). Все дело в том, что это – лишь одна из вещей, которую вам нужно сделать. Остаются еще и другие.

Можно ли улучшить WordPress в этом контексте? Естественно! Однако это не тот вопрос, на котором должны акцентировать свое внимание ведущие разработчики и участники. Есть много способов импорта/экспорта, однако такой сложный процесс, как перенос сайта на новый сервер и смена URL-адреса, все же должен производить профессионал. Лучший план действий в этом случае – найти опытного разработчика и делегировать ему эту задачу.

Однако вы всегда можете сделать некоторые вещи своими силами, без тщательного и долгого изучения WordPress. Перенос всех ваших изображений с вашего сервера – хорошее начало. Я уже говорил про Amazon S3. Мне нравится передавать туда все картинки. Если вы переносите крупный сайт, его база данных и файлы (все плагины и ваша тема) могут весить всего лишь несколько десятков мегабайт, в то время как медиафайлы могут занимать 20 Гб. Скачивание их и загрузка на новый сервер – достаточно болезненное решение.

Если вы используете произвольные поля, обязательно придерживайтесь одной и той же структуры их именования. Если вы используете CamelCase-регистр заголовков, всегда применяйте его на сайте. Структура вашего сайта станет более предсказуемой для разработчиков.

Клиентам сложно работать с WordPress

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

Однако это не вина WordPress. Обучение вашего клиента – это частично ваша задача. Вы должны знать о потребностях клиента и должны создавать панель администрирования, которая будет этим потребностям отвечать. Можно просто закрыть на все глаза и сказать, что «клиенты глупые»; реальная проблема здесь состоит в том, что веб-разработчик не смог предвидеть их потребности. Однако сделать это очень трудно, и я сам с этим сталкивался.

Можно ли было улучшить WordPress в этом контексте? Ответ – четкое «да».

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

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

Код ядра WordPress запутан

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

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

Позвольте мне немного разъяснить это. Я думаю, мы должны определить, что такое «путаница». Код WordPress непоследователен, но не запутан. На то были свои исторические и практические причины. Код, который зовут «запутанным», способствует практически беспрецедентной устойчивости базовых механизмов.

Система WordPress появилась более 10 лет назад, когда ООП и другие высокоуровневые подходы не были особо распространены в веб-технологиях, таких как PHP. С тех пор WordPress многое взяла у этих прекрасных методологий, однако оставила старые механизмы для обратной совместимости.

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

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

Мог бы код быть лучше? Естественно, но это привело бы к тому, что миллионы сайтов внезапно прекратили бы работать. Фреймворки, такие как Laravel, способны поставлять более стандартизированный код, однако в случае с WordPress приходится думать о миллионах пользователей. Суть в том, что относительно новый код должен придерживаться строгих инструкций, и у нас для этого имеется документация.

Заключение

Этот список можно было бы продолжить. Чтобы разобраться во всех этих вопросах, нужно иметь разные знания и навыки. Практически все проблемы вызваны тремя составляющими: субъективными причинами, плохими методами разработки, а также самой системой WordPress.

Всякий раз, когда вы слышите критику WordPress, старайтесь рассмотреть все ее аспекты, условия, старайтесь думать своей головой, а не просто слушать человека и автоматически верить ему – вне зависимости от того, кто находится перед вами: основатель WordPress, автор данной статьи, ваш веб-хостинг или кто-то другой.