Taak 1: Operatie “Pruts”

Op mijn eerste dag slenterde ik nogal onwennig het bedrijf binnen. Dimitri, mijn stagementor, zat al op me te wachten. Hij vroeg me meteen hoeveel ik al van Drupal kende. Ik antwoorde zo eerlijk mogelijk.

Vorig semester had ik me nog bezig gehouden met het maken van Drupal thema’s en modules, maar het bouwen van websites zelf was voor mij eigenlijk al anderhalf jaar geleden (denk ik). Het zat in ieder geval heel ver weg. Het zag er dus naar uit dat ik me eerst weer moest inoefenen. Dimitri viste een projectje uit Bitbucket en gaf me een database. Mijn eerste taak was simpel: Installeer dit project lokaal, start dan zelf een nieuw project op en maak het na. Pruts er maar mee tot je het snapt.

Voor mijn eerste “taak” ging het ook alleen maar om de structuur, en dan bovenal de modules. Ik moest leren welke modules er allemaal gebruikt werden, en hoe ze gebruikt werden. Van de CSS mocht ik afblijven. Het was iets dat ik zelfstandig mocht uitzoeken en ik kon hulp vragen wanneer nodig. Ik werd daarom tactisch gestationeerd tussen een ervaren Drupal ontwikkelaar (Steve) en een ex-IMD’er die hier een jaar geleden ook had stage gelopen (Hanna).

De installatie van het project bleek niet zo eenvoudig te zijn als ik gewend was. Op de schoolbanken zetten wij altijd de Drupal projecten op met Acquia Dev Desktop, maar bij Mia opteren ze vaker voor XAMPP. Ik kende XAMPP – ik had het altijd al gebruikt voor mijn PHP projecten – maar om dit Drupal project te installeren heb ik toch even in de instellingen van XAMPP’s apache moeten duiken om hier en daar wat aan te passen. Zo stel ik nu bijvoorbeeld virtual hosts in op Apache in plaats van zo omslachtig naar localhost/éénofandermapje te surfen.

Git kende ik ook, uit verschillende vakken. Maar om één of andere reden waren we tijdens Drupal lessen nooit verder geraakt dan het delen van zip bestanden. Vreemd, nu vraag ik me af waarom we eigenlijk nooit git gebruikten voor Drupal. Een git clone is echter niet genoeg om een Drupal project te installeren. Composer komt er ook bij te pas. Composer wordt gebruikt om alle contributed modules te installeren en te beheren. Wanneer een bestaand project gecloned wordt moet Composer dus eerst nog alle contributed modules (en nog wat dingen) installeren in /vendor, net als npm /node-modules zou moeten aanmaken bij een verse clone. Ik werkte met XAMPP dus de database importeerde ik gewoon in phpmyadmin. Zo was het project dan volledig lokaal geïnstalleerd.

Vervolgens moest ik een volledig nieuw project starten om dan van scratch het eerste project na te bouwen. In de lessen zouden we naar drupal.org/download surfen en een zip downloaden, maar het hoeft helemaal niet zo omslachtig te gaan. Waarom zouden wij die zip gaan halen als Composer dat ook kan met een enkel commando? Namelijk het volgende:

composer create-project drupal-composer/drupal-project:8.x-dev some-directory --no-interaction

Bij de installatie van het nieuwe project maakte ik gebruik van de minimal installatie optie. Drupal wordt dan geïnstalleerd zonder thema en zonder enige modules. Geen enkele CSS dus en zelfs Drupal’s fameuze toolbar is dan nog niet geïnstalleerd. Geen probleem, want de interface is helemaal niet nodig om de nodige modules te installeren. Daarvoor dienen Composer en Drush. De minimal installatie is een goede oefening in het begrijpen van welke modules essentieel zijn en welke niet. Omdat ik alle nodige modules één voor één enablede leerde ik goed waarvoor welke module diende, welke modules ik eigenlijk al kende zonder ik het wist en welke modules voor mij nieuw waren.

Paragraphs

Veruit de belangrijkste nieuwe module die ik heb leren kennen was de Paragraphs module. In plaats van een content type standaard velden te geven, kan je met deze module paragraphs als velden gebruiken. Een paragraaf zelf is dan een vooraf bepaalde reeks van velden, bijna een content type op zich. Een content type om in content types te steken. Voor de eindgebruiker is dit heel handig. Zonder deze module zouden ze zelf hun images, tekst en links in één body field van een content type stoppen in de hoop dat alles er zal mooi uitzien in het resultaat en dat het er consistent uit ziet met alle andere content. De paragraphs zijn veel sneller, makkelijker en meer modulair om te gebruiken. De gebruiker selecteert gewoon dat hij een tekst wilt met een vettere titel en een image er rechts naast en vult de content in. Veel sneller dan het zelf proberen juist te alignen in een WYSIWYG tekst editor.

Het is dan aan mij om er voor te zorgen dat de paragraphs er overal zullen uitzien zoals het hoort. Net zoals het mogelijk is om de twig templates van specifieke types van content aan te passen, kan dat ook voor de verschillende types van paragraphs. Wanneer een gebruiker dus selecteert dat hij zijn image rechts van de tekst wilt, kan ik het relevante veld opvangen in twig, de waarde uitlezen en op basis daarvan de html printen zoals het nodig is. Zoals bijvoorbeeld:

{% if paragraph.field_position_image.value == "top" %}
    <img src="{{ file_url(paragraph.field_media.entity.field_media_image.entity.uri.value) }}" alt="{{ paragraph.field_media.entity.field_media_image.alt }}">
    <p> {{ "Content!" }} </p>
{% elseif paragraph.field_position_image.value == "bottom" %}
    <p> {{ "Content!" }} </p>
    <img src="{{ file_url(paragraph.field_media.entity.field_media_image.entity.uri.value) }}" alt="{{ paragraph.field_media.entity.field_media_image.alt }}">
{% endif %}

Kint helpt enorm bij het vinden van de juiste waarden in de context. Zo zal de volgende lijn code de hele context printen.

{{ kint(_context|keys) }}
De output van kint(_context|keys)

Maar beter dan eindeloos veel if-statements te schrijven voor elke mogelijke instelling, is om gewoon aangepaste CSS classes aan de paragraphs te geven, afhankelijk van de waarden die er voor zijn ingesteld. Als de templates eenvoudig genoeg opgebouwd worden, kan het uitzicht van de verschillende paragraphs dan volledig met css geregeld worden.

{%
    set classes = [
        'paragraph',
        'paragraph-' ~ paragraph.bundle|clean_class,
        'paragraph-' ~ paragraph.bundle|clean_class ~ '--' ~ 'image-position-' ~ paragraph.field_position_image.value
    ]
%}

{% block paragraph %}
    <div {{ attributes.addClass(classes) }}>
        <p> {{ "Content" }} </p>
    </div>
{% endblock paragraph %}

De paragraphs heb ik nu volledig onder de knie en onderweg leerde ik ook dingen bij over subthema’s, de media library, embed views, talen, twig tweak en menu’s. Maar als ik daarover ook nog wil vertellen wordt deze post echt schandalig lang, en het is al schandalig lang. Mogelijks kom ik er wel nog op terug op een minder bezige week. Mijn eerste taak heb ik nu afgewerkt en als volgende taak zal ik een aantal bugs fixen in de website van Studant. Daarover zal ik de volgende keer wel meer vertellen.

Leave a Reply

Your email address will not be published. Required fields are marked *