Тематика WordPress имеет богатую историю. За прошедшие годы авторы тем внесли в платформу множество функций. Отчасти потому, что им часто приходилось решать фундаментальные проблемы с WordPress, чтобы создать функции, которые нужны конечным пользователям.
Классы постов и тела, которые сегодня используют все авторы тем? Изначально они были в теме под названием Sandbox.
Избранные изображения? Их популяризировали журнальные темы десять лет назад.
Вы думаете, что форматы сообщений возникли в Tumblr? Мэтт Мулленвег, соавтор WordPress, научил нас, как создавать дополнительные посты в наших темах в 2004 году, но они существовали и до этого.
Функции WordPress часто берут свое начало в мире тем. Иногда мы принимаем как должное годы экспериментов и итераций над идеями, над которыми авторы тем работают. Даже редактор блоков обрабатывает элементы, которые традиционно входили в сферу дизайна тем. Блок крышки – хороший тому пример. В течение многих лет авторы темы создавали варианты темы для основного изображения героя с наложенным текстом и кнопками. Результат часто был неуклюжим и не идеальным для пользователей. Внедрение этой функции в ядро предоставило пользователям возможность помещать этот защитный блок в любую разрешенную область блокировки.
Причина, по которой многие функции темы становятся ядром, заключается в том, что они просто работают лучше, когда они стандартизированы. Пользователи знают, чего ожидать, и авторы тем могут сосредоточиться на аспекте дизайна, а не на решении проблемы взаимодействия с пользователем.
Отчасти проблема прошлого заключалась в том, что каждая новая функция, принятая в ядро, не соответствовала никакому стандартному шаблону проектирования или схеме именования. Огромный навык в разработке тем WordPress заключается в том, чтобы запомнить мешанину из сотен классов.
Редактор блоков имеет уникальную возможность изменить это, создав универсальную структуру дизайна.
Нужен ли WordPress фреймворк для фронтенд-дизайна?
С появлением блочных шаблонов в будущем и полной настройкой сайта в какой-то момент после этого авторы темы задаются вопросом, где именно плывет этот корабль. Это интересно, потому что возможности безграничны для конечных пользователей. Это пугает авторов тем, которые построили свои империи на одном способе ведения дел, но разработка – это скорее адаптация, чем что-либо еще.
Вооруженные предвидением того, что ландшафт меняется, это момент, когда авторам тем необходимо объединиться, чтобы сформировать свое будущее в мире, основанном на блоках.
В одной из групп разработчиков, в которую я вовлечен, ходят шутки, что основные разработчики не являются авторами тем. С точки зрения автора темы, иногда может показаться, что идеи были случайно собраны вместе, не думая о системах дизайна CSS.
О, я вижу БЭМ. Почему этот подэлемент не соответствует той же схеме именования? Подождите. Это служебный класс из 38 символов?
Чего всегда не хватало WordPress, так это универсальной системы фронтенд-дизайна. Иногда это было хорошо. Это позволило авторам тем использовать предпочитаемую ими структуру. Любой автор темы, который проработал в игре достаточно долго, скажет вам, что такая гибкость – это здорово… пока это не так . Вы когда-нибудь пробовали добавлять в виджеты контекстные классы? А как насчет добавления служебного класса в оболочку формы комментариев? Вам понадобится аспирин. Или два.
В WordPress некоторые вещи высечены в камне, а другие можно подключить. Некоторые функции следуют стандартной схеме именования классов, а другие не имеют смысла. Результатом для тем часто является раздутый CSS в попытке разобраться в различных компонентах.
Практически невозможно полностью использовать фреймворк служебного класса, такой как Tailwind CSS, в теме без воссоздания основных функций.
Во многом это связано с годами накопления устаревшего кода и приверженностью WordPress обратной совместимости. Но будущее не обязательно должно напоминать прошлое. Мы находимся на пороге новой эры, и сейчас самое время для фронтенд-дизайнеров вступить в разговор.
WordPress нужен прочный фреймворк для внешнего дизайна.
Это загруженное заявление. Если вы поместите 20 дизайнеров в комнату и попросите их обсудить рамки дизайна, это может быть рецептом кулачных схваток. Я склонен быть оптимистом и надеюсь, что дискуссия принесла результаты.
Гутенберг частично подтолкнул нас в этом направлении, но этого недостаточно. При полном редактировании сайта в будущем потребуется более целостный подход к решению этой проблемы.
Больше всего нам нужно, чтобы в диалоге участвовало больше фронтенд-дизайнеров. Там нет никакого способа , .has-subtle-pale-green-background-color должно существовать как класс полезности над чем – то , как .bg-pale-green, .bg-green-100 или даже .background-pale-green, если вы хотите быть более многословным. В этом решении не было концепции оптимизации. В то время, когда разработчики используют гигабитные интернет-соединения, легко забыть, что большая часть мира следит за ними более медленными темпами.
Схема именования на основе компонентов со здоровой дозой служебных классов – это один из вариантов, который может поразить несколько слабых мест. Это не аргумент в пользу одной CSS-структуры перед другой. Есть много хороших существующих вариантов. WordPress должен решить эту проблему, заимствуя основы, заложенные другими проектами, и создавая нечто уникальное для WordPress. Он должен быть лидером в своей области.
Фреймворки дизайна – это также плагины. Есть некоторый переход в царство тем, где двое ведут непрекращающуюся войну с момента зарождения системы тем. Поле битвы между темами и плагинами усеяно смертями хороших идей. Слишком многие так и не получили поддержки, необходимой им для того, чтобы приземлиться в ядре. Какой-то универсальный стандарт дизайна может остановить поток проблем и призвать к прекращению огня.
Плагин, который выводит пользовательский интерфейсный компонент, не может, например, узнать, как текущая тема обрабатывает вертикальный ритм. Используется ли верхнее или нижнее поле? Какая величина и единица измерения используются? Это фундаментальный материал, и он почти всегда ломается, когда плагин пытается добавить собственный CSS для его обработки.
WordPress нужен фреймворк или язык дизайна, который позволяет всем его движущимся частям гармонично сочетаться во внешнем интерфейсе. Я уверен, что в какой-то момент мы туда доберемся. Я надеюсь, что это более связно, чем случайные компоненты и схемы именования прошлого. У нас также должна быть четкая дорожная карта, которая заполняет некоторые технические детали, чтобы разработчики и дизайнеры могли быть готовы.
Возможно ли будущее с одной темой?
Рич Табор в своей статье «Взгляд на темы WordPress будущего» утверждает, что ядро WordPress может предоставить единую родительскую тему . Идея состоит в том, чтобы авторы темы создавали дочернюю тему для этой «основной» темы.
Инстинктивная реакция многих была бы такова, что это не сработает, темы потеряют свою индивидуальность, и мы будем жить в мире дизайнов печенья.
Реальность такова, что мы мчимся к будущему, в котором идея единственного родителя или главной темы будет серьезным предметом рассмотрения.
Большинство тем – это настраиваемые группы стандартных элементов, которые существуют почти во всех темах. Помимо стилистических соображений, есть некоторые решения, которые отличают темы друг от друга, например, макет заголовка. Одна тема может содержать заголовок сайта и навигационное меню в одном блоке. У другого может быть навигационное меню, заголовок и второе навигационное меню ниже. Тем не менее, в другой теме может отображаться поле поиска. В мире, где полная настройка сайта принадлежит пользователю, эти решения становятся частью опыта пользователя, а не опыта разработчика.
Темы должны будут выделяться цветовыми палитрами, типографикой и собственной необычностью – возвращение времен CSS Zen Garden, но в гораздо большем масштабе.
Я не буду об этом грустить. Было бы интересно увидеть конкуренцию между ведущими дизайнерами в этой области. Это также может вернуть тематику WordPress в ту эпоху, когда любой мог сделать это с небольшими знаниями и решимостью CSS.
Хотя мы еще не совсем готовы к будущему, в котором одна тема будет управлять всеми темами, это место для начала разговора. Если бы мы разработали WordPress для этого потенциального будущего, даже если бы мы никогда не реализовали основную тему, как бы выглядела дорожная карта? Какие препятствия стоят на пути? Насколько это возможно?
