WordPress RAD toepassingen – Toolset vs. ACF vs. PODS

Over websites en web applicaties

Als ondernemer kan je niet meer zonder website. Zelfs wanneer je uitsluitend locale diensten aanbiedt, dan is je aanwezigheid op het Internet gewoon vereist. Want niemand zal tegenwoordig meer ‘De Gouden Gids’ (bestaat die eigenlijk nog?) raadplegen wanneer ze op zoek zijn naar een dienstverlener. Zelfs als ‘De Gouden Gids’ online nog bestaat, zal je alleen toevallig via deze gids gevonden worden, omdat Google toevallig je adres naar boven haalt.

Wanneer je als ondernemer je diensten aan wilt bieden via het Internet, heb je een website nodig. Punt uit.

En er zijn talloze bedrijven die je websites kunnen leveren. Of je nu zelf via Vistaprint, Wix of WordPress.com aan de slag gaat (het online alternatief van vroeger ‘je eigen folders via WordPerfect maken en kopiëren in de bibliotheek), of dat je nu een grafisch ontwerper in de arm neemt (vergelijkbaar met een professioneel gedrukte tri-fold flyer verspreid via de bezorger van het locale krantje). Een website maken an sich kan bijna iedereen.

Het wordt wat anders indien je meer interactiviteit wilt. Je wilt niet alleen jouw informatie aan de wereld tonen (eventueel met een contactformulier en natuurlijk met een opt-in procedure), maar je wilt, dat jouw bezoeker ook daadwerkelijk diensten af kan nemen via je website. Zoals het bestellen van producten of het volgen van een online training.

Webapplicaties

In zo’n geval hebben we het eigenlijk niet meer over een website, maar een ‘webapplicatie’. Je biedt niet langer een foldertje aan, maar je verleent een dienst op het web. En in zo’n geval heb je toch meer nodig dan iemand die mooie plaatjes kan maken. Wellicht kan je dit het best vergelijken met een grafisch vormgever. Je hebt er geen enkel probleem mee om je grafisch vormgever de uitnodiging voor je feestje te laten maken. Het kan een minder goede beslissing zijn om hem ook dit feestje te laten organiseren.

Om maar met een eenvoudig voorbeeld te beginnen. Ik twijfel er nauwelijks aan (alhoewel ik er heel wat gezien heb, die ook dit weten te verprutsen) of iedere webdesigner is in staat om een WooCommerce plugin te installeren. Niet iedere webdesigner is echter ook in staat om je zodanig te helpen met je webwinkel, dat je ook daadwerkelijk gaat verkopen. Je hoeft eigenlijk alleen maar mijn gratis e-boeken ‘13 maal winst met Woo‘ en ‘Cool met Coupons‘ te lezen om te begrijpen, wat ik bedoel. De kennis in deze boeken doe je niet op tijdens lessen ‘compositieleer’, maar dit is het gevolg van jaren ervaring in de eCommerce sector zelf.

Als er nog geen plugin voor is…

Het wordt nog wat lastiger wanneer je iets wilt wat (nog) niet zomaar in een plugin bestaat. Wanneer jij werkelijk een uniek idee hebt, dan kan je er zeker van zijn, dat hier nog geen plugin voor bestaat. Immers, het ontwikkelen van een plugin is pas interessant als meer mensen het potentieel gaan gebruiken. Je hebt dan eigenlijk maatwerk nodig.

Zelf ben ik oorspronkelijk systeemontwerper en systeemintegrator. Tenminste, wat mijn arbeidsverleden betreft. Mijn opleidingsachtergrond ligt op het gebied van theologie en psychologie. Ik ben dus gewend om soms hele complexe systemen te ontwerpen. Dingen te bedenken, die nog niemand bedacht heeft.

Maar als die dingen ook in detail gerealiseerd moeten worden, dan had je vroeger in WordPress een probleem. Want hoewel alles technisch mogelijk was, moest dit allemaal in detail worden ‘uitgeprogrammeerd’ in PHP. En dat kost tijd. En tijd is geld.

Het is goed beroemd te zijn!

Het voordeel van een beroemdheid te zijn, is dat iedereen iets met je te maken wilt hebben. Wanneer je toevallig ‘WordPress’ heet, en het meest beroemde CMS ter aarde bent, dan is de kans groot dat er een aantal programmeurs zijn die je willen plezieren. Het duurde ook niet lang, of er kwamen allerlei plugins die het makkelijker moesten maken om eigen toepassingen in WordPress te maken.

Rapid Application Development

Wanneer we software ontwikkelen door eigenlijk kant en klare voorgedefinieerde componenten ‘aan elkaar’ te koppelen, dan spreken we van ‘Rapid Application Development’ of RAD.

Het mooie van WordPress is dat WordPress zelf eigenlijk al heel veel componenten in zich heeft om van RAD gebruik te kunnen maken. Want heel WordPress is gericht op het hergebruik van code en ‘informatieobjecten’ in WordPress zelf. ‘Code is Poetry’ is niet voor niets de slagzin van de WordPress.org site.

Wat deze plugins feitelijk doen, is deze ‘standaard objecten’ van WordPress dusdanige benaderbaar maken, dat je zelf -zonder een regel te programmeren- informatie aan de objecten toe kan voegen, nieuwe objecten definieren en al deze zaken met elkaar in verband brengen.

In dit blogartikel wil ik een drietal nader met jou bekijken.

Ik beperk mij hierbij tot dit drietal, omdat ik hier daadwerkelijk mee gewerkt heb of nog steeds mee werk. Een belangrijke reden hiervoor is, dat deze plugins vaak heel wat praktijk ervaring eisen om te kunnen bepalen of ze aan de doelen voldoen. Je moet er als het ware eerst een serieus project mee voltooid hebben, voor je er iets zinvols over kan zeggen.

Toolset

Toolset is hier de veteraan in het spel. Het is allemaal begonnen met ‘WP Types’, een makkelijke manier om Custom Post Types te maken. Omdat je gegevens die je op wilt slaan later ook weer terug wilt zien, werd daar al snel WP Views aan toegevoegd… en langzaamaan breidde het aantal plugins zich zo uit, dat de makers zich realiseerden, dat dit niet langer een ‘set plugins’ was maar een complete gereedschapskoffer.

En het totaal werd omgedoopt naar de productnaam ‘Toolset’.

Ik heb hier een aantal jaren naar volle tevredenheid mee gewerkt voor zowel mij als mijn klanten. In een tijd dat bijna niets mogelijk was, tenzij tegen hoge kosten voor de klant, kon ik Toolset gebruiken voor heel wat toepassingen.

Maar naarmate de mogelijkheden van Toolset groeiden, groeide ook de overhead. De Toolset die in 2013 nog nauwelijks impact had op de performance van sites, legt hier nu een groot beslag op. Bovendien, de licenties voor Toolset zijn ook best kostbaar. En toen de makers in 2016 besloten dat de ‘Lifetime licentie’ kwam te vervallen, omdat ze gebruik gingen maken van een nieuw licentiesysteem en iedereen die een ‘Lifetime licentie’ had gekocht maar een nieuwe ‘Licentie per jaar’ moet kopen, hield ik het voor gezien.

De mogelijkheden van Toolset

Toolset is een heel krachtige set van ‘gereedschappen’. Het begint allemaal met de ‘Types’ module. Met behulp van types kan je zonder een regel te programmeren nieuwe ‘Custom Post Types’ definieren. Een ‘Custom Post Type’ is een gegeven type wat is gebaseerd op de ‘Bericht / Pagina’ structuur van WordPress.

Wanneer je met verschillende WordPress toepassingen hebt gewerkt, dan heb je waarschijnlijk wel gemerkt dat veel lijkt op elkaar. WooCommerce producten of WP Courseware ‘course units’ zien er net zo uit als de berichten en pagina’s. En dat is omdat WordPress heel veel gegevensstructuren en code hergebruikt. Dat maakt WordPress juist zo flexibel.

WP Types helpt je dus bij het definiëren van deze nieuwe gegevensstructuren.

WP Views

Door middel van WP Views kan je vervolgens die gegevens weer zichtbaar maken. Alleen… WP Views is niet iets waarmee je ‘What you See is What you Get’ pagina’s kan maken. Je moet de pagina’s in detail ‘uitcoderen’ in HTML met speciale codes om de gegevens in te voegen. En hoewel ik hier veel sneller mee kan werken, dan wanneer ik een aparte plugin zou moeten bouwen, kost werken hiermee toch nog heel wat tijd.

CRED – Forms

Daarnaast bevat Toolset ook een module die ‘CRED, Create, Read / Retrieve, Edit, Delete’ genoemd werd maar later tot ‘Forms’ is omgedoopt. CRED/Forms maakt het mogelijk om formulieren te maken waarmee de gebruiker zelf zijn gegevens bij kan houden.

Later zijn er nog diverse modulen toegevoegd aan deze ‘Toolset’, maar aangezien deze minder direct met het onderwerp van dit artikel hebben te maken, laat ik deze even buiten beschouwing.

Advanced Custom Fields

Advanced Custom Fields (ACF) biedt niet de mogelijkheid om zelf nieuwe ‘Custom Post Types’ aan te maken, maar wel de functies om een bestaand post type uit te breiden met extra velden. Met behulp van short codes en template tags kan ik daarna deze informatie weer zichtbaar maken op de website. Omdat het gebruik van deze informatie op de website tot voor kort aan programmeurs was voorbehouden -’template tags’ zijn code fragmenten die je in een thema gebruikt, wanneer je een thema programmeert- heb ik nooit veel aandacht aan ACF gegeven in mijn blog. Per slot van rekening blog ik niet voor programmeurs maar voor eindgebruikers.

ACF is pas interessant geworden voor de eindgebruiker, sinds het mogelijk is om via een theme builder als Elementor Pro (ik ken nog geen andere plugin die dit kan) direct de informatie uit deze velden te tonen.

In mijn blogartikel over resource pagina’s recentelijk heb ik laten zien hoe je ACF en Elementor (Pro) makkelijk in combinatie met elkaar kan gebruiken. Toch heeft ACF de nodige beperkingen. Eigenlijk is deze plugin alleen geschikt, wanneer je eenvoudige toepassingen hebt. Zoals het voorbeeld van de ‘Resource Items’. Wanneer je het voor je toepassing nodig hebt om meerdere ‘gegevenssoorten’ met elkaar in verband te brengen, dan is ACF ontoereikend.

Gegevensrelaties

Voor ik nu verder ga met het bespreken van de derde plugin wil ik het even met je over ‘Gegevens relaties’ hebben. Ik merk in de praktijk namelijk vaak genoeg, dat dit iets is, waar mensen die niet in de ICT werken dikwijls niet bij stil staan.

Wanneer ik een applicatie voor het Internet wil maken, dan kan dit soms heel eenvoudig zijn. Laat ik als voorbeeld productadvertenties op een website nemen. Voor een dergelijke toepassing heb ik maar één ding echt nodig. De advertentie.

Wanneer ik echter een web toepassing zou ontwikkelen voor een school, waarbij bijvoorbeeld aangegeven zou worden welke docenten les geven aan welke leerlingen, dan wordt het al iets ingewikkelder.

Complexe relaties

Want docenten geven les aan klassen. Eén klas krijgt mogelijk les van meerdere docenten. En in één klas zitten meerdere leerlingen. Kortom hier komt een complex netwerk van relaties om de hoek kijken. En hierbij negeren we nog even het feit dat één docent les kan geven in meerdere vakken en één vak kan worden gegeven door meerdere docenten.

Dit soort relaties kunnen wanneer je ACF gebruikt onmogelijk beschreven worden, zonder dat je moet gaan programmeren. En werk je met Toolset dan is een complex relationeel model zoals hierboven omschreven ook niet haalbaar. Wil je zo iets toch implementeren zonder direct terug te moeten grijpen op het ontwikkelen van een specifieke plugin, dan is de PODS plugin eigenlijk de enige van de besproken plugins die aan die eisen tegemoet komt.

PODS

Toen ik in 2016 besloot, dat het tijd was om vaarwel te zeggen tegen Toolset, ben ik gaan zoeken of er iets was, wat Toolset kon vervangen. Ik liep toen tegen PODS aan, maar eigenlijk was dit toen nog een vrij onvolwassen product. Het werkte niet echt goed en de documentatie was gewoon slecht. Op basis van een aantal cryptische aantekeningen op een onduidelijke website werd ik geacht te begrijpen wat de bedoeling was.

Nog niet zo gek lang gelezen ben ik -omdat Elementor Pro met PODS integreert- eens op nieuw gaan kijken naar dit product.

En ik was blij verrast om te ontdekken, hoe ver PODS inmiddels geëvalueerd is.

Het PODS concept

Om PODS helemaal te kunnen waarderen, moet je eigenlijk eerst de gedachtegang achter PODS begrijpen. Een ‘pod’ is een peul. Iets wat is ‘ingepakt’. Een ‘Black Box’. Voor je met PODS aan de slag gaat ‘pak je de informatie in’ door een nieuwe POD te maken. De inhoud van zo’n POD kan een Custom Post Type met toegevoegde velden zijn. Deze CPT kan je nieuw gemaakt hebben, of je kan een CPT gebruiken, die door andere plugins zijn aangemaakt (zoals bijvoorbeeld een product in WooCommerce).

Maar je kan ook een ‘POD’ maken van de gebruikerstabel of sommige andere standaard onderdelen van WordPress. Of je eigen ‘Advanced Content Types’ aanmaken. Zo’n ‘Advanced Content Type’ is eigenlijk het best te vergelijken met een traditionele ’tabel .

Daarnaast heeft PODS een soort ‘macro taal’ ontwikkeld, waardoor je met een paar shortcodes eigenlijk enorm veel kan doen. Ik kan bijvoorbeeld in zo’n eerder besproken ‘relationeel model’ alle leerlingen uit een bepaalde klas laten zien. Of alle leerlingen die les hebben van een bepaalde docent.

Met andere woorden, zonder veel problemen, kan ik de relatie tussen verschillende ‘objecten’ laten zien. Iets waarvoor ik in ACF moet gaan programmeren en iets wat in Toolset maar heel beperkt mogelijk is (ik kan daar geen relaties laten zien, waarbij aan beide kanten meerdere gegevens gekoppeld zijn, zoals docenten die les geven in meerdere vakken en meerdere vakken die gegeven worden door verschillende docenten).

Een ander leuk ding is dat PODS eenvoudig te integreren is met Elementor Pro.

Enkele kritische kanttekeningen

In het geval van PODS moet er wel een kanttekening bij die integratie worden gemaakt. Het kost mij geen enkele moeite om de zaken uit een enkelvoudige ‘POD’ te laten zien. Maar wil ik bijvoorbeeld op één pagina iets tonen als de gegevens van een docent met daaronder een lijst met de leerlingen, dan wil dat niet omdat Elementor Pro op dit moment geen voorzieningen voor repeterende gegevens van gerelateerde objecten heeft.

Wat ik wel kan doen is een ‘PODS’ template maken (maar hierin moet ik dan wel HTML gebruiken) waarin deze details worden getoond en vervolgens dit PODS template via een shortcode in Elementor gebruiken.

Het vergelijk

Drie plugins die alle drie ‘iets’ doen met extra gegevensobjecten in WordPress en alle drie verschillend zijn. Ik wil deze plugins op basis van een aantal kenmerken met elkaar vergelijken.

Systeembelasting

ACF is op dit gebied de meest ‘lichte’ plugin. Omdat hier alle voorzieningen voor het zelf definieren van CPT’s ontbreken. Heb ik een CPT nodig, dan kan ik een andere plugin gebruiken om deze te maken (zoals de in een eerder artikel besproken CPT UI plugin), of een online dienst als GenerateWP gebruiken om de code te genereren en daarna deze zelf toe te voegen aan mijn functions.php.

PODS komt hier op een tweede plaats. Het is een vrij complete plugin, maar dit komt ook met een systeembelasting. Wanneer ik een eenvoudige applicatie als de ‘Resource pagina’ in PODS gemaakt zou hebben, dan zou ik dit meer merken op de performance van de website dan nu, nu ik dit in ACF heb gemaakt.

Tenslotte Toolset. Is de vertraging die PODS veroorzaakt ‘meetbaar’, de vertraging die Toolset veroorzaakt is merkbaar, met name wanneer ik meerdere modulen in combinatie ga gebruiken.

Gebruikersgemak

Beperk je je tot alle faciliteiten die de plugins gemeenschappelijk hebben, dan is bij alle plugins het gebruikersgemak vergelijkbaar. PODS is misschien net iets complexer, omdat je eerste de PODS filosofie moet leren begrijpen.

Gaan we een stapje verder, dan laat ACF ons al snel in de steek. Werken we bijvoorbeeld met ‘gerelateerde objecten’, dan biedt ACF geen mogelijkheden meer.

Toolset is vrij rommelig. Om één pagina te bouwen moet ik vaak in meerdere onderdelen van de applicatie HTML fragmenten definieren. Ik zie al snel door de bomen het bos niet meer.

PODS heeft maar één plaats waar ik mogelijk ooit HTML fragmenten moet definieren. Bovendien is de ‘macro taal’ die PODS biedt om HTML fragmenten met data te koppelen heel wat inzichtelijker dan het oerwoud van shortcodes en parameters wat Toolset aanbiedt.

Mogelijkheden

ACF biedt eigenlijk maar één ding: De mogelijkheid om extra velden toe te voegen aan je ‘custom post types’. Dit is voor een groot aantal webapplicaties echter meer dan voldoende.

Toolset biedt een complete ontwikkelomgeving voor webapplicaties. De enige beperking hier, is dat de objecten uitsluitend aan elkaar gerelateerd kunnen zijn in een zogenaamde ‘1:n relatie’. Bij ieder ‘child’ object is slechts één ‘parent’. De vraag is echter hoe noodzakelijk het is om 1:n relaties te implementeren in jouw specifieke webtoepassing.

PODS biedt veel meer en bredere mogelijkheden. Bijzonder interessant is de mogelijkheid om ook ‘interne zaken’ zoals commentaren, gebruikers etc in PODS te gebruiken. Een ander interessante mogelijkheid is die van de ‘Advanced Post Types’, ook informatie die niet echt goed in een CPT structuur past kan ik op deze manier in de applicatie verwerken.

Prijs

ACF is gratis. Er is een PRO versie te koop, waarmee het aantal veldtypen kan worden uitgebreid, maar standaard biedt ACF eigenlijk al voldoende veldtypen om een goede toepassing te bouwen. Koop je deze uitbreiding, dan betaal je hiervoor een éénmalig bedrag.

Toolset is vrij prijzig. Op dit moment betaal je bijna 300 dollar per jaar voor een onbeperkte licentie. Daarnaast heeft het bedrijf achter deze plugin weinig vertrouwen bij mij gewekt door ‘levenslange licenties’ ineens ongeldig te verklaren en ontwikkelaars naar de ‘licenties per jaar’ te dwingen.

PODS is op dit moment gratis. Ik zeg nadrukkelijk ‘op dit moment’, omdat achter PODS een bedrijf zit. En bedrijven moeten geld verdienen. Het verdienmodel achter WordPress is mij bijvoorbeeld heel duidelijk. Automattic, de makers van WordPress, bieden dit gratis aan, omdat ze hun geld verdienen met allerlei extra diensten rond WordPress (Akismet, de JetPack premium modules en niet te vergeten een groot aantal betaalde WooCommerce extensies). Ik zie totaal geen verdienmodel achter PODS. En het zou niet de eerste keer zijn, dat een initieel gratis plugin ineens ‘betaald’ wordt op het moment dat deze aan populariteit heeft gewonnen.

Maar zoals gezegd, nu is hij gratis.

Conclusie

Na dit alles op een rijtje te hebben gezet leek mij de conclusie eigenlijk wel duidelijk. Er is geen enkele goede reden te bedenken om Toolset te gebruiken. Ooit, tot zo’n drie jaar geleden, waren ze het enige initiatief op dit gebied in de markt. Maar ondertussen hebben ze niet gewerkt aan de werkelijke verbetering van het product (bijvoorbeeld niets gedaan om het sneller te maken), terwijl de prijzen enorm de lucht in gegaan zijn.

ACF is een prima product voor eenvoudige toepassingen. En het grote voordeel van ACF is, dat het geen merkbare impact op de snelheid van je site heeft.

Worden de toepassingen complexer, dan is PODS de grote winnaar.

Hierbij nog een belangrijke kanttekening. Ben je een ’typische eindgebruiker’, dan zijn Toolset en PODS beide misschien niet wat je zoekt. Want met beide producten ga je aan de slag met HTML, CSS en een eigen ‘macrotaaltje’ om een eindresultaat te bereiken. Ben je dit allemaal niet machtig, maar heb je wel een geweldig idee voor een webapplicatie, dan is het vaak beter om een derde partij als WordXPression hiervoor in te schakelen. Het voordeel van PODS en Toolset is hierbij, dat complexe applicaties tegen lagere kosten kunnen worden gemaakt.

Als ’typische eindgebruiker’ kan je echter prima aan de slag met de combinatie van ACF en Elementor Pro.