{"id":67419,"date":"2024-03-04T10:18:57","date_gmt":"2024-03-04T13:18:57","guid":{"rendered":"https:\/\/kinsta.com\/pt\/?p=67419&preview=true&preview_id=67419"},"modified":"2024-03-08T09:59:06","modified_gmt":"2024-03-08T12:59:06","slug":"plugin-wordpress-suporte-extensoes","status":"publish","type":"post","link":"https:\/\/kinsta.com\/pt\/blog\/plugin-wordpress-suporte-extensoes\/","title":{"rendered":"Como Projetar um Plugin de WordPress para Oferecer Suporte a Extens\u00f5es"},"content":{"rendered":"

No ecossistema do WordPress, adotar um modelo freemium<\/a> \u00e9 um m\u00e9todo comum para promover e monetizar plugins comerciais. Essa abordagem envolve lan\u00e7ar uma vers\u00e3o b\u00e1sica do plugin gratuitamente, geralmente atrav\u00e9s do diret\u00f3rio de plugins do WordPress<\/a>, e oferecer funcionalidades avan\u00e7adas por meio de uma vers\u00e3o PRO ou complementos, normalmente vendidos no site do plugin.<\/p>\n

H\u00e1 tr\u00eas maneiras diferentes de integrar funcionalidades comerciais em um modelo freemium:<\/p>\n

    \n
  1. Incluir funcionalidades comerciais no plugin gratuito, ativando-as apenas quando a vers\u00e3o comercial estiver instalada no site ou mediante o fornecimento de uma chave de licen\u00e7a comercial.<\/li>\n
  2. Criar vers\u00f5es gratuita e PRO como plugins independentes, com a vers\u00e3o PRO projetada para substituir a vers\u00e3o gratuita, garantindo que apenas uma vers\u00e3o seja instalada em um determinado momento.<\/li>\n
  3. Instalar a vers\u00e3o PRO com o plugin gratuito, ampliando sua funcionalidade. Para isso, \u00e9 necess\u00e1rio que ambas as vers\u00f5es estejam presentes.<\/li>\n<\/ol>\n

    No entanto, a primeira abordagem \u00e9 incompat\u00edvel com as diretrizes<\/a> para plugins distribu\u00eddos por meio do diret\u00f3rio de plugins do WordPress, pois essas regras pro\u00edbem a inclus\u00e3o de funcionalidades que s\u00e3o restritos ou bloqueados at\u00e9 que um pagamento ou atualiza\u00e7\u00e3o seja feito.<\/p>\n

    Isso nos leva \u00e0s duas \u00faltimas op\u00e7\u00f5es dispon\u00edveis, cada uma apresentando seus pr\u00f3s e contras. Nas se\u00e7\u00f5es seguintes, detalharemos os motivos pelos quais a \u00faltima estrat\u00e9gia, denominada “Vers\u00e3o PRO sobre a Gratuita”, representa a nossa escolha ideal.<\/p>\n

    Vamos detalhar a segunda op\u00e7\u00e3o, “PRO como substituto do gratuito”, e discutir seus pontos fracos, esclarecendo o motivo pelo qual n\u00e3o a recomendamos.<\/p>\n

    Em seguida, daremos uma aten\u00e7\u00e3o especial ao “PRO em adi\u00e7\u00e3o ao gratuito”, real\u00e7ando os motivos que o tornam a escolha mais vantajosa.<\/p>\n

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

    Vantagens da estrat\u00e9gia “PRO como substituto do gratuito”<\/h2>\n

    A estrat\u00e9gia “PRO como substituto do gratuito” \u00e9 relativamente f\u00e1cil de implementar porque os desenvolvedores podem usar uma \u00fanica base de c\u00f3digo para ambos os plugins (gratuito e PRO) e criar dois resultados a partir dela, com a vers\u00e3o gratuita (ou “padr\u00e3o”) simplesmente incluindo um subconjunto do c\u00f3digo e a vers\u00e3o PRO incluindo todo o c\u00f3digo.<\/p>\n

    Por exemplo, a base de c\u00f3digo do projeto poderia ser dividida nos diret\u00f3rios standard\/<\/code> e pro\/<\/code>. O plugin sempre carregaria o c\u00f3digo padr\u00e3o, com o c\u00f3digo PRO sendo carregado condicionalmente, com base na presen\u00e7a do respectivo diret\u00f3rio:<\/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
    Ent\u00e3o, ao gerar o plugin por meio de uma ferramenta de integra\u00e7\u00e3o cont\u00ednua<\/a>, podemos criar os dois ativos myplugin-standard.zip<\/code> e myplugin-pro.zip<\/code> a partir do mesmo c\u00f3digo-fonte.<\/p>\n
    Se voc\u00ea hospedar o projeto no GitHub e gerar os ativos por meio do GitHub Actions, o fluxo de trabalho a seguir far\u00e1 o trabalho:<\/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
    Problemas com a estrat\u00e9gia “PRO como substituto do gratuito”<\/h2>\n
    A estrat\u00e9gia “PRO como substituto do gratuito” exige a substitui\u00e7\u00e3o do plugin gratuito pela vers\u00e3o PRO. Como consequ\u00eancia, se o plugin gratuito for distribu\u00eddo por meio do diret\u00f3rio de plugins de WordPress, sua contagem de “instala\u00e7\u00f5es ativas” diminuir\u00e1 (j\u00e1 que ele rastreia apenas o plugin gratuito, n\u00e3o a vers\u00e3o PRO), dando a impress\u00e3o de que o plugin \u00e9 menos popular do que realmente \u00e9.<\/p>\n
    Esse resultado anularia o objetivo de usar o diret\u00f3rio de plugins de WordPress em primeiro lugar: Como um canal de descoberta de plugins em que os usu\u00e1rios podem saber mais sobre nosso plugin, baix\u00e1-lo e instal\u00e1-lo. (Depois disso, uma vez instalado, o plugin gratuito pode convidar os usu\u00e1rios a fazer upgrade para a vers\u00e3o PRO).<\/p>\n
    Se o n\u00famero de instala\u00e7\u00f5es ativas n\u00e3o for expressivo, pode ser dif\u00edcil convencer os usu\u00e1rios a instalar nosso plugin. Um exemplo do que pode dar errado \u00e9 o caso dos desenvolvedores do plugin Newsletter Glue, que optaram por retir\u00e1-lo do diret\u00f3rio de plugins do WordPress<\/a>. A decis\u00e3o foi motivada pelo baixo n\u00famero de ativa\u00e7\u00f5es, o que estava comprometendo o potencial de sucesso do plugin.<\/p>\n
    Como a estrat\u00e9gia “PRO como substituto do gratuito” n\u00e3o \u00e9 vi\u00e1vel, isso nos deixa com apenas uma op\u00e7\u00e3o: a estrat\u00e9gia “PRO baseado no do gratuito”.<\/p>\n
    Vamos explorar os pr\u00f3s e contras dessa estrat\u00e9gia.<\/p>\n
    Conceituando a estrat\u00e9gia “PRO em adi\u00e7\u00e3o ao gratuito”<\/h2>\n
    A ideia \u00e9 que o plugin gratuito seja instalado no site e sua funcionalidade possa ser ampliada com a instala\u00e7\u00e3o de plugins ou complementos adicionais. Isso pode ser feito por meio de um \u00fanico plugin PRO ou por meio de uma cole\u00e7\u00e3o de extens\u00f5es, ou complementos PRO, com cada um deles fornecendo uma funcionalidade espec\u00edfica.<\/p>\n
    Nessa situa\u00e7\u00e3o, o plugin gratuito n\u00e3o se importa com os outros plugins que est\u00e3o instalados no site. Tudo o que ele faz \u00e9 fornecer funcionalidade adicional. Esse modelo \u00e9 vers\u00e1til, permitindo a expans\u00e3o tanto pelos desenvolvedores originais quanto por criadores de terceiros, promovendo um ecossistema em que um plugin pode evoluir em dire\u00e7\u00f5es imprevistas.<\/p>\n
    Note que \u00e9 irrelevante se as vers\u00f5es PRO ser\u00e3o desenvolvidas por n\u00f3s (os mesmos desenvolvedores do plugin padr\u00e3o) ou por terceiros: o c\u00f3digo necess\u00e1rio para gerenciar ambos \u00e9 o mesmo. Portanto, \u00e9 prudente estabelecer uma base que n\u00e3o limite as maneiras como o plugin pode ser ampliado. Isso possibilitar\u00e1 que os desenvolvedores de terceiros ampliem nosso plugin de maneiras que n\u00e3o hav\u00edamos imaginado.<\/p>\n
    Abordagens de design: Hooks e cont\u00eaineres de servi\u00e7o<\/h2>\n
    H\u00e1 duas abordagens principais para tornar o c\u00f3digo PHP extens\u00edvel:<\/p>\n
      \n
    1. Por meio da a\u00e7\u00e3o do WordPress e dos hooks de filtro<\/a><\/li>\n
    2. Por meio de um cont\u00eainer de servi\u00e7o<\/a><\/li>\n<\/ol>\n
      A primeira abordagem \u00e9 a mais comum entre os desenvolvedores WordPress, enquanto a segunda \u00e9 a preferida pela comunidade PHP<\/a> mais ampla.<\/p>\n
      Vamos ver exemplos de ambas.<\/p>\n
      Tornando o c\u00f3digo extens\u00edvel por meio de hooks de a\u00e7\u00e3o e filtro<\/h2>\n
      O WordPress oferece hooks<\/a> (filtros e a\u00e7\u00f5es) como um mecanismo para modificar o comportamento. Os hooks de filtro s\u00e3o usados para substituir valores e os hooks de a\u00e7\u00e3o para executar funcionalidades personalizadas.<\/p>\n
      Nosso plugin principal pode ent\u00e3o ser “cheio” de hooks em toda a sua base de c\u00f3digo, permitindo que os desenvolvedores modifiquem seu comportamento.<\/p>\n
      Um bom exemplo disso \u00e9 o WooCommerce<\/a>, que abrangeu um enorme ecossistema de complementos, sendo que a maioria deles pertence a fornecedores terceirizados. Isso \u00e9 poss\u00edvel gra\u00e7as ao grande n\u00famero de hooks<\/a> oferecidos por esse plugin.<\/p>\n
      Os desenvolvedores do WooCommerce adicionaram hooks propositalmente, mesmo que eles pr\u00f3prios n\u00e3o precisem deles. \u00c9 para que outra pessoa os utilize. Observe o grande n\u00famero de hooks de a\u00e7\u00e3o “antes” e “depois”:<\/p>\n