Для профессионала очень странно составлять подобный рейтинг без реальных плюсов и минусов. Конечно, дисклеймер "это сугубо моё имхо" и т.д. в тексте присутствует, но Joomla как-то обойдена вниманием совершенно несправделиво. На ней есть примеры сайтов-новостников с 250к уников в сутки и даже больше. На ней существуют успешно интернет-магазины (автозапчастей, например) с более чем 32М товаров. И про эти сайты можно сказать, что они не предназначены для СЕО и их регулярно взламывают? Да, может быть Вы не в курсе состояния развития CMS за последние лет 5-6. Но внутри Joomla полноценный PHP-фреймворк. Проект Joomla является проектом-участником группы PHP FIG, вырабатывающим стандарты PSR для всего мира PHP. Рядом в этом списке, на минутку, Laravel и Symphony. В тексте же статьи читается отношение к Joomla как CMS, для которой можно накупить ломаных модулей и плагинов на варёзниках рублей этак по 300 и быстренько что-то сляпать. Увы это не так. В статье правильно сказано, что каждый делает сайты на том, что умеет. Но почему-то Joomla из общего списка выбивается. "Мальчик для битья" в статье нужен. А стратегия продвижения личного бренда должна предполагать объект для хейта и собственно хейт. Я знаю ребят, которые обожают MODX, которые любят работать с WP, есть кто матерится, но работает с Битрикс, но почему-то они не позволяют себе подобного отношения к Joomla потому, что они профессионалы. Мне кажется, что для того, чтобы статья была полезной, нужно посмотреть внимательнее роль и место Joomla, что на ней делают последние годы, что у неё с СЕО. И возможно скорректировать текст так, чтобы он отражал картину реалистичнее. Либо же действительно изменить заголовок так, чтобы он отражал Ваше личное мнение.
Очередная статья, вносящая путаницу с заголовками. Согласно спецификации HTML5 на странице может быть сколько угодно заголовков h1, а логические уровни выстраиваются с помощью section, в каждом из которых может быть свой header и footer. Это при условии, если данный контент неотделим от содержимого страницы. Если отделим, то используется article. Если контент, не относящийся к главному содержимому страницы (рекламные блоки, ссылки на всякие ресурсы "для галочки"), то должен быть aside.
WordPress также имеет большую команду, работающую за кулисами для обеспечения безопасности , а также множество вариантов для автоматических обновлений. Joomla предлагает своим клиентам много информации, которая поможет им обезопасить свои веб-сайты.
В Joomla есть целый отдел, занимающийся безопасностью движка. Почти с каждым релизом закрываются уязвимости разного уровня. Почитайте прошлый дайджест, там говорилось об этом. В интернете есть статьи команд, исследующих уязвимости и в своих отчетах они отмечают качество и внутреннюю логику устройства движка. Joomla - фреймворк-ориентированная CMS. У WordPress нет такого развитого API с высокой степенью абстракции. Причина популярности - в маркетинге и кажущейся простоте.
Я пытаюсь представить задачи, в рамках которых может потребоваться await на сайте. В joomla ajax-запросы делаются для получения данных из модуля, плагина или (реже) компонента на том же сайте. Физически запрос идёт на тот же сервер и если он отдал вёрстку, то и ответ на запрос вряд заставит себя долго ждать. В Joomla 4 есть rest API из коробки, но вряд ли фронт будут писать на joomla.request. Запросы к удалённому серверу, от ответа которого зависят данные на странице - согласен. Но мне кажется, что joomla.request больше для внутреннего пользования. Представить сайт, где внешних запросов нет, анимации в дизайне сделаны на css. Тогда jquery не слишком нужен. И сеошник будет спокойнее, зная, что не грузится ещё одна неиспользуемая библиотека от 60 до 200кб весом.
С 2-3 детьми в возрасте 0-12 чтоб накопить жирок нужно впахивать как Папа Карло, потому что дети требуют очень много внимания и работать чаще всего просто и некогда.
Фронтовые нюансы, в общем и целом) Это писалось больше для тех, кто подключает jquery, а порой и не один экземпляр ради того, что уже реализовано в ядре CMS.
Я про fetch не знал, хотя возможно, что он давно уже существует. В своей работе сталкиваюсь в основном с бэком. Насколько велика разница между XMLHttpRequest и fetch кроме синтаксиса?
Поскольку фронт формы Вы собираете по сути сами - можете подключать какую угодно капчу. Дело в том, что в случае с Radical Form CSRF-токена в коде формы нет. Боты даже если сабмитят форму, то токен не получают. Поэтому спама через Radical Form меньше. Как вариант - можно не оборачивать форму в тег form, хотя это уже нарушение стандартов, но вроде такое решение тоже будет работать. Так же слышал, что боты (хрумер и т.д.) ещё не осилили hcaptcha. Попробуйте её. В телеграме есть чат русскоязычного сообщества Joomla, в котором есть разработчик Radical Form. По ней он сможет ответить на все вопросы.
Тему CLI в четверке нужно изучать)) При подготовке опирался на крохи информации из разных источников. В тройке cli тоже есть и примеров работы даже больше, чем в четвёрке.
Мне тоже, но попадался пару лет назад сервер со злобным админом из тех времен, когда 640кб оперативной памяти хватало всем.
Guzzle - PSR 7. Это удобно. Но в тройке из коробки нет PSR7. Он появится только в Joomla 4, которая сейчас RC3. Guzzle нужно подключать дополнительно, а речь шла о нативных возможностях фрейма. Если оно работает, core feature - зачем ставить лишние зависимости и от них зависеть?
Есть такой модуль https://www.phoca.cz/phoca-top-menu-module Или речь о чём-то другом?
Для профессионала очень странно составлять подобный рейтинг без реальных плюсов и минусов. Конечно, дисклеймер "это сугубо моё имхо" и т.д. в тексте присутствует, но Joomla как-то обойдена вниманием совершенно несправделиво. На ней есть примеры сайтов-новостников с 250к уников в сутки и даже больше. На ней существуют успешно интернет-магазины (автозапчастей, например) с более чем 32М товаров. И про эти сайты можно сказать, что они не предназначены для СЕО и их регулярно взламывают? Да, может быть Вы не в курсе состояния развития CMS за последние лет 5-6. Но внутри Joomla полноценный PHP-фреймворк. Проект Joomla является проектом-участником группы PHP FIG, вырабатывающим стандарты PSR для всего мира PHP. Рядом в этом списке, на минутку, Laravel и Symphony.
В тексте же статьи читается отношение к Joomla как CMS, для которой можно накупить ломаных модулей и плагинов на варёзниках рублей этак по 300 и быстренько что-то сляпать. Увы это не так.
В статье правильно сказано, что каждый делает сайты на том, что умеет. Но почему-то Joomla из общего списка выбивается. "Мальчик для битья" в статье нужен. А стратегия продвижения личного бренда должна предполагать объект для хейта и собственно хейт.
Я знаю ребят, которые обожают MODX, которые любят работать с WP, есть кто матерится, но работает с Битрикс, но почему-то они не позволяют себе подобного отношения к Joomla потому, что они профессионалы.
Мне кажется, что для того, чтобы статья была полезной, нужно посмотреть внимательнее роль и место Joomla, что на ней делают последние годы, что у неё с СЕО. И возможно скорректировать текст так, чтобы он отражал картину реалистичнее. Либо же действительно изменить заголовок так, чтобы он отражал Ваше личное мнение.
Section неотделим от контента страницы. Article отделим и может быть переиспользован на других страницах.
Очередная статья, вносящая путаницу с заголовками. Согласно спецификации HTML5 на странице может быть сколько угодно заголовков h1, а логические уровни выстраиваются с помощью section, в каждом из которых может быть свой header и footer. Это при условии, если данный контент неотделим от содержимого страницы. Если отделим, то используется article. Если контент, не относящийся к главному содержимому страницы (рекламные блоки, ссылки на всякие ресурсы "для галочки"), то должен быть aside.
Эта проблема не возникает вообще, если за сайтом следить и поддерживать версии актуальными.
В Joomla есть целый отдел, занимающийся безопасностью движка. Почти с каждым релизом закрываются уязвимости разного уровня. Почитайте прошлый дайджест, там говорилось об этом. В интернете есть статьи команд, исследующих уязвимости и в своих отчетах они отмечают качество и внутреннюю логику устройства движка. Joomla - фреймворк-ориентированная CMS. У WordPress нет такого развитого API с высокой степенью абстракции. Причина популярности - в маркетинге и кажущейся простоте.
Я пытаюсь представить задачи, в рамках которых может потребоваться await на сайте. В joomla ajax-запросы делаются для получения данных из модуля, плагина или (реже) компонента на том же сайте. Физически запрос идёт на тот же сервер и если он отдал вёрстку, то и ответ на запрос вряд заставит себя долго ждать. В Joomla 4 есть rest API из коробки, но вряд ли фронт будут писать на joomla.request. Запросы к удалённому серверу, от ответа которого зависят данные на странице - согласен. Но мне кажется, что joomla.request больше для внутреннего пользования. Представить сайт, где внешних запросов нет, анимации в дизайне сделаны на css. Тогда jquery не слишком нужен. И сеошник будет спокойнее, зная, что не грузится ещё одна неиспользуемая библиотека от 60 до 200кб весом.
Почитал про промисы - такого, чтоб цепочки делать нет. В тройке точно, в четвёрке надо посмотреть, но вроде тоже нет. Только описанные колбэки.
С 2-3 детьми в возрасте 0-12 чтоб накопить жирок нужно впахивать как Папа Карло, потому что дети требуют очень много внимания и работать чаще всего просто и некогда.
Фронтовые нюансы, в общем и целом) Это писалось больше для тех, кто подключает jquery, а порой и не один экземпляр ради того, что уже реализовано в ядре CMS.
Я про fetch не знал, хотя возможно, что он давно уже существует. В своей работе сталкиваюсь в основном с бэком. Насколько велика разница между XMLHttpRequest и fetch кроме синтаксиса?
Не корректно выразился. Токен есть, но он появляется после загрузки страницы. Поэтому боты токен не получают
Поскольку фронт формы Вы собираете по сути сами - можете подключать какую угодно капчу. Дело в том, что в случае с Radical Form CSRF-токена в коде формы нет. Боты даже если сабмитят форму, то токен не получают. Поэтому спама через Radical Form меньше. Как вариант - можно не оборачивать форму в тег form, хотя это уже нарушение стандартов, но вроде такое решение тоже будет работать. Так же слышал, что боты (хрумер и т.д.) ещё не осилили hcaptcha. Попробуйте её.
В телеграме есть чат русскоязычного сообщества Joomla, в котором есть разработчик Radical Form. По ней он сможет ответить на все вопросы.
Спасибо :-)
Тему CLI в четверке нужно изучать)) При подготовке опирался на крохи информации из разных источников. В тройке cli тоже есть и примеров работы даже больше, чем в четвёрке.
"Workflows" так и переведено - "процессы".
Долго, но они это сделали.
Благодарю!
Мне тоже, но попадался пару лет назад сервер со злобным админом из тех времен, когда 640кб оперативной памяти хватало всем.
Guzzle - PSR 7. Это удобно. Но в тройке из коробки нет PSR7. Он появится только в Joomla 4, которая сейчас RC3. Guzzle нужно подключать дополнительно, а речь шла о нативных возможностях фрейма. Если оно работает, core feature - зачем ставить лишние зависимости и от них зависеть?
Спасибо, поправил.