CMS *

WordPress уже много лет пытаются «похоронить». Сначала казалось, что его вытеснят конструкторы сайтов, затем современные JavaScript-фреймворки, headless-подход и облачные платформы. Теперь к этому добавились нейросети, которые умеют не только писать код, но и работать с проектом целиком: запускать WP-CLI, подключать плагины, готовить тесты и помогать с деплоем.

Так что происходит с WordPress в 2026 году? Есть ли смысл новому разработчику изучать его с нуля? Как ИИ-агенты и вайб-кодинг меняют привычную работу с сайтами? Где заканчиваются возможности WordPress и начинается Laravel? Насколько еще актуальны Elementor, Gutenberg, ACF и WooCommerce? И что вообще останется разработчику, если все больше задач можно поставить обычной фразой?

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Сокиркой — разработчиком, который пришел во фриланс еще школьником, начинал с баннера за пять долларов, затем работал с Joomla и WordPress, продавал шаблоны на маркетплейсах, сотрудничал с американскими студиями и сейчас активно экспериментирует с вайб-кодингом и ИИ-инструментами. У Александра также есть YouTube-канал: «Быть Программистом», где он публикует материалы о разработке и своем опыте.

Разговор получился не только про WordPress. Мы обсудили Laravel, Copilot, Claude, Codex и Qwen, рынок фриланса и зависимость от платформ, Elementor и Gutenberg, ACF и таксономии, Docker и CI/CD, WooCommerce, выгорание и то, как меняется сама роль разработчика. Отдельно поговорили о том, что сегодня действительно имеет смысл учить, где ИИ уже экономит часы работы, а где без понимания архитектуры, кода и логики проекта по-прежнему не обойтись.

Корпоративный сайт на пяти языках: около сотни страниц, блог, новости и 100–150 тысяч пользователей в месяц. Два года он жил на Webflow. Переезд на Next.js 15 и Payload CMS сейчас на финишной прямой, и шёл он без дня Х: страница за страницей, на одном домене со старым сайтом.

Разбираю, как это устроено. Счёт Webflow по строкам, Next.js под /app на Webflow Cloud и 301-редиректы с пятью локалями, перенос CMS-коллекций в Lexical, next-intl и проверки в CI, которые ловят то, что раньше находил только дизайнер через месяц.

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

Оказалось наоборот. Четыре CMS — четыре разных мира, и в каждом свой способ соврать вам об успехе.

Joomla возвращает 400, когда статья уже создана: плагин «Умный поиск» падает после записи в базу. Повторили запрос — получили дубль. InSales требует published_at даже у черновика, потому что черновиков там просто нет. А у 1С-Битрикс метода для создания статьи через API не существует вовсе — официальная документация прямо говорит про read-only режим.

Внутри: как выглядит общий интерфейс на четыре системы, почему CIBlockElement::Add() возвращает ошибку при успешно созданном элементе, зачем понадобилась двойная буферизация вывода и прямой SQL в обход автотранслитерации.

Данный таск был частью 7 сезона CTF, который проводился на платформе aclabs.pro. Любителям фильма «Охотники за приведениями» рекомендую ознакомиться. Это необычная тачка с двумя флагами user и root. В центре внимания будет уязвимость в вебчике движка ghost cms, а вот флаги, вот здесь интереснее. Были случаи, когда участники брали рута, но не смогли найти ни одного флага. Поэтому считаю эту машину крайне инетресной.

Суббота, клиент вернулся из отпуска, открыл свой сайт и написал мне: «сайт лежит, вижу только белый экран, что случилось?». Код ответа при этом 200, мониторинг зелёный, хостинг жив, база данных на месте.

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

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

А ещё честно расскажу, где мы сами ошиблись. Одна ошибка стоила ещё десяти часов спама в Google уже после того, как мы решили, что всё закончилось.

В конце — 5 способов за 5 минут проверить ваш собственный сайт.

Все главные новости из мира Joomla за апрель, май и июнь 2026 года в одной статье. Традиционно дайджест собирает новости сообщества, релизы, расширения, интеграции, видео и статьи из мира Joomla. Прошлый выпуск доступен на Хабре.

В мире, пожалуй, есть несколько самых популярных классических систем управления сайтами — это, конечно, WordPress и Joomla!. Joomla! немного сложнее WordPress, да и шаблонов дизайна у нее меньше. Но ее доля составляет до 3% всех сайтов в мире и до 10-18% — в России. Об истории создания Joomla! и патентах с ее упоминанием — в нашей статье.

Привет, коллеги. Я Евгений Пуляев, разработчик в группе компаний Далее. Имел дело с разными CMS/CMF, но MODX Revolution всегда занимал особое место в моем профессиональном опыте. 

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

Чтобы докопаться до правды, я проанализировал 7 млн доменов Рунета. В статье рассказываю, как проводил исследование и что оно показало.

Слово «агент» в 2026 году встречается в описаниях почти любой CMS или конструктора сайтов – от Webflow до uCoz. Однако появление рядом с кнопкой «Редактировать» новой кнопки «Спросить AI» еще не означает, что архитектура платформы действительно изменилась.

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

Ниже – попытка разобрать происходящее с точки зрения архитектуры, а не, порой, “пустозвонных” пресс-релизов сервисов.

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

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

Чтобы показать вам драматизм ситуации, я для примера провёл с помощью профилировщика PHP измерение ресурсозатратности каждой линейки семейства WordPress - это версии 1, 2, 3, 4, 5, 6 и недавняя 7.

Кому интересно, прошу под кат. Увидите, как от первых версий, на которых WordPress завоёвывал славу легковесной блоговой системы, он пришёл в конце концов к многократно утяжелённой платформе по множеству срезов измерения.

Что делать, если системный CDN вашей e-commerce платформы внезапно попал под блокировки, саппорт не помогает, а корзина и галерея на сайте умерли? Рассказываю реальный кейс, как с помощью Яндекс CDN за 150 рублей в месяц, пары сниппетов и MutationObserver удалось ускорить загрузку ядра сайта в сотни раз и вернуть интернет-магазин к жизни. Честный разбор костылей, граблей и результатов в цифрах.

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

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

Для поиска таких мест были созданы разные инструменты профилирования. Этим термином называют всестороннее измерение нагрузки, оказываемой исследуемым скриптом на сервер сайта. Например, для языка PHP наиболее известными профилировщиками кода являются следующие: Blackfire, Xdebug Profiler, Tideways, XHProf/XGHui.

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

Для решения подобной узкой задачи я разработал очень простой бесплатный профилировщик PHP. Так сказать, студийную версию профайлера, то есть урезанную до объёма, достаточного вебмастеру при работе над проектами в студии. И делюсь этим скриптом с сообществом. Кому интересно, прошу под кат.

Понадобилось дать ИИ-ассистентам (Claude Code, Cursor) доступ к данным своего сервиса — мониторы, события, аптайм, — чтобы вопрос «что сейчас в сбое?» можно было задать прямо в чате, а не идти кликать по вкладкам дашборда. Стандартный путь для этого — MCP (Model Context Protocol): сервер декларирует инструменты, и любой MCP-клиент их находит и вызывает.

Официальные примеры и SDK предлагают поднимать отдельный MCP-сервис — с транспортной машинерией, сессиями и SSE-стримингом. Я сделал иначе: один HTTP-хендлер внутри существующего Go-монолита, около 200 строк, без единой новой зависимости. Вечер работы, включая тесты curl-ом.

В статье разбираю: какой минимум JSON-RPC-методов реально требует спека для tools-only сервера (initialize, tools/list, tools/call — и почти всё), почему stateless-режим без Mcp-Session-Id легален по спецификации и что он даёт бесплатно, зачем хранить id запроса как json.RawMessage, как описывать инструменты, чтобы LLM вызывала их правильно, и какие грабли ждут при подключении Claude Code и Cursor. Весь код — из работающего продакшена, сокращён до сути.

Как работает ядро Joomla 6 на уровне Приложения (Application)? Сколько видов Приложений на самом деле есть в Joomla и в чём между ними разница? Какой жизненный цикл каждого Приложения Joomla, включая роутинг, диспетчеризацию и события плагинов? На эти и другие вопросы попытается дать ответ эта статья, опирающаяся на кодовую базу Joomla 6.1.0. Также в статье хронология вызова триггеров плагинов в разных сценариях.

👉 Бонус для любопытных читателей: а вы знали, что Joomla можно использовать в качестве daemon-процесса?

Всем привет!

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

Сегодня я предлагаю перейти от слов к делу. Я проанализировала работу команды из четырех архитекторов контента за один месяц и подготовила детальный разбор без приукрашивания: покажу, как описанные ранее функции воплощаются в жизнь, к каким результатам пришли за 30 дней. Уверена, что такой отчет позволит вам увидеть реальную ценность архитектора контента для команды и оптимизации рабочих процессов. Запаситесь чашечкой кофе, будет много деталей!

В 1865 году британский журналист Томас Майн Рид написал роман "Всадник без головы", который послужит нам отправной точкой в вопросе о том, что же такое "безголовая" CMS и какие из них представлены сейчас на рынке веб-разработки.

Большинство статей о миграции с SharePoint описывают её как проект с двумя чёткими состояниями: «до» и «после». Вот вы работаете в SharePoint — вот уже в новой системе. На практике это не так. Между «до» и «после» существует третье состояние, которое может длиться месяцами: обе системы работают в проде одновременно, пользователи работают в обеих, а данные могут меняться в любой из них.

Именно это третье состояние и создаёт самый неприятный класс проблем. И именно о нём — эта статья.

Когда маркетологи хотят всё: сырые данные в GA4, запись сессий в Метрике, хитмапы в Clarity и при этом «Lighthouse 100» в PageSpeed Insights — приходится изобретать. Расскажу, как мы это сделали на небольшом проекте и во что это обошлось по времени и нервам.

Проект — нишевый агрегатор российских хостинг-провайдеров. Более 120 страниц в sitemap, 31 статья, десятки категорий услуг, живые цены, сравнения. Стек: Astro 6 + Strapi 5 + Tailwind 4, плюс Partytown, PostgreSQL, Nginx и обычный VPS на Ubuntu. Сайт собирается в статику во время билда, никакого SSR в рантайме нет.

На desktop — Lighthouse 100 / 100 / 100 / 100. На mobile с жёстким throttling (4x slow CPU) — 99 / 100 / 100 / 100. В реальных условиях и по Chrome UX Report — 100 везде. LCP на desktop — 0,5 секунды, на mobile throttled — 1,7 секунды. CLS — ноль. TBT — 10 ms на мобильном и 0 ms на десктопе.

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

Недавно я решил завести собственный блог. Сначала посмотрел в сторону SSG, но они показались мне не слишком удобными для того сценария, который я хотел получить. Затем попробовал несколько CMS, однако быстро упёрся в другую проблему: мой сервер оказался слишком слабым для большинства современных решений.

В итоге ни одно из готовых решений так и не смогло закрыть все мои требования одновременно. Так и появилась идея сделать небольшую файловую CMS на Rust, которая не требует базы данных, не потребляет много памяти и при этом остаётся достаточно гибкой для повседневного использования.

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