Drupal 8 development: non-content | Deel 2/3: ontwikkeling van een custom block.

28 Apr 2017

Joris Snoek
Digital Consultant
+31 (0)20 - 261 14 99

In voorgaand deel 1 van deze blog-serie beschreef ik wat in onze ogen non-content is en hoe we dat gebruikersvriendelijk beheerbaar maken voor content managers.

Deze blog serie bestaat uit drie delen:

  1. Bouw van het Drupal 8 backend configuratie formulier en definiëren van een Twig template file.
  2. Implementatie van een Drupal 8 Block, waarin ingevoerde teksten uit het configuratie formulier opgehaald worden; ge-rendered in een custom Twig template file.
  3. Het beheerbaar maken van de achtergrond afbeelding, via het backend configuratie formulier.

Ter opfrissing van je geheugen, binnen deze blog-serie leg ik uit hoe je non-content beheerbaar kunt maken voor content managers. Dit is het voorbeeld waarmee we werken:

In dit deel 2:

  1. Drupal 8 custom block implementatie.
  2. Ingevoerde teksten uit het configuratie formulier ophalen en renderen in een custom Twig template file.

1. Drupal 8 custom block implementatie

Om de data op te halen en vervolgens in het Drupal 8 frontend te presenteren maak ik een custom Drupal block in onze custom module. Drupal biedt ook allerlei non-developer backend functies om blocks aan te maken, velden eraan toe te voegen en deze te plaatsen in de website. Die Drupal backend block functies gebruiken we niet, omdat content managers dan moeten graven in allerlei technische admin-schermen.

Daarnaast is het voor Drupal developers makkelijker beheerbaar, flexibel en schaalbaar als dit consistent in custom blocks ontwikkeld wordt. De tijd voor implementatie kost bijna niets meer omdat je gebruik kunt maken van skeleton code.

De benodigde moeite om dit custom te bouwen wordt ruimschoots gecompenseerd door de flexibiliteit, schaalbaarheid en gebruikersvriendelijkheid wat je ervoor terug krijgt.

Het block opbouwen

We genereren de skeleton code weer met behulp van Drupal Console:

  1. Ik enter drupal generate:plugin:block in een terminal, vanuit de webroot.
  2. Ik wil hem plaatsen in onze eigen module openlucius_configuration, die we in deel 1 al aanmaakte.
  3. Geen de plugin (in dit geval het block) een herkenbare class name.
  4. Plugin label, plugin id, region en load services: deze 4 waardes zijn default prima, gewoon 4 keer door enteren.
  5. Ik wil geen block fields genereren, onze benodigde data leeft namelijk in een configuratie formulier om eerder genoemde redenen, zie ook deel 1. Hier enter ik dus no.

Het Drupal 8 block (een plugin) wordt nu gegenereerd in mijn module, betreffende code:

Het block plaatsen in het frontend

Er is nu dus een block aangemaakt, om te zien of dit goed gegaan is kan je naar Block Layout in het Drupal backend navigeren en bekijken of hij in de lijst staat wanneer je bij een region op ‘Place block’ klikt:

Ik klik op ‘Place block’ en kies ervoor om hem alleen op frontpage te plaatsen:

Voor het gemak plaats ik het block op deze manier, maar in een productie systeem zullen we dit altijd via Panels en Page manager doen. Via die modules kan je makkelijker bepalen welk block waar staat en onder welke condities. Daarnaast is exporteren naar code met die modules makkelijk en consistent.

Anyway, voor dit voorbeeld dus via de Drupal core backend waardoor ik dit te zien krijg op mijn frontpage:

Ter herinnering, dat wil ik graag omtoveren naar:

2. Ingevoerde teksten uit het configuratie formulier ophalen en die teksten printen in een custom Twig template file

Binnen het zojuist aangemaakte block kunnen we nu de opgeslagen data uit het configuratie formulier ophalen, deze zullen we via een Twig template file daarna gaan renderen in het frontend:

  1. Haal benodigde configuratie op.
  2. Zet alle benodigde variables.
  3. Vul alle Twig template variables en geef aan welk Twig template gebruikt moet worden.

Waar ik deze gegevens vandaan haal:

  1. Haal alle benodigde configuratie op (1a), je kunt het benodigde config id kopiëren uit het door Drupal Console gegenereerde formulier in deel 1. Zie 1b.
  2. Vul alle benodigde variables (2a), deze variable id’s hebben we in deel 1 zelf gedefinieerd en kunnen we dus terugvinden in de .module file (2b), waar de benodigde Twig template file en Twig variables gedefinieerd staan.
  3. Geef in 'de $build' aan in welke Twig template file de HTML ge-rendered moet worden (3a). Dit gaat middels de render API van Drupal 8. We hebben in deel 1 deze Twig template file zelf gedefinieerd (3b) je kunt hem dus van daaruit kopiëren.

Clear nu alle caches met behulp van Drupal Console’s drupal cre en voilá:

Een Drupal 8 block, wat dynamisch beheerd kan worden middels het backend config form, zoals gebouwd in Deel 1.

Wrap up deel 2

Alrighty, we hebben nu een custom Drupal 8 block gebouwd, opgeslagen configuratie ingeladen en gerendered middels de Drupal 8 Render API, waardoor we nu een werkend dynamisch block hebben.

Enige wat nog mist is een beheerbare achtergrond afbeelding, in deel 3 zullen we dit gaan ontwikkelen. So stay tuned!

Comments

Nóg meer
kennis nodig?

Check ons ons blog archief >