Comments 27
Всегда работал с Joomla. А последние выпуски 4 и 5 - вообще песня. И да, если у вас доступы к БД под рукой, то займет установка не 5, а 2 минуты. Но то, такое. Срач разводить не собираюсь.
В общем, как-то думаю, дай попробую этот WP. Все таки самый популярный в мире движок. И как-то очень быстро, практически в первый же день, я понял, что мне с ним не по пути.
Причина? Ну она на поверхности. Когда вы вставляете в статью Joomla изображение, это прямая scr ссылка на конкретное изображение, в какой-то папке. Все.
В базе данных, в таблице _content строк ровно столько, сколько у вас статей.
И каково же было мое удивление, когда я увидел, что WP для каждого изображения в статье создает в БД новую строку с типом attachment. То есть, если у вас есть статья, а в ней 20 изображений, в таблице _posts вы получите 21 одну строку. В итоге, WP делает 21 запрос к БД, а потом еще 20 к диску для физического получения файлов. В то время как в Joomla к БД идет один запрос, остальные напрямую к диску.
Я так и не понял, для чего это сделано именно так, но это явно не по феншую.
В Joomla ранее тоже многое было сделано неправильно и команда Joomla решила всё это переписывать, даже ценой обратной совместимости и потери пользователей. Теперь у Joomla отличный код, но аудитория хотела просто нажимать кнопку Обновить. Команда WP же решила делать бесшовные обновления и сильно вложилась в маркетинг, впрочем не забывая и о новых технологиях, но поверх старого легаси. Встроенный блочный редактор, кастомные поля, огромное количество решений в магазине. Проблемы производительности решились доступностью быстрого железа и на этом все успокоились.
Да это понятно зачем. Смотрите, у вас фотография в статье и на сайте вы не один автор. Если это коммерция, то сразу вопрос: какая лицензия и тп. Те в WP изначально задумывал что все пикчи это сущности отдельные со своей страницей (если нужно). Всякие вики движки точно также делают…
Насчет числа запросов: я думаю там все кэшируется…
На счет "не один автор" не понял. В Joomla, фото добавленные автором доступны только ему из Media.
Ну ок, изображение - отдельная сущность. Я просто не понимаю, что это дает.
По поводу кэша. Так везде кэшируется. Но кэш же не вечный. Да и размеры базы не резиновые.
Не знаю, может в этом и есть смысл. Меня это отпугнуло ))
Насчет нескольких авторов я имел ввиду, что каждый несет ответственность отдельно за свои изображения (а не глобально один админ).
> Ну ок, изображение - отдельная сущность. Я просто не понимаю, что это дает.
Ну как и сказал, всякую мета-дату: лицензия, автор, чем и где было снято. Это по идее должно быть в данных самого изображения, но так как можно кропнуть, либо при загрузке ресайз был и т.п. Скажем, я публиковался в Towards Data Science, там всю эту фигню надо прописывать в капче, это раздражает конечно. Потом другой был сайт госструктуры на Django CMS, там похожим образом как в WP. Редактор не дает использовать никакие изображения публично до тех пор, пока не прописано кем и когда было сделано фото/изображение и также лицензию на его использование) Тогда капча оказывается свободной, а сама пикча ведет на небольшую страницу, где эта мета-информация отображается
WP создаёт копии изображений разных размеров для каждого загруженного изображения. При его удалении удаляются все эти превьюшки и уменьшенные копии. Минимум для этого нужна эта сущность.
Что мешает вставлять фотки напрямую без загрузки их стандартными способом? Грузишь в любую папку фото, в посте указываешь прямую ссылку. Будет ровно то, о чем ты пишешь. Никаких attachment создаваться не будет. Управлять такими фото можно через другие плагины, так как стандартная медиа библиотека их не увидит.
Для удобства можно плагин или блок Гутенберг сделать, который будет грузить фотки без создания attachment.
При этом, наверно, и плюсы есть у подхода с attachment, если подумать.
в посте указываешь прямую ссылку
Это типа руками img scr вставлять?
плагин или блок Гутенберг сделать, который будет грузить фотки
Ну а в Joomla без всяких плагинов, прямо из папки вся медиа библиотека отображается и в нее же загружаются новые при необходимости.
Руками вставлять саму ссылку в блок изображения. Непосредственно в src сам блок вставит. Но весьма вероятно есть плагины готовые, которые просто будут нужную папку показать по аналогии с джумлой. Я к тому, что по крайней мере в WP можно такие моменты подогнать под себя. Вот можно ли наоборот джумлу подогнать под wp это другой вопрос. Надо будет поэкспериментировать, чтоб увидеть разницу.
И всё же у Joomla стабильный тренд на спад популярности согласно https://w3techs.com/technologies/history_overview/content_management/all/y
Макретологов нормальных не подвезли.
Сам движок офигенский. И бэкенд супер удобный. И плюшек там вагон и тележка.
Вот и ладно. Меньше всякие хакеры на Джумлу зариться будут. Не надо, чтобы Джумла, как WP мелькала в новостях про взлом. Каждый год начинается с новостей в январе, что очередной школьник взломал WP. Ужасная система, как по мне.
Кстати с 22 года, судя по графику у WP тоже рост остановился. Тем не менее, оба движка из Топ 2.
В таблице wp_posts хранятся не только статьи как таковые, но и данные изображений (attachment), комментарии, ревизии постов и т.п. Как вы вообще себе представляете, загрузить в какую-либо CMS изображение и не сделать запись о нем в БД? Ну и на фронте, при просмотре этой статьи не будет никаких 20 запросов в БД для 20 картинок, т.к. в уже полученном теле статьи ссылки на эти изображения присутствуют
Согласен. Но на сегодня, все это есть и в Joomla. Кнопка обновить + предупреждение о возможных несовместимых расширениях. А так да, раньше сделать обновление - это слезы. Но переезд на WP еще слезоточивее был. По поводу расширений, их тоже огромное количество. Я не знаю, чего там нет такого, что есть в WP. А блочный редактор - это зло, по моему мнению. Хотя, судя по всему, именно он + обновление и сделали его популярным. Ну то есть не нужно лезть в код, следить за количеством элементов в DOM и т.д. Красиво и ладно. А то, что одна кнопка из блочного редактора завернута в кучу div, то такое. Да я в целом только "за" конкуренцию. Иначе, все стояло бы на месте.
В свое время написал скрипт, который автоматизация массовых обновлений WordPress через WP-CLI
https://github.com/paulmann/Bash_WP-CLI_Update
2 скрипта крутятся через крон - один обновляет wp, плагины, темы и оптимизирует БД раз в сутки. Второй выполняет задачи для cron и выполняется каждые 5 минут.
**P.S.** Для промышленных сред рекомендую добавить:
- Предварительные бэкапы через `wp db export`.
- Флаг `--skip-themes/plugins` для точечного контроля.
- Интеграцию с системой мониторинга (напр., отправку логов в Sentry).
Самое ужасное в WP - что он самый взламываемый. Месяца не проходит, чтобы очередная новость об этом не вышла. Свежая - вчера в Хакере. Популярная тема для WordPress позволяет менять пароли пользователей — Хакер https://share.google/dpeIQ1aB2he5P67Pk
Ну и из коробки, в отличие от той же Джумла!, мало что есть. А когда движок обрастает плагинами, становится неповоротливым. Особенно с Виртуемартом, если в нем товаров больше сотни.
Оставили бы блогоплатформу блогерам. Зачем делать из нее то, что она не способна нормально тянуть?
Так это обратная сторона популярности.
Самое ужасное в WP - что он самый взламываемый.
Все взломы идут через сторонние плагины и темы, собственно вы сами это и пишете "Популярная тема для WordPress позволяет менять пароли пользователей"
А когда движок обрастает плагинами, становится неповоротливым. Особенно с Виртуемартом, если в нем товаров больше сотни.
Я честно говоря даже не слышал про этот магазин, стандарт де-факто магазина на WP это Woocommerce - там нет проблемы с производительностью даже на тысячах товаров.
С точки зрения использования движка как бэкенда для независимого фронта интересно было бы узнать плюсы и минусы по сравнению с фреймворками типа Laravel.
вот где функциональное программирование!!!, а не в ваших этих хаскелах и кложурах
Еще у WP есть такая потрясающая вещь как Headless CMS, когда front end и back end отделены друг от друга, что позволяет работать с ними независимо.
Название headless подразумевает следующее: наш front end — это голова, его отделяют и получается «безголовая (headless)» CMS. В headless CMS удаляется только front end, оставляя back end и application programming interface (API). CMS становится хранилищем контента и мы можем сделать собственный front с использованием самых последних и вкуаных технологий.
Под капотом WordPress — разбираем движок и изучаем инструменты