Когда я впервые начал думать о шаблонах в WordPress, я думал о двух аспектах:
- контент специально для участников ,
- контент, который можно разбить на один пост.
Но чем больше я думал об этом, тем больше я понимал, что это можно (и, возможно, нужно) объяснить в течение нескольких постов.
Итак, я расскажу о текущем состоянии шаблонов WordPress, а затем о практических способах организации, скажем, наших плагинов, чтобы мы использовали стандартный PHP.
После этого в следующих сериях я рассмотрю, что означает использование других шаблонизаторов (как PHP, так и JavaScript в нашей работе).
Однако для начала я хочу взглянуть, как часто мы видим шаблоны, написанные в контексте как тем WordPress, так и плагинов.
Шаблоны WordPress для начинающих
В зависимости от вашего опыта работы с WordPress и другими системами на основе PHP, ваше определение шаблонов может отличаться от чьего-то другого.
Итак, чтобы попытаться создать общее определение, которое я буду использовать в этой серии постов, я буду использовать Кодекс WordPress:
Шаблоны — это файлы, которые управляют тем, как ваш сайт WordPress будет отображаться в Интернете.
Далее на странице рассказывается о том, как это работает в сочетании с базой данных и другими активами, и я рекомендую прочитать об этом, если вы не знакомы с этим.
Тем не менее, приведенное выше определение хорошо подходит для того, как я планирую двигаться вперед, думая об этом.
1 Как это есть (прямо сейчас)
Когда дело доходит до размышлений о шаблонах WordPress, я думаю, что полезно рассмотреть один шаблон с кодом, который выглядит примерно так:
<div id="content-container">
<p>
Oh! The garbage chute was a really wonderful idea. What an incredible smell you've discovered! Let's get out of here!
Get away from there... No! wait! Will you forget it? I already tried it. It's magnetically sealed! Put that
thing away! You're going to get us all killed.
</p>
<h2>List of Post Titles For Acme Post Type</h2>
<?php
$args = array(
'post_status' => 'publish',
'post_type' => 'acme',
'posts_per_page' => '10'
);
$custom_query = new WP_Query( $args );
if ($custom_query->have_posts()) {
echo '<ul>';
while ($custom_query->have_posts()) {
$custom_query->the_post();
echo '<li>'. get_the_title(). '</li>';
}
echo '</ul>';
wp_reset_postdata();
}
?>
<p>
Absolutely, Your Worship. Look, I had everything under control until you led us down here. You know, it's not
going to take them long to figure out what happened to us. It could be worst... It's worst.
There's something alive in here! That's your imagination. Something just moves past my leg!
Look! Did you see that? What? Help!
</p>
</div><!-- #content-container -->Суть приведенного выше кода в том, что вы видите, что он смешивает PHP и HTML.
Кроме того, важно отметить, что каждый из этих файлов оформлен с использованием CSS и может иметь дополнительное поведение, управляемое с помощью JavaScript. С этой целью вы можете концептуализировать это следующим образом:
Это представляет собой единый шаблон, объединяющий HTML и PHP в единый шаблон. Затем этот шаблон оформляется с помощью CSS и управляется с помощью JavaScript.
Все они работают вместе, чтобы обеспечить то, что видит пользователь.
2 Влияет ли организация разработчиков на производительность?
Но то, как это работает, немного запутано, и хотя это может выглядеть хорошо для пользователя, это вызывает некоторые вопросы:
- Является ли он настолько производительным, насколько мог бы быть?
- Насколько легко разработчику поддерживать?
- Каков процесс сборки?
- как активы поддерживаются и организованы?
Конечно, большая часть того, что вы читаете выше, очень ориентирована на разработчиков, но я считаю, что когда код организован таким образом, чтобы разработчикам было легко с ним работать, он часто может быть еще проще для пользователя.
Что это значит?
- Представляем Sass?
- Минимизируем ли мы JavaScript?
- Как нам объединить эти активы и импортировать их?
- Как насчет пользовательских запросов PHP, которые выполняются в контексте каждого шаблона?
И хотя первые вещи важны и того стоят (и я могу рассказать об этом в серии), отделение логики внутри шаблона даже без механизма шаблонов может помочь сделать код более ориентированным на разработчика.
Ускоряет ли это работу пользователя? Не обязательно. Но это помогает нам сделать первый шаг к этому.
Давайте реорганизоваться
В следующем посте этой серии я разберу контент, который мы привыкли видеть в шаблонах WordPress, на примере и начну его реорганизацию, чтобы лучше организовать его таким образом, чтобы методы можно было использовать в разных проектах.
Это означает перемещение вещей в их функции (или даже в их классы и, следовательно, их функции) и то, как мы можем вызывать их из контекста наших шаблонов.
В конечном счете, это приведет к тому, что код будет легче читать, лучше разделять обязанности и подтолкнет нас к способам изменения того, как данные вводятся в шаблон.