{"id":58652,"date":"2024-03-04T14:14:30","date_gmt":"2024-03-04T13:14:30","guid":{"rendered":"https:\/\/kinsta.com\/nl\/?p=58652&preview=true&preview_id=58652"},"modified":"2024-03-12T18:30:28","modified_gmt":"2024-03-12T17:30:28","slug":"pro-gratis-versies-wordpress-plugin","status":"publish","type":"post","link":"https:\/\/kinsta.com\/nl\/blog\/pro-gratis-versies-wordpress-plugin\/","title":{"rendered":"Zo bouw je een WordPress plugin die extensies ondersteunt"},"content":{"rendered":"

In het WordPress ecosysteem is het gebruik van een freemium model<\/a> een veelgebruikte methode voor het promoten en te gelde maken van commerci\u00eble plugins. Deze aanpak houdt in dat je een basisversie van de plugin gratis uitbrengt – meestal via de WordPress plugin directory<\/a> – en uitgebreide features aanbiedt via een PRO versie of add-ons, die meestal verkocht worden op de website van de plugin.<\/p>\n

Er zijn drie verschillende manieren om commerci\u00eble functies te integreren in een freemium model:<\/p>\n

    \n
  1. Herberg deze commerci\u00eble functies in de gratis plugin en activeer ze alleen als de commerci\u00eble versie op de website is ge\u00efnstalleerd of als er een commerci\u00eble licentiesleutel is verstrekt.<\/li>\n
  2. Maak de gratis en PRO versies als onafhankelijke plugins, waarbij de PRO versie ontworpen is om de gratis versie te vervangen, zodat er altijd maar \u00e9\u00e9n versie ge\u00efnstalleerd is.<\/li>\n
  3. Installeer de PRO versie naast de gratis plugin en breid de functionaliteit uit. Hiervoor moeten beide versies aanwezig zijn.<\/li>\n<\/ol>\n

    De eerste benadering is echter onverenigbaar met de richtlijnen<\/a> voor plugins die worden gedistribueerd via de WordPress plugin directory, omdat deze regels verbieden om functies op te nemen die beperkt of vergrendeld zijn totdat er een betaling of upgrade is gedaan.<\/p>\n

    Dan blijven de laatste twee opties over, die voor- en nadelen hebben. De paragrafen hieronder leggen uit waarom de laatste strategie, “PRO naast gratis”, onze beste keuze is.<\/p>\n

    Maar laten we eerst kijken naar de tweede optie, “PRO die de gratis versie vervangt”, de gebreken ervan en waarom het uiteindelijk niet wordt aanbevolen.<\/p>\n

    Daarna gaan we dieper in op “PRO naast gratis”, waarbij we uitleggen waarom dit de beste keuze is.<\/p>\n

    <\/div><\/kinsta-auto-toc>\n

    Voordelen van de “PRO die de gratis versie vervangt” strategie<\/h2>\n

    De “PRO die de gratis versie vervangt” strategie is relatief eenvoudig te implementeren omdat de ontwikkelaars een enkele codebase kunnen gebruiken voor beide plugins (gratis en PRO) en er twee uitgangen van kunnen maken, waarbij de gratis (of “standaard”) versie eenvoudigweg een subset van de code bevat en de PRO versie alle code.<\/p>\n

    De codebase van het project zou bijvoorbeeld kunnen worden opgesplitst in standard\/<\/code> en pro\/<\/code> directories. De plugin zou altijd de standaardcode laden, waarbij de PRO code voorwaardelijk wordt geladen, gebaseerd op de aanwezigheid van de betreffende map:<\/p>\n

    \/\/ Main plugin file: myplugin.php\n\n\/\/ Always load the standard plugin's code\nrequire_once __DIR__ . '\/standard\/load.php';\n\n\/\/ Load the PRO plugin's code only if the folder exists\n$proFolder = __DIR__ . '\/pro';\nif (file_exists($proFolder)) {\n  require_once $proFolder . '\/load.php';\n}\n<\/code><\/pre>\n
    Wanneer we dan de plugin genereren via een Continuous Integration<\/a> tool, kunnen we de twee assets myplugin-standard.zip<\/code> en myplugin-pro.zip<\/code> maken van dezelfde sourcecode.<\/p>\n
    Als we het project hosten op GitHub en de assets genereren via GitHub Actions, dan doet de volgende workflow het werk:<\/p>\n
    name: Generate the standard and PRO plugins\non:\n  release:\n    types: [published]\n\njobs:\n  process:\n    name: Generate plugins\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout code\n        uses: actions\/checkout@v3\n\n      - name: Install zip\n        uses: montudor\/action-zip@v1.0.0\n\n      - name: Create the standard plugin .zip file (excluding all PRO code)\n        run: zip -X -r myplugin-standard.zip . -x **\/src\/\\pro\/\\*\n\n      - name: Create the PRO plugin .zip file\n        run: zip -X -r myplugin-pro.zip . -x myplugin-standard.zip\n\n      - name: Upload both plugins to the release page\n        uses: softprops\/action-gh-release@v1\n        with:\n          files: |\n            myplugin-standard.zip\n            myplugin-pro.zip\n        env:\n          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n<\/code><\/pre>\n
    Problemen met de “PRO die de gratis versie vervangt” strategie<\/h2>\n
    De “PRO die de gratis versie vervangt” strategie vereist het vervangen van de gratis plugin door de PRO versie. Als gevolg daarvan, als de gratis plugin wordt gedistribueerd via de WordPress plugin directory, zal het aantal “actieve installaties” dalen (omdat alleen de gratis plugin wordt bijgehouden, niet de PRO versie), waardoor de indruk wordt gewekt dat de plugin minder populair is dan hij in werkelijkheid is.<\/p>\n
    Dit zou het doel van het gebruik van de WordPress plugin directory teniet doen: Als een ontdekkingskanaal van plugins waar gebruikers onze plugin kunnen vinden, downloaden en installeren. (Daarna, als het eenmaal ge\u00efnstalleerd is, kan de gratis plugin gebruikers uitnodigen om te upgraden naar de PRO versie).<\/p>\n
    Als het aantal actieve installaties niet hoog is, worden gebruikers wellicht niet overtuigd om onze plugin te installeren. Een voorbeeld van hoe het mis kan gaan: de eigenaren van de Newsletter Glue plugin besloten om de plugin te verwijderen uit de WordPress plugin directory<\/a>, omdat het lage aantal actieve installaties de vooruitzichten van de plugin schaadde.<\/p>\n
    Omdat de “PRO die de gratis versie vervangt” strategie niet levensvatbaar is, blijft er maar \u00e9\u00e9n keuze over: de “PRO bovenop gratis” strategie.<\/p>\n
    Laten we de ins en outs van deze strategie bekijken.<\/p>\n
    Conceptualisering van de “PRO naast gratis” strategie<\/h2>\n
    Het idee is dat de gratis plugin op de site wordt ge\u00efnstalleerd en dat de functionaliteit kan worden uitgebreid door extra plugins of addons te installeren. Dit kan via een enkele PRO plugin of via een verzameling PRO extensies of addons, waarbij elk van hen een specifieke functionaliteit biedt.<\/p>\n
    In deze situatie maakt het de gratis plugin niet uit welke andere plugins er op de site ge\u00efnstalleerd zijn. Het enige wat het doet is extra functionaliteit bieden. Dit model is veelzijdig en biedt ruimte voor uitbreiding door zowel de oorspronkelijke developers als externe makers, waardoor een ecosysteem ontstaat waarin een plugin zich in onvoorziene richtingen kan ontwikkelen.<\/p>\n
    Merk op dat het niet uitmaakt of de PRO uitbreidingen door ons geproduceerd worden (d.w.z. dezelfde developers die de standaard plugin bouwen), of door iemand anders: De code om met beide om te gaan is hetzelfde. Daarom is het een goed idee om een basis te cre\u00ebren die geen beperkingen oplegt aan hoe de plugin kan worden uitgebreid. Dit maakt het mogelijk voor externe d om onevelopers ze plugin uit te breiden op manieren waar wij niet aan gedacht hadden.<\/p>\n
    Ontwerpbenaderingen: hooks en service containers<\/h2>\n
    Er zijn twee hoofdbenaderingen om PHP code uitbreidbaar te maken:<\/p>\n
      \n
    1. Via de WordPress action- en filterhooks<\/a><\/li>\n
    2. Via een service container<\/a><\/li>\n<\/ol>\n
      De eerste benadering is het meest gebruikelijk onder WordPress developers, terwijl de laatste de voorkeur heeft van de bredere PHP community<\/a>.<\/p>\n
      Laten we voorbeelden van beide bekijken.<\/p>\n
      Code uitbreidbaar maken via action- en filterhooks<\/h2>\n
      WordPress biedt hooks<\/a> (filters en actions) als een mechanisme om gedrag aan te passen. Filterhooks worden gebruikt om waarden te overschrijven en actionhooks om aangepaste functionaliteit uit te voeren.<\/p>\n
      Onze hoofdplugin kan dan worden “bezaaid” met hooks in de hele codebase, zodat developers het gedrag kunnen aanpassen.<\/p>\n
      Een goed voorbeeld hiervan is WooCommerce<\/a>, dat een enorm ecosysteem van add-ons heeft, waarvan de meerderheid eigendom is van derde partijen. Dit is mogelijk dankzij het uitgebreide aantal hooks<\/a> dat deze plugin biedt.<\/p>\n
      De devs van WooCommerce hebben doelbewust hooks toegevoegd, ook al hebben ze die zelf niet nodig. Iemand anders kan ze gebruiken. Let op het grote aantal “after” en “before” actionhooks:<\/p>\n