В WordPress 5.8 была введена система выбора опций для тем, позволяющая настраивать параметры блоков, стили, шаблоны и т. д. Делается это с помощью нового файла theme.json, который разработчики могут помещать в корень своих папок с темами. Энн МакКарти, руководитель программы FSE Outreach Program, опубликовала опрос для получения отзывов разработчиков о данной возможности.
«Поскольку этот механизм является первым шагом на пути к общей системе стилей в WordPress, важно услышать мнение всех, кто в настоящее время пользуется theme.json. Нам надо знать, как люди работают с этим инструментом, что еще можно включить в ядро в будущем», – отметила Энн в анонсе.
Опрос открыт для всех авторов тем, которые пользовались theme.json. Это поможет собрать воедино все отзывы и пустить разработку в правильном направлении.
Я много работал с этой системой за последние несколько месяцев, а потому мне было что сказать. Да и в целом мне нравится участвовать в опросах, связанных с WordPress. Заодно я смог поделиться своими мыслями по поводу текущего состояния theme.json с точки зрения разработки.
Ниже приведены мои ответы на вопросы анкеты.
Примечание: пост ориентирован на разработчиков. Простым читателям он может не зайти, поскольку от них потребуется понимание некоторых аспектов разработки тем. В посте ведется повествование от лица Джастина Тэдлока.
Опыт разработчика
Первый вопрос достаточно простой. Каков ваш опыт работы с блочными темами и theme.json. Есть четыре варианта ответа (и вариант «другое»):
- Я создавал и запускал блочные темы.
- Я экспериментировал с разработкой блочных тем.
- Я использовал theme.json в классических темах.
- Я использовал блочные темы, но не сталкивался с их разработкой.
Я выбрал первый вариант, потому что я уже создавал ранее блочные темы для семьи и друзей. Это были простые личные сайты, которые я поддерживаю бесплатно – вообще надо бы уже начинать брать плату за это. Также я работаю над темой, которую хочу опубликовать в будущем.
Начало использования theme.json и блочных тем
Второй вопрос связан с тем, как вы начали работать с блочными темами и theme.json. Тут можно выбрать пункты: форк существующей темы, использование пустой темы Empty Theme или написание темы с нуля.
Опять же, я экспериментировал по всем направлениям, а потому не могу вспомнить, с чего я начал. Больше всего времени я провел над форком темы, и последний раз это было в 2019 году.
Я планирую выпустить ее бесплатно когда-нибудь в будущем. В основном мои ожидания следующие:
- Финальная проработка блока Navigation.
- Разбиение блока Post Author на более мелкие блоки.
- Надежный набор блоков, связанных с комментариями.
- Блок Post Featured Image с опцией выбора размера изображения.
Если бы эти вопросы были решены, я бы выпустил бета-версию своей темы уже сегодня.
Шаблоны и участки шаблонов
В ходе анкетирования задавался вопрос, какие шаблоны и участки шаблонов вы всегда добавляете в свои блочные темы.
На данный момент у меня неоднозначное отношение к блочным шаблонам. Статичная природа HTML-шаблонов напоминает мне о тех временах, когда разработка тем была менее сложной. Однако и в динамической системе проблема тоже остается.
Я не помню, когда я последний раз создавал тему на базе PHP с более чем одним шаблоном верхнего уровня: index.php. Динамические участки всегда находились внутри шаблонов. С помощью PHP можно легко задать некоторую переменную или использовать вызов функции для контекстной загрузки участков шаблонов, требуемых для той страницы, которую пользователь просматривает в данный момент.
Система блочных шаблонов так не работает. Получается, разработчики должны отказаться от принципа Don’t Repeat Yourself (DRY).
К примеру, если дизайнер раньше хотел вывести разные участки хэдера для записей и страниц, ему надо было создать только шаблон header-page.php или header-post.php в традиционных темах. Но поскольку система блочных шаблонов отличается, теперь дизайнерам надо создавать уже два шаблона верхнего уровня, single.html (для записи) и page.html, для достижения той же самой цели.
И это плохо, потому что разработчикам тем нужно дублировать весь код в каждом из шаблонов верхнего уровня. Невозможно контекстно загружать разные участки шаблонов.
Мой ответ на начальный вопрос: я использую практически все возможные шаблоны верхнего уровня по необходимости.
Я также ответил на вторую часть вопроса и перечислил наиболее часто используемые мною участки шаблонов (с разбивкой по иерархии):
- Header
- Content
- – Loop
- – Sidebar
- Footer
Определение цветов
В следующем разделе задается вопрос, как авторы тем определяют слаги цветовой палитры в theme.json. Вы не поверите, но наименование цветов – это «горячая точка» в мире тем за последние годы. Разработчики обычно сходятся в названии background и foreground цветов.
В 2018 году Мортен Рэнд-Хендриксен открыл тикет по поводу стандартизации схемы наименования цветов. Это было далеко не первое обсуждение и не последнее. Проблема, поднятая в тикете, заключалась в слагах для цветов в системе (особенности задания палитр цветов в темах). Как только пользователь выбирает предустановленный цвет, слаг тут же прописывается в коде. Достаточно переключиться на другую тему с другими слагами – и старые цвета исчезнут. Автоматического перехода на цвета новой темы не произойдет.
Я использую семантические имена, которые чем-то напоминают систему, принятую в Tailwind CSS-фреймворке. Вместо red-medium (дескриптивное имя) я использую primary-500 (семантическое имя). Семантический подход позволяет авторам тем определять набор цветов, которые будут обновляться всякий раз при переключении темы пользователем.
Естественно, имеются и другие подходы. Даже разработчики, предпочитающие семантическое наименование, не всегда согласны с той же системой. Я описал свой подход более подробно в свежем GitHub-тикете. Также у меня есть theme.json Gist для тех, кто хочет все это попробовать.
Другие настройки JSON
В опросе есть пункт: какие еще настройки используют разработчики тем (помимо цветов и типографики)? Обычно здесь я отвечаю, что использую все доступные параметры и опции.
Одна из настроек, для которой в данный момент нет предустановок в WordPress – это глобальные отступы (spacing). Большинство авторов тем обычно используют одно значение для всех вертикальных полей (отступы между блоками и элементами). Часто задаются базовые вертикальные и горизонтальные отступы (padding).
Я не уверен в том, нужен ли мне такой пресет, поскольку я не знаю, как он будет применяться в WordPress. Но другие разработчики часто об этом спрашивают. Привязка всей системы к этому глобальному значению вызовет определенную головную боль для разработчиков в будущем. Однако я все же хотел бы видеть дискуссию по поводу реализации хотя бы стандартного пресета для глобальных отступов.
Параметры и стили для каждого отдельного блока
В этом разделе был задан простой вопрос с ответом «да/нет»: включили ли авторы тем параметры или стили для отдельных блоков в свои файлы theme.json? Я решил поделиться своими мыслями в поле комментариев чуть ниже.
Система мне в целом нравится, особенно когда дело доходит до параметров, позволяющих разработчикам задавать, какие функции будут включены глобально или для отдельных блоков. Однако мне не требуется добавление стилей через theme.json.
Указание CSS в JSON, на мой взгляд, является неправильным. В настоящий момент можно задавать только несколько настраиваемых стилей, а потому все, что выходит за рамки этого, нужно будет все равно прописывать в CSS-файле. Здесь мы видим проблему: CSS-код темы разбит на theme.json и отдельные CSS-файлы. Это затрудняет поддержание кодовой базы.
Изначально я пробовал настраивать стили для блоков и элементов через theme.json. Но потом я вернулся обратно к заданию стилей через CSS-файлы. Это выглядит более естественным, плюс у меня есть бонус в виде понятных мне инструментов. Прямо сейчас я не могу представить себе ситуацию, когда бы я захотел вернуться к стилям в theme.json.
Помимо экономии нескольких байтов кода, я не увидел особых преимуществ в добавлении стилей через JSON. Возможно, что-то изменится в будущем, и я поменяю свое мнение. Но сейчас я решил придерживаться CSS.
Другие отзывы: уровень PHP
Я уже говорил об этом ранее, но повторю еще раз. Нам нужен уровень PHP для системы конфигурирования theme.json. Уже сейчас есть открытый тикет для данной проблемы.
У такой системы будет два основных преимущества. Наличие PHP API для связывания воедино конфигурации будет более естественным шагом для разработчиков традиционных тем. Это станет демонстрацией доброй воли со стороны разработчиков ядра/Gutenberg, ведь в таком случае авторам тем будет гораздо проще освоить функционал FSE при помощи уже знакомого языка программирования.
Второе преимущество: появится много плагинов для расширения глобальных стилей, редактирования сайта и т. д. Достаточно предложить простой способ сцепления с системой JSON в темах. Можно внедрить простой фильтр, чтобы существенно облегчить жизнь разработчикам.
Источник: wptavern.com
Вчера каталог паттернов WordPress стал доступен для всего мирового сообщества. Команда разработчиков внесла в него последние штрихи. Со временем он будет функционировать аналогично каталогам плагинов и тем. В WordPress 5.8 пользователи могут просматривать и использовать паттерны блоков прямо из редактора записей.
Официально каталог паттернов является частью релиза WordPress 5.8. Однако вчера мы не стали включать его в обзор, поскольку на момент выхода WP он имел пометку «в разработке». Команда все еще вносила мелкие правки.
На данный момент в каталоге представлен курируемый список паттернов от более 20 волонтеров. Команда просила сообщество принять участие в разработке паттернов еще в июне, и сообщество не замедлило ответить. Сегодня доступно более 70 паттернов в разных категориях:
- Buttons
- Columns
- Gallery
- Header
- Images
- Text
На данный момент выполнены переводы на 12 языков. Остальные пока еще подтягиваются. Если вы хотите помочь проекту WordPress, вы можете внести свой вклад в переводы.
Джастин Тэдлок приложил свою руку к разработке паттернов About Me Cards и Team Social Cards. Его идеи были в дальнейшем реализованы Кьеллом Рейгстадом и Мэл Чойс-Дуэн.
На следующем этапе проекта возможность добавления паттернов появится у всех разработчиков.
«Мы начинаем работу над следующим майлстоуном, который позволит всем разработчикам загружать свои паттерны, как это сделано сейчас на примере каталогов тем и плагинов», – рассказала Келли Чойс-Дуэн в анонсе.
Я рад тому, что все сообщество сможет подавать свои предложения в каталог. Представленные материалы были сильно ограничены и основывались на определенной эстетике, которую сложно назвать универсальной. Меня не вдохновляют многие паттерны, поскольку они не соответствуют моему персональному стилю. Некоторым пользователям будет сложно представить, как тот или иной макет будет выглядеть у них на сайте.
У каталога паттернов есть один недостаток. Очень сложно найти фотографии или иллюстрации, которые соответствовали бы рекомендациям по добавлению в каталог WordPress.org. У сервисов, таких как Unsplash, Pexels, Pixabay, есть ограничения на лицензирование изображений. Возможно, проблема чуть сгладится посредством потенциальной интеграции с Openverse, бывшей поисковой системы Creative Commons.
Я с нетерпением жду, когда лучшие дизайнеры WordPress смогут загружать свои паттерны в каталог. В итоге он станет в разы интереснее и разнообразнее.
Источник: wptavern.com
Компания Automattic приобрела Pocket Casts, популярное приложение для прослушивания и поиска подкастов на Android и iOS. Австралийские соучредители Рассел Иванович (Russell Ivanovic) и Филип Симпсон (Philip Simpson) продолжат возглавлять Pocket Casts в рамках сделки по приобретению.
Приложение позволяет пользователям централизованно хранить все свои подписки на подкасты и синхронизировать их между платформами. Приложение Pocket Casts, ранее предназначавшееся только для коммерческих целей, стало бесплатным с сентября 2019 года, когда разработчики решили перейти на модель распространения freemium. Монетизация Pocket Casts осуществляется через Plus-тариф, который дает пользователям доступ к десктопным приложениям, облачному хранилищу, повторному воспроизведению подкастов, а также к темам и иконкам всего за $9.99/год.
В мае 2018 года Pocket Casts был приобретен общественными медиа-организациями NPR, WNYC Studios, WBEZ Chicago и This American Life. Небольшой долей также владела BBC Studios до приобретения Automattic.
Несмотря на то, что Pocket Casts называли одним из лучших приложений для подкастинга, финансовые отчеты и аудиты компании NPR за 2020 год показали чистый убыток в $800K. Управляющий состав компании собрался в декабре 2020 года и принял решение продать Pocket Casts.
Финансовые подробности сделки не разглашались. Понятно, что Automattic смогла бы заключить сделку только в том случае, если и другие компании с долями в приложении тоже несли убытки. В результате покупки Tumblr и Day One компания Automattic приобрела репутацию скупщика приложений, которые нравятся пользователям, в результате чего у этих приложений появляется шанс на финансовую стабильность и перспективное развитие. Automattic демонстрирует интерес к технологиям, связанным с подкастингом – достаточно вспомнить недавние инвестиции в Castos и партнерство с платформой Anchor от Spotify.
Объявления о покупке сервисов/приложений обычно содержат заверения о том, что для текущих клиентов никаких изменений не будет. Однако в анонсе Automattic таких обещаний не содержалось. Да и особых деталей касательно планов в отношении Pocket Casts не было. Возможно, в ближайшем будущем появится интеграция с WordPress.com (но пока разрабатывается).
«Как часть Automattic, Pocket Casts продолжит предлагать вам функционал, который требуется для прослушивания ваших любимых подкастов (или поиска чего-то нового)», – отметила Эли Баделли (Eli Budelli), глава подразделения приложений Automattic. – «Мы рассмотрим возможность создания тесной интеграции между WordPress.com и Pocket Casts, чтобы упростить распространение и прослушивание подкастов. Мы очень рады тому, что можем и дальше предлагать нашим пользователям множество способов взаимодействия с историями».
Источник: wptavern.com