Config ignore module tutorial voor Drupal

In de vorige tutorial spraken we over de module Config Split voor Drupal 8. Vandaag laat ik je een andere configuratie-gerelateerde module zien voor Drupal 8/9 - Config Ignore. Ze overlappen elkaar gedeeltelijk. Beide helpen ons om configuraties van verschillende omgevingen gescheiden te houden. Het gebruik is echter iets anders. Het resultaat ook. De beste manier om het te leren en te begrijpen is door voorbeelden uit de praktijk te gebruiken.

Stel dat we iets moeten ontwikkelen aan de functionaliteit voor het verzenden van e-mail. Misschien willen we een sjabloon stijlen. Of een gebeurtenis-abonnee maken waarbij we een specifieke e-mail naar de sitebeheerder willen sturen. Of een melding maken bij een cron-uitvoering. Of gewoon zorgen dat we überhaupt e-mails kunnen versturen!

Laten we voor dit voorbeeld het standaard e-mailadres van de site gebruiken. Dus in de lokale omgeving zouden we waarschijnlijk onze eigen e-mail gebruiken, toch? Maar wanneer we de configuraties exporteren voor de test- of live-omgeving, willen we niet dat onze e-mail als standaard wordt ingesteld, maar willen we dat dit de echte e-mail is. Dus moeten we deze configuratie negeren. Kunnen we dat doen?

Natuurlijk kunnen we dat! Nu al nieuwsgierig? Laten we beginnen!

We moeten eerst de module Config Ignore installeren en inschakelen:

composer require drupal/config_ignore 
drush en config_ignore 

Laten we ook de cache wissen

drush cache:herbouwen

en we zouden de module al hebben draaien. De module is afhankelijk van een andere module - Config Filter, maar dat wordt automatisch voor ons afgehandeld. We hoeven alleen maar goed te keuren dat beide modules worden ingeschakeld als dat nodig is. Deze module werkt dichter bij het configuratiesysteem van de core, dus het is op het eerste gezicht niet zo duidelijk waar het plaatsvindt. We hebben geen nieuwe items in het hoofdgedeelte Configuratie → Ontwikkeling. Laten we eens kijken wat we daar hebben.

Zoals al vermeld - niets bijzonders. Gewoon het standaard configuratiesynchronisatiesysteem van de kern dat we meestal gebruiken om onze configuraties te importeren en exporteren. Wanneer we deze acties uitvoeren via de drush commando's [config:import] en [config:export], activeren we in principe dezelfde acties die we hier zouden zien. Maar laten we eens kijken wat erin zit.

OK, hier hebben we al een ander tabblad naast de standaard tabbladen. Dit is het tabblad 'Negeren' waar we moeten werken. Laten we eens kijken hoe het eruit ziet.

Het is vrij eenvoudig. Gewoon een formulier waarop we onze configuraties kunnen plaatsen die we willen negeren. De mensen die het gemaakt hebben, beschrijven zelfs hoe je het moet gebruiken. Bedankt, jongens! Ik zal de voorbeelden die we daar hebben niet dupliceren, maar me in plaats daarvan richten op onze specifieke use case. We willen dat onze e-mail alleen wordt gebruikt voor lokale ontwikkeling. De volgende dingen die we nodig hebben zijn:

• wanneer we de configuraties exporteren, moet onze e-mail daar niet tussen staan
• Wanneer we de configuraties importeren, willen we niet dat de echte e-mail van de test- of live-omgeving wordt gebruikt voor onze ontwikkelingsdoeleinden, dus we willen niet dat onze configuratie wordt overschreven.

Config Ignore schiet te hulp! We hebben een paar manieren om de configuraties te beschrijven. Maar laten we eerst de initiële configuraties exporteren om later het verschil te kunnen zien:

drush config:export

Opmerking: Voer de volgende stap nog niet uit. Ik doe het hier alleen voor de uitleg.

Ik ging naar Configuratie → Systeem → Basis site-instellingen, veranderde de e-mail met mijn eigen e-mail en sloeg het op. Als we nu teruggaan naar het configuratiesynchronisatiegedeelte (Configuratie → Ontwikkeling → Configuratiesynchronisatie), zien we een wijziging in het bestand system.site.yml en kunnen we deze controleren door op Verschillen weergeven te drukken.

Laten we nu de configuratietekenreeks uit de afbeelding hieronder toevoegen op het tabblad 'Negeren' en op de knop 'Configuratie opslaan' drukken.

Maar als we nu weer exporteren, zien we beide wijzigingen - de ene in system.site en de andere in config_ignore.settings. En dat willen we niet. We hebben alleen de tweede nodig. De reden dat we ze nu allebei zien is dat het config systeem nog niet weet dat het de system.site moet negeren. Dus wat we beter kunnen doen is eerst de record toevoegen in het negeergebied, exporteren, dan de e-mail wijzigen en opslaan. OK, dan doen we het deze keer goed.

We gaan naar het tabblad Negeren en voegen een van de volgende dingen toe:

- system.site → Merk op dat dit de hele pagina 'Basis site-instellingen' zou negeren.

- system.site:mail → Dit zou alleen het e-mailgedeelte van de instelling negeren. Heb je de dubbele punt voor de mail opgemerkt? Dit is hoe we instellen dat alleen een specifieke sleutel uit een configuratiebestand wordt genegeerd. Laten we deze nu gebruiken. Deze keer zouden we het volgende moeten hebben:

We zijn klaar om te exporteren via:

drush config:export

zodat we er zeker van zijn dat de e-mail de volgende keer wordt genegeerd als we het veranderen. Deze keer zien we alleen de verandering in 'config_ignore.settings'. Dit is wat we verwachten. Laten we nu die e-mail al gaan veranderen. Laten we daarna eens kijken wat het tabblad 'Synchroniseren' ons laat zien.

Het systeem is slim genoeg om het verschil te zien, maar negeert het en laat ons zelfs weten dat het al genegeerd is. Nu zien we alleen dat er een wijziging is, maar we hebben niet de knop om die te bekijken. We zijn nu klaar om die e-mailwaarde zoveel te veranderen als we willen. Het is belangrijk om te zeggen dat, omdat we alleen de mail hebben genegeerd, elke andere verandering in de system.site zou worden behandeld als een echte verandering door het systeem, d.w.z. het zou niet worden genegeerd tenzij we de hele system.site in het negeer gebied zetten of een van zijn andere sleutels op dezelfde manier als we met de mail hebben gedaan. Elk nieuw record moet op een nieuwe regel worden geplaatst. Dit is hoe de module Config Ignore werkt.

Ik weet zeker dat je dit al hebt opgemerkt, maar ik wijs er alleen op voor de volledigheid. Deze configuratie moet nu worden ingesteld met de echte waarde op elke verschillende omgeving, wat betekent dat je nog steeds de mails moet bijwerken in de test-, live- of andere omgevingen. Het wordt niet vervangen door importeren of exporteren.

Dat zou werken met elke configuratie, zelfs als het een aangepaste is die we zelf hebben gedefinieerd. Onthoud alleen dat het negeren van een nieuwe configuratie deze leeg zou laten, zelfs als deze een waarde heeft op de lokale omgeving. Exporteren zou echter het yml-bestand genereren, zodat het overal beschikbaar zou zijn.

Dit is een korte handleiding voor het gebruik van de module Config negeren. We kunnen ook wijzen op enkele verschillen tussen deze module en de module Config Splitsen. Ze hebben allebei hun sterke punten. Dus hoe kiezen we welke we gebruiken? Nou, dit hangt af van de use case die we hebben, maar laten we eens kijken naar hun specificaties:

• Config Negeer - eenvoudiger in gebruik, dichter bij de kernfunctionaliteit. Het toevoegen van een andere configuratie voor negeren is net zo eenvoudig als het invoeren in het formulier. Je moet echter wel zorgen voor dezelfde configuratie in elke omgeving. Als er maar een paar records worden toegevoegd, is dit niet echt een probleem.
• Config Splitsen - krachtiger, biedt de optie om alle mogelijke omgevingen vooraf te definiëren. Hiermee kunnen we de configuraties die we willen per omgeving vooraf definiëren en ze vergeten zodra ze zijn geïmporteerd. Er is ook een optie om veel eenvoudiger te configureren of een hele module per omgeving wordt in- of uitgeschakeld. Het is echter iets moeilijker in te stellen en te gebruiken.

Uiteindelijk is het echt een kwestie van voorkeur.

Ik hoop dat je deze tutorial nuttig vindt!