Недостатки монолитных систем управления контентом на примере WordPress

Ваш контент слишком важен, чтобы его можно было оставить в системе, разработанной для управления блогами более двадцати лет назад. Посмотрим на 5 основных недостатков WordPress как контент-решения в эпоху микросервисов и омниканальности.

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

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

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

WordPress не создан для современной эпохи модульной архитектуры

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

Мы больше не просто создаем веб-сайты, мы создаем цифровой опыт.

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

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

Ожидания от инструментов изменились

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

Они ожидают, что смогут поставлять контент быстрее и надежнее благодаря инструментам, обеспечивающим непрерывную доставку и интеграцию (CD/CI). Они хотят использовать специализированные решения для решения сложных проблем, таких как глобальная масштабируемость и повторное использование контента в разных контекстах.

Эти сервисы и API предоставляют абстракции, которые позволяют вашим разработчикам сосредоточиться на технических задачах, характерных для ваших целей и бизнеса, и повысить ценность. Более того, сегодня разработчики стремятся получить отличный опыт разработки. Они хотят получать удовольствие и чувствовать себя хорошо от технологии, которую используют (не так ли?).

Многоуровневые API и плагины не решают основные проблемы

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

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

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

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

WordPress имеет открытый исходный код, но не бесплатен

WordPress в значительной степени позиционирует себя как открытый исходный код. Но означает ли это, что это бесплатно (как с точки зрения стоимости, так и времени, которое вы должны потратить)?

Не совсем. Вы действительно можете получить доступ к исходному коду WordPress и изменить его, чтобы использовать его (почти) для всего, что захотите. Однако, чтобы следить за обновлениями, вам также необходимо поддерживать совместимость своей собственной «вилки» и гарантировать, что ваши настройки не нарушатся, что приведет к дополнительному обслуживанию.

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

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

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

Функциональность становится товаром

Многие люди расскажут о возможности расширения WordPress с помощью плагинов. Если вы хотите выйти за рамки простого блога, вам необходимо установить такие плагины, как Jetpack, Yoast SEO, Imagify, WP Rocket и Advanced Custom Fields. Или вы можете установить приложения для создания страниц, такие как Elementor и Divi, которые заменяют инструменты создания контента WordPress. Эти плагины коммерциализированы, поэтому за функциональность вам придется платить разным поставщикам.

Итак, чем это отличается от составных архитектур? В WordPress вы платите за плагины, привязанные к одной CMS и определенному количеству сайтов. Используя модульный стек, вы платите за API-интерфейсы, которые можно использовать во многих приложениях и платформах, предоставляя вам гибкость, необходимую в эпоху компоновки.

WordPress относится к вашему контенту так, как будто сейчас 2003 год

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

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

Контент заблокирован

Но WordPress блокирует ваш контент, что затрудняет его повторное использование, перепрофилирование или переход на другую платформу. Это связано с технологическими решениями, принятыми более 20 лет назад:

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

Нет гибкости для разных представлений

WordPress изначально завоевал популярность среди создателей контента, потому что он давал вам возможность публиковать сообщения в блогах без написания (слишком большого количества) HTML. Вы можете напечатать сообщение в блоге в обычном текстовом редакторе, нажать «Опубликовать» и увидеть его в Интернете. Позже вы также сможете просмотреть контент, чтобы увидеть, как он будет выглядеть, прежде чем поделиться им со всем миром.

С запуском редактора блоков WordPress What-You-See-Is-What-You-Get (WYSIWYG) Gutenberg основной продукт добился успехов в превращении в конструктор страниц, в качестве которого люди начали его использовать. Это означает, что пользовательский интерфейс дает вам больше контроля над тем, как контент визуально представлен на веб-сайте. Интересно, что, судя по официальным данным WordPress по активным плагинам, классический редактор по-прежнему используется более чем на 5 миллионах сайтов.

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

Обновление дизайна вашего веб-сайта с использованием только возможностей тем WordPress становится сложнее, если вы используете Gutenberg или другие дополнения к визуальным плагинам, такие как Elementor, потому что ваш контент изобилует разметкой, специфичной для дизайна. И кому-то придется потратить время на его очистку, если вы хотите представить его в другом месте или дизайне.

WordPress не поддерживает совместную работу

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

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

…между создателями контента

Использовали ли вы когда-нибудь современные инструменты для совместной работы, такие как Google Docs, Notion, Figma или Miro? Если да, то вы, вероятно, привыкли работать над контентом в одном и том же месте одновременно с несколькими другими людьми.

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

Более того, система версий WordPress очень элементарна: вы не можете отменить отдельные изменения, вы не получаете детальной информации о том, кто и что изменил, и это заставляет создателей контента читать и сравнивать HTML-код, чтобы увидеть, что изменилось. Это становится неоправданно сложно, когда HTML перегружен специальным кодом для представления и макета.

…между создателями контента и разработчиками

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

И наоборот, когда технологии ставят во главу угла отличный опыт разработчиков, команды с большей вероятностью скажут: «Да, конечно!» к запросам и доставлять их быстро. К сожалению, опыт разработчиков WordPress не поспевает за развитием событий, которые мы наблюдали за последние 10 лет.

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

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

…между дизайнерами, создателями контента и разработчиками

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

Этот подход к проектированию хорошо сочетается со средами разработки, построенными на идее составления компонентов и интеграции контента из API. React, Vue, Next.js, Angular и другие — популярные веб-технологии, созданные для того, чтобы позволить разработчикам повторно использовать визуальные компоненты в веб-приложениях и между ними.

У этих фреймворков есть кое-что общее: они лучше всего работают с контентом, структурированным в виде данных. Когда базовой структурой является HTML — формат, в котором WordPress сохраняет свой контент, — гораздо более вероятно, что будет введен произвольный код, что затрудняет интеграцию с другими системами.

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

…между создателями контента и интеграциями

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

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

WordPress всем знаком, но это не значит, что он удобен для пользователя

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

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

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

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

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

Переходим от WordPress

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

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

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