Matt Mullenweg, WordPress-ontwikkelaar en CEO van Autommatic, stelde voor om te stoppen met het toevoegen van nieuwe functies aan WordPress en in plaats daarvan over te stappen op een plug-inbeleid.

Deze nieuwe benadering van de toekomst van WordPress heeft al geresulteerd in een nieuwe functie voor de volgende versie van WordPress die volledig zal worden verwijderd.

Er wordt gezegd dat canonieke plug-ins een manier bieden om WordPress sneller te blijven verbeteren.

Maar sommige topbijdragers aan WordPress waren van mening dat de gebruikerservaring van de editor eronder kan lijden.

Canonieke connectoren

Voor het eerst besproken in 2009, canonieke plug-ins zijn een manier om nieuwe functies te ontwikkelen in de vorm van plug-ins.

Het doel van deze aanpak is om de kern van WordPress snel en slank te houden en tegelijkertijd de ontwikkeling van experimentele functies in de vorm van plug-ins aan te moedigen.

Het oorspronkelijke voorstel uit 2009 beschreef het als volgt:

“Canonieke plug-ins zouden plug-ins zijn die zijn ontwikkeld door de gemeenschap (meerdere ontwikkelaars, niet slechts één persoon) en de meest populaire functieverzoeken adresseren met overtreffende trap uitvoering.

… Er zou een zeer sterke relatie zijn tussen de kern en deze plug-ins, zodat a) de plug-incode veilig zou zijn en het best mogelijke voorbeeld van coderingsstandaarden, en ib) dat nieuwe versies van WordPress met deze plug-ins zouden worden getest vóór de lancering om compatibiliteit te garanderen”.

Deze benadering van functies en opties wordt ook Plugin First genoemd, om te benadrukken hoe functies als eerste verschijnen in de vorm van plug-ins.

Deze plug-ins worden canoniek genoemd omdat ze zijn ontwikkeld door het kernteam van WordPress, in plaats van niet-canonieke plug-ins die door derden zijn gemaakt en die functies kunnen beperken om de aanschaf van een pro-versie aan te moedigen.

Het integreren van canonieke plug-ins in de WordPress-kern zou worden overwogen zodra de plug-intechnologie populair en essentieel is gebleken voor de meerderheid van de gebruikers.

Het voordeel van deze nieuwe benadering van WordPress zou zijn om te voorkomen dat nieuwe functies worden toegevoegd die de meeste gebruikers misschien niet nodig hebben.

Plugin-first zou kunnen worden gezien als conform de WordPress-filosofie genaamd Decisions, Not Options, die tot doel heeft gebruikers niet te belasten met lagen technische opties.

Door verschillende functies en functionaliteit in plug-ins te downloaden, hoeft een gebruiker de functionaliteit die hij nodig heeft, niet nodig heeft of niet begrijpt, in of uit te schakelen.

De ontwerpfilosofie van WordPress zegt:

“Het is onze plicht als ontwikkelaars om slimme ontwerpbeslissingen te nemen en te voorkomen dat de last van technische keuzes op onze eindgebruikers rust.”

Zijn canonieke plug-ins de toekomst?

Matt Mullenweg publiceerde een bericht met de titel Canonical Plugins Revisited, waarin hij betoogde dat dit de manier is waarop WordPress in de toekomst moet worden ontwikkeld.

Hij schreef:

“We komen op een punt waarop de kern meer redactioneel moet zijn en nee moet zeggen tegen functies die zo ad hoc binnenkomen als soms, en ik hoop dat meer teams dit zullen gebruiken als een kans om invloed uit te oefenen op de toekomst van WordPress door middel van een plug-in-first-aanpak die hen de luxe geeft van snellere ontwikkelings- en releasecycli (in plaats van drie keer per jaar), minder revisie-overhead en een pad naar de kern als de plug-in een ongecontroleerd succes wordt.

Het eerste slachtoffer van deze nieuwe aanpak is de annulering van de integratie van WebP-beeldconversie in de volgende versie van WordPress, WordPress 6.1, die momenteel gepland staat voor november 2022.

Plugin-First is controversieel

De overstap naar een ontwikkelingsproces voor plug-ins stond ter discussie in de opmerkingensectie.

Sommige ontwikkelaars, zoals hoofdbijdrager Jon Brown, uitten hun bedenkingen bij het voorstel om over te stappen op ontwikkeling met canonieke plug-ins.

Ze merkten op:

“Het probleem blijft dat er te veel gecompliceerde add-ons zijn die een eenvoudige optionele functie vervangen.

Plug-ins zijn _niet_ een gemakkelijk te gebruiken optie voor basisinstellingen. Eerst moeten gebruikers ontdekken dat er een plug-in bestaat, dan hebben ze een ander installatiescherm en updates en onderhoud voor die plug-in onderhandeld.”

De commentator gebruikte het voorbeeld van een reactiefunctionaliteit die verschillende plug-ins momenteel bieden en die opgeblazen is als een minder dan ideale gebruikerservaring.

Ze merkten op dat het hebben van een canonieke plug-in om een ​​probleem op te lossen de voorkeur verdient boven de huidige staat waarin wenselijke opties alleen te vinden zijn in opgeblazen plug-ins van derden.

Maar ze zeiden ook dat het hebben van een configuratie-optie binnen de kern, zonder de noodzaak van een plug-in, een betere gebruikerservaring zou kunnen bieden.

Ze vervolgden:

“Nu denk ik dat de Canonical-plug-ins een betere situatie zijn dan de 6+ opgeblazen plug-ins die hier momenteel bestaan, maar het zou ook een enkel selectievakje toevoegen aan de kernelconfiguratiepagina om dit te doen. Wat het nog beter zou maken plus de UX en vindbaarheidsproblemen die inherent zijn aan plug-ins.”

Uiteindelijk bracht de commentator het idee naar voren dat het concept van canonieke plug-ins een manier leek om discussies over functies die moeten worden overwogen af ​​te sluiten, zodat het gesprek nooit plaatsvindt.

“Canonieke connectoren” lijken een bewapend hulpmiddel om discussies te laten ontsporen op dezelfde manier als “beslissingen, geen keuzes” al jaren zijn geworden.”

Deze laatste verklaring is een verwijzing naar de frustraties die sommige kernbijdragers voelen over het onvermogen om opties voor functies toe te voegen vanwege de “beslissingen, geen opties”-filosofie.

Anderen waren het ook niet eens met de aanpak van de eerste plug-in:

“De canonieke plug-in klinkt geweldig, maar het zal de onderhoudslast voor beheerders verder vergroten.

Volgens mij is dat niet mogelijk.

Het is veel beter om enkele basisfuncties in de kern op te nemen in plaats van meer te zeggen – het is een goede plek voor de plug-in.”

Iemand anders wees op een fout in de eerste plug-in, omdat het misschien niet eenvoudig is om gebruikersfeedback te verzamelen. Als dit het geval is, is er misschien geen goede manier om plug-ins te verbeteren op een manier die voldoet aan de behoeften van de gebruiker als die behoeften niet bekend zijn.

Zij schreven:

“Hoe kunnen we feedback van gebruikers beter vastleggen?

Tenzij de site-eigenaren voldoende kennis hebben om problemen op GitHub of Trac te melden (laten we eerlijk zijn, niemand meldt problemen met plug-ins op Trac), is er echt geen manier om gebruikersfeedback te verzamelen om deze aanbevolen/officiële plug-ins te verbeteren. “

Canonieke connectoren

De ontwikkeling van WordPress evolueert om verbeteringen sneller door te voeren. Feedback van kernbijdragers geeft aan dat er veel onbeantwoorde vragen zijn over hoe dit systeem voor gebruikers zal werken.

Een van de eerste indicatoren zal zijn wat er gebeurt met de geannuleerde WebP-functie die ooit bedoeld was om in de kern te worden ingebouwd en nu een plug-in zal worden.

Uitgelichte afbeelding door Shutterstock/Studio Romantic

Source link