{"id":76897,"date":"2024-03-04T14:11:09","date_gmt":"2024-03-04T13:11:09","guid":{"rendered":"https:\/\/kinsta.com\/it\/?p=76897&preview=true&preview_id=76897"},"modified":"2024-03-12T18:30:19","modified_gmt":"2024-03-12T17:30:19","slug":"versioni-gratuite-e-pro-plugin-wordpress","status":"publish","type":"post","link":"https:\/\/kinsta.com\/it\/blog\/versioni-gratuite-e-pro-plugin-wordpress\/","title":{"rendered":"Progettare un plugin di WordPress che supporti le estensioni"},"content":{"rendered":"

Nell’ecosistema WordPress, l’adozione di un modello freemium<\/a> \u00e8 un metodo prevalente per promuovere e monetizzare i plugin commerciali. Questo approccio prevede il rilascio gratuito di una versione di base del plugin, di solito attraverso la directory dei plugin di WordPress<\/a>, e l’offerta di funzionalit\u00e0 avanzate attraverso una versione PRO o dei componenti aggiuntivi, di solito venduti sul sito web del plugin.<\/p>\n

Esistono tre modi diversi per integrare le funzionalit\u00e0 commerciali in un modello freemium:<\/p>\n

    \n
  1. Inserire le funzionalit\u00e0 commerciali all’interno del plugin gratuito e attivarle solo quando la versione commerciale viene installata sul sito web o viene fornita una chiave di licenza commerciale.<\/li>\n
  2. Creare le versioni gratuite e PRO come plugin indipendenti, con la versione PRO progettata per sostituire la versione gratuita, assicurando che sia installata una sola versione in qualsiasi momento.<\/li>\n
  3. Installare la versione PRO accanto al plugin gratuito, estendendone le funzionalit\u00e0. Ci\u00f2 richiede la presenza di entrambe le versioni.<\/li>\n<\/ol>\n

    Tuttavia, il primo approccio \u00e8 incompatibile con le linee guida<\/a> per i plugin distribuiti tramite la directory dei plugin di WordPress, in quanto queste regole vietano l’inclusione di funzionalit\u00e0 limitate o bloccate fino al pagamento o all’aggiornamento.<\/p>\n

    Rimangono quindi le ultime due opzioni, che presentano vantaggi e svantaggi. Le sezioni seguenti spiegano perch\u00e9 l’ultima strategia, “PRO in aggiunta a free”, \u00e8 la scelta migliore.<\/p>\n

    Partiremo approfondendo la seconda opzione, “PRO come sostituto di free”, i suoi difetti e i motivi per cui \u00e8 sconsigliata.<\/p>\n

    Successivamente, analizzeremo in modo approfondito la strategia “PRO in aggiunta a free”, evidenziando il motivo per cui \u00e8 la scelta migliore.<\/p>\n

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

    Vantaggi della strategia “PRO come sostituto di free”<\/h2>\n

    La strategia “PRO come sostituto di free” \u00e8 relativamente facile da implementare perch\u00e9 gli sviluppatori possono utilizzare un’unica base di codice per entrambi i plugin (free e PRO) e creare due output, con la versione free (o “standard”) che include semplicemente un sottoinsieme del codice e la versione PRO che include tutto il codice.<\/p>\n

    Ad esempio, la base di codice del progetto potrebbe essere suddivisa nelle directory standard\/<\/code> e pro\/<\/code>. Il plugin caricherebbe sempre il codice standard, mentre il codice PRO verrebbe caricato in modo condizionale, in base alla presenza della rispettiva directory:<\/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
    Quindi, quando si genera il plugin tramite uno strumento di integrazione continua<\/a>, possiamo creare le due risorse myplugin-standard.zip<\/code> e myplugin-pro.zip<\/code> dallo stesso codice sorgente.<\/p>\n
    Se il progetto \u00e8 ospitato su GitHub e si generano le risorse tramite le GitHub Actions, il flusso di lavoro seguente svolge il suo compito:<\/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
    Problemi con la strategia “PRO come sostituto di free”<\/h2>\n
    La strategia “PRO come sostituto di free” prevede la sostituzione del plugin gratuito con la versione PRO. Di conseguenza, se il plugin gratuito viene distribuito tramite la directory dei plugin di WordPress, il suo conteggio delle “installazioni attive” diminuir\u00e0 (poich\u00e9 tiene conto solo del plugin gratuito e non della versione PRO), dando l’impressione che il plugin sia meno popolare di quanto non sia in realt\u00e0.<\/p>\n
    Questo risultato vanificherebbe lo scopo dell’utilizzo della directory dei plugin di WordPress come canale di scoperta dei plugin in cui gli utenti possono scoprire il nostro plugin, scaricarlo e installarlo. (Una volta installato, il plugin gratuito pu\u00f2 invitare gli utenti a passare alla versione PRO).<\/p>\n
    Se il numero di installazioni attive non \u00e8 elevato, gli utenti potrebbero non essere convinti a installare il nostro plugin. Come esempio di come le cose possono andare male, i proprietari del plugin Newsletter Glue hanno deciso di rimuoverlo dalla directory dei plugin di WordPress<\/a>, poich\u00e9 il basso numero di attivazioni stava danneggiando le prospettive del plugin.<\/p>\n
    Poich\u00e9 la strategia “PRO come sostituto di free” non \u00e8 praticabile, ci rimane solo una scelta: la strategia “PRO in aggiunta a free”.<\/p>\n
    Analizziamo i dettagli di questa strategia.<\/p>\n
    Concetto di strategia “PRO in aggiunta a free”<\/h2>\n
    L’idea \u00e8 che il plugin gratuito venga installato sul sito e che le sue funzionalit\u00e0 possano essere estese installando altri plugin o addon. Questo pu\u00f2 avvenire tramite un singolo plugin PRO o tramite una serie di estensioni o addon PRO, ognuno dei quali fornisce una funzionalit\u00e0 specifica.<\/p>\n
    In questa situazione, il plugin gratuito non si preoccupa di quali altri plugin siano installati sul sito. Tutto ci\u00f2 che fa \u00e8 fornire funzionalit\u00e0 aggiuntive. Questo modello \u00e8 versatile e consente l’espansione sia agli sviluppatori originali che ai creatori di terze parti, favorendo un ecosistema in cui un plugin pu\u00f2 evolvere in direzioni impreviste.<\/p>\n
    Notate che non importa se le estensioni PRO saranno prodotte da noi (cio\u00e8 dagli stessi sviluppatori del plugin standard) o da qualcun altro: il codice per gestire entrambi \u00e8 lo stesso. Per questo motivo, \u00e8 una buona idea creare una base che non limiti le modalit\u00e0 di estensione del plugin. In questo modo, gli sviluppatori di terze parti potranno estendere il nostro plugin in modi che non avevamo previsto.<\/p>\n
    Approcci progettuali: hook e contenitori di servizi<\/h2>\n
    Esistono due approcci principali per rendere estensibile il codice PHP:<\/p>\n
      \n
    1. Tramite gli hook per le azioni e i filtri<\/a> di WordPress<\/li>\n
    2. Tramite un contenitore di servizi<\/a><\/li>\n<\/ol>\n
      Il primo approccio \u00e8 il pi\u00f9 comune tra gli sviluppatori di WordPress, mentre il secondo \u00e8 preferito dalla pi\u00f9 ampia comunit\u00e0 PHP<\/a>.<\/p>\n
      Vediamo alcuni esempi di entrambi.<\/p>\n
      Rendere il codice estensibile tramite hook per azioni e filtri<\/h2>\n
      WordPress offre degli hook<\/a> (filtri e azioni) come meccanismo per modificare il comportamento. Gli hook per i filtri sono utilizzati per sovrascrivere i valori e gli hook per le azioni per eseguire funzionalit\u00e0 personalizzate.<\/p>\n
      Il nostro plugin principale pu\u00f2 essere “disseminato” di hook in tutto il suo codice, consentendo agli sviluppatori di modificarne il comportamento.<\/p>\n
      Un buon esempio di ci\u00f2 \u00e8 WooCommerce<\/a>, che ha dato vita a un enorme ecosistema di componenti aggiuntivi, la maggior parte dei quali \u00e8 di propriet\u00e0 di fornitori di terze parti. Questo \u00e8 possibile grazie all’ampio numero di hook<\/a> offerti da questo plugin.<\/p>\n
      Gli sviluppatori di WooCommerce hanno aggiunto di proposito gli hook, anche se loro stessi non ne avevano bisogno. Vengono, per\u00f2, utilizzati da altri. Notate il gran numero di hook per le azioni “prima” e “dopo”:<\/p>\n