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.
Een erg welkome functie inderdaad. Als je het dan goed zou willen doen, zou je als plugin bouwer niet 1 plugin als dependency op moeten kunnen geven, maar misschien wel meerdere.
Ik zou dan eerder denken dat als je bepaalde functies altijd nodig hebt deze dan gewoon in de core opgenomen moeten worden.
Absoluut. De plugin van Silviu-Cristian Burcă bied ook al ondersteuning voor meerdere dependencies.
Met het toevoegen van veelgebruikte functies in de core ben ik het niet eens. WordPress levert al een set fantastische APIs die heel veel functionaliteit bieden. Echter de core moet zo ‘lean and mean’ mogelijk blijven en iedere extra functie die niet standaard benodigd is voor WordPress zelf hoort er niet in thuis.
Helemaal mee eens. WordPress moet de mogelijkheden bieden om zich door plugins uit te laten breiden, maar moet deze uitbreidingen standaard nog niet in zich dragen.
Leuk stuk, Luc, zijn al enkele plugins (oa Pods + Pods UI die dit doen dacht ik (ben niet meer helemaal zeker))
Maar ook terecht dat je ook de negatieve zaken belicht.
Tom – in comic sans for now – Hermans
De negatieve kanten heb ik jammer genoeg te vaak aan den lijve ondervonden bij enkele Drupal projecten. Het probleem was met name dat de community hier gewoon niet snel genoeg op reageerde wat er mede aan bijgedragen heeft dat de reputatie van Drupal een flinke deuk heeft opgelopen onder de ontwikkelaars die ermee bekend zijn. Eerlijk is eerlijk, met Drupal 7 lijkt het weer een beetje de goede kant uit te gaan.
Pods UI kun je activeren zonder Pods zelf te hebben geactiveerd, maar geeft inderdaad een melding op elke pagina van /wp-admin:
Niet helemaal hetzelfde als dependencies, maar het is een goede start en veel duidelijker dan dit gaat het op het moment niet worden.
Voor de volledigheid. Ik heb een Engelse versie van dit opiniestuk geplaatst op mijn eigen website.
Zou idd een perfecte toevoegingen zijn. Je hebt child thema’s, dus waarom geen child plugins? 🙂
Zelf loop ik ook geregeld tegen het probleem aan dat ik iets wil verbeteren aan de abstracte klasse welke ik met al mijn plugins extend. Sommige plugin combinaties leveren dan ook iritante bugs op..
Overigens kende ik de plugin ‘plugin dependencies’ nog niet. Vast de moeite waard om eens naar te kijken, thanks!
Persoonlijk zie ik drop-ins en beetje als child plugins.
Wanneer je problemen ondervind met bepaalde plugin combinaties dan zijn dat eigenlijk gewoon slecht geschreven plugins. Ikzelf gebruik altijd een prefix als LDB_ voor mijn functies om conflicten te voorkomen. Er zijn simpelweg teveel plugins met generieke functienamen die voor problemen zorgen.
Ik bedoel meer wanneer meerdere plugins gebruik maken van dezelfde (abstracte) klasse en hier een oudere versie van word ingeladen omdat de gebruiker een van je plugins nog niet heeft geupdate. Doordat de klasse maar 1x word ingeladen maken hierdoor al je plugins gebruik van je oudere abstracte klasse, en laat een andere plugin nou net iets nodig hebben uit die ‘nieuwe’ klasse. 😉 Die abstracte klasse zou in dit geval perfect als dependency kunnen dienen IMO.
Encapsulation of prefixes is natuurlijk standaard een goed idee. 🙂