Проект Gutenberg и его возможная функция редактирования всего сайта сталкиваются с серьезной проблемой, которую необходимо решить. Блочные темы будущего в настоящее время находятся на пути к системе шаблонов, которая будет состоять из простых файлов HTML. Хотя это будет работать для большей части вывода темы, проблема состоит в том, чтобы выяснить, как проект будет обрабатывать динамические значения.
Большая часть обсуждения была сосредоточена на обработке URL-адресов, которые, вероятно, являются наиболее распространенным вариантом использования. В настоящее время шаблоны тем содержат всевозможное динамическое содержимое. Большая часть этого будет заменена блоками по мере того, как мы продолжаем двигаться к полному редактированию сайта. Однако не все динамические данные будут иметь блочный эквивалент.
Хорошим примером является то, что авторы темы в настоящее время не могут добавить URL-адрес домашней страницы в блок навигации . Некоторые экспериментальные блочные темы используют простой /символ, указывающий на неправильное местоположение во многих установках WordPress.
Решить эту проблему раньше, чем позже, важно для развития темы в блочном мире. Однако такое решение необходимо тщательно продумать, чтобы тематическое сообщество не увязло на десятилетие и более из-за плохой реализации шаблонов.
Текущие предложения
В репозитории Гутенберга в настоящее время есть открытый билет для обсуждения обработки динамических значений в шаблонах. На данный момент есть четыре предложения, как решить эту проблему.
Замена струн на лету
Одним из решений было бы использование PHP для анализа каждого файла HTML и замены строк, представляющих динамические данные, на лету. Это потребует анализа всех шаблонов темы при каждой загрузке страницы. Обратной стороной является то, что это замедлит загрузку страницы. Нам понадобятся настоящие модульные тесты, чтобы увидеть, какой всплеск времени загрузки создает этот метод.
Предполагая синтаксис, подобный Mustache , шаблоны будут иметь такие значения, как следующий вывод изображения:
<img src=”{{ theme_image_example }}” />
Дополнительным преимуществом принятия такого решения является то, что WordPress может автоматически избегать этих динамических значений по умолчанию. Это будет благом для безопасности темы, что является одной из самых больших проблем, с которыми сталкивается группа проверки темы .
Единовременная замена строки
Второе решение предлагает использовать тот же метод, но один раз проанализировать файлы HTML при активации темы и заменить динамические значения соответствующими значениями. Самым большим преимуществом этого метода является то, что синтаксический анализ не влияет на скорость загрузки внешнего интерфейса.
Этот метод проблематичен, поскольку он не учитывает изменения в шаблонах после первоначального анализа. Он также не обрабатывает сценарии, когда значение изменяется через ввод пользователя. Например, пользователь может решить изменить расположение своей страницы сообщений в блоге. Следовательно, анализируемый URL-адрес, который становится статическим, будет указывать на неправильное местоположение.
Шаблоны как JSON
Третье решение предлагает идею преобразования файлов темы в JSON. Гораздо проще анализировать и извлекать данные из файла JSON, чем из файла HTML. Однако разработчики тем не пишут JSON для создания выходных данных шаблона. HTML существует не просто так.
Это решение поднимет барьер для новых авторов тем настолько высоко, что те, кто только что изучил основы CSS и HTML, вряд ли смогут заняться разработкой тем WordPress. Эта идея настолько чужда идее шаблонного дизайна, что не стоит серьезно рассматривать ее.
Шаблоны, возвращающие блоки через PHP
Четвертое и последнее предложение – использовать файлы PHP с функцией, возвращающей шаблон блока. Этот метод будет простым и легко подойдет существующим авторам тем, знакомым с PHP.
Шаблон будет выглядеть примерно так:
function my_theme_front_page() {
return ‘<!– wp:cover {“url”:”‘ . get_template_directory_uri() .’/block-background-image.png”,”id”:273,”dimRatio”:0,”minHeight”:647,”align”:”wide”} –>’;
}
Эта идея уделяет больше внимания PHP, чем HTML. Это было бы самым простым в реализации решением для команды разработчиков Gutenberg. Однако, как и метод JSON, он поднимет барьер для входа для начинающих авторов темы. Это будет означать, что символы кавычек и двойных кавычек не перепутались. Этот метод подвержен ошибкам и выглядит чуждым современным шаблонам.
Шаблоны должны фокусироваться на HTML
Шаблоны всегда должны быть в первую очередь HTML. Даже в нашей текущей системе тем авторы тем могут создавать красивые, безопасные и функциональные темы, просто зная HTML и CSS. PHP второстепенен, особенно когда речь идет о шаблоне. Наша система шаблонов полагается на знание HTML и включение нескольких тегов шаблонов , которые представляют собой функции PHP, которые WordPress предоставляет для вставки между тегами HTML. Эта простота отчасти и сделала разработку тем WordPress такой простой для всех, кто хочет потратить немного времени.
Темы на основе блоков могут снизить барьер даже ниже, чем наша текущая система шаблонов. Однако шаблоны как функции JSON или PHP противоречат этому. Любое решение, которое отталкивает нас от основных строительных блоков Интернета, HTML, не должно быть предметом обсуждения.
Возможно, пришло время принять подходящий механизм шаблонов PHP. Есть множество примеров. Twig , Blade , Smarty и другие существуют уже много лет. У них также есть некоторый барьер для входа в виде нового синтаксиса, но это не должно быть сложнее, чем научиться вставлять теги шаблонов в текущую систему.
По крайней мере, нам нужно будет найти решение для обработки динамических данных в статических файлах HTML.
