Custom Post Types, Custom Taxonomies en Custom Fields

Custom Post Types, de bouwstenen van WordPress

In diverse blogartikelen heb ik in de afgelopen jaren ‘Custom Post Types’ genoemd. Meestal ook met enige uitleg, wat dat precies is, maar regelmatig krijg ik toch nog de vraag wat een ‘Custom Post Type’ nu eigenlijk is. En hoe dit zich verhoud met ‘Custom Taxonomies’ en ‘Custom Fields’. Dus ik besloot, dat het tijd werd om eens een compleet blogartikel te wijden aan wat al deze zaken nu precies zijn en vooral, hoe deze samenhangen.

WordPress – Alleen om te bloggen

Toen Matt Mullenweg en Mike Little in mei de eerste versie van WordPress aan de wereld presenteerden, was WordPress een programma met maar één doel. Bloggen. En in een aantal jaren groeide WordPress uit tot het meest populaire blog platform wat je zelf kon hosten. Maar de WordPress bloggers wilden meer. Want een blog is natuurlijk leuk, maar als blogger wil je toch ook wat over jezelf kunnen vertellen. En om dat mogelijk te maken heb je naast blogposts ook pagina’s nodig.

En op het moment dat besloten werd, dat WordPress in de toekomst ook pagina’s zou gaan ondersteunen, werden er eigenlijk twee belangrijke juiste beslissingen genomen, die ervoor zouden zorgen, dat WordPress niet alleen het meest populaire blog platform zou worden, maar ook het meest populaire CMS platform.

Herbruikbare tabellen

De blogposts in WordPress worden opgeslagen in een tabel die (standaard) wp_posts heet. De ‘prefix’ (wp_) is tijdens de installatie van WordPress aan te geven, en het is meer dan verstandig, om niet voor een standaard wp_ prefix te kiezen, maar voor het gemak blijf ik het in dit artikel wp_posts noemen. In deze tabel worden de belangrijkste gegevens over je blogpost opgeslagen. De titel, de inhoud, de auteur, verschillende data etc.

Toen -met ingang van WordPress 1.5 besloten werd, dat WordPress voortaan ook pagina’s zou moeten ondersteunen, lag het eigenlijk heel erg voor de hand, om een tweede tabel te maken, met de naam wp_pages. Zou hiervoor gekozen zijn, dan zou de populariteit van WordPress mogelijk niet zo’n vlucht hebben genomen, want daarmee zou het tweede idee, wat het werkelijke succes van WordPress zou worden, nooit van de grond gekomen zijn.

Maar omdat men niet verwachtte, dat er veel pagina’s aangemaakt zouden worden -wat heb je als blogger meer nodig, dan een ‘over mij’ en een ‘contact’ pagina?- werd besloten geen aparte tabel aan te maken, maar in plaats daarvan de ‘pagina’. gewoon in de wp_posts tabellen op te slaan.

Custom post types

Daarnaast werd besloten om niet alleen die ‘pages’ op te nemen in de ‘wp_posts’ tabellen, maar ook andere informatie. Bij het uitbrengen van WordPress 2.0 was dat alleen ‘Attachments’, maar later kwamen ‘Revisions’, ‘Nagivation menu’s’, ‘Custom CSS’ en ‘Changesets’ daar ook bij.

Wat echter nog veel belangrijker was, was dat ook het besluit werd genomen om ‘in de toekomst’ er ook een mogelijkheid zou moeten komen om de programmeur van een plugin zelf extra post types te laten definiëren. De ‘custom post types’. En sinds WordPress 2.4 werd de Custom Post Type API openbaar gemaakt, waardoor iedere programmeur zijn of haar eigen post types aan WordPress toe kon voegen.

Wat maakt Custom Post Types dan zo krachtig?

Stel je voor. Jij bent een plugin ontwikkelaar. En jij wilt een plugin ontwikkelen, waarin de gebruikers van de plugin hun evenementen kunnen publiceren. Je zal dan eerst een ‘datamodel’ moeten maken, hoe de gegevens opgeslagen moeten worden. Voor het gemak gaan we even van twee objecten uit : Evenementen en Locaties. Op iedere locatie kunnen meerdere evenementen gehouden worden. Heb je dus een tweede evenement op dezelfde locatie, hoef je de gegevens niet opnieuw in te voegen.

Als programmeur moet je dan pagina’s maken om de evenementen bij te houden, pagina’s om de locaties bij te houden. Komen er in een toekomstige versie van de plugin nieuwe velden bij in een tabel voor evenementen of locaties, zal je ook conversie scripts moeten schrijven om van de éne versie naar de andere te converteren.

Kortom, het is behoorlijk wat werk. En omdat tijd geld is, zouden plugin heel wat duurder zijn en maatwerk zou voor de meeste ZZP-ers en MKB-ers onbetaalbaar zijn. Het idee van de ‘custom post type’ zorgt er echter voor, dat het relatief makkelijk is om zowel de dataopslag als de beheerspagina’s voor gegevens aan WordPress toe te voegen.

De kern van WordPress bestaat namelijk uit slechts twee tabellen, wp_posts en wp_postmeta. De tabel wp_posts bevat informatie die door verschillende

De ‘klassieke’ benadering

Even een heel eenvoudig voorbeeld. Stel, dat ik op de klassieke manier een NAW (Naam, Adres, Woonplaats) tabel op zou willen bouwen. Mijn tabel zou er dan -sterk vereenvoudigd- als volgt uit kunnen zien :

Voor ieder ‘dataobject’ moet ik een aparte tabel aanmaken.

De WordPress benadering

De WordPress benadering lijkt in eerste instantie complexer. Maar bedenk, dat niet jij maar de computer die gegevens bij elkaar moet zoeken. In een sterk vereenvoudigd voorbeeld, eerst heb je de tabel wp_posts, die er ongeveer zou uit zou kunnen zien

In bovenstaande tabel zie je, dat in één tabel verschillende soorten gegevens voorkomen, ‘naw’ gegevens en (wat het ook mag zijn) ‘cpt’ gegevens. Het veld ‘Post Type’ geeft namelijk het soort gegevens aan. Naast deze tabel, is er nog een tweede tabel met metadata. Slechts een deel wordt hier weergegeven:

Enzovoorts….

De kolom ‘Post ID’ verwijst naar de ‘ID’ in de hoofdtabel. Dus alle regels met een Post ID van 1, horen bij Jan Jansen, ook als ze niet direct onder elkaar staan (zie de laatste regel in het voorbeeld), 2 bij Toon Ladder etc.

Door voor een dergelijke opslagstructuur te kiezen, heb je twee grote voordelen.

Het eerste voordeel is, dat je inplaats van tientallen tabellen -minimaal één tabel voor ieder informatie object- slechts twee tabellen nodig hebt. Het tweede voordeel is, dat je informatieobjecten makkelijk uitbreidbaar zijn. Heb je nieuwe ‘velden’ nodig, dan hoeven er geen database conversies plaats te vinden.

Toch heeft deze aanpak ook nadelen. Met name voor rapportages. Stel bijvoorbeeld dat ik drie informatieobjecten zou hebben. locaties, evenementen en evenement bezoekers. Wanneer ik het aantal bezoekers boven een bepaalde leeftijd per evenement uit de database zou willen halen, dan is dat niet eenvoudig te doen. ‘Ad hoc’ vraagstellingen zijn lastig uit de database te halen.

Zelf custom post types maken

Toen WordPress 2.4 publiek werd, was het algemene idee, dat het zelf maken van post types iets was voor de plugin programmeur. Het zal je waarschijnlijk weinig verbazen, dat er al snel ook plugins kwamen om zelf post types te kunnen definiëren. Een aantal jaren geleden heb ik een drietal plugins met elkaar vergeleken, waarmee dat mogelijk is. Er zijn echter ook tientallen andere plugins, waarmee je zelf een custom post type kan definiëren. De eenvoudigste om mee te werken is -denk ik zelf- CPT UI.

De slug voor je custom post types

Welke plugin je ook gebruikt, het algemene idee is hetzelfde. Er zijn 3 secties met belangrijke gegevens die je in moet vullen. In de eerste sectie vul je de labels voor je Custom Post Type in (enkelvoud en meervoud) en de ‘slug’.

Voor die ‘slug’ moet je met een aantal zaken rekening houden.

• Je kan de slug (naam) later niet meer aanpassen. Wanneer je dat wel doet, dan wordt er een nieuw Custom Post Type aangemaakt.
• Namen voor Custom Post Types moeten uniek zijn. Je kan dus geen naam gebruiken, die door een plugin al aangemaakt zijn.
• Wanneer je in het verleden een plugin geïnstalleerd hebt gehad, die een bepaalde slug gebruikte en je gebruikt nu die slug opnieuw, dan kan het zijn, dat oude data ‘zichtbaar’ wordt.
  Stel, je hebt ooit een events plugin gebruikt. Daar ben je vanaf gestapt, plugin is weg, en nu maak je een eigen ‘events’ CPT aan. Tot je verbazing zal je merken, dat alle events die je met de oude plugin hebt aangemaakt er weer zijn. Die kan je eventueel verwijderen met behulp van de plugin Bulk Delete. Met deze plugin kan je specifieke post types in één keer verwijderen.
• Tenzij je bepaalde instellingen aanpast (zie later in dit artikel) zal de door jou gebruikte slug deel uit gaan maken van de URL. Kies dus slugs die SEO technisch interessant zijn.

De labels voor je custom post types

De tweede sectie is het ingeven van de labels voor je custom post type. Dat zijn de labels die zichtbaar zijn in het Dashboard. Zelf besteed ik daar voor mijzelf weinig aandacht aan, werk ik aan een opdracht voor een klant, dan steek ik de nodige energie in de vertaling hiervan.

De CPT-UI plugin heeft een handige optie om de labels automatisch te genereren. Hier zal af en toe wat fout gaan in het Nederlands (Nieuw vs. Nieuwe bv), maar is het voor mijzelf, dan stoor ik mij hier niet aan.

Hieronder zie je een deel van die automatisch gegenereerde labels.

Custom Post Types parameters

Vervolgens komt er een sectie met parameters die je in kan stellen, om aan te geven hoe een custom post type zich moet gedragen.

Dit artikel concentreert zich rond het gebruik van custom post types die in de pagina’s van je website op de één of andere manier zichtbaar moeten worden gemaakt. Vanuit dit gebruik staat een groot aantal parameters in de afbeelding hieronder al ‘goed’. Ik bespreek daarom uitsluitend de parameters waar je daadwerkelijk een keuze bij moet maken. De rest van de parameters kan je gewoon overnemen vanuit het screenshot hieronder.

• Verwijder met gebruiker Geef je ‘Ja’ aan bij ‘verwijder met gebruiker dan zullen alle posts van dit type worden verwijderd, wanneer de gebruiker die ze heeft aangemaakt wordt verwijderd. Dit kan bijvoorbeeld handig zijn, wanneer jouw custom post type advertenties van gebruikers zouden zijn. Verwijder je de gebruiker, worden ook de advertenties van die gebruiker verwijderd.
• Toon in REST API – Ik ga hier niet in op alles met betrekking tot de rest API, maar wanneer je hier ‘Ja’ opgeeft, dan kan je de Gutenberg editor gebruiken, geef je ‘Nee’ op, dan kan dit niet, en krijg je de klassieke editor.
• Archief – Is er wel of geen archief voor dit post type. Ofwel, kan je dit post type ook op overzichtspagina’s laten zien. Dit zal meestal ‘Ja’ zijn, maar ik kan mij enkele situaties indenken, waarbij je dat niet wilt.
• Hiërarchie – Heeft dit post type ‘child’ posts van hetzelfde type. Denk hierbij bijvoorbeeld aan ‘Pagina’s’, waarbij onder een pagina meerdere sub-pagina’s kunnen bestaan of ‘menu’ waarbij onder een menu verschillende submenu’s kunnen voorkomen. In de meeste gevallen zal ‘Hiërarchie’ echter ‘nee’ zijn.
• Kan exporteren – Wil je de gegevens kunnen exporteren met de WordPress export functie. Is alleen van belang als je de WordPress exportfunctie gebruikt.
• Menu-icoon – De Dash icoon die je voor het menu wilt gebruiken of de URL naar een afbeelding van 20×20 pixels. Vul je hier niets in krijg je een tandwiel. Voor eigen gebruik neem ik de moeite niet hier iets in te vullen.
• Ondersteunt – Welke onderdelen van een custom post type wil je hier ondersteunen. Door dingen wel of niet aan te vinden worden bepaalde onderdelen wel of niet getoond in de userinterface.
  • Titel – Moet er wel of niet een titel zichtbaar zijn om in te kunnen vullen?
  • Editor – Wil je dat de editor (Gutenberg of Klassiek, zie ook ‘Toon in REST API’) gebruikt kan worden?
  • Uitgelichte afbeelding – Wel of geen uitgelichte afbeelding gewenst?
  • Samenvatting – Wil je wel of niet dat er een samenvatting van de content ingevuld kan worden.
  • Trackbacks – Eén advies: Nooit aanzetten!
  • Extra velden – Bespreken we verderop. Zal je meestal niet aan willen zetten.
  • Reacties – Wil je wel of niet, dat er reacties op je post type gegeven kunnen worden.
  • Revisies – Wil je dat bij aanpassingen de ‘oude’ versie ook blijft bestaan, zodat je altijd een aantal stappen terug kan?
  • Auteur – Wil je de auteur gegevens opslaan. Deze instelling heeft ook invloed op ‘Verwijder met gebruiker’ (als de auteur gegevens niet worden opgeslagen, zal ‘verwijder met gebruiker’ ook niet werken).
  • Pagina attributen – Noodzakelijk bij Hiërarchise post typen, anders niet
  • Berichtformaat – Valt buiten de scope van dit artikel.
    

Velden toevoegen aan je Custom Post Type

Met het maken van je custom post type heb je als het ware een kapstok gemaakt, waar je je gegevens aan op kan hangen. Nou ja, eigenlijk al een beetje meer dan alleen maar een kapstok. Want wanneer je jouw post type hebt opgeslagen, dan zie je links in het dashboard al een menu item met de naam van je custom post type staan. Klik je op dat menu item, zie je ook een tweetal andere opties ‘Alle (naam van je CPT)’ en ‘(Naam van je CPT) toevoegen’ staan.

Maar stel nu dat je een custom post type ‘Evenement’ zou hebben aangemaakt. Jouw evenement is natuurlijk meer dan alleen een omschrijving en een titel. Er is een begin- en mogelijk een einddatum, er is een prijs, er is een locatie. Kortom er is allerlei extra informatie die jij aan jouw evenement zou willen toevoegen.

Om dat te kunnen doen moet je ‘custom fields’ aanmaken. Of -zoals het in het Nederlands wordt vertaald- ‘extra velden’. Nu wordt dit direct vanuit WordPress ondersteund, maar het is niet echt een fijne manier van werken.

Laten we eerst eens kijken, hoe dit door WordPress wordt ondersteund. Let op: Wanneer je de plugin ‘Advanced Custom Fields’ al geïnstalleerd hebt staan, zal dit niet werken!

We gaan naar een willekeurige blogpost in het Dashboard en klikken op de 3 puntjes rechtsboven in beeld. In het menu wat nu verschijnt, klikken we op ‘voorkeuren’. Dan wordt de volgende pop up zichtbaar:

We klikken hier op ‘Panelen’, en daarna -onder ‘Extra’- schakelen we aangepaste velden in. Wanneer je dat gedaan hebt, moet je de pagina herladen.

Na het herladen van de pagina zie je onder de tekst de volgende box:

Wat ik hier zie zijn de technische namen van verschillende velden. Je zal snappen dat dit niet de meest duidelijke manier is om extra informatie aan een post type toe te voegen. En dat is dan ook de belangrijkste reden, dat we dit ook niet willen gebruiken. In plaats daarvan maken we gebruik van een plugin die ons helpt om extra velden toe te voegen aan WordPress. Hier zijn verschillende plugins voor beschikbaar zoals Toolset, Advanced Custom Fields, PODS, Carbon Fields en JetEngine. De meest gebruikersvriendelijke hier is Advanced Custom Fields. De meest uitgebreide -en bovendien geheel gratis- is Carbon Fields, het enige nadeel van deze plugin is dat deze niet makkelijk in combinatie met Elementor is te gebruiken.

Advanced Custom Fields

Het grote nadeel van de WordPress eigen ‘custom fields’ is dat er geen enkele vorm van controle op de inhoud en het gebruik van de velden is.

Je hebt geen idee welke velden je in moet vullen, je hebt geen enkel idee wat de velden betekenen en je hebt ook geen enkel idee hoe je een veld in moet vullen. Want moet je bijvoorbeeld een datum als YYYYMMDD, YYYY-MM-DD invullen, of op een compleet andere manier (bijvoorbeeld als ‘Unix datum’, wat het aantal seconden is, wat er inmiddels sinds 01-01-1970 is verstreken?)

Bovendien wordt het ook lastig om meer complexe velden toe te voegen. Zou ik bijvoorbeeld een afbeelding toe willen voegen, dan zou ik eerst een afbeelding moeten uploaden, de URL opzoeken en die URL kopiëren en plakken in het veld.

En daarom is er een aantal plugins gemaakt die het toevoegen van dit soort extra velden makkelijker moet maken. Omdat ik zelf veel met Elementor doe, en inmiddels de ondersteuning vanuit Elementor voor Advanced Custom Fields (ACF) het best is, werk ik graag met ACF.

Bij de bespreking van de Custom Post Types had ik al aangegeven, dat een custom post type zelf geen velden voor informatie heeft. Die voegen we er apart aan toe.

Een plugin als ACF doet een aantal dingen om dit makkelijk te maken :

1. De plugin zorgt ervoor, dat de ‘extra velden’ worden opgeslagen in de database.
2. De plugin zorgt ervoor, dat er een duidelijke omschrijving (veld label plus eventuele invulinstructies) bij ieder veld staat.
3. De plugin zorgt ervoor, dat er een controle op de inhoud van de velden wordt uitgevoerd.
4. De plugin zorgt voor een juiste opslag bij complexe velden (vergelijk het voorbeeld van de afbeelding, die ik zojuist genoemd heb)
5. Wanneer er een onderlinge afhankelijkheid tussen velden is, zal ACF ervoor zorgen, dat ook deze integriteit gewaarborgd blijft (datum begin moet lager zijn dan datum einde bijvoorbeeld)
6. De plugin zorgt voor een juiste presentatie van de content aan de frontend van de website.

Een praktische invulling

Om te zien hoe het praktisch werkt kijken we even naar de velden in mijn eigen Custom Post Type ’trainingen’. Met ’trainingen’ laat ik aan mijn site bezoekers zien welke trainingen er beschikbaar zijn en zorg ik voor een consistente opmaak van alle trainingen op de WordXPression website.

ACF -en de meeste andere ‘velden’ plugins- werken met het idee van ‘veld sets’ of ‘veld groepen’. ACF noemt het groepen. En de veldgroep’ Trainingen’ bevat alle velden die bij elkaar horen.

De velden koppelen aan een post type

De volgende stap is het instellen wanneer deze velden nu bij welk post type worden getoond. En hier is Advanced Custom Fields wat uitgebreider dan veel van de andere velden plugins.

Bij veel plugins koppel je een set velden aan een specifiek post type. Dus -zoals ik het hier zelf gebruik – Het post-type moet gelijk zijn aan ‘Training’.

Maar ik kan hier meer. Stel, dat ik een bepaalde set velden alleen wil zien, wanneer de post tot een bepaalde categorie behoort… dan kan ik ook kiezen voor ‘Bericht Taxonomy’ en dan een specifieke categorie.

Dat biedt heel wat mogelijkheden.

Custom Taxonomies

De laatste magische bouwsteen in het begrijpen van de uitgebreide mogelijkheden van WordPress Custom Post Types is ‘Custom Taxonomies’.

Om te begrijpen wat dat is, moet je in eerste instantie natuurlijk het woord ‘Taxonomy’ begrijpen. Een ’taxonomie’ is eigenlijk gewoon een heel duur woord voor ‘indeling’. We hebben de neiging om alles in hokjes en groepjes in te willen delen, en hoewel dat niet altijd goed is, is het vooral voor het terugvinden van informatie wel handig.

En met WordPress heb je ook al met die ’taxonomies’ te maken gekregen. Want ‘Categorieën’ en ‘Tags’ zijn twee voorbeelden van hoe taxonomies geïmplementeerd zijn in WordPress.

Je kan zelf ook je eigen taxonomieën aanmaken in WordPress. Stel, ik heb een site waar ik boeken op bespreek. En bij zo’n boek wil ik een aantal kenmerken van dat boek opnemen. Bijvoorbeeld het ISBN nummer, het Genre, de Schrijver en de Uitgeverij.

Nu is een ISBN nummer uniek. En dat zou ik dus typisch als ‘Custom Field’ op willen nemen. Maar zaken als Genre, Schrijver en Uitgeverij zijn niet uniek. Een schrijver kan meerdere boeken schrijven, er is pas sprake van een ‘genre’ als er meerdere boeken van eenzelfde soort zijn verschenen, en doorgaans zal een uitgeverij ook meerdere boeken uitgeven.

Dit soort informatie leent zich er dus goed toe om als ‘Custom Taxonomy’ te worden geïmplementeerd. Een bijkomend voordeel is, dat je direct informatie op deze taxonomie kan filteren, simpel door erop te klikken.

Je eigen Custom Taxonomy toevoegen

Wanneer je CPT-UI als plugin voor je Custom Post Types gebruikt, is het toevoegen van een Custom Taxonomy eigenlijk een fluitje van een cent. Net zoals bij het Custom Post Type bestaat het definiëren van een Custom Taxonomy met deze plugin uit een drietal stappen.

Definiëer de slug voor je custom taxonomy

Het eerste wat je zal moeten doen is de slug voor je Custom Taxonomy te definiëren. Hiervoor gelden eigenlijk alle regeltjes, die ook voor een Custom Post Type gelden. Het is dus verstandig dit nog even na te lezen.

Bij het definiëren van een taxonomy is het mogelijk dit direct aan één of meerdere Custom Post Types te koppelen. In het verleden heb ik meer dan eens mee mogen maken, dat meerdere custom post types gekoppeld aan één taxonomie problemen opleveren. Hoewel technisch niet vereist, beveel ik toch van harte aan om slechts één post type aan een taxonomie te koppelen. Meerdere custom taxonomies aan één custom post type is geen probleem.

Dus ‘Mijn Categorie’ en ‘Mijn tags’ gekoppeld aan ‘Mijn CPT’ is ok. ‘Categorieën’ gekoppeld aan ‘Berichten’ en ‘Mijn CPT’ is een slecht idee.

De labels aanpassen…

Zie ook het toevoegen / aanpassen van de labels bij de bespreking van Custom Post Types. Het werkt hetzelfde.

De parameters instellen…

Ook dit werkt grotendeels hetzelfde als voor de Custom Post Types, met echter dit verschil, dat de actuele parameters andere namen en betekenissen hebben.

Hieronder zie je een afbeelding met de meest gebruikelijke instellingen. Daar waar een instelling enige discussie nodig heeft, zal ik dit onder de afbeelding bespreken.

Er zijn hier heel wat parameters die ingevuld kunnen worden, maar gelukkig valt het mee wat hier daadwerkelijk belangrijk is.

In zijn algemeenheid is het goed de parameters in te stellen zoals hierboven, met een aantal zaken waar je rekening mee moet houden.

• Hiërarchie – Hiermee geef je in principe de ‘stijl’ aan, waarin de taxonomie gebruikt gaat worden. Staat Hiërarchie op ‘Ja’, dan zal de gebruikersinterface voor de taxonomie er uitzien als voor Categorieën. Staat het op ‘Nee’, dan ziet het eruit als Tags.
• Toon in REST-API – Wat hier belangrijk is, is dat dit dezelfde waarde heeft als de parameter ‘Toon in REST-API’ van de bijbehorende Custom Post Type. Staat het CPT op ‘Ja’ en staat hier de waarde op ‘Nee’, dan zal de taxonomie niet zichtbaar worden in de editor. Staat de CPT op ‘Nee’ en de taxonomie op ‘Ja’, dan gaat er in principe niets fout, maar wordt er ’teveel’ geladen in de REST-API.

En nu… je Custom Post Type zichtbaar maken!

Wanneer je een Custom Post Type, met Custom Fields en Custom Taxonomies hebt gedefinieerd en je kijkt er naar via een standaard WordPress thema, dan lijkt het erop, dat je heel veel werk voor niets hebt gedaan. Want al die extra taxonomieën en die extra velden die blijven onzichtbaar!

Dat was natuurlijk niet de bedoeling.

Maar wel logisch, want jou thema heeft er geen idee van, wanneer je extra velden wel of niet getoond moeten worden.

Je zal dus eigen templates moeten maken voor specifieke custom post types. En daarvoor moet je programmeren. Wil je leren hoe je jouw eigen thema’s voor WordPress kan bouwen, dan verwijs ik je graag naar mijn cursus voor WordPress Developer. In dit artikel wijs ik je op de mogelijkheden om jouw Custom Post Type op te nemen in een template zonder te hoeven programmeren.

PODS en Toolset

De eerder genoemde plugins ‘PODS’ en ‘Toolset’ bieden een mogelijkheid om zelf templates te maken. Dit kan je doen zonder te programmeren, maar je moet wel je weg in HTML en CSS weten, het opmaken van de pagina doe je namelijk op deze manier.

Dit is natuurlijk leuk voor een webdesigner, maar een ‘eindgebruiker’ van een WordPress website zal er weinig behoefte aan hebben om eerst HTML en CSS te leren, voor men aan de slag kan gaan.

Theme Builders als Elementor Pro, BeaverBuilder en Thrive Architect

De meest eigentijdse manier om gebruik te maken van de mogelijkheden van Custom Post Types is door deze in combinatie met een theme builder als Elementor Pro, BeaverBuilder of Thrive Architect te gebruiken. Zoals de regelmatige lezer van deze blog weet, ben ik zelf een groot voorstander van Elementor Pro.

In Elementor Pro kan je binnen de ‘Theme Builder’ heel makkelijk aangeven dat een ‘Single Post Template’ of een ‘Archive Template’ gebruikt moet worden voor een specifiek post type. Heb je dat gedaan, dan kan je -nog steeds even makkelijk- specifieke elementen op het scherm laten vullen met de tekst die is opgeslagen in Custom Fields, PODS velden, ACF velden of Toolset velden. Kennis van HTML of CSS is absoluut niet noodzakelijk.

Wil je meer weten over hoe je dit kan doen, verwijs ik je graag naar mijn cursus ‘Elementor voor Gevorderden’.