Overslaan en naar de inhoud gaan

Wat is een hook? En andere veelvoorkomende Drupal vragen

Custom Entity of content type, wat is het verschil? Worden Views door de Drupal core gecached? Hoe verander ik de opmaak van een enkel artikel?

Uit nieuwsgierigheid bezocht ik vandaag Drupal Answers (DA), ook om eens na te gaan waar mede-Druppelaars zoal tegen aan lopen.

Tussen de meest omhoog gestemde vragen vond ik de volgende vier kwesties waarvan ik het idee heb dat ze meer mensen zullen bezighouden:

  1. Wat is een hook?
  2. Wat is het voordeel van een custom entity ten opzichte van een content type?
  3. Hoe koppel ik een stylesheet aan een specifieke node?
  4. Cached Drupal mijn views of moet ik Views' eigen caching systeem gebruiken?

De antwoorden vind je hieronder:

Vraag 1: Wat is een hook?

De term "hook" zul je geregeld tegenkomen als je je met Drupal bezighoudt. Het woord, dat afstamt van hooking, is niet Drupal-specifiek maar een algemene term in de programmeurs wereld. Alle CMS systemen maken gebruik van hooks, ook Wordpress en Joomla. Ook al ben je geen programmeur dan nog is het handig om in ieder geval een beetje te weten wat een hook inhoudt, al is het maar omdat de term vaak gebruikt wordt voor woordgrapjes, die je anders niet zult begrijpen. 

Een hook-module is een stukje code die een ander stuk(je) code uitbreidt of veranderd. Een van de bezoekers op DA gebruikt het woord "contract" om de relatie tussen modules en hooks te beschrijven:

"If a module implements a hook, it enters into a contract to perform a particular task or return a particular type of information when the hook is invoked. The calling code need not know anything about the module or the way the hook is implemented in order to get useful work done by invoking the hook." bron

Ook het woord "interactie" komt voorbij: "In layman's terms, hooks are sort of bridges which provide a way for modules to interact with each other, alter each other's structure and data, provide new data etc." bron

Oftewel, een hook maakt samenwerking tussen modules simpeler. Een goede programmeur zorgt er dan ook voor dat zijn module zo is geschreven dat andere modules erop voort kunnen bouwen door punten toe te voegen "where the code pauses and shouts "Anyone else got anything to add here?" bron

De manier waarop hooks worden gebruikt kan verschillen, zo heb je action hooks en filter hooks. Een simpel voorbeeld van een filter hook is een module die een CSS klasse toevoegt aan een titel veld. Een functie binnen een bestaande module, de output van het titel veld, wordt ingeladen en aangepast, zonder dat de hook-module hoeft te weten hoe de rest van de module in elkaar zit. In zekere zin is een hook een hack die niet gericht is op het aanrichten van schade.

Ook de Drupal core modules bevatten meerdere hooks waar module bouwers gebruik van kunnen maken. De Node module heeft bijvoorbeeld een hook_node_update. Elke keer als een node wordt geüpdatet dan wordt deze code uitgevoerd. Wanneer je een module wilt schrijven die ervoor zorgt dat alle auteurs een bericht krijgen wanneer een artikel wordt geüpdatet dan maak je gebruik van deze hook. Je maakt dan een nieuwe module waarin je met de functie mijnnieuwemodule__node_update naar deze hook verwijst. Drupal weet nu precies wanneer jouw module moet worden uitgevoerd, in dit geval spreek je van een action hook. 

Vraag 2: Custom entity of toch een content type?

Wat zijn de voordelen van het handmatig coderen van een custom entity in vergelijking met een content types die je zo in elkaar klikt en waar Drupal modules zoals Views helemaal op zijn afgestemd?

Het overwegende antwoord op DA is dat dit ligt aan de situatie, je zult daarin een afweging moeten maken, zo zegt iemand "A very simple rule of thumb I use is whether your content need to be publicly displayed on its own. If so, then go for node, if not choose an entity." bron Een ander verwijst naar taxonomie entity's om het verschil tussen entities en content types te duiden:

"A taxonomy term is essentially for grouping together different entities and as such doesn't require the same functionality as a node. While you could theoretically use a content type to perform this functionality (with perhaps a node reference field), a taxonomy term doesn't need to do the same thing as a node so it doesn't really make sense to do so. (...) " think the simple answer is that when a node/content type doesn't do what you need it to, or it's just a massive amount of overkill/overhead for very little benefit, then you should choose to write a custom entity." bron

Waarom de ateur zegt: I think it's bit more clear now. Data that doesn't need all of the extra "fluff" that a node provides, like author, published date, etc. 

Samengevat kies je voor een entity als je met content hebt te maken die niet publiekelijk zichtbaar hoeft te zijn (tussen bijvoorbeeld zoekresultaten of nieuwsberichten) en die een specifieke taak heeft welke sterk verschilt van de structuur die nodes en content types hanteren, maar je wel bepaalde velden wilt toevoegen aan de data. Taxonomies en users zijn hiervan een voorbeeld van.

Een custom entity zou bijvoorbeeld . Sinds de Entityforms module zet je deze net als een content type via een interface in elkaar. Meer informatie over Drupal entities vind je in dit artikel.

Vraag 3: CSS koppelen aan een specifieke node?

Dit kan op meerdere manieren. De auteur van de vraag, die gebruik maakt van het Zen thema, is er zelf achter gekomen dat in de template.php een stukje code klaar stond voor dit doeleinde (lijn 80). Is dit niet het geval bij jouw specifieke thema dan kun je zelf de onderstaande code toevoegen en ietwat aanpassen naar jouw eigen voorkeur (zie DA voor hulp): 

MYTHEME_preprocess_node($vars) {
  if (drupal_get_path_alias("node/{$vars['#node']->nid}") == 'foo') {
    drupal_add_css(drupal_get_path('theme', 'MYTHEME') . "/css/foo.css");
  }
}

De andere manier is via een module. Je zou bijvoorbeeld kunnen gaan voor Code Per Node die puur voor dit doeleinde heel geschikt is. Andere optie is de Context module in combinatie met Context Add Assets. Dit is een wat uitgebreider pakket waarmee je via een eigen UI meerdere nodes aan een stylesheet kunt toewijzen. Ook kun je eventueel extra voorwaarden toevoegen zodat je een thema bijvoorbeeld veranderd op basis van de gebruikersrol van een bezoeker.

Vraag 4: Views caching of Drupal core caching?

De Drupal core cached views voor bezoekers, maar niet voor ingelogde gebruikers. De Views cache maakt gebruik van de Drupal Cache API en voegt hier extra functies aan toe (oftewel, een hook!). Zo zorgt de Views cache er voor dat ook ingelogde gebruikers een gecached versie van een view te zien krijgen, en kun je per View aangeven hoe lang deze gecached moet worden.

De views caching is dus niet perse beter, maar wel uitgebreider. Je kunt bijvoorbeeld ook kiezen om de querie uitvoer te chachen of de totale HTML output. Laatstegenoemde optie is net iets sneller, maar als je dynamische stylessheets hebt voor verschillende gebruikersrollen dan kun je beter kiezen voor het cachen van de pure data.

Op DA worden drie modules genoemd die de cache mogelijkheden nog uitgebreider maken:

  • Views Content Cache - Onmisbaar als je gebruik maakt van Views cache maar niet wilt dat (ingelogde) bezoekers veranderingen pas na een uur te zien krijgen. De module zorgt ervoor dat de cache vernieuwd wordt op het moment dat de inhoud wijzigd.
  • Cache Actions - UI om de cache van een view of panel te legen. Werkt samen met de Rules module zodat je zelf de voorwaarden kunt bepalen wanneer dit automatisch moet gebeuren.
  • Blockcache Alter - Met deze module kun je per block instellen of, en hoelang, deze moet worden gecached.

Nog niet zo bekend met caching? De basics van caching in Drupal en Joomla leert mijn collega Thomas je in dit artikel.

Heb jij ook een Drupal gerelateerde vraag waar je al een poosje mee zit? Stel hem hieronder.

Heb je iets aan deze content gehad? Laat weten hoe je ons waardeert.

Meld je aan voor onze nieuwsbrief

En je ontvangt net als 2321 andere leden een overzicht van onze nieuwste artikelen. Met onderwerpen als; de laatste webdesign trends, SEO tips, conversie optimalisatie, Joomla, Drupal en Wordpress ontwikkelingen.

Reacties

Beperkte HTML

  • Regels en alinea's worden automatisch gesplitst.