веб-разработчик
0,0
рейтинг
23 февраля 2015 в 17:35

Разработка → Недостатки Wordpress — техническая сторона

Прежде всего, считаю нужным уточнить несколько моментов:

  1. Эта статья не про какие-либо возможные недостатки интерфейса панели администрирования, тем оформления, готовых плагинов для wordpress или что там еще может интересовать типичного веб-мастера? Со всем этим как раз, на мой взгляд, у WordPress всё относительно в порядке. Эта статья про код.
  2. Статья во многом опирается на материалы, мною собранные воедино, вольно переведенные и от себя значительно дополненные. Ссылки представлены в конце статьи.
  3. Популярность — не синоним качества. Не нужно использовать этот довод как доказательство качества технического исполнения. WordPress популярен явно по совершенно иным причинам.


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


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

Так вот, WordPress использует их везде и для всего. К примеру, The Loop или Цикл, если по-русски. Используя его, WordPress обрабатывает каждый пост для вывода на текущей странице. Он может быть с легкостью сломан внедрением следующего кода:

global $post;
$post = null; 

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

А пригодился бы разработчику слой абстракции базы данных?


Определенно да. В WordPress не используется концепция моделей и каких-либо сущностей (ладно, есть WP_Post, но это смешно). Как насчет ORM и ActiveRecord? Забудьте. Вся работа с базой данных устроена с помощью отдельных специальных объектов для запросов, вроде WP_Query и WP_User_Query. В придачу к ним идет безумное количество неэффективной логики для поддержки пагинации, фильтрации, санитайзинга, установки связей и т.д. И в довершение ко всему перечисленному, каждый раз, когда осуществляется запрос, он изменяет глобальный объект (см. предыдущий пункт). Нет, серьезно, почему вообще результат запроса к базе должен храниться глобально?

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

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

Предлагаю также читателю постараться не засмеяться и не заплакать во время ознакомления со следующей иллюстрацией-объяснением работы WP_Query:



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

Другой важный момент — WordPress не подразумевает, что разработчик может захотеть создать произвольные таблицы в БД для своих нужд. По какой-то причине нужно хранить все данные только в заранее предусмотренных таблицах. Далее представлена схема БД WordPress версии 3.8:

WP3.8-ERD

WordPress очень полагается на сущность post и типы этих постов (post types). Тут прослеживается наследие WordPress как изначально движка только для блогов. По умолчанию у нас есть следующий список типов постов:
  • post — запись в блоге, пост
  • page — страница
  • attachment — медиафайл (то есть изображение, загруженное и прикрепленное к посту с помощью кнопки «Добавить медиафайл», в терминологии WP это тоже в свою очередь пост)
  • revision — разные редакции одного и того же поста
  • nav_menu_item — элемент меню (ага, значит ссылка в меню тоже является постом, прекрасно)

Если вы делаете плагин и вам нужно объявить свою собственную сущность, например «выполненный проект», вы регистрируете новый тип поста. Такая возможность появилась с версии 3.0 и именуется custom post types.

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

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

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

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


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

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

Чтобы понять насколько всё печально, предлагаю заглянуть на соответствующую страницу документации.

Как насчет файловой архитектуры?


Первый релиз WordPress состоялся 27 мая 2003го года, более 11 лет назад (представьте себе). Архитектура MVC тогда еще не была широко известна и используема, соответственно  WordPress просто разбит на множество неких отдельных файлов, разложенных по неким директориям, в привычном ключе для PHP разработчика того времени.  Этот подход находит свое отражение в устройстве шаблонов оформления, в которых страницы с определенными ролями имеют соответствующие PHP файлы: index.php, archive.php, single.php, и т.д. — вместо использования толковой маршрутизации (см. пункт выше). Да, это всё наследие с незапамятных времен, но от этого оно не перестает быть проблемой сейчас. Если у вас достаточно свободного времени, то можете ознакомиться с видеозаписью доклада, который иллюстрирует с какими вопросами сегодня приходится сталкиваться профессиональным WordPress разработчикам. Там человек 40 минут рассказывает как он организовал архитектуру тем оформления чтобы она была, скажем так, несколько удобнее. Круто, но почему ему вообще приходится этим заниматься и потом рассказывать об этом на конференции?

А вот еще маленькая и не очень существенная деталь, но заставляющая каждый раз страдать мое чувство прекрасного. Название шаблона оформления и прочая мета информация о нем хранятся в файле style.css, лежащем в корневой директории шаблона. Там же обычно хранятся и стили. Что если мы хотим использовать scss, задействовать сборщик, минифицирующий, конкатенирующий и укладывающий весь css код куда нибудь в файл app.css в папке build? Окей, но от style.css в корневой директории нам всё равно так просто не избавиться. WordPress жестко привязывается к названию шаблона, хранящемся в этом файле. Там может не быть ни единой строчки css, но должна быть строка с названием шаблона. Если этот файл удалить или переимновать — всё сломается.

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

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

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


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

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

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


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

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


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

В WordPress данный механизм хуков используется, как и глобальные переменные, везде и для всего. Вся система построена таким образом, что по мере выполнения кода происходят определенные события, на которые повешены определенные функции. Вы можете сказать, что это классно, ведь разработчик может как угодно переопределить поведение системы, без надобности вносить изменения непосредственно в ядро. Да, любой плагин или тема оформления могут нести в себе хуки, которые изменяют какие-либо данные, переопределяют логику и, вместе с тем, вызывают проблемы в последствии по мере продолжения выполнения кода. Другая особенность состоит в том, что количество аргументов, передаваемых в обработчики событий, по умолчанию обрезается до одного, если явно не указано иное (отсылка к $accepted_args выше в коде). В каком таком случае мне вообще может это понадобиться и я не захочу получить все аргументы?

Оба этих момента иной раз приводят к кошмару во время процесса отладки.

Как насчет обработки ошибок?


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

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

Зато у WordPress куча классных плагинов и шаблонов оформления!


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

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

Ах, да. С каждым новым установленным плагином вы также повышаете шанс вот такого развития событий: "Критическая уязвимость в популярном плагине FancyBox for WordPress". Плагин с более 500 000 скачиваний. Любой мог просто отправить составленный определенным образом анонимный POST запрос WordPress'у, тем самым как угодно изменяя опции уязвимого плагина, среди которых есть опция вывода дополнительного содержания. XSS готов.

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


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

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


Вместо того, чтобы использовать настоящий планировщик cron, для WordPress создали свой собственный, работающий на уровне PHP. Он сохраняет ссылки на колбэки в БД, а затем при помощи PHP запускает их при определенных событиях. Само собой он не работает всё время в фоновом режиме, как можно было бы подумать. Каждый раз когда кто-то заходит на сайт, происходит проверка cron задач и, если пришло время для какой-то из них, то она выполняется. Может на минуту позже, может на несколько часов.

В результате можно найти кучу заметок о том, как отключить wp_cron и подключить настоящий. И еще вот такие: Why WP-Cron sucks. Там уже про негативное влияние WP-Cron на скорость работы высоконагруженных сайтов.

Нарезка изображений


При загрузке изображения в библиотеку медиафайлов WordPress нарезает его на разные размеры. По умолчанию жестко заданы 3 размера: миниатюра (150х150), средний размер (300х300), крупный размер (1024х1024). В панели управления можно изменить ширину и высоту каждого из этих размеров, но не удалить или добавить новый размер. Для добавления размера нужно залезть в код и воспользоваться функцией add_image_size().

Представим, что мы установили тему оформления, разработчик которой добавил следующий код в файл темы functions.php, в котором предлагается описывать дополнительные функции для работы темы и устанавливать параметры ядра 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. Вне зависимости от вашего желания и не предоставляя какой-либо возможности выбора, WordPress создаст в директории wp-uploads следующие файлы: foobar.jpg (оригинальный загруженный файл), foobar-150x150.jpg, foobar-300x300.jpg, foobar-1024x1024.jpg, foobar-400x400.jpg, foobar-220x180.jpg. То есть в нашем случае по 6 файлов на 1 загруженное изображение, даже если вы просто хотели вставить на страницу оригинальное изображение и вам не нужна вся остальная нарезка. Когда мы загрузим еще 300 изображений, файлов будет уже 1800, большая часть которых никогда не будет использована и просто мертвым грузом будет лежать на жестком диске. А если у нас еще установлены плагины, которые тоже добавляют свои размеры? Сколько тогда файлов будет создаваться на 1 изображение?

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

Заключение


Может показаться, что я ненавижу WordPress. Вовсе нет. Я имею дело с этой CMS с 2.* версий, приблизительно с 2009го года, с её помощью за прошедшее время мне довелось сделать не один десяток сайтов, за это я благодарен. Мы активно используем WordPress в студии, где я сейчас работаю и вряд ли сможем в скором времени его заменить на что-то более эффективное, хотя с интересом наблюдаем за развитием October CMS (CMS на базе PHP фреймворка Laravel) и фантазируем о миграции после выхода стабильной версии.

Сайт w3techs приводит следующую статистику на январь 2015го года — WordPress используют 23% сайтов из проанализированных топ 10 миллионов сайтов по рейтингу Alexa. Доля среди других CMS по этой выборке равна 60%. Следом идет Joomla с 7.5%, отрыв огромен. Откуда такая популярность? Почему я в своё время и огромное количество других людей выбрали WordPress? Видимо играет роль большая дружественность интерфейса управления сайтом, простота установки и использования, все эти тысячи готовых плагинов и шаблонов, низкий порог вхождения для того чтобы, простите, наговнокодить что-то своё. Эти качества отвечают всему тому, что так важно типичному веб-мастеру или человеку, которому просто нужен свой блог с фотографиями котиков. Людям, которые и близко не являются инженерами и не хотят ничего слышать про какие-то архитектуры, хуки и т.д.

Не стоит также забывать про сервис wordpress.com, позволяющий быстро создать сайт на основе WordPress, не заботясь о покупке хостинга и самостоятельной установке CMS. Обслуживает более 60 миллионов сайтов. Сервис создан в 2005м году компанией Automattic, которая вносит огромный вклад в развитие WordPress. И, как мне кажется, это напрямую связано с тем, что в новости об очередном грядущем обновлении WordPress указаны такие вещи, как новая тема оформления, улучшения в интерфейсе работы с текстом, удобное выравнивание изображений, новая вкладка «рекомендованные плагины» и прочая мишура. Это то, что нужно целевой аудитории. А в разделе для разработчиков написано, что поправлено куча багов. И никакого намека на глобальное улучшение ситуации. Это можно понять, нельзя так просто взять и всё отрефакторить, да и, опять же, целевой аудитории это не нужно. Поэтому я не верю в какие-либо действительно значимые позитивные изменения в техническом отношении.

В завершение приведу цитату из интервью с Алексеем Бобковым, разработчиком October CMS. Цитату, которая, на мой взгляд, очень точно описывает ситуацию с WordPress:
С какими CMS ты до этого работал и почему решил написать свою CMS?
Приходилось работать с разными CMS. Интерфейс многих CMS выглядит так плохо, что руки опускаются с ними работать. Я не люблю ругать чужие продукты, поэтому не буду перечислять названия, кроме одного. WordPress неплох, но уже видно, что это приложение старой школы. Даже лучшие (популярные) плагины для него это чистейшее спагетти из кода PHP и разных файлов. Чтобы разобраться что к чему и что-то починить требуется уйма времени и каких-то специальных знаний, для получения которых нужно перелопачивать форумы и блоги, в которых люди в основном задают такие же вопросы и не получают внятных ответов.
Хочется иметь что-то простое и гибкое, настоящую платформу для разработки сайтов и приложений, с красивым интерфейсом и продуманным подходом к расширяемости. Нечто такое, что можно описать несколькими страницами документации и чтобы люди, которые будут это использовать, могли тратить время на более приятные вещи, чем решение простых задач сложным способом.

Ссылки по теме:


Александр Храмов @lkart
карма
15,0
рейтинг 0,0
веб-разработчик

Похожие публикации

Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (188)

  • +5
    Странная статья. Нет ни одного продукта без недостатков. Вордпресс в том числе. И многие штуки в нем — просто потому что так исторически сложилось. Никто не говорит, что нельзя сделать лучше. Для всего есть свой инструмент, развернуть быстро простой сайт на шаблонном дизайне, но заплатить качеством кода это одно. Выбрать фреймворк и пилить свой проект с нуля это другое. Разные задачи — разные решения.

    Октобер ЦМС? Пусть ка сначала октобер цмс наберет 60 млн установок. Я думаю, когда она этого статуса достигнет, к ней можно будет насобирать не меньше претензий, чем вы насобирали к вордпрессу.

    Я не то чтобы защищаю WP, я его тоже в работе довольно часто использую и он не идеален, но опять же. Хотите писать свой велосипед — пожалуйста, вас же никто не ограничивает!
    • +7
      Для всего есть свой инструмент, развернуть быстро простой сайт на шаблонном дизайне, но заплатить качеством кода это одно. Выбрать фреймворк и пилить свой проект с нуля это другое. Разные задачи — разные решения.

      По вашему нельзя быстро развернуть простой сайт на шаблонном дизайне, не заплатив качеством кода?

      Пусть ка сначала октобер цмс наберет 60 млн установок.

      Ну прям вообще не аргумент. Сомневаюсь, что October CMS наберет 60 млн установок, и вовсе не от того, что он хуже WordPress.
    • +16
      Нет ни одного продукта без недостатков.
      Но когда смотришь код вордпресса, он только из этих недостатков и состоит. Он просто отвратителен, гораздо хуже того, что пишут современные юниоры.
      Но оказывается, если этот ужас запрятать в красивую раскрученную коробку, этим можно пользоваться. До тех пор, пока не надо лезть внутрь. А надо это делать очень часто, когда встроенного функционала и функционала популярных плагинов не хватает.
      И тут сразу понимаешь, что жизнь — это боль.
      Сам буду использовать этот движок только в случае, если такая гибкая кастомизация точно не понравится. Если понадобится — то не буду трогать это даже самой длинной палкой.
      • +2
        И тут сразу понимаешь, что жизнь — это боль.

        Как раз для wordpress написать плагин — проще простого.
    • +3
      А может это просто реклама?
      • +8
        Скорее антиреклама. В вордпрес куча говна, но его проблематично, а то и невозможно выпилить из-за обратной совместимости у тысяч плагинов. В October CMS просто куча говна, а про BC от проекта на laravel не стоит даже ожидать, не говоря уже о том, что в новой версии уже даже nodejs нужно для работы с ассетами. (Я поклонник laravel, но bc больная тема)

        Статья отлична, нужно перемывать косточки старым проектам, чтобы новые не ступали по тем же граблям, но вот пир новых проектов со старыми граблями был не в тему.
        • –9
          В WordPress все ок, просто немного запутано так, что новичок сразу не поймет, что и как делать. Поэтому столько криков: «какашка», «плохой код!». Думаю дело в том, что люди не разобрались еще. А если прочитать кодекс, то почти все становится ясно. Просто некоторые разделы еще не написаны и не освещены, поэтому нужно читать конкретно код, чтобы узнать, какими хуками нужно пользоваться.
  • 0
    Ждём ответа на эту статью от Wordpress-гуру в следующем выпуске подкаста uWebDesign!
    • +8
      Вам правда интересно услышать аргументы вида:
      На WordPress работает сайт Forbes, он очень нагруженый, следовательно WordPress лучше

      или
      У WordPress 140 миллионов загрузок, это еще без учета хостинг-менеджеров. Значит WordPress лучше

      ?
      • 0
        А forbes.ru работает на Drupal.
        Кто лучше? Их WP или наш Drupal?
        • 0
          Лучше их программисты, администраторы и дизайнеры.
    • +3
      Я не гуру Wordpress, но подозреваю, что перечисленные недостатки одновременно являются и его основными достоинствами.

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

      Глобальный рефакторинг который убьет обратную совместимость одновременно убьет и все эти достоинства — ведь если новая версия Worpress потребует переучивания и переписывания плагинов то вместо миграции на нее пользователи с таким же успехом смогут мигрировать и на другие платформы (либо остаться сидеть на старой версии).

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

      Ситуация абсолютно стандартная для нашей отрасли — точно так же же причины обуславливают популярность Windows например (как минимум до Windows 8). Или PHP как языка.
  • –4
    главный недостаток WP — это нет блек джека и девчат легкого поведения
  • –5
    Пример про global $post; настолько притянут за уши, что дальше даже не стал читать. Как на счет не использовать эту фичу? Поиск багов там где их нет — тот еще бред.
    • +7
      Пример про global $post; настолько притянут за уши, что дальше даже не стал читать ...


      А вот зря вы так думаете. Из моего опыта: в drupal'е похожая «архитектура» основаная на хуках. Так вот был случай — один гавнокодер, в одном из хуков, сделал глобальной перменной $user = null. Долго пришлось дебажить чтобы выяснить в чем дело.
      • –7
        WP это как правило блог. Блог ведет, как правило, один человек, который в состоянии контролировать глобальные переменные. Я не говорю, что это супер-круто их (глобальные переменные) использовать, но я вот не использую же как-то, уверен, что таких большинство. Кому нужно строить на этом движке промышленное решение, которое пилит 1000 человек одновременно (хотя даже в таком случае, я думаю новичку скажут чтобы не использовал такие штуки)?
        • +12
          Хорошо, лично вы с такими проблемами не сталкивались, а по поводу иных моментов вам есть что сказать? Ах, да, вы же не читали, но осуждаете.
        • +1
          Кому нужно строить на этом движке промышленное решение, которое пилит 1000 человек одновременно

          Ну зачем же утрировать?

          уверен, что таких большинство

          Вопрос в том, почему они все еще есть в CMS, которая позицианируется как «самая популярная»?
      • +10
        Можете показать хоть одну цмс, где гавнокодер не сможет сделать что-то такое, после чего «придется долго дебажить, что бы выяснить в чем дело»?
        Нечто вроде define true rand(0,1)? true: false; тоже можно написать, и что?
        Проблема именно у ВП не в global $post, проблема в говнокодерах, которые не следуют гайдлайнам.
        У ВП всего пара глобальных переменных, которые известны любому прогеру который занимается ВП. Там нету «проблемы глобальных переменных» как таковой (как в некоторых цмс, где их сотни и все на них построено), запомнить парочку глобальных и не поганить их — не велика премудрость.
        • –1
          Глобальные переменные и функции — это не проблема, потому что каждая функция, класс и глобальная переменная в плагинах и темах должна иметь уникальный префикс, который никогда не повторяется (название темы или плагина). Проблему решили просто.
        • +2
          Проблема именно у ВП не в global $post, проблема в говнокодерах, которые не следуют гайдлайнам.


          Это как раз проблема WP. Человек, по не знанию, может похерить все глобально. А должно быть локально.
          • 0
            А что в CMS вообще делает человек, который не знает ее азов?
            Этож не какой-нибудь хитровыделанный секрет, это блин азы.
            Вообще это конечно проблема WP, но другая. Никто не лезет писать на ZF не прочтя манов, никто в консоли не напишет rm -rf / не понимая что он делает, никто не будет ставить битрикс не заглянув в инструкцию, заглянув в код magento первая мысль будет — ааа, где же маны… но блин «wp же так легко»©… и среди WP программистов каждый второй даже просто не прочитал кодекс, не то что не изучил, не то что не понял, а даже просто не прочитал.
            • +2
              никто в консоли не напишет rm -rf /

              Ошибайтесь. Если не ошибаюсь, в Ubuntu эта команда даже не выполняется.

              Полностью согласен.
        • +1
          Можете показать хоть одну цмс

          Воу, воу, полегче. От говнопрограммистов никто не защищен, но наличие их среди пользователей других CMS не делает код и архитектуру WP качественной.
          • 0
            Такова жизнь, у всех есть недостатки. Идеала нет, но мы к нему стремимся. Так?
            • +2
              Я о том, что вы съезжаете с темы. От того, что помимо WP есть неидеальные CMS, не делает WP лучше.
              • –7
                WordPress лучше всех!!!
          • +2
            Воу, воу, полегче. От говнопрограммистов никто не защищен, но наличие их среди пользователей других CMS не делает код и архитектуру WP качественной.
            Не делает.
            Но и global $post трагедию в WP не делает. Это недостаток в пределах «погрешностей оценки». Каждый кто имеет дело с WP знает об этом, это описано в мане на первых страницах и потому проблемой как таковой не является.
            Вот работа с БД, например, там сделана весьма неудобно и никаким образом это не устранишь, не обойдешь и не проблема не решается чтением манов.
            Так что БД это проблема. А global $post это нюанс.

            И потом, если уж мы говорим о «недопустимости использования глобальных переменных», то как вообще могло в голову прийти написать global $post и что-то испортить? Это же из серии секрета полишинеля, если все такие правильные и глобальные не используют, тогда использование глобальной никому не помешает, ибо их никто не трогает:)
  • +3
    Нахожусь в стороне от WP, но интересуюсь разными CMS.
    Потому вопрос к знатокам, а что менялось в WP с выходом мажорных версий? Я думал в WP уже всё хорошо с кодом стало.
    • 0
      В WordPress добавили Customizer в версии 3.4, он раньше был плагином. Теперь его улучшают всячески, вот панели появились и объект setting передается в хук при сохранении параметров произвольного типа.
    • +4
      код не меняется (почти), меняется оформление
  • +6
    WP не пытается быть CMS-кой для всего и вся. Кажется таковыми хотели быть Drupal и MODx, но у них это тоже не сильно получается.
    Если вы хотите MVC, роутинг, рулить таблицами в БД, делать высоконагруженные проекты — так используйте фреймворк. Впрочем крутить табличками не используя посты можно — это позволяет неплохой плагин PODS (http://pods.io).
    Хотя некоторые вещи типа нарезки изображений, действительно бесят. Но пока ничего проще для быстрой разработки сайтов я еще не видел.
    • –1
      Но пока ничего проще для быстрой разработки сайтов я еще не видел.

      Как именно WP ускоряет и упрощает разработку сайтов? Все об этом твердят, только как то размыто.
      • +1
        Наверное, за счет крутой админки. Сделать самому систему управления аналогичного уровня для средней студии будет непросто, даже если просто копипастить решения WP
        • –1
          Все современные и популярные CMS имеют не менее крутую админку. Вот Drupal вообще позволяет через админку целые выборки с БД делать, добавляя параллельно к ним различные плюшечки.
          • –2
            Это как раз минус, когда админка позволяет выборки из БД делать. WP имеет удобную админку для пользователя. Которой реально удобно пользоваться (для околоблоговых задач) и это проверенно миллионами пользователей. Проагрммисты часто даже понятия не имеют о многих фичах, за которые обычные пользователи ценят эту админку. Ну и привычность как бонус.
            • 0
              Недостаток функционала — плохо — переизбыток функционала — плохо. Намекаете, что в WP идеальное соотношения функционала в админке?
              • +3
                Намекаю на то, что она удобна для обычных пользователей. Это уже проверенно многократно. Построить аналоничную по удобству систему самостоятельно будет очень сложно. Даже если этим займутся не программисты с sql запросами в админке, а нормальные UX специалисты, у них многие месяцы уйдут только на исследования и тесты.

                Потому студии жуют кактусы при разработке под WP, но показывая клиенту то, как сайт потом управляется, легко окупают все неудобства при разработке.
                • –2
                  но показывая клиенту то, как сайт потом управляется

                  Вы так говорите, как будто админки остальных CMS невозможно использовать.
                  • +2
                    Я говорю о том, что WP это один из лучших вариантов и при этом невероятно популярный, потому многим знаком (как минимум, на уровне пользователя админки). Ради этого терпят неудоства разработки.
                    • –1
                      Получается WP это своего рода PHP, но в области web-движков )
  • –4
    Автору спасибо за статью.
    Выразить свое отношение к гавнокоду и не сорваться на мат — похвально.

    Вообще странно в 2015 году видеть всех этих адептов гавнокода. Неужто люди больше ничего не видели? А если видели, не ужто их не тошнить от гавнокода Wordpress и Drupal.

    • 0
      а что по вашему идеально?
    • +3
      Говнокод это несомненно плохо, но говнограматика тоже не красит.
  • +5
    А еще это занимает 40 мегабайт кода. без плагинов/тем/медиафайлов.
    А теперь считаем: 40 мегабайт кода * 1000 пользователей одного сервера шаред хостинга.
    В рамках современных винтов — копеечный обьём, да.

    Вот я админю небольшой хостинг.
    80% вордпрессов на нём — это первые, вторые и местами третьи версии. без каких либо обновлений, с пиратскими темами, пиратскими плагинами, или пользователи заплатили денег за дизайн, плагины и функционал, который им написали программисты, и обновление WP с большой вероятностью это всё ломает.

    В среднем на сервер — 3-5 аккаунтов в день блокируются или за рассылку спама, или за пролом, или за вебшеллы.
    А объем логов, которые генерируются исключительно ботами, ищущими уязвимости — около полгигабайта/сутки.
    Вот такая статистика.
    По остальным CMS говорить не буду, т.к с ними, к моему удивлению в рамках этого хостинга проблемы — единичные.
    • +2
      Пиратов — заблокировать. Темы на помойку, а WordPress — обновить!
      • 0
        Ну я оператор хостинга, я не знаю у кого что там купленнное, что тыренное.
        Если плагины/темы проламывают — блокирую. А так — не вычислить, просто знаю что на варезах валяются темы и плагины с шеллами.
        А обновлять несколько сот инсталляций чужих вордпрессов — и потом выгребать косяки отломавшихся тем и плагинов — эти никто из хостеров не занимается.
        • 0
          Занимаются, но специализированные wordpress хостинги. Я так понимаю, у них оно как-то централизовано работает.
          • 0
            Расстрою. редко — плагины/темы.
            Да, централизованно, с очень урезанной песочницей под юзера.
            • 0
              Ну да, я думаю, ограничений там поболее, чем у просто хостинга. Обычно плагины из каталога хостера (но все более-менее актуальное присутствует), с темами не в курсе.

              Для сильно кастомного сайта на базе WP не подойдет, но для обычного блога или чего-то собранного из конструктора популярных плагинов это очень хорошее решение.
              • 0
                Я видел совершенно шикарные сайты на WP, по которым не скажешь, что они на WP.
                • 0
                  Что-то не сильно релевантный у вас комментарий вышел;) Я понимаю, что на WP можно сделать внешне конфетку. Но я говорю, что сайт на wordpress, в котором сильно покопались программисты (а не просто собранный из готовых плагинов и тем) далеко не всегда ложится на специализированный WP хостинг.
                  • 0
                    Именно. Часто это очень интересные архитектурные и кодовые особенности, в котором от базовой платформы остается только название
    • 0
      80% вордпрессов на нём — это первые, вторые и местами третьи версии. без каких либо обновлений
      — вот вам и куча проблем с безопасностью. Любая(ну ладно, почти любая) система обновляется, в том числе, в сторону улучшения безопасности. WP тут не исключение на мой взгляд. В этом плане ваши пользователи сами себе злобные гоблины.
      с пиратскими темами, пиратскими плагинами
      — опять же люди сами себе придумали головную боль. Абсолютное большинство таких вещей содержит в себе вредоносный код. Об этом уже столько писали/говорили, а людям все так же плевать.
      пользователи заплатили денег за дизайн, плагины и функционал, который им написали программисты, и обновление WP с большой вероятностью это всё ломает
      — увы, многие программисты(читай — быдлокодеры) не поддерживают какие-либо вещи для совместимости.

      В общем и целом, если быдлокодеры/пользователи WP не думаю головой и ничего не делают, чтобы защищать свой проект — ну упс. При этом не думаю, что ситуация другая относительно прочих CMS. Разве что это не так заметно, т.к. их процент использования меньше.
      • 0
        Ну, говоришь это пользователям, не говоришь — не понимают — за три года в хостингах — проверено. Морочатся с этим хоть как-то только те, кто понимают, что сайт -> клиент -> деньги.
    • +2
      Включите opcache и получите 8Мб памяти на процесс со всеми плагинами.

      + кеширование через memcached и на простеньком VPS сможете выдержать легко несколько десятков тысяч посетителей в сутки.
      • 0
        Повторюсь — у меня несколько сот инсталляций старых вордпрессов и юзеры в 90% чайники, а вмешиваться в работу клиентских сайтов рискуя поломать работающий сайт- этим никто из шаред хостеров не занимается — только по конкретному запросу клиента.
        Да, это мой не первый проект хостинга, с которым связан.
      • 0
        Для себя то я решил открыть новый Wordpress, методом смены его на простую самописную статику, без php в принципе.
  • –7
    На мой взгляд, это незрелая критика. WordPress разрабатывается сотнями добровольцев, это Open Source, нет такого, что вот сейчас мы решили и все переделаем. Кто хочет, тот и переделывает. Хотите улучшить что-то? Флаг вам в руки и welcome на WordPress.org в команду разработчиков ядра, там уже есть один (!) россиянин, круто? Присоединяйтесь)) И никто не будет вам мешать внедрять ваши идеи, напротив, все будут очень рады))
    • 0
      Думаю автор намекает на то, что относительно WP проще взять какой нибудь фреймворк и написать с нуля, или вглядется в другую CMS, чем разбираться с исходниками WPса. Именно потому, что WP недостаточно гибкий и очень популярный, практически невозможно его исправить. Можно конечно пытаться латать дыры, да изменять функционал, но архитектуру менять будет крайне сложно. Прекрасный пример этому, всеми любимый IE, который таки решились похоронить и начать сначала.
      • 0
        Есть проблемы в организации, наличии грамотных людей для дальнейшего создания и обслуживания. Если есть деньги, то можно создать команду программистов, но когда это начнет приносить доход и сможет ли сравниться по популярности с WordPress — это большой вопрос. Программистам, которые работают с WordPress, придется переучиваться на новые API и пожертвовать всем, что они сделали, возможно, за многие годы, а это не очень интересно, согласитесь.

        А WordPress? Он уже есть, настоящий, реальный и он работает!
        • –1
          Ну почему вы все сводите к популярности? Зачем вам популярность? У вас есть CMS, вам удобно и просто разрабатывать на ней и вам это приносит доход, этого не достаточно?

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

          Я пожертвовал PHPStorm от JetBrains в пользу Vim и не жалею. Для меня он удобнее. Так почему вы решили, что программисты не сделают подобный шаг (по отношению к CMS)? *Я говорю о программистах, а не говнокодерах*

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

          Посмотрите в сторону Линуса Торвольдса. Хорошая и простая по сути организация. А грамотные люди они сами придут.
          • 0
            Ну почему вы все сводите к популярности? Зачем вам популярность? У вас есть CMS, вам удобно и просто разрабатывать на ней и вам это приносит доход, этого не достаточно?
            Вы предлагаете одному человеку (каждому?) написать свою CMS и делать на ней сайты?

            Я пожертвовал PHPStorm от JetBrains в пользу Vim и не жалею. Для меня он удобнее. Так почему вы решили, что программисты не сделают подобный шаг (по отношению к CMS)? *Я говорю о программистах, а не говнокодерах*
            WordPress — это хорошо знакомые темы и плагины, которые выполняют задачи. Для новой CMS придется писать все заново. А что, если вы пользовались популярными плагинами, которые писали другие люди? Создавать эти плагины для своей новой CMS? На это уйдут годы…
            • 0
              Вы предлагаете одному человеку (каждому?) написать свою CMS и делать на ней сайты?

              Ничуть. Разве был на это намек? Я предлагаю использовать CMS с хорошей архитектурой, не глядя на то, популярна она или нет. Если такой не найдете, пишите свою, но не пользуйтесь популярным говнокодом.

              WordPress — это хорошо знакомые темы и плагины, которые выполняют задачи. Для новой CMS придется писать все заново. А что, если вы пользовались популярными плагинами, которые писали другие люди? Создавать эти плагины для своей новой CMS? На это уйдут годы…

              Я не подходящий собеседник в этом вопросе (уже полгода переписываю популярные плагины для Vim), но знаю, что можно написать такую CMS, которая сможет работать со сторонними плагинами.
              • 0
                Есть проблемы с этим. Если я напишу CMS, сделаю сайты, а потом умру, то кто будет потом их поддерживать?

                Хорошая архитектура? Для большинства задач у WordPress прекраснейшая архитектура.

                Не нужна популярность? Так ведь популярность CMS обеспечивает людей рабочими местами и пользователями.

                Тому, что тут приводят как хорошая архитектура и новшества в мире программирования через пару лет на смену придут BBP, GSQ и MVP. За модой не угонишься. А WordPress останется и… Он будет работать! И у него будет не 32 тысячи плагинов а 64 тысячи, а возможно и больше.
                • 0
                  Если я напишу CMS, сделаю сайты, а потом умру, то кто будет потом их поддерживать?

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

                  Для большинства задач у WordPress прекраснейшая архитектура.

                  Автор привел в этой статье дыры архитектуры WP. Какая бы задача не была, эти дыры не исчезнут и архитектура не поправится.

                  Так ведь популярность CMS обеспечивает людей рабочими местами и пользователями.

                  Не правда. Людей обеспечивает рабочими местами работодатель, а пользователям вообще параллельно, какой двиг использовался в этом сайте. Популярность создает комьюнити и ускоряет разработку, одновременно делая ее более качественной.

                  За модой не угонишься.

                  Паттерны и архитектурные решения это не мода. Точнее для хороших программистов это не мода.

                  Он будет работать!

                  Мой скрипт в одну строчку на Bash тоже будет работать через пять лет, разве это показатель?

                  И у него будет не 32 тысячи плагинов а 64 тысячи, а возможно и больше.

                  Возможно в мой скрипт на Bash я добавлю еще парочку строчек через пять лет, но это ниочем не говорит.
                  • 0
                    Кардинальная проблема, оданко. Если вы напишите сайт на распространенной CMS и умрете, то не факт что его смогут поддерживать другие
                    Согласитесь, что поддерживать сайт — это несравнимо более простая задача, чем поддерживать всю CMS.
                    Автор привел в этой статье дыры архитектуры WP. Какая бы задача не была, эти дыры не исчезнут и архитектура не поправится.
                    Много неправды (глобальные переменные — это зло, создавать таблицы в бд нельзя, хуки — это плохо и т.д.) Хотя, конечно, доля истины есть (много кода, много функций, много времени исполняется). Но для очень большого количества сайтов это не критично (скорость исполнения ядра).

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

                    Не правда. Людей обеспечивает рабочими местами работодатель
                    WordPress — работодатель.

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

                    Популярность создает комьюнити и ускоряет разработку, одновременно делая ее более качественной.
                    Что сделано, то сделано. Давайте двигаться вперед.

                    Паттерны и архитектурные решения это не мода. Точнее для хороших программистов это не мода.
                    Посмотрите на Египетские пирамиды, а потом на китайские дворцы. И теперь скажите, архитектурные решения — это не мода? Или то, что архитектор стал программистом что-то меняет?

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

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

                      после скачивания просто читайте код и если он вам не нравится, ищите другой плагин.

                      Вы пробовали так делать? Я пробовал, и это нереально.

                      WordPress — работодатель

                      Не правда. Работодатель — это компания, которая предоставляет рабочие места. Сегодня она может пользоваться WP, а завтра начнет клепать сайты на Joomla. Как бы то ни было, при чем тут это? Мне все равно, какую социальную и экономическую пользую приносит CMS, я о качестве кода говорю.

                      Они хотят именно такие сайты

                      Как правило они не знают чего хотят, но если и хотят, то скопировать тему для любого двига совсем не сложно. Лично я никогда не встречался с задачей вида — дайте мне сайт с дизайном от WP. Обычно клиент говорит — дайте мне сайт с таким же дизайном, что и этот, только вот тут должно быть так, а там вот так. В результате все равно придется переписывать дизайн.

                      Если ваш скрипт будет нужным, популярным и востребованным как WordPress, то да

                      Размываете понятия. Мой скрипт нужен мне, он ничуть не популярен, да ему это и не надо, как и быть востребованным, но он будет работать и через пять лет. Это не показатель качества кода, это показатель того, что код не обязан умереть через пару недель. Аналогично и WP не обязан умереть быстро.

                      Вы развиваетесь.

                      К счастью увеличение числа строк кода это не развитие.
                      • –1
                        Вы пробовали так делать? Я пробовал, и это нереально.
                        Иногда я скачиваю плагины для того, чтобы посмотреть код и идеи, с помощью которых реализована та или иная задача, поэтому я читаю код. Скажем, мне нужна некая функция, но я не хочу встраивать сторонний плагин, или это невозможно в принципе, или он меня не устраивает чем-то. Я нахожу это довольно увлекательным.
                        Не правда. Работодатель — это компания, которая предоставляет рабочие места.
                        Есть же огромное количество фрилансеров, для которых работодатель — это человек, использующий или заказывающий сайт на WordPress. Да и прочие области.
                        Сегодня она может пользоваться WP, а завтра начнет клепать сайты на Joomla
                        Маловероятно, ведь придется всех сотрудников заменить на новых, а старые сайты все равно останутся, их нужно поддерживать.
                        Мне все равно, какую социальную и экономическую пользую приносит CMS, я о качестве кода говорю.
                        У WordPress нормальное качество кода. Если у вас есть реальные аргументы, то приведите пример (отрывок кода ядра), который вы считаете плохим, пожалуйста.
                        Как правило они не знают чего хотят, но если и хотят, то скопировать тему для любого двига совсем не сложно.
                        Скопировать не сложно, а сделать такую же, рабочую может быть довольно сложно, это зависит от темы.
                        Лично я никогда не встречался с задачей вида — дайте мне сайт с дизайном от WP. Обычно клиент говорит — дайте мне сайт с таким же дизайном, что и этот, только вот тут должно быть так, а там вот так. В результате все равно придется переписывать дизайн.
                        Это понятно. Возможно, люди, которым нужен сайт именно на WordPress, не обращаются к вам, потому что, чтобы создать такой сайт, не нужен сторонний специалист. WordPress представляет себя как готовое решение создания сайтов для человека, не знакомого с HTML и CSS в первую очередь (видимо, именно это дает популярность). «То есть, создайте свой сайт за 5 минут и бесплатно» — это WordPress. А далее все вытекающее. WordPress — это бесплатная CMS и в первую очередь она нацелена на создание бесплатных, удобных простым пользователям сайтов. Вокруг этого все и крутится.
                        Лично я никогда не встречался с задачей вида — дайте мне сайт с дизайном от WP. Обычно клиент говорит — дайте мне сайт с таким же дизайном, что и этот, только вот тут должно быть так, а там вот так.
                        Это не показатель качества кода
                        Важен не код, а то, что он делает.
                        К счастью увеличение числа строк кода это не развитие..
                        Извините, я думала, вы его улучшали.
                        • +1
                          Иногда я скачиваю плагины для того, чтобы посмотреть код и идеи

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

                          Есть же огромное количество фрилансеров...

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

                          Маловероятно, ведь придется всех сотрудников заменить на новых...

                          Ну если эти сотрудники являются говнопрограммистами, которые более чем одного ЯП/CMS/Фреймворка не знают, то да, придется.

                          Если у вас есть реальные аргументы, то приведите пример

                          В данной статье полно примеров. Если я начну приводить свои, это будет отдельная статья.

                          Скопировать не сложно, а сделать такую же, рабочую может быть довольно сложно, это зависит от темы

                          Аналогично сложно и для WP написать с нуля, но зачем, когда можно скопировать? Сидеть на CMS только потому, что на ней есть некоторая тема — глупо.

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

                          Не спорю, но почему она должна быть богомерзка внутри?

                          Важен не код, а то, что он делает.

                          Исходите из позиции — главное чтоб работало?

                          Извините, я думала, вы его улучшали.

                          К тому и веду. Если бы код WP улучшали, было бы прекрасно.
                          • 0
                            Ну если эти сотрудники являются говнопрограммистами, которые более чем одного ЯП/CMS/Фреймворка не знают, то да, придется.

                            Когда человек делает сайты для всех CMS, не разобравшись по сути ни в одной из них, тогда он и делает все плохо и неправильно во всех проектах, пытается код из Битрикс вставить в WordPress или скопировать дизайн какого-то сайта, что, по-сути, является пиратством. Это нехорошие задачи. Потому столько критики. Все CMS разные и на изучение стандартов каждой из них нужно потратить хорошее время, прежде, чем делать проекты. Создается такое впечатление, что основная задача программистов сегодня — это «натянуть HTML» на какую-нибудь CMS, скопировав дизайн на заказ. А поскольку WordPress не поддается, то люди ищут виновного во вне (перенесение внутренней обиды на внешний источник, довольно распространенный психологический прием современного человека, по типу модели «ругаем правительство за свои неудачи») и вот им тут попадается эта статья и они рады, что нашли его: конечно же! Во всем виноват WordPress и его глобальные переменные.

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

                            Это ваш выбор. Вы поставили скорость выше качества (ваш приоритет).

                            В данной статье полно примеров. Если я начну приводить свои, это будет отдельная статья.

                            Это, в основном, абстрактные рассуждения. Выискивание недостатков ради критики, чтобы представить WordPress в черном свете.

                            Исходите из позиции — главное чтоб работало?

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

                            p.s. Прощу продения, у меня цитирование сломалось:\
                            • 0
                              Когда человек делает сайты для всех CMS, не разобравшись по сути ни в одной из них

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

                              Это ваш выбор. Вы поставили скорость выше качества (ваш приоритет).

                              Это приоритет клиента. Думаете мне не хочется посидеть лишний денек за кодом?

                              Это, в основном, абстрактные рассуждения.

                              Вполне конкретные рассуждения. Вот еще один пример говнокода в WP. Тоже абстракция?

                              см. ваше

                              Не нашел выше моего намека на — главное чтоб работало. Если бы для меня на первом месте был этот аргумент, я бы не писал здесь про качество кода.
                              • 0
                                «А что мешает человеку делать сайты на нескольких CMS разобравшись во всех? Вы так говорите об этом, как будто это что то крайне сложное.»

                                А вы по-пробуйте…

                                «Не нашел выше моего намека на — главное чтоб работало.»
                                см.
                                «Это приоритет клиента. Думаете мне не хочется посидеть лишний денек за кодом?»

                                Перенос ответственности за свои поступки на плечи клиента (клиент хочет, я подчиняюсь. А вы кто? Раб безвольный или человек свободный?)

                                «Вполне конкретные рассуждения. Вот еще один пример говнокода в WP. Тоже абстракция?»

                                Есть такая особенность.
                                • 0
                                  А вы по-пробуйте

                                  Уже попробовал. Получилось.

                                  клиент хочет, я подчиняюсь. А вы кто? Раб безвольный или человек свободный?

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

                                  Есть такая особенность.

                                  Говнокод это не особенность.
                                  • 0
                                    «Уже попробовал. Получилось.»

                                    Расскажите, сколько на это ушло времени и каких результатов вы достигли.

                                    «Отчасти раб клиента»

                                    Опять-таки, это ваш личный выбор.
                                    • 0
                                      Расскажите, сколько на это ушло времени

                                      Сколько живу, столько учусь.

                                      каких результатов вы достигли

                                      Толково пишу на более 5 ЯП, знаю более 10, использовал кучу библиотек, инструментов, фреймворков. Написал свою CMS с блекджеком.

                                      Опять-таки, это ваш личный выбор

                                      Естественно мой, иначе кому я такой принципиальный буду нужен?
                                      • 0
                                        «Толково пишу на более 5 ЯП»

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

                                        «Естественно мой, иначе кому я такой принципиальный буду нужен?»

                                        Это ваши приоритеты. Они определяют конечный результат. Попробуйте придти к врачу и потребовать у него сделать вам операцию за три дня или поставить вас на ноги за три недели. Никто не станет вас калечить и вы можете искать другого, но результат будет соответствующий запросу.
                                        • 0
                                          Вопрос был не о языках программирования, а о CMS

                                          Изучить CMS гораздо проще, чем изучить ЯП, так что мой ответ опережает ваши аргументы относительно сложности.

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

                                          Я написал свою CMS, но не пользую ей, потому вы зря делаете поспешные выводы. Так же я не говорю, что лучше со своей CMS.

                                          Попробуйте придти к врачу и потребовать у него сделать вам операцию за три дня или поставить вас на ноги за три недели

                                          Совершенно разные вещи. Врач не может это сделать, а я могу.
                                          • +1
                                            «Изучить CMS гораздо проще, чем изучить ЯП, так что мой ответ опережает ваши аргументы относительно сложности.»

                                            CMS — это огромная библиотека, например, кодекс имеет больший объем, чем любая, самая подробная, книга по языку программирования. Чтобы понять написанное, как и везде, нужна практика. Так что я с вами не соглашусь.

                                            Ладно, я ухожу из этой темы.

                                            «Совершенно разные вещи. Врач не может это сделать, а я могу.»

                                            Дело в отношении. Нужно уважать себя. удачи!
          • +1
            Здравствуйте, привет вам из 2016 года.
            Какая CMS сегодня, на ваш взгляд, может заменить по удобности и доступности разработки WordPress? И чтобы там не было говнокода и новичок не мог себе в ногу случайно выстрелить?
            Приведите примеры, пожалуйста. Спасибо.
    • 0
      Прошу прощения, их там двое оказалось. Просто я второго совсем уж не видела нигде.
  • +3
    Интересно было бы услышать мнение Константина Ковшенина (kovshenin) или Сергея Бирюкова (flash_usb)
    • 0
      Мы обычно не комментируем к таким записям. Если вам нужны фишечки и няшечки вроде MVC, MVP, ORM и прочие аббревиатуры, методологии и стили жизни, то вряд ли вам подойдет WordPress.
      • –2
        Золотые слова! Было бы еще лучше, если бы вы дополнили их списком того, для чего подходит WP, на том и порешим.
      • +7
        Вы так говорите «фишечки и няшечки вроде MVC, MVP, ORM и прочие аббревиатуры» как будто это что-то плохое и ненужное.
        • +8
          Как правило сайтоделы на WP оправдывают неиспользование ими аббревиатур тем, что они ненужны. В общем не только сайтоделы на WP так поступают, те же пользователи Vim/Emacs или известных ОС.

          P.S. Никого не хочу обидеть, просто замечание.
    • +1
      Недостатки можно найти в любой достаточно зрелой системе.

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

      В каждый релиз входят сотни исправлений и улучшений, заметных пользователям и разработчикам, плотно работающим с системой. Глобального рефакторинга ради самого рефакторинга в обозримом будущем ждать действительно не стоит, здесь автор прав.
  • +6
    Wordpress — это сборище говнокода. Многие благодаря его популярности считают, что так всё на PHP и пишется. Но это кошмар! Не смотрите на код Wordpress! Смотрите на код Symfony2.
    • +2
      Я вот никогда не понимал, но быть может Вы мне подскажите. Почему люди критикуют блоговую платформу, которая не позиционирует себя как средство создания сложного/коммерческого проекта(или может быть позиционирует, но я все пропустил?)? Ребята написали эту CMS, сделали код открытым, получили много плюсов в карму, а их критикуют программисты, которые пытаются извлечь из чужого кода коммерческую выгоду. Хочешь сделать правильно — сделай сам на любом фреймворке или пиши с нуля, так же можешь найди чужое решение, которое будет отлично подходить под твои нужды.
      Зачем есть кактус и плеваться?
      • +2
        Дело в том, что вы понимаете цели, плюсы и минусы некоторого решения, но 95% людей этого не понимают и пилят на WP все подряд, от того и существуют тысячи плагинов. Мы просто хотим, чтобы люди трезво оценивали используемый ими инструмент, а не пилили на нем то, для чего он не преспособлен.
      • +1
        Скажите это заказчикам и тем, кто судит о PHP по Wordpress.
        • 0
          А судят многие. Пришлось даже собственного начальника отправлять смотреть тот же Symfony, чтобы хоть как-то сбить негативное отношение к языку (при том, что он сам ни разу не программист). При этом этот же человек считает правильным поднимать Bitrix для посадочной страницы и переубедить его нельзя.

          Если уж некоторые люди себе вбили нечто-то в голову — переубедить почти нереально.
    • 0
      Приведите доказательства.
      • –1
        Так в статье их предостаточно.
  • +2
    А теперь вопрос — у кого есть такая же развитая админка и такое же количество настроек, как то, что мне даёт WP?
    • 0
      См. пункт 1 в самом начале статьи. Статья не про админку.
      • +4
        Я это прекрасно понял. Суть в том, что никого не волнует код внутри. Всех волнует результат.
        • 0
          Суть в том, что никого не волнует код внутри.

          Суть в том, что результат напрямую зависит от «кода внутри».
        • +1
          Эта статья доказывает, что не всех. Однако, большую часть, согласен. Статью писал как раз для людей, не относящихся к большей части.
    • 0
      Мы тут как бы о качестве кода говорим, а не об админках для «домохозяек».
    • +2
      В WP очень мало настроек в админке, в Drupal их в разы больше.
      • 0
        Насколько я знаю, в Drupal + Views + Panels их куда больше.
        • 0
          Ну я это и имел ввиду.
    • 0
      Количество настроек, говорите! Да там даже нельзя указать 2 мейла в качестве системных для получения уведомлений.
      • 0
        Я скорее говорю о качестве. Вероятно, там не хватает каких-то штук, но овт у меня есть блог на вордпрессе, который работает хорошо и выглядит красиво. А на друпале так не получилось.
  • +4
    В целом, критика вполне объективная, но многие моменты сильно притянуты за уши.

    global $post;

    Да, это боль, но это терпимо. Почему не исправили? Потому, что это работает, а так же, WP очень серьезно относится к обратной совместимости.

    ладно, есть WP_Post, но это смешно

    Вовсе нет, возможностей WP_Post хватает в 99% случаев. Если честно, я даже не помню, когда последний раз использовал wpdb.

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

    Это неправда, создавайте что угодно, никто слова плохого не скажет.

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

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

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

    А как вы предлагаете скрывать index.php из путей? Сама WP пишет в .htaccess только стандартный набор правил, который используется на любом другом сайте с любой другой кмс/фреймворком. Вся маршрутизация проходит внутри самого ВП. А, то, что не многие плагины(кеширующие, например) тоже что-то пишут в .htaccess, чтобы создать возможность для быстрой отдачи контента непосредственно самим веб-вервером — это конечно не приятно, но вполне решаемо.
    Что касается создания новых правил маршрутизации, то там не все так просто, как хотелось бы, но можно сделать все что угодно.

    Шаблонизация в WordPress? Нет, никаких шаблонизаторов не используется.

    Все верно, и снова все дело в том, что так исторически сложилось. Хотите полноценный шаблонизатор — кто вам запрещает? Timber обеспечит вам поддержку Twig, не нравится — к сожалению придется писать самому.

    Механизм action и filter

    Экшены и фильтры это как раз то, почему WP так универсален. Это мощный механизм, который позволит вам сделать практически все что угодно.

    Зато у WordPress куча классных плагинов и шаблонов оформления

    Именно. Многие плагины и многие шаблоны являются просто великолепными. Например, плагин Advanced Custom Fields добавит в WP возможность встраивать свои собственные произвольные интерфейсы. Этот плагин — великолепен и является образчиком в сфере любых плагинов.

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

    И снова, так исторически сложилось. Строго говоря, PSR тоже ругают и ругают много. Но вот в чем все дело — WP-стандарт есть, но вас никто не заставляет ему следовать. Хотите — юзайте PSR.

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

    WP себя позиционирует как CMS, которая будет и должна работать на любом хостинге. Если говорить о настоящем cron, то достаточных прав на внесение изменений может не хватать у самой WP, или такая возможность может отсутствовать в принципе.
    Хотите нативный крон? Да кто запрещает, просто пропишите хоть в /wp_config.php, хоть в functions.php define('DISABLE_WP_CRON', true); , а зтем дергайте /wp-cron.php сколько душе угодно.

    Нарезка изображений

    Все верно, это просто боль.

    И пара слов о классическом мифе «WP и говнокод». Да, раньше, лет 5 назад все было не очень хорошо, но сейчас внутри WP дела обстоят иначе. Я честное слово не понимаю этих выпадов о низком качестве кода в WP. Код WP — максимально прозрачен, все функции хорошо описаны в самом коде. Я достаточно часто читаю код WP и у меня не возникает никаких проблем с его пониманием. Да, все крутые последние фишки PHP там не используются, но лишь по той причине, что у команды WP есть голова на плечах и они понимаю, что десятки миллионов инсталляций — это большая ответственность.

    У WP есть множество преимуществ, есть и недостатки. Но, как уже было сказано в комментариях, WP не позиционирует себя как самая универсальная CMS в мире.
    • +1
      Это неправда, создавайте что угодно, никто слова плохого не скажет.

      Я написал об этом: «Теоретически разработчик может создать свои произвольные таблицы в БД, но WordPress не будет о них ничего знать и не сможет организовать никакого интерфейса для управления данными, хранящимися в такой таблице. Всё, что останется разработчику — это PDO и MySQL запросы.»
      Сама WP пишет в .htaccess только стандартный набор правил

      Что если я в апаче отключил опцию чтения конфигурации из .htaccess из соображений скорости и безопасности? Что если я не пользуюсь апачем вообще?
      плагин Advanced Custom Fields добавит в WP возможность встраивать свои собственные произвольные интерфейсы

      Да, я использую этот плагин. Он делает встроенный в Wordpress функционал custom fields удобным для использования. Бесплатная версия урезана (мне сильно не хватало возможностей), Pro версия стоит 100 австралийских баксов, но окей, это не относится к качеству кода. Суть в том, что существование ACF не убирает описанную в статье проблему с готовыми плагинами и не опровергает ее.

      Насчет «мифа» про говнокод. В статье я привел конкретные аргументы почему это не совсем миф. Часть из этих аргументов вы пропустили, на часть ответили, что это наследие. Согласен, наследие, но от того, что кто-то когда-то принял неудачные решения, через 10 лет эти решения магическим образом не становятся удачными. Я считаю, что на эти решения не нужно закрывать глаза, молчать о них и считать нормальными только от того, что они являются наследием. Также я понимаю, что отрефакторить Wordpress совсем не просто и этим никто заниматься не будет, о чем написал в заключении.
      • +5
        Что если я в апаче отключил опцию чтения конфигурации из .htaccess из соображений скорости и безопасности

        Правило реврайтов WP совершенно стандартное, используется в любом другом фреймворке или cms, которые желают скрыть index.php из адреса. В том же nginx это 3 строки.

        Что касается тех моментов в статье, которые я не комментировал — по большей части я с ними согласен, но считаю великой проблемой.

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

        И пара слов про ACF — да, теперь за фишки Pro версии нужно платить, но $100 — это версия плагина с неограниченным количеством активаций, лицензия на 1 сайт стоит только $25. Если вы занимаетесь разработкой на WP профессионально, то эти $100 вообще не предмет для дискуссии, плагин окупает себя многократно. Если кто-то все же жмется, то может найти Pro версию в сети, разработчик не встраивает никакой защиты в плагин, а в ридми явно написано, что лицензия — GPLv2. Деньги вы платите только за возможность автоматически обновляться.
        • 0
          Маршрутизация это не только скрытие index.php из адреса, хотя может это и самое частое применение в контексте простого сайта на WP.

          Касательно «не путать устаревшую архитектуру и говнокод» — в целом я готов с этим согласиться. Лично я готов характеризовать Wordpress как приложение с устаревшей архитектурой, а не говнокод. =)

          Однажды я нашел Pro версию ACF в сети, как вы пишите. С целью посмотреть что он умеет и нужно ли это мне. Само собой в нем была зашита бяка, он подтягивал с левого адреса произвольное содержимое и встраивал в код отдаваемой страницы. У меня хватило знаний заметить это и найти глубоко закопанный и замаскированный код злоумышленника. Большое количество рядовых пользователей WP о таком развитии событий даже не задумаются. Так что такой вариант никому не рекомендую. Но это так, к слову, это не проблема конкретно Wordpress.
          • 0
            Однажды я нашел Pro версию ACF в сетиЭто же пиратство.

            Я, кстати, пользуюсь функцией add_meta_box

            Мне она очень нравится.
            • 0
              У плагина лицензий GPLv2.
              add_meta_box — это хорошо, но в ACF реализовано очень много функционала, и создавать интерфейсы на нем в разы проще. Например, я не представляю, как бы обходился без его Repeater или Flexibile Content.
      • 0
        Простите, пока еще не читал статью, прочитаю позже. Но
        Я написал об этом: «Теоретически разработчик может создать свои произвольные таблицы в БД, но WordPress не будет о них ничего знать и не сможет организовать никакого интерфейса для управления данными, хранящимися в такой таблице. Всё, что останется разработчику — это PDO и MySQL запросы.»

        С чего бы CMS знать о таблицах, кторые кто то там создал, и что то с ними делать? CMS создала свои таблицы и с ними работает. Если плагин или разработчик создал для своих целей дополнительные таблицы, так пусть он с ними и работает, зачем WordPress-у туда вмешиваться, да и откуда ему знать как данные таблицы взаимосвязаны с другими данными? Добавил таблицу, так уж и добавь обработчики этих данных, если уж так нужно, но это явно не проблемма WordPress
        • 0
          Этот тезис относится не столько к тому, что CMS должна уметь работать с дополнительно созданными разработчиком таблицами, сколько к тому, что разработчик останется только с PDO и MySQL запросами. Слой абстракции БД улучшал бы эту ситуацию, о чем и говорится в статье.
    • 0
      Нарезка изображений

      Все верно, это просто боль.


      core.trac.wordpress.org/ticket/15311

      ждем ждем ждем!)
      • 0
        Есть плагины для удаления ненужных размеров. Все решаемо. Не думайте, что вы приговорены иметь 5 или 10 одинаковых картинок у себя на сервере.
        • –1
          А есть плагины, делающие код WP качественным?
  • +10
    WP не хорош. WP популярен. Когдая вижу _сайт_, построенный на WP, я понимаю, что люди из этого блого-движка, как из конструктора, с установкой десятка-другого плагинов, соорудили себе механизм, на котором можно более-менее безболезненно строить сайт — и построили его. Увы и ух. Под «просто сайт» блого-движок не подходит, так как статические страницы так — суть понятие вторичное, а на первом месте всегда блогопосты. Но, не устаю поражаться, можно интернет магазин построить, и еще много чего сострагать, приняв, что блогопосты — это и есть товары, скажем, в магазине.

    Вот что он небыстр, грубо говоря — это печалька. Но при такой архитектуре он и не может быть быстрым, особенно если все-все сделать через плагины. Зато всем этим хозяйством можно усправлять через веб-морду, и все оно довольно неплохо еще и заработает. Не безопасно (наверное), не быстро (вперед, на DO, у них хранилище быстрое!) — но будет.

    На этом фоне рассуждать про качество кода — глупо. Зато работает, и многим дает заработать на кусок хлеба. Сменить его на один из более адекватных движков можно, но это, увы, близко к старой теме: работа стоит денег, владелец сайта разницы не особо и заметит, так кто будет платить?

    В общем, если хочется выглядеть поумнее — критикуй не хочу! Если можешь сделать чт-то, столь же популярное, что позволит переехать старым сайтам на это новое, и не потерять наработки в сайтах — будешь герой вовеки. А до того…
  • –1
    простота установки

    Как установка может быть простой, когда надо прописывать что-то в файле? Для не разбирающегося человека это шок. Намного удобнее было бы, если был бы установщик в визуальном режиме, как в друпале и джумле.
    • +3
      Wordpress уже очень давно устанавливается с помощью веб-интерфейса, ничего в файлах прописывать не нужно.
  • +1
    Смешинг магазин работает на wordpress. Это озвучивал главный редактор, пару месяцев назад была ссылка на его доклад по фронтенд оптимизации, там кажется он это и говорил (доклад интересный, советую). Да, их версия wordpress с «сильным тюнингом», но она грузится меньше чем за секунду (ну или около того).
    Я работаю с wordpress c версии ~2.3, не из дня в день, но сайты делаю на нем ~ 1 раз в месяц. Со многим соглашусь, но давайте разделять:
    — если необходимо сделать сайт
    — визитку
    — бложик
    — небольшой портальчик компании
    — для благотворительной организации
    — простенький каталог чего либо
    — небольшое новостное издание

    то почему бы не использовать WP? Быстро, удобно (причем для всех), гибко

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

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

    Как пример, горький пример:
    Я дописывал 2-е или 3 недели сайт на чужом, кастомном фреймворке версии php5.3 (выше не было). Тематика: риелторский каталог (пользователи, страничка со списком домиков и фильтром, домики со всякими свойствами вида карта/кол. комнат и т.д. ).
    Я за 3 недели максимум половину реализовал. Уровень знаний был конечно меньше, но это не оправдывает.
    Так вот было принято решение переносить это все в друпал. Я в друпале, можно сказать, балбес.
    Мой коллега сделал весь этот сайт на друпале под ключ за неделю.

    Задача по сути была «как раз под друпал» и его views, это я уже потом понял.
    Мой вывод таков: Выбор мотора должен исходить из спектра решаемых задач.
  • +2
    С точки зрения разработчика — это конечно ужасно. Я сам в прошлом С++ — программист, под капот WordPress'а заглядывал только краем глаза и то что я там увидел мне очень не понравилось. То что рассказал автор статьи — это ужасные для классической разработки вещи.

    Но есть одно но. 60 млн установок. Господа, WordPress явно выполняет то что от него хотят владельцы сайтов. И это говорит о том, что качество кода никак не влияет на успех продукта. Хорошо это или плохо — решать вам.
    • –3
      Господа, WordPress явно выполняет то что от него хотят владельцы сайтов.

      Далеко не факт. У меня нет статистики, но народ может качать и использовать WP по следующим причинам:

      1. Узнали о WP раньше других
      2. Посоветовал друг
      3. Не было другого выбора на хостинге
      4. Ошибочно решил, что другие CMS будут слишком сложны для него
      5. Лживая реклама
      6. Нежелание переучиваться
      7. Лень переучиваться и переходить на другую CMS
      8. Незнание технических тонкостей, от чего проблемы, связанные с безопасностью, скоростью работы и доступностью не учитываются

      Продолжать можно долго. Я к тому, что число установок нисколько не говорит о том, что данное решение «явно выполняет то, что от него хотят владельцы»
      • +2
        Ну хорошо, давайте переформулируем «удовлетворяет базовые потребности владельцев». Если бы не удовлетворял — их бы рано или поздно снесли бы, верно?
        У меня самого пара сайтов на нем крутится — именно потому что уровень входа очень низкий. И да, я конечно с удовольствием рассмотрю другие CMS, если они будут столь же просты и функциональны. А качество кода меня до поры до времени не интересует.
        • –1
          Если бы не удовлетворял — их бы рано или поздно снесли бы, верно?

          Тоже не соглашусь. Как уже писали раньше, есть полно сайтов на устаревших версиях WP, дырявых и кривых, но владельцы их не сносят.
          • 0
            А многие владельцы не думают такими категориями как «дырявый, кривой или безопасный, прямой». Они знают, что сайт им приносит клиентов, например. И выглядит неплохо.
            • 0
              Я веду к тому, что удовлетворять может и плохое решение.
              • +1
                Плохое с какой точки зрения? Технически плохое решение может быть успешным у потребителя, это как раз и доказывает Вордпресс. Я к этом веду :)
                • 0
                  Но почему бы не сделать успешное решение еще и технически хорошим?
                  • 0
                    Конечно, почему бы и нет? Но я боюсь WP уже не переделать. Просто рано или поздно он уйдет с главных ролей.
  • 0
    WP — это движок для блогов. В общем-то, все перечисленные недостатки идут от того, что движок для блогов пытаются использовать для всего на свете.

    Ну есть глобальные переменные, а чем они вам не угодили? Да, глобальные переменные — это зло в парадигме ООП и паттернов MVC. Здесь ничего такого нет, здесь не должно быть никакой сложной логики. Это скрипт, который сделан для того, чтобы отображать блоговые страницы, логика здесь всегда очень простая. Глобальные переменные удобны, когда в потоке всё понятно: скрипт стартовал, сделал выборку постов, пустил по ней Loop, завершил выполнение. Абсолютно все страницы блога работают по одной схеме.

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

    Если хочется серьёзно попрограммировать и обязательно на PHP, берите уй или ларавель, используйте инструменты по назначению.
  • –2
    Видимо автор недавно стал работать с вордпрессом, нашёл десяток говнокодистых моментов и решил написать статью.
    Что будет когда он найдёт там остальные десять тысяч? Каждый раз по статье?
  • 0
    Вспоминается тестирование вп с отключением кеширования, где страницы начинают грузиться минуту. Давненько я читал об этом, всех фактов уже не помню.
  • 0
    Мне кажется на это всё: качество кода, корявые плагины… обращаешь внимание либо при первом знакомстве, либо поддерживая один проект на WP. Если же, идёт постоянная разработка на WP, то все эти огрехи с течением времени скрываются под слоем своего фреймфорка/библиотеки. И тут не важен язык/CMS… Это в любой области так.
    Со временем от проекта к проекту появляются свои абстракции, набор API. Не нравится глобальные переменные? — Спрячьте для себя за каким — нибудь IoC-контейнером, хоть самописным. Generics бы гораздо упростили работу, но что поделать. Также и с сущностями — можно создать базовую сущность, интерфейс для её сохранения…
    В общем, всё это решаем. Да — плохо соответствует канонам «академического программирования», но для рабочих проектов не всегда критично.

  • +1
    Не стоит забывать про самое важное — деньги! Куда же без них то? Некоторые типы сайтов очень удобно делать на ВП. Сделал сайт — получил деньги. Разработчики ВП и сторонних плагинов зарабатывают что? Деньги. И не забывайте, что это все же опен сурс. Всем угодить не получится ну никак. Сам факт того, что команда существует, развивает свои сервисы и зарабатывает — говорит об очень многом. Можно конечно годами вылизывать свой symfony-код и полировать его behat-тестами, а потом грустно смотреть на одного фолловера и одну звезду на гитхабе. Но кушать от этого меньше не хочется =)
    • 0
      Соглашусь с вами. Часто заказчику нужен «сайт, через месяц» и «хочу сам буковки везде менять». Если его «хотелка» вписывается в возможности WP(пусть и с небольшой доработкой) — он получит предложение использовать его в качестве движка. Конечный выбор всегда за клиентом, но у нас как-то заказчики выбирают WP, хоть мы честно демонстрируем им работу в админках других CMS.

      И немного о грустном… Что вам скажет ваш начальник, если вы придете к нему с предложением перейти для всех проектов на какой-то популярный фреймворк ради качественного кода/архитектуры и т.д., при этом увеличив трудозатраты и снизив доход? Думаю в большинстве случаев ответ очевидный.
      • 0
        Совершенно верно. Тут вопросы в приоритетах и целевых аудиториях. ВП сделан для веб-мастеров и домохозяек и вполне себе их устраивает. Если есть потребность или желание использовать паттерны, ООП и прочее — просто выбираете продукт под эти потребности, например github.com/Sylius/Sylius — для магазина, если нужен движок для блога-сайта — bolt.cm/
  • 0
    Один раз потребовалось срочно приспособить WP к высокой нагрузке.
    Спас HHVM.
    Для WP реально помогает.
  • +1
    Легко и приятно писать о недостатках самой популярной бесплатной сms.

    Вопрос тут такой: может популярность cms вообще не связана с качеством кода?
    А, простите, цель любой новой cms случайно что?) Качество кода?)

    Нарезка изображений — в данный момент обсуждается улучшение этого места в ядре.
    • 0
      Я тоже не люблю многие моменты и надеюсь, что это все поправят и согласен с автором.
      Но в багтрекере один ответ на все вопросы «обработанная совместимость».
    • 0
      может популярность cms вообще не связана с качеством кода?
      А, простите, цель любой новой cms случайно что?) Качество кода?)

      Ну вообще да, я выбираю CMS по качеству ее кода и удобству разработки (читать — программирования) в ней. Клиенту не важно, какой двиг я использую, а мне не важно, популярен он или нет.
  • +4
    Не будем показывать пальцем, но с cron например 1С-Битрикс также делает ;)))
    • 0
      Есть возможность это перенастроить и в админке описывается как это сделать )
      • 0
        Что перенастроить? На что перенастроить? Не знаю как в 14-ой, а на уровне 12-ой версии cron работал именно как хук на хитах. И не было никакого другого cron. О да, включая бэкапы.
        • +1
          • 0
            «С этой секунды на хитах будут исполняться только периодические агенты.» — это вообще что такое?

            Но ок да, не прошло и 100 лет.
  • +3
    Всегда поражала способность PHP'шников писать говнокод, который прекрасно работает.
    • 0
      Вы поразитесь еще больше, узнав, что так умеют не только на PHP. Да что там, большая часть кода, который прекрасно работает, похожа на огромную кучу навоза.
  • +2
    Очень интересная и полезная на мой взгляд статья. Я давно уже просил программистов объяснить мне в чем минусы WP. Вы первый кому это удалось сделать более или менее сносно. Это если о хорошем )

    Теперь о плохом.
    Статья однобока. Точка зрения на продукт лишь со стороны программиста. Вырвана из контекста задач.

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

    Тут много сказано о том что WP это CMS. Не фреймворк. С точки зрения логики и значения слов — это бред. Но это мало кого волнует.

    А теперь разберем пример. Вздумалось как то нам решить задачу комплексной автоматизации бизнес процессов крупного предприятия распределенного по всей стране.

    Включив мозг и сделав анализ множества платформ мы выбрали WordPress. На тот момент весь ИТ отдел состоящий преимущественно из веб разработчиков заржал. Особенно глава. Аргументы были примерно такие же только ещё глупее.

    Ну наняли мы пару студентов. В буквальном смысле. И чуток фрилансеров. Через год на этой системе крутилось уже более 20 бизнес процессов включая крайне сложные и запутанные workflow.
    Аналогов по сложности и комплексности в РФ просто нет. Есть опыт общения с ИТ руководителями крупнейших предприятий нашей страны.

    Для сравнения идеально быстрая платформа которую пилили остальные 20 веб программистов в итоге смогла осилить лишь 2-3 процесса за тот же период. И начала тормозить жуть как.
    Результат был на лицо. Один из студентов в итоге стал ИТ директором. Потому что смог решить задачи бизнеса в 10 раз эффективней. А те кто над ним смеялся стали его подчиненными.

    Причина? Сомневаюсь что она в том что 2 студента оказались умнее 20 опытных веб разработчиков.

    Реальная причина в том что WordPress антихрупок. Он не эффективен с точки зрения кода. Это исключающие свойства. В нём заложена куча гиберкомпенсаций. Для того чтобы понять что тут написано придётся прочитать книгу Насим Талеб Николя про антихрупкость систем.
    И этот эффект хорошо виден по фильму Война миров. Там где в конце эффективные и сильные захватчики вдруг проигрывают войну слабым и глупым землянам. Ты должен быть оптимален в глобальном понимании со многих точек зрения. Для этого тебе придётся быть не оптимальным в каких то локальных частях. Только так можно заслужить право выжить в реальном мире.
    Что WP отлично демонстрирует.
    Это точка зрения архитектора. Она философская. Но именно так выбираются архитектурные решения для сложных проектов аналогов которых в мире нет или очень мало. Приходится применять философию и смотреть на вещи сразу со множества точек зрения.
    Именно антихрупкость определила победу WP в нашем проекте. По этой же причине WP разрывает рынок.

    Я не говорю что WP эффективен или правилен. Это не феррари и не танк если говорить аналогиями из мира машин. Это кроссовер. Он медленней чем феррари и уступает танку по вооружению. Но именно его выбирает рынок за универсальность и удобство.

    Как только вы начнете принимать иные точки зрения отличные от вашей. Вы поймете в чем сила WP.
    • –1
      Включив мозг и сделав анализ множества платформ мы выбрали WordPress.… Ну наняли мы пару студентов.

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

      Аналогов по сложности и комплексности в РФ просто нет.

      По сложности системы или по сложности задачи? Если первое, то это камень в ваш огород, если второе, то вы плохо знаете задачи РФ.
      • +1
        они и WordPress не знали. Просто студенты которые как то умели программировать. Все остальное они учили по ходу. Сложность задачи которую они решили превосходит многое что мне известно из практики автоматизации в РФ. А повидать мне пришлось много сложных проектов как в федеральных предприятиях так и в правительственных структурах. Там где проекты загибались один за другим и выживали только самые оптимальные решения.
        • –1
          они и WordPress не знали. Просто студенты которые как то умели программировать

          Боюсь представить, что там получилось в результате.

          Там где проекты загибались один за другим и выживали только самые оптимальные решения

          Наше любимое государство, очень плохой оценщик IT-проектов. Если вы «повидали много сложных проектов как в федеральных предприятиях, так и в правительственных структурах», то должны знать, что главной целью всех этих проектов является — минимальная цена с максимальным откатом, в минимальные сроки и чтоб результат был незамедлительно. Под результатом понимается показушность и количественность, чтоб завтра проверка увидела, похлопала и ушла. Так было со СМЭВ, так было с единой системой документооборота, так было с СПО. Отсюда делается вывод, что проекты «загибались один за другим и выживали только самые оптимальные» не потому, что они чем то превосходят аналоги, а от того, что у вас были знакомства или вы предложили больший откат. Я не хочу никого обвинять, просто крайне часто сталкиваюсь с таким поведением нашего государства.
      • 0
        Я думаю, что для компании которая продаёт сайты на Wordpress (http://systemo.biz/, ссылка из профиля maxxannik), ничего лучше, чем Wordpress нет.
        • 0
          В том то и проблема. Народ сам соглашается с тем, что для каждой задачи нужен свой инструмент, и при этом активно пользуют золотой молоток.
    • 0
      Автоматизация бизнес-процессов предприятия на вордпресс? Всё правильно?
      • +1
        Я просто не очень понимаю, что именно от вордпресса вам там понадобилось? Это же по-любому какая-нибудь каша из топора, где весь вордпресс никак не используется, а над ним нагорожена большая колбаса, которую можно было бы сделать и отдельно.
        • 0
          Чтобы сделать отдельно, нужно знать больше, чем то, как установить WP и плагины на него.
        • 0
          Давайте уберем коней в вакууме и попробуем назвать хоть один пример у нас в РФ или в мире который хоть как то приблизился вот к такому уровню охвата бизнес процессов systemo.biz/skaz-o-tom-kak-my-dvizhok-dlya-blogov-wordpress-zatochili-pod-crm-erp-acm-sistemu-kompleksnogo-upravleniya-predpriyatiem/

          У меня более 10 лет управления сложными ИТ-проектами и построения сложных ИС. Я утверждаю что нельзя этого сделать на другой платформе. Потому что делал, пытался и не раз. И получилось только на WordPress. Почему? — это отдельная тема для разговоров.

          Вы тут через «бы» утверждаете что можно. Убираем «бы». Приведите пример. Будем о чем поговорить. А пока тут конь в вакууме по имени «бы». Говорить не о чем.
          • +1
            Я вам задаю один конкретный вопрос — почему именно Wordpress. Какие его особенности вам понадобились. Вашу статью я читал. Теперь вот по этой ссылке прошёл и прочитал. Ни там, и там нет ни слова про то, как вы это сделали, и чем конкретно вам помог Wordpress.

            Мне просто интересно, я тоже не с улицы зашёл. Веб-проекты делаю, про бизнес-процессы знаю.
            • 0
              По ссылке есть раздел с описанием причин. Если вы название другие платформы с такими параметрами буду признателен.
              Мне нечего добавить к тому списку на данный момент.
              • 0
                Извините, но совершенно неубедительно. Если убрать всякую эзотерику про антихрупкость и ООП в вордпрессе, то любой популярный фреймворк с приятной админкой подойдёт под эти принципы.
          • 0
            Давайте уберем коней в вакууме и попробуем назвать хоть один пример у нас в РФ или в мире который хоть как то приблизился вот к такому уровню охвата бизнес процессов

            В России.
            В мире.
            Платформа одна и та же, сложность задачи в разы выше вашей.

            Повторюсь, то что вы сделали, это не самый сложный проект в России и тем более в мире.
            • 0
              я разве утверждал что самый?
              но и ваши ссылки это левые продукты из других категорий.
              по первой в описании речь лишь об одном процессе. может быть двух. в нашем случае их было более 20. там 1500 пользователей. у нас их было более 2000. по каким таким признакам вы решили что указанные вами проекты сложнее?

              или просто хочется что нибудь написать вне зависимости от адекватности мысли?
              • 0
                Если бы вы немного отклонились от поиска числа процессов в приведенном мной примере и заглянули в функционал, то увидели бы такую вещь, как дизайнер процессов. Эта штуковина позволяет в считанные минуты реализовывать самые сложные бизнес процессы. Она настолько проста, что даже ваши два студента с ней справятся после прочтения одного мануала. Я веду к тому, что реализованные вами 20 процессов это не достижение. Хотите я сейчас вам накидают 30 процессов?

                Что касается пользователей, то вот цитата из второй, приведенной мной системы:
                A comprehensive, customisable taxi solution to support fleets from 100 to 10,000 vehicles — Sherlock provides a business-proven end-to-end system that supports every aspect of running large scale taxi businesses
                • 0
                  да в считанные минуты. я б даже сказал за 5 секунд. кони в вакууме они такие. они все могут.
                  подростете и узнаете чем отличается набросок процесса в дизайнере от реально рабочего процесса.
                  до тех пор у меня нет желания обсуждать вакуумных коней с человеком без опыта. мы в разных мирах живем. в моём мире с реальным процессами это не возможно. в вашем мире коней и фантазий живут дизайнеры процессов в считанные минуты реализующие самые сложные процессы. нам не о чем говорить.
                  • 0
                    Апелляции к возрасту, необоснованные предположения. Дорогой, да у вас нет аргументов в этом споре.

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


      Как только вы начнете принимать иные точки зрения отличные от вашей. Вы поймете в чем сила WP.

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

      Касательно вашего примера — какая-то удивительная история. Из нее напрашивается вывод, не относящийся к WordPress, что 20 опытных веб-разработчиков вовсе не такие опытные и чем-то не тем на работе занимались или же им неверно была поставлена задача или вы о чем-то еще умалчиваете.
      • 0
        Мне понравилась ваша точка зрения касательно примеров и минусов. Я лишь утверждаю что она однобока. И что популярность WP это следствие причин которые вы не затронули, или не заметили. А не потому что люди глупые и не понимают какая это плохая платформа и ставят ее на право и на лево. У WP затраты на маркетинг ниже чем у Битрикс, Юми или даже Joomla. Их почти нет. Но при этом именно эта платформа отжирает рынок уже не первый год. А у остальных показатели все время падают.

        Мой пример — есть пример. Факт. Реальность. Которую я сам лично наблюдал. 20 опытных веб разработчиков против 2х студентов, которые WP даже не знали и начали его изучать лишь с началом проекта. В противовес к 20 специалистам где система уже была рабочая, и все были с опытом и знали веб технологии очень глубоко. Нас учили многому. Тому что мы спрашивали и тому чего не спрашивали.

        Но через год — у них лишь 3 процесса со скрипом и еле как, а у студентов более 20. Со всеми вытекающими.

        На мой взгляд разница была лишь в платформе. Возможно разница была в том кто ставит задачу. В первом случае это был руководитель веб-програмистов и самый опытнейший из них. А во втором я — не программист ниразу. Но думаю что этот факт вам покажется еще более не реальным :) Потому про него умолчал.
        • 0
          Тогда другой вопрос. Как вы думаете, почему при наличии таких фактов и такой реальности, которые вы описываете, множество других компаний еще не разогнали все эти высокооплачиваемые штаты десятков веб-разработчиков и не посадили вместо них по студенту на десяток уволенных программистов и не вручили им всем WP?
          • 0
            Вероятно причина в том что лучший инструмент для решения задачи тот что ты знаешь. Ну или в чем то другом. Зачем мне знать ответ на этот вопрос? Я уверен что существуют тысячи задач для которых wp не оптимален. Но я лишь говорю что взяв конкретику начинаешь иначе смотреть на выбор. Появляется предмет. Минусы и плюсы относительно конкретной цели. Тогда и можно выиграть или проиграть. А тут нет предмета и цели. А просто описаны технические тонкости обозначенные как минусы. Часть из которых мб таковыми и есть. А часть мб лишь продолжение его полюсов. То что минус с первого взгляда в реальном мире может оказаться плюсом. Вот как то так )
  • +1
    Есть хорошая формула, по которой можно можно рассчитать эффективность любого действия: эффективность = затраченные ресурсы / время

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

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

    Я — как программист использую yii в разработке проектов. Но я — как блогер, использую вордпресс. Для каждой задачи подбирать наиболее подходящий инструмент (способ решения) из субъективно доступных.
    Тут надо решить: вам шашечки или доехать?

    «Я-программист» хочу быстро создавать и в дальнейшем поддерживать проекты. А «я-блогер» хочу концентрироваться на написании заметок, а не на обслуживании сайта.
    • –1
      Насчет популярности и простых пользователей я написал в заключении статьи. Я тоже использую WP как блогер и для рабочих проектов. Но не считаю, что по каким-то причинам не стоит обсуждать его технические недостатки. Почему популярное решение для простых пользователей не должно или не может быть и технически хорошо выполненным?
      • +1
        Почему популярное решение для простых пользователей не должно или не может быть и технически хорошо выполненным?

        Оценив большинство аргументов, данных в комментариях к этой теме, сделал вывод, что пользователи просто не могут «технически хорошо выполнить» код WP (не позволяют знания, опыт, время и т.д.). Признаться они в этом не хотят, но пытаются оправдаться тем, что это не нужно и вообще WP не для этого.
  • 0
    Нарезка изображений
    Простите, что влезаю, просто оставлю это здесь: uploadcare.com

    Загружаются только оригиналы, дальше запрашиваете в какие хотите размерах сколько нужно, в любой момент времени. Ничего нарезать не нужно. Все работает через URL API.
    • +1
      И вы там работаете. Несколько неуместная реклама для данной статьи, я считаю.
      Ваш сервис неплохих денег стоит, по крайней мере не дешевле и даже дороже хостинга, и замена нативной обработки медиафайлов сторонним платным сервисом — это, скажем так, специфическое решение. Тем более, что, как указали в иных комментариях, разработчики WordPress уже занимаются этим вопросом.
      • 0
        И я там работаю, все верно. В статье вы написали про боль, которую испытывают разработчики от нарезки изображений. Вроде бы это идеальное место для решения, которое эту боль снимает.
        • 0
          Идеальное решение, это потратить два дня и таки допилить функцию нарезки изображений в WP, а не платить стороннему сервису за элементарное действие.
          • 0
            Да, не спорю, просто должен быть выбор, согласны? Потратить еще 2 часа 4 года (столько открыт баг) на элементарную фичу, или сэкономить время и силы и воспользоваться готовым.
          • 0
            Для начала, я тоже там работаю :)

            Если вы посмотрите на количество классных платных плагинов (не все из них так плохи, как написано в статье (наш — плох)), которые решают для пользователей задачу класса «потратить два дня и допилить», вы можете понять, что в этом мире не все так просто и не все программисты на PHP или под Wordpress.

            За те два дня, которые будут оплачены по средней ставке $100 в час (без гарантии что они не вырастут в 2 недели, и вообще что-то заработает), бизнес, который умеет считать деньги накупит себе плагинов, сервисов и начнет зарабатывать прямо сейчас, получая поддержку, апдейты и прочее.
            • 0
              Клиент скорее всего не узнает или не поймет в чем тут проблема со стандартной нарезкой изображений в WP. Докупит места и всё, тем более это наверняка обойдется дешевле, чем платить за ваш сервис.
              Лично я могу представить использование вашего сервиса на масштабных нагруженных ресурсах, скорее всего со своим штатом разработчиков, которые собственно и пользуются CDN'ами. Но сдавать среднестатистическому заказчику сайт или уж тем более делать какой-нибудь личный блог с завязкой на ваш сервис — не вижу никакого смысла, это банально не выгодно. Такие сайты вполне могут работать на какой-нибудь VPS'ке за 5$/мес., скажем, от Digital Ocean, а вы предлагаете платить дополнительно от 10$ просто за работу с картинками. Конечно, допускаю, что у вас может быть статистика использования вашего сервиса, показывающая, что его используют не только для крупных проектов, и которая меня удивит.
              А если бы у WP не было такого недостатка с нарезкой, то и обсуждать тут толком было бы нечего.
              • 0
                Вообще то, я говорил про абстрактную задачу, решаемую абстрактным программистом за кучу денег или абстрактным плагином/сервисом за малую долю той кучи.

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

                По статистике могу сказать, что на данный момент мелких пользователей c блогами или мелкими магазинчиками у нас больше, чем крупных нагруженных проектов.
            • 0
              в этом мире не все так просто и не все программисты на PHP или под Wordpress

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

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