One example I can think of is module which provides RDF mapping through attributes only.
DRUPAL RULES HARDCODE SELECTOR CODE
It’s not recommended to hardcode drupal attributes (HTML attributes like id, class) in twig files and the reason for this is: there are several modules which perform alteration of drupal attributes and make use of Drupal attributes and will no longer work if we hard code this. Placement of Preprocessors will work both in module and theme, while for twig files placing them in the module may need hook_theme_registery_alter based on the twig file we are overriding. We place them in the module, in case the functionality to be provided should work on a modular approach.
Regarding placement of these preprocessors, it is completely based on the project requirement and usage.
So, for a generic twig, we can make use of specific hooks as suggested by twig debug too which definitely gives better performance. In that case creating specific twig and then using the specific preprocessor (node_content_type_teaser) for alteration is an extra step, instead, we can directly use the preprocessor hook_node_content_type_teaser without writing the specific twig file. One more important thing regarding hook_preprocess_HOOK:Ĭonsider a scenario, where we are using for node and then we have to do some alteration for a specific content type teaser view. In this case, writing a specific preprocessor for date field makes more sense. But we need to consider that this preprocessor will run for all fields, which will definitely affect the performance. In that case, a general approach we may take is to write hook_preprocess_field. Consider overriding display of date field value based on certain conditions. Hence, when we have to do some custom work where we have to alter data conditionally, we make use of preprocessor functions. Tweak Markup -> Use Twig level customizations So, generally, we follow the following rule for customizations: Tweak data -> Use Preprocess level alter Drupal provides us handful of ways to do so, an important point here is to know and analyze what will be the best way to achieve expected results for the case. Most of the time, we come across scenarios where we need to do tweaks to field output based on certain requirements. With great flexibility, comes responsibility. Selection of template files/preprocessor functions and placement of the same. It’s very easy concept and you would love once you start using this, there are several other bases on which you can decide cache-ability of a renderable array. Especially for those cases, we have cache contexts.
There come few scenarios where we cannot use direct caching but that particular array can be cached on per user/URL basis. The main point to understand here is hierarchy and nesting and the caching among this.Ī general mistake I have seen many of us perform is using So it’s like, a page is a renderable array which actually consists of other renderable arrays: region (renderable) arrays and in a region, we can have block (renderable array). One Renderable array can consist of other renderable arrays (nesting):.Understand that every renderable array is cacheable.At the end have an answer to all these questions: Go through documentation besides implementing the same once thoroughly on a vanilla Drupal instance. It’s very important to understand how Drupal 8 caching works.
So, now it’s high time we start exploiting these to get best out of Drupal 8. We will focus on the following concepts: Renderable array caching, walk through Drupal 8 caching power and Cache contextsĭrupal 8 comes with a lot of changes and almost all of us are even familiar with these changes. To get best out of this post, you should be comfortable with:
DRUPAL RULES HARDCODE SELECTOR HOW TO
In this post, I'll share my experience on how to best utilise these concepts for a robust and performant frontend with Drupal 8. Some of these are improvements of old concepts, while others are new introduction in Drupal 8. Few concepts that come to mind while thinking of Drupal 8 theme layer include Renderable Array, Cacheabilty, Cache Context, Cache Tags, Twig and Preprocessors. When it comes to Drupal 8 theming layer, there is a lot Drupal 8 offers.
0 kommentar(er)
