Something every WordPress developer has wished for, sometime during the development of one of their plugins, is plugin dependencies. Dependencies in the sense of other plugins that provide extra or base functionality for the to be installed plugin. This is something every Linux but also Drupal developer has some experience with. Continue reading “WordPress needs plugin dependencies”
WordPress heeft plugin dependencies nodig
Iets waar WordPress plugin ontwikkelaars al een tijd tegenaan lopen is het feit dat ze geen dependencies voor hun plugin op kunnen geven. Dependecies in deze zin zijn vereiste andere plugins om functionaliteit van de te installeren plugin te garanderen. Dit is iets waar iedere Linux, maar ook bijvoorbeeld, Drupal gebruiker ongetwijfeld ervaring mee heeft.
Het voordeel voor ontwikkelaars is dat zij, wanneer ze meerdere plugins ontwikkelen met veel terugkerende functies, dat dan in een algemene functie library (plugin) kunnen opzetten en deze als dependency kunnen opgeven.
Niet alleen voor ontwikkelaars
Ook de eindgebruikers zullen hier baat bij hebben. Mijn populairste plugin brengt ondersteuning voor iDeal transacties naar WP e-Commerce, ik krijg echter een keer per week een support request om mijn plugin te configureren om vervolgens te ontdekken dat de gebruiker geen WP e-Commerce geïnstalleerd heeft. Nu klinkt dit vooral als ‘lastig’ voor mij maar de persoon die contact met mij opneemt voelt zich vaak bezwaard om dit te doen.
Niet iedere gebruiker zal de documentatie of FAQ van je plugin lezen maar als dependencies goed zichtbaar gemaakt worden, desnoods met uitleg, dan voeden we de eindgebruiker ook een beetje op.
In de praktijk
Nog een praktijkvoorbeeld is de plugins van Joost de Valk. Bij de meeste van zijn plugins tref je het bestand yst_plugin_tools.php
aan. In dit bestand verzamelt Joost een reeks functies die hij vaker gebruikt over meerdere plugins. Wanneer hij deze functies in een aparte plugin zou kunnen plaatsen en deze als dependency kan opgeven voor bijvoorbeeld WordPress SEO dan scheelt dat niet alleen een paar kb per plugin maar het maakt plugins in theorie ook makkelijker te beheren. Stel Joost vind een betere best practice voor een functie die hij nu in yst_plugin_tools.php
heeft staan dan zou hij deze voor al zijn plugins in één keer kunnen updaten op de geschetste manier.
Maar je kunt ook denken aan het aanbieden van algemene libraries voor bijvoorbeeld online betalingsdiensten. Wanneer PayPal of iDeal een algemene plugin ter beschikking zou stellen met de basisfunctionaliteiten voor hun product of dienst en ontwikkelaars alleen nog maar de brug hoeven te leggen tussen hun plugin en deze library dan kunnen zij eenvoudiger een goede werking van hun koppeling garanderen en bespaart dit andere ontwikkelaars veel tijd.
De valkuilen
Natuurlijk heeft het dependecy systeem ook zijn valkuilen. Wat kan een gebruiker doen wanneer plugin x versie >=1.0 van plugin y vereist en plugin z versie <1.0 van plugin y? Dit levert natuurlijk vervelende situaties op.
Daarnaast is er ook het risico wanneer teveel ontwikkelaars gebruik gaan maken van een bepaalde dependency en deze ineens niet meer doorontwikkeld wordt of bepaalde compatibiliteit verwijderd. Hiermee zouden eindgebruikers onnodig gedupeerd kunnen worden.
Dit zijn beiden punten waar wij als WordPress community op moeten anticiperen.
Hoe nu verder?
Ontwikkelaar Silviu-Cristian Burcă heeft al een mooie plugin voor een dependency systeem opgezet. Jammer genoeg werkt dit dependency systeem niet zonder zijn eigen plugin en daarin ligt natuurlijk ook de nodige ironie. Daarnaast staat deze plugin nog enigzins in de kinderschoenen omdat er geen versie informatie aan de dependencies gekoppeld kan worden.
Ik verwacht dat we pas na WordPress versie 3.3[ref]Uit Andrew Nacin’s reacties op dit artikel wordt in versie 3.3 het redirect/rewrite systeem van WordPress stevig op de schop genomen. Ik verwacht dat dit zoveel werk zal zijn dat er niet nog een grote nieuwe feature in deze versie zal zitten.[/ref] een keer een dependency systeem in de core kunnen verwachten. Er is steeds meer vraag naar (#10190, #11308, #12612) maar eigenlijk moet de discussie eens goed opengebroken worden en alle aspecten belicht worden. Het idee vereist namelijk ook aanpassingen op WordPress.org.
WordPress kan op dit gebied in ieder geval veel leren van de fouten die door de Drupal community zijn gemaakt, zo had Drupal tot versie 7 geen versie indicatie voor dependencies maar had ook de community problemen met de adoptie hiervan. Ik weet zeker dat als we als WordPress community eens goed de koppen bij elkaar steken dat wij het wel in één keer goed doen.