Как мы построили новый дом для WordPress.com Разработчиков, использующих тему Twenty Twenty-Four
Команда WordPress.com недавно перестроила developer.wordpress.com, используя модифицированную версию темы WordPress Twenty Twenty-Four по умолчанию. Вот как они это сделали.
За последние несколько недель наша команда здесь, в WordPress.com, перестроилась с нуля. Если вы создаете или проектируете веб-сайты для других людей, в любом качестве, добавьте этот сайт в закладки. Это ваш новый дом для документации, ресурсов, последних новостей о функциях разработчика и многого другого.
Вместо того чтобы создавать уникальную пользовательскую тему, мы пошли ва-банк, используя тему, которая является темой по умолчанию для всех сайтов WordPress.
Все верно, благодаря сочетанию встроенных функций редактора сайтов и традиционных шаблонов PHP мы смогли создать сайт с нуля, чтобы разместить все наши ресурсы для разработчиков.
Ниже я подробно рассказываю, как наша команда это сделала.
Дочерняя тема Twenty Twenty-Four.
Сайт существует уже много лет, но мы поняли, что он нуждается в капитальном ремонте, чтобы модернизировать внешний вид сайта в соответствии с нашим текущим брендингом, а также адаптировать его.
Вы, вероятно, согласитесь, что сайт нуждался в обновлении; вот как он выглядел две недели назад:
Как только мы решили перепроектировать и перестроить сайт, у нас было два варианта: 1) создать его полностью с нуля или 2) использовать существующую тему.
Мы знали, что хотим использовать, потому что это позволило бы нам легко использовать существующие шаблоны и дало бы нашей команде разработчиков контента наилучший опыт написания и редактирования без необходимости фиксировать код.
Мы рассматривали возможность начать с нуля и использовать. Создание новой темы с нуля – отличный вариант, если вам нужно что-то, адаптированное к вашим конкретным потребностям, но Twenty Twenty-Four уже была близка к тому, что мы хотели, и это дало бы нам преимущество, потому что мы можем наследовать большинство стилей, шаблонов и кода от родительской темы.
Мы быстро определились с подходом к гибридной теме: мы будем использовать редактор сайта как можно чаще, но при необходимости все же вернемся к CSS и классическим шаблонам PHP (например, для нашего пользовательского типа записи в Docs).
Имея это в виду, мы создали минимальную дочернюю тему на основе Twenty Twenty-Four.
Запустите scaffold с помощью @wordpress/create-block
Мы инициализировали нашу новую тему, запустив npx @wordpress/create-block@latest wpcom-developer
.
Это дало нам папку с примерами кода, скриптами сборки и плагином, который загружал пользовательский блок.
Если вам нужен только пользовательский блок (не тема), все готово.
Но мы создаем тему здесь! Давайте поработаем над этим дальше.
Измените настройку на дочернюю тему
Сначала мы удалили wpcom-developer.php
, файл, ответственный за загрузку нашего блока через плагин. Мы также добавили файл functions.php и файл
style.css
, чтобы идентифицировать его как дочернюю тему.
Несмотря на то, что это файл CSS, мы не добавляем никаких стилей в файл style.css
. Вместо этого вы можете подумать об этом там, где Template: twentytwentyfour
указывает, что новая тема, которую мы создаем, является дочерней темой Twenty Twenty-Four.
/*Название темы: wpcom-developerTheme URI: https://developer.wordpress.comDescription: Twenty Двадцать четвертая дочерняя тема для разработчика.WordPress.com Автор: AutomatticAuthor URI: https://automattic.comTemplate: Twentytwentyfour Версия: 1.0.0*/
Мы удалили все демонстрационные файлы из папки “src” и добавили внутрь две папки: одну для CSS и одну для JS, каждая из которых содержит пустой файл, который будет отправной точкой для создания нашего кода.
Структура папок темы теперь выглядела следующим образом:
Скрипты сборки в @wordpress/create-block
могут создавать SCSS/CSS и TS/JS “из коробки”. Он использует Webpack за кулисами и предоставляет стандартную конфигурацию. Мы можем еще больше расширить конфигурацию по умолчанию с помощью пользовательских точек входа и плагинов, добавив наш собственный webpack.config.js
файл.
Делая это, мы можем:
- Создавать специальные выходные файлы для определенных разделов сайта. В нашем случае у нас есть как шаблоны PHP, так и шаблоны редактора сайта как из пользовательского кода, так и из нашей родительской темы Twenty Twenty-Four. Шаблоны редактора сайта требуют минимального (если таковые имеются) пользовательского оформления (благодаря
theme.json
), но в нашей области документации для разработчиков сайта используется пользовательский тип записи и шаблоны страниц, для которых требуется CSS. - Удалите пустые JS-файлы после сборки файлов
*.asset.php
. Без этого для каждого CSS-файла будет сгенерирован пустой JS-файл.
, у нас есть полный контроль над тем, как мы хотим изменить или расширить процесс сборки.
Далее мы установили необходимые пакеты:
путь установки npm webpack-remove-empty-scripts --save-dev
Наш webpack.config.js
в итоге получился похожим на приведенный ниже код. Обратите внимание, что мы просто расширяем defaultConfig
несколькими дополнительными свойствами.
Любые дополнительные точки входа, в нашем случае src/docs
, могут быть добавлены как отдельная запись в объект entry
.
// WordPress webpack config.const defaultConfig = требуется( `@wordpress/scripts/config/webpack.config` );// Plugins.const RemoveEmptyScriptsPlugin = требуется( `webpack-remove-empty-scripts` );// Utilities.const path = требуется( `путь` );// Добавьте любые новые точки входа, расширив webpack config.module.exports = {...defaultConfig,...{запись: {`css/global`: путь.разрешить(process.cwd(), `src/css`, `global.scss` ),`js/index`: путь.разрешить( process.cwd(), `src/js`, `index.js ` ),},плагины: [// Включить конфигурацию плагина WP....defaultConfig.plugins,// Удаляет пустые файлы `.js`, сгенерированные webpack, но// устанавливает их после того, как WP сгенерировал свои `*.asset.php ` file.new RemoveEmptyScriptsPlugin( {этап: RemoveEmptyScriptsPlugin.STAGE_AFTER_PROCESS_PLUGINS} )]}};
В functions.php
мы помещаем в очередь наши встроенные ресурсы и файлы в зависимости от конкретных условий. Например, мы создали отдельные CSS-файлы и поместили их в очередь только для наших документов.
<?phpfunction wpcom_developer_enqueue_styles() : void { wp_enqueue_style( `wpcom-developer-style`, get_stylesheet_directory_uri() . `/build/css/global.css` );}add_action( `wp_enqueue_scripts`, `wpcom_developer_enqueue_styles` );
Нам не нужно было регистрировать файлы стилей из Twenty Twenty-Four, поскольку WordPress обрабатывает их встроенно.
Нам действительно нужно было поставить в очередь стили для наших классических шаблонов, не относящихся к редактору сайта (в случае нашего), или любые дополнительные стили, которые мы хотели добавить поверх стилей редактора сайта.
Чтобы создать рабочие JS и CSS локально, мы запускаем npm run build
.
Для локальной разработки вы можете запустить npm run start
в одном окне терминала и npx wp-env start
() в другом, чтобы запустить локальный сервер разработки WordPress, на котором запущена ваша тема.
При создании этого сайта наша команда дизайнеров, разработчиков и авторов контента использовала такие методы, чтобы изменения не влияли на существующий сайт до тех пор, пока мы не будем готовы запустить эту новую тему.
theme.json
Twenty Twenty-Four имеет всеобъемлющую тему.файл json
, определяющий его стили. По умолчанию наша гибридная тема наследует все определения стилей от родительской темы (Двадцать двадцать четыре).файл json
.
Мы выборочно переписали те части, которые хотели изменить (цветовую палитру, шрифты и другие элементы бренда), оставив остальное загружаться из родительской темы.
WordPress обрабатывает это слияние, а также любые изменения, которые вы вносите в редакторе.
Многие стили по умолчанию нам подходили, и в итоге мы получили компактную тему.файл json
, который определяет цвета, шрифты и градиенты. Наличие темы.файл json
упрощает просмотр ссылок на цвета.
Вы можете изменить тему.json
в вашем любимом редакторе кода или вы можете изменить его непосредственно в редакторе WordPress и .
Почему вы можете захотеть экспортировать изменения, внесенные в редактор? Затем стили можно перенести обратно в код, чтобы убедиться, что они совпадают, и упростить распространение вашей темы или ее перенос с локального сайта разработки на рабочий сайт. Это гарантирует, что шаблоны страниц редактора сайта сохраняются в коде с контролем версий.
Когда мы запустили эту новую тему в производство, файлы шаблонов загрузились из нашего каталога тем; нам не нужно было импортировать записи базы данных, содержащие синтаксис шаблона или глобальные стили.
Глобальные стили в SCSS/CSS
Глобальные стили добавляются как переменные CSS, и на них можно ссылаться в CSS. Изменение значения в теме.json
также будет.
Например, вот как мы ссылаемся на наш “контрастный” цвет в качестве цвета границы:
border-color: var(--wp--preset--color--contrast);
Как насчет header.php
и footer.php
?
Некоторым плагинам требуются эти файлы в теме, например, при вызове функции get_header()
, которая автоматически не загружает шаблон заголовка редактора сайта.
Мы не хотели воссоздавать наш верхний и нижний колонтитулы, чтобы охватить эти случаи; иметь только один источник достоверности намного лучше.
Используя do_blocks()
, мы смогли отобразить необходимый нам блок заголовка.