WordPress

Сериал “Мэтт Мюлленвег против WP Engine” продолжает развиваться. Примерно в то же время, когда мы в Радио-Т обсуждали историю с дополнительной галочкой (теперь при логине на Wordpress.org вы должны подтвердить, что не аффилированы с WP Engine), Wordpress.org приняли решение и форкнули плагин Advanced Custom Fields.

Advanced Custom Fields — это популярный плагин, с 2 млн установок, который широко используется разработчиками при разработке сайтов на Wordpress, он позволяет гибко конфигурировать дополнительные поля для существующих типов контента и задавать новые. И да, в свое время его купила компания WP Engine и достаточно давно ведет его разработку. Поскольку теперь у разработчиков компании нет возможности обновлять плагин, размещенный в репозитории Wordpress.org (в своем зеркале они это делают, а пользователи платной версии получают обновления отдельным образом, как и с любым другим платным плагином), то Wordpress.org на основании статьи 18 правил репозитория сделали форк плагина и переименовали его в Secure Custom Fields. Теперь, если у вас стоит исходный плагин и вы обновитесь, у вас появится новый плагин. На данный момент он полностью совместим с оригиналом, в нем просто закрыта уязвимость — собственно, необходимостью её закрыть в условиях отсутствия доступа оригинальных разработчиков этот форк и объяснен официально.

WP Engine в лице команды разработчиков ACF назвали это захватом (take over). С одной стороны, open source с учетом требований GPLv2 никак не ограничивает любого желающего в праве форкнуть любой проект и развивать его самостоятельно. С другой — если я или вы форкнем любой плагин, мы никак при этом не затронем существующую аудиторию оригинального плагина, а Wordpress фактически сделал именно это. Если внимательно почитать тот самый пункт 18, то, в целом, он оставляет за Wordpress, то есть за Automattic, то есть за Мэттом Мюлленвегом лично, право захватить таким образом любой другой плагин — например, уже высказываются предположения, что следующей жертвой станут разработчики конструкторов страниц типа Elementor, мол, и Мэтт про них высказывался нелицеприятно, да и они представляют собой явную конкуренцию любимому детищу Мэтта — блочному редактору Gutenberg, который далеко не всеми воспринимается как идеальный продукт.

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

Интересный скандал, кажется, разгорается вокруг Wordpress. На прошедшей на этой неделе в Портленде регулярной конференции WordCamp US основатель Wordpress Мэтт Мюлленвег рассказал, что он думает про экосистему open-source проектов и, в частности, что открытость такой экосистемы привлекает ряд бизнесов, которые предпочитают паразитировать на бесплатном проекте, не участвуя в его создании.

Основным примером такого бизнеса стала компания WPEngine, которую Мэтт обвинил в итоге в использовании не только самого продукта, но и торговых марок и стилистике, принадлежащих Automattic. По утверждению Мэтта, WPEngine, построив свой бизнес на Wordpress (компания продаёт хостинг для Wordpress), меньше контрибутит в проект, чем даже Google, создавая при этом впечатление, что они-то и есть Wordpress. Скандальность ситуации придало и то обстоятельство, что WPEngine являлся одним из спонсоров WordCamp US, но Мэтт сразу пообещал, что это последний случай такого спонсорства.

Собственно, список претензий к WPEngine не ограничивается низким уровнем отдачи компании в проект — в отдельном посте в блоге Wordpress Мэтт приводит пример того, что Wordpress, предлагаемый WPEngine, выглядит не совсем Wordpress, например, там отключено версионирование записей и включить его можно только через саппорт. Мэтт это считает серьезной проблемой — честно говоря, да, это выглядит как если бы Github хранил историю только на пару коммитов, а для большего предлагал бы писать в поддержку.

Основной проблемой с WPEngine Мэтт счел их инвесторов — компанию Silverlake, — он считает, что WPEngine полностью принадлежит Silverlake, но, скорее всего, у них просто большой, возможно, контрольный пакет акций. Но воспрепятствовать использовать Wordpress в бизнесе WPEngine, конечно, он не может — это открытый продукт и использовать, модифицировать и ничего не контрибутить может любой желающий. Возможно, определенную перспективу имеет юридическая претензия по поводу использования торговых марок.

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

Комьюнити при этом скорее поддерживает Мэтта. Я это вполне понимаю — выглядит действительно не очень справедливо, особенно на фоне большого количества компаний, делающих бизнес на Wordpress, но и делающих свои наработки доступным для комьюнити.

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

Заинтересовавшимся темой использования Wordpress как основы для быстрого фронтенда на модных фреймворках могу посоветовать симпатичную штучку под названием Frontity. Это полноценный движок, который цепляется к Wordpress через существующий REST-API и строит из полученного контента react-приложение — очень быстрое, легкое и приятное.

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

Но если вам не нужны навороченные темы и у вас нет проблемы с пермалинками — попробуйте, будет интересно.

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

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

Основное ощущение касается скорости. Нет, блог вроде не тормозит и ему хватает возможностей хостинга (а если бы не хватало, то увеличить не проблема), но работает небыстро и это в основном результат того, что он работает на том стеке, на котором работает — php+mysql, хоть и с агрессивным кэшированием.

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

Я, впрочем, попробовать еще с месяц назад перенести контент в Ghost — который я помню еще в версии 0.1 и который вроде бы развился во что-то, но был достаточно сильно разочарован. После Wordpress, где информация достаточно хорошо структурирована, в Ghost регулярно встречаются места, где предлагается просто написать вот так, чтобы оно выводилось красиво — это как, знаете, в Word-е секретарши делают шрифт пожирнее и побольше, чтобы получился заголовок, а редактор честно продолжает считать это обычным текстом, а не заголовком. Впрочем, особенно меня удивило отсутствие групповых операций — представьте себе блог с тысячами записей, где любое действие надо делать с одной отдельной записью! Тем более, что первое, что сделал Ghost с контентом — объявил всех пользователей блога, которых Wordpress зарегистрировал как комментаторов (вы и сейчас можете так зарегистрироваться для комментария), просто авторами блога. Таких оказалось несколько десятков и никакого способа выбрать всех и сменить им роли или даже удалить не оказалось. Хотя показатели скорости публичной части прямо радовали, но пришлось отказать.

В результате я решил покопать тему Headless CMS. Упрощенно говоря, это такая конструкция, когда у вас отдельно есть сама CMS, которая управляет созданием и хранением контента, а отдельно — конструкция/фреймворк/генератор, который этот контент собирает в очень быстрый и часто — статический вебсайт и отвечает за его работу. Конструкция очень интересная — во-первых, она действительно красива логически, разделяя контент и его представление, во-вторых, она практически безопасна, поскольку даже критическая уязвимость публичной части вряд ли сможет сказаться на контенте. При этом на выходе получается действительно очень быстрый сайт.

Первая возможность, которую я исследовал, — как бы не отказываться от Wordpress-а и заменить только головную часть блога, которую видят пользователи. Такая возможность есть, поскольку у Wordpress по умолчанию есть Rest API, а с помощью плагина реализуется GraphQL API — пожалуйста, забирайте данные и собирайте из них что хотите.

Я попробовал несколько фреймворков — Next.js, Gatsby и Nuxt, тем более, что это довольно легко сделать с помощью облачных сервисов типа Netlify и Vercel — вы просто берете репозиторий на Github, даете его сервису и он сам собирает из него сайт. Если дать ему статический контент — соберет из него, дать контент через API из Wordpress — терпеливо запросит и соберет из полученного.

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

Так вот, тестирование фреймворков закончилось некоторым разочарованием — получающиеся сайты были действительно быстрыми, но даже на ограниченных данных они строились довольно долго и в любом случае говорить о разумной скорости публикации не удавалось — новый контент отображался примерно минуты через две-три. Возможно, всё было бы быстрее, если не пользоваться готовыми CI/CD сервисами, а собрать свой, но там впереди нарисовалась еще одна проблема — некрасивость.

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

В общем, несмотря на сильное нежелание, я пошел исследовать вторую возможность — перенос всего блога на другую платформу.

Тут особых вариантов не было — если не увлекаться совсем экзотическими форматами, то очевидный выбор — экспортировать блог в набор файлов в формате Markdown и использовать статический генератор типа hugo, который используется у нас на сайте подкаста Радио-Т.

Скрипт, переносящий контент, найти оказалось несложно, впрочем, результат его работы пришлось долго править руками — возможно, тому причиной опять-таки большой архив, причем созданный еще движком под названием «Movable Type», если кто такой помнит. Соорудить сайт на hugo оказалось на удивление несложно — в отличие от JS-фреймворков, у движка большое сообщество и немало прилично выглядящих шаблонов. При этом те же сервисы CI/CD позволяют собирать сайт и на базе hugo — опять же, только укажи им репозиторий и вперед.

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

Впрочем, когда я решил попробовать что-то туда написать, стало еще печальнее. Вы помните, я говорил о богатых возможностях Wordpress — причем, очень большую часть в них занимают возможности редактора. Так вот, практически единственный способ создания текстов в данном случае выглядит так — возьмите текстовый редактор и напишите в нем файл со всеми служебными полями. Есть какое-то количество онлайн-редакторов (на самом деле их примерно два), позволяющих ввести текст и как-то его отправить в репозиторий, но их возможности гораздо беднее нынешнего редактора Wordpress, у них какие-то свои настройки, которые еще где-то лежат и при всём это совершенно не факт, что они заработают. Конечно, в мире больших сайтов есть те самые Headless CMS типа Strapi или Contentful, но они сами по себе или платные, или требуют отдельной установки и это перестает помещаться в рамки персонального блога.

Переходя на статический сайт, возникает еще одна проблема — что делать с комментариями? Они, во-первых, есть за все эти годы, и, во-вторых, я надеюсь, еще будут. Чтобы их как-то включить на статических страницах, требуется использовать что-то типа disqus или даже remark42 от нашего уважаемого Umputun-а. Но это либо еще один комплекс для установки и настройки, либо сторонний сервис. Кроме того, установка disqus моментально роняет скорость загрузки — он сам по себе загружает около 400 кБ библиотек, графики и чего-то еще. И вся затея по оптимизации сайта становится немного бессмысленной.

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

Впрочем, если у вас есть какой-то особенный способ решить те проблемы, которые я описал — делитесь, с удовольствием попробую.