WordPress core contributor Alex Shiels heeft een voorstel gepubliceerd voor een WordPress.org block directory, speciaal voor het hosten van JavaScript-gebaseerde single block plugins. De directory zou het mogelijk moeten maken om, direct vanuit de Gutenberg editor, blocks te zoeken en te installeren. Het bouwen van een directory voor het ontdekken en installeren van blocks is een van de 9 projecten die Matt Mullenweg als prioriteit voor 2019 heeft geïdentificeerd.
Single block plugins
Voor standaard core blocks kun je de Gutenberg Blocks Design Library Plugin gebruiken. Maar hoe zit het met andere blocks? Block collecties zijn een van de meest populaire manieren om een groep van gerelateerde blocks te distribueren, maar deze methode kan soms leiden tot tragere websites. Gebruikers kunnen nu nog niet op naam naar individuele blocks zoeken, en daarbij zijn plugin namen en beschrijvingen niet altijd een goede indicatie van wat blocks nu precies doen.
Shiels stelde voor om de nieuwe directory te beperken tot single block plugins: Front-end JavaScript blocks zonder gebruikersinterface buiten de editor. Het zou een apart gedeelte binnen het WordPress plugins directory moeten worden, geoptimaliseerd voor gebruikers om blocks te zoeken op basis van naam en beschrijving. Ontwikkelaars zouden vereist zijn om een block.json bestand met metadata te gebruiken (zoals staat beschreven in de technische specificatie van de Block Registration RFC).
Vanuit de Gutenberg editor
Het meest controversiële onderdeel van het voorstel is om het mogelijk te maken de blocks vanuit de Gutenberg editor te laten installeren. Het uiteindelijke doel is om dat proces zo soepel mogelijk te laten verlopen. Block collecties en blocks die niet voldoen aan de vereisten van het single block plugins directory zouden nog wel verkrijgbaar zijn via het normale plugin installatieproces. Dit zou echter wel verwarrend kunnen zijn voor gebruikers die niet weten dat blocks in twee afzonderlijke directories te vinden zijn.
Volgens Matt Cromwell zou de Gutenberg editor GEEN bron voor plugin installatie moeten zijn, omdat je dan met scope-creep te maken zou krijgen. “Dat is niet het doel of de functie [van de Gutenberg editor],” schreef hij. “Laat het een editor, layout builder, contentmanager, etc. zijn.” Cromwell vind dat de Gutenberg editor niet de plek mag worden waar we een externe bibliotheek kunnen doorzoeken. Hij suggereerde een gecentraliseerde block manager als alternatief, die een betere ervaring zou bieden voor het doorzoeken en installeren van blocks. Hij wees ook op het belang van het betrekken van dynamische blocks in de directory, in plaats van deze te beperken tot “JavaScript only” blocks. “Ik zie niet echt een voordeel aan het beperken van deze directory.”
Ook WordPress ontwikkelaar Jamie Schmid uitte zijn twijfels over een oplossing die block installatie binnen de editor zet; hij denkt dat het gebruikers misschien zal ontmoedigen om over hun gebruik van blocks na te denken.
“In plaats daarvan zou ik graag een gecentraliseerde weergave voor alle geïnstalleerde blocks zien – gelijk aan hoe dat voor plugins is, maar dan meer geordend op type/functie/etc, en voorzien van iets visueels. Dit zal gebruikers stimuleren om beslissingen op site-niveau te maken en naar het grote geheel te kijken.”
“Verschillende contexten”
“Het is belangrijk om blocks te zien als hun eigen eenheid, die een eigen betekenis hebben, die in verschillende contexten kan worden gebruikt,” schreef Riad Benguella, Gutenbergs leider voor fase 2. “Een block is een stukje content (statisch of dynamisch) dat overal geconfigureerd en gerenderd kan worden.”
Volgens Benguella moeten ze ambitieus zijn en over al deze contexten (het eindresultaat) nadenken, maar tegelijkertijd pragmatisch blijven. Shiels benadrukte dat zijn voorstel was bedoeld als startpunt, en dat contributors nog in de verkennende fase zitten. Je moet ergens beginnen, nietwaar?
