Мы постоянно улучшаем производительность нашего кода и отслеживаем загрузку каждой страницы, чтобы оптимизировать время загрузки и рендеринга на наших сайтах.
Принимая во внимание вышесказанное, я наткнулся на вопрос, где мы должны отображать рендеринг массивов?
Если вы визуализируете их в своем препроцессоре, шаблон остается довольно аккуратным, поскольку вы печатаете только переменные.
Препроцессор:
function template_preprocess_node__faq(&$variables) {
$node = node_load($variables['nid']);
$node_style = node_view($node, $variables['view_mode']);
$faq_sets = array(
'#theme' => 'my_module_faq_set',
'#sets' => $variables['field_faq_set'],
);
$variables['faq_image'] = render($node_style['field_faq_image']);
}
Шаблон:
<div class="faq_image">
<?php print $faq_image; ?>
</div>
Тем не менее, я не уверен, что это правильный / быстрый / удобный способ предварительной обработки и печати переменных.
Думаю, Drupal не состоит в этом вопросе ... node.tpl.php
Переменные по умолчанию отображаются, в то время как в других шаблонах по умолчанию (например html.php.php
) переменные просто печатаются.
У кого-нибудь есть правило и / или несколько советов и советов о том, как решить эту проблему самым чистым и быстрым способом?
источник
node_view()
для визуализации поля; поля не отображаются таким образом в шаблоне узла.node.tpl.php
и печать вhtml.tpl.php
? Как бы вы решили этуnode_view()
проблему?Ответы:
Это не совсем верно. Если вы посмотрите на,
template_preprocess_html()
вы увидите, что ничего не проходит черезrender()
/drupal_render()
. Так что довольно просто переменные в html.tpl.php печатаются, а не отображаются, потому что их не нужно отображать. Все переменные уже являются строками, и для построения шаблона не использовались массивы рендеринга.И наоборот, содержимое узла в node.tpl.php является массивом рендеринга. Таким образом, любые его части, которые должны быть отображены, должны быть пропущены,
render()
а не просто напечатаны.Я был бы соблазн следовать примеру использования ядра
render()
в шаблонах, а не в функциях предварительной обработки, если у вас нет особой причины делать это по-другому.С точки зрения производительности разница, безусловно, будет незначительной, но профилирование кода в контексте вашего сайта и оборудования - единственный способ убедиться в этом.
источник