{"id":69327,"date":"2024-03-04T13:57:24","date_gmt":"2024-03-04T12:57:24","guid":{"rendered":"https:\/\/kinsta.com\/de\/?p=69327&preview=true&preview_id=69327"},"modified":"2024-03-12T18:30:00","modified_gmt":"2024-03-12T17:30:00","slug":"pro-kostenlose-versionen-wordpress-plugin","status":"publish","type":"post","link":"https:\/\/kinsta.com\/de\/blog\/pro-kostenlose-versionen-wordpress-plugin\/","title":{"rendered":"Ein WordPress-Plugin f\u00fcr die Unterst\u00fctzung von Erweiterungen entwickeln"},"content":{"rendered":"

Im WordPress-\u00d6kosystem ist das Freemium-Modell<\/a> eine g\u00e4ngige Methode, um kommerzielle Plugins zu bewerben und zu monetarisieren. Bei diesem Ansatz wird eine Basisversion des Plugins kostenlos ver\u00f6ffentlicht – in der Regel \u00fcber das WordPress-Plugin-Verzeichnis<\/a> – underweiterte Funktionen \u00fcber eine PRO-Version oder Add-ons angeboten, die in der Regel auf der Website des Plugins verkauft werden.<\/p>\n

Es gibt drei verschiedene M\u00f6glichkeiten, kommerzielle Funktionen in ein Freemium-Modell zu integrieren:<\/p>\n

    \n
  1. Binde die kommerziellen Funktionen in das kostenlose Plugin ein und aktiviere sie nur, wenn die kommerzielle Version auf der Website installiert ist oder ein kommerzieller Lizenzschl\u00fcssel bereitgestellt wird.<\/li>\n
  2. Erstelle die kostenlose und die PRO-Version als unabh\u00e4ngige Plugins, wobei die PRO-Version die kostenlose Version ersetzen soll, um sicherzustellen, dass immer nur eine Version installiert ist.<\/li>\n
  3. Installiere die PRO-Version neben dem kostenlosen Plugin und erweitere dessen Funktionen. Dazu m\u00fcssen beide Versionen vorhanden sein.<\/li>\n<\/ol>\n

    Der erste Ansatz ist jedoch unvereinbar mit den Richtlinien<\/a> f\u00fcr Plugins, die \u00fcber das WordPress-Plugin-Verzeichnis vertrieben werden, da diese Regeln die Aufnahme von Funktionen verbieten, die eingeschr\u00e4nkt oder gesperrt sind, bis eine Zahlung oder ein Upgrade erfolgt ist.<\/p>\n

    Damit bleiben uns die letzten beiden Optionen, die Vor- und Nachteile bieten. In den folgenden Abschnitten wird erkl\u00e4rt, warum die letzte Strategie, „PRO zus\u00e4tzlich zu kostenlos“, unsere beste Wahl ist.<\/p>\n

    Die zweite Option, „PRO als Ersatz f\u00fcr kostenlos“, hat ihre M\u00e4ngel und ist nicht zu empfehlen.<\/p>\n

    Anschlie\u00dfend gehen wir n\u00e4her auf die Strategie „PRO zus\u00e4tzlich zu kostenlos“ ein und zeigen auf, warum sie die beste Wahl ist.<\/p>\n

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

    Vorteile der Strategie „PRO als Ersatz f\u00fcr kostenlos“<\/h2>\n

    Die Strategie „PRO als Ersatz f\u00fcr kostenlos“ ist relativ einfach umzusetzen, da die Entwickler\/innen eine einzige Codebasis f\u00fcr beide Plugins (Free und PRO) verwenden und daraus zwei Ausgaben erstellen k\u00f6nnen, wobei die Free-Version (oder „Standard“-Version) einfach eine Teilmenge des Codes enth\u00e4lt und die PRO-Version den gesamten Code umfasst.<\/p>\n

    Zum Beispiel k\u00f6nnte die Codebasis des Projekts in die Verzeichnisse standard\/<\/code> und pro\/<\/code> aufgeteilt werden. Das Plugin w\u00fcrde immer den Standardcode laden, w\u00e4hrend der PRO-Code abh\u00e4ngig vom Vorhandensein des jeweiligen Verzeichnisses geladen wird:<\/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
    Wenn wir das Plugin dann mit einem Continuous Integration<\/a> Tool erstellen, k\u00f6nnen wir die beiden Assets myplugin-standard.zip<\/code> und myplugin-pro.zip<\/code> aus demselben Quellcode erzeugen.<\/p>\n
    Wenn das Projekt auf GitHub gehostet wird und die Assets \u00fcber GitHub Actions erstellt werden, funktioniert der folgende Workflow:<\/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
    Probleme mit der Strategie „PRO als Ersatz f\u00fcr kostenlos“<\/h2>\n
    Die Strategie „PRO als Ersatz f\u00fcr kostenlose Plugin“ verlangt, dass das kostenlose Plugin durch die PRO-Version ersetzt wird. Wenn das kostenlose Plugin \u00fcber das WordPress-Plugin-Verzeichnis verbreitet wird, sinkt die Anzahl der „aktiven Installationen“ (da nur das kostenlose Plugin, nicht aber die PRO-Version erfasst wird), was den Eindruck erweckt, dass das Plugin weniger beliebt ist als es tats\u00e4chlich ist.<\/p>\n
    Dies w\u00fcrde den Zweck des WordPress-Plugin-Verzeichnisses zunichte machen: Als Plugin-Entdeckungskanal, \u00fcber den Nutzer\/innen unser Plugin kennenlernen, herunterladen und installieren k\u00f6nnen. (Nach der Installation kann das kostenlose Plugin dann zum Upgrade auf die PRO-Version einladen).<\/p>\n
    Wenn die Anzahl der aktiven Installationen nicht hoch ist, kann es sein, dass Nutzer\/innen nicht \u00fcberzeugt werden k\u00f6nnen, unser Plugin zu installieren. Ein Beispiel daf\u00fcr, wie es schief gehen kann, ist das Plugin „Newsletter Glue“, das aus dem WordPress-Plugin-Verzeichnis entfernt wurde<\/a>, weil die niedrige Aktivierungszahl die Erfolgsaussichten des Plugins beeintr\u00e4chtigte.<\/p>\n
    Da die Strategie „PRO als Ersatz f\u00fcr kostenlos“ nicht praktikabel ist, bleibt uns nur eine M\u00f6glichkeit: die Strategie „PRO zus\u00e4tzlich zu kostenlos“.<\/p>\n
    Schauen wir uns die Vor- und Nachteile dieser Strategie an.<\/p>\n
    Das Konzept der „PRO zus\u00e4tzlich zu kostenlos“-Strategie<\/h2>\n
    Die Idee ist, dass das kostenlose Plugin auf der Website installiert wird und seine Funktionalit\u00e4t durch die Installation von zus\u00e4tzlichen Plugins oder Addons erweitert werden kann. Dies kann \u00fcber ein einzelnes PRO-Plugin oder \u00fcber eine Sammlung von PRO-Erweiterungen oder Addons geschehen, wobei jede von ihnen eine bestimmte Funktionalit\u00e4t bietet.<\/p>\n
    In diesem Fall ist es f\u00fcr das kostenlose Plugin unerheblich, welche anderen Plugins auf der Website installiert sind. Es stellt lediglich zus\u00e4tzliche Funktionen zur Verf\u00fcgung. Dieses Modell ist vielseitig und erm\u00f6glicht Erweiterungen sowohl durch die urspr\u00fcnglichen Entwickler als auch durch Drittanbieter.<\/p>\n
    Bitte beachte, dass es keine Rolle spielt, ob die PRO-Erweiterungen von uns (d. h. von denselben Entwicklern, die auch das Standard-Plugin erstellen) oder von jemand anderem entwickelt werden: Der Code f\u00fcr beide Varianten ist derselbe. Daher ist es eine gute Idee, eine Grundlage zu schaffen, die die Erweiterungsm\u00f6glichkeiten f\u00fcr das Plugin nicht einschr\u00e4nkt. Das erm\u00f6glicht es Entwicklern von Drittanbietern, unser Plugin auf eine Weise zu erweitern, an die wir nicht gedacht haben.<\/p>\n
    Design-Ans\u00e4tze: Hooks und Service-Container<\/h2>\n
    Es gibt zwei Hauptans\u00e4tze, um PHP-Code erweiterbar zu machen:<\/p>\n
      \n
    1. \u00dcber die WordPress-Action- und Filter-Hooks<\/a><\/li>\n
    2. \u00dcber einen Service-Container<\/a><\/li>\n<\/ol>\n
      Der erste Ansatz ist unter WordPress-Entwicklern am weitesten verbreitet, w\u00e4hrend der zweite Ansatz von der breiteren PHP-Gemeinde<\/a> bevorzugt wird.<\/p>\n
      Sehen wir uns Beispiele f\u00fcr beide an.<\/p>\n
      Code \u00fcber Action- und Filter-Hooks erweiterbar machen<\/h2>\n
      WordPress bietet Hooks<\/a> (Filter und Aktionen) als Mechanismus zur Verhaltens\u00e4nderung. Filter-Hooks werden verwendet, um Werte au\u00dfer Kraft zu setzen, und Action-Hooks, um benutzerdefinierte Funktionen auszuf\u00fchren.<\/p>\n
      Unser Haupt-Plugin kann dann in seiner gesamten Codebasis mit Hooks „\u00fcbers\u00e4t“ werden, damit Entwickler sein Verhalten \u00e4ndern k\u00f6nnen.<\/p>\n
      Ein gutes Beispiel daf\u00fcr ist WooCommerce<\/a>, das ein riesiges \u00d6kosystem von Add-ons umfasst, von denen die meisten von Drittanbietern stammen. Dies ist dank der zahlreichen Hooks<\/a> m\u00f6glich, die dieses Plugin bietet.<\/p>\n
      Die Entwickler von WooCommerce haben absichtlich Hooks hinzugef\u00fcgt, obwohl sie sie selbst nicht brauchen. Jemand anderes soll sie nutzen. Beachte die gro\u00dfe Anzahl von „Vorher“- und „Nachher“-Action-Hooks:<\/p>\n