{"id":74018,"date":"2024-03-04T14:04:05","date_gmt":"2024-03-04T13:04:05","guid":{"rendered":"https:\/\/kinsta.com\/es\/?p=74018&preview=true&preview_id=74018"},"modified":"2024-03-06T13:59:19","modified_gmt":"2024-03-06T12:59:19","slug":"pro-versiones-libres-plugin-wordpress","status":"publish","type":"post","link":"https:\/\/kinsta.com\/es\/blog\/pro-versiones-libres-plugin-wordpress\/","title":{"rendered":"Dise\u00f1ar un plugin de WordPress que admita extensiones"},"content":{"rendered":"

En el ecosistema de WordPress, la adopci\u00f3n de un modelo freemium<\/a> es un m\u00e9todo predominante para promocionar y monetizar plugins comerciales. Este enfoque implica lanzar una versi\u00f3n b\u00e1sica del plugin de forma gratuita \u2014 normalmente a trav\u00e9s del directorio de plugins de WordPress<\/a> \u2014 y ofrecer funciones mejoradas a trav\u00e9s de una versi\u00f3n PRO o add-ons, que suelen venderse en el sitio web del plugin.<\/p>\n

Hay tres formas diferentes de integrar funciones comerciales en un modelo freemium:<\/p>\n

    \n
  1. Incluir estas funciones comerciales dentro del plugin gratuito, y activarlas s\u00f3lo cuando se instale la versi\u00f3n comercial en el sitio web o se proporcione una clave de licencia comercial.<\/li>\n
  2. Crea las versiones gratuita y PRO como plugins independientes, con la versi\u00f3n PRO dise\u00f1ada para sustituir a la versi\u00f3n gratuita, garantizando que s\u00f3lo haya una versi\u00f3n instalada en cada momento.<\/li>\n
  3. Instalar la versi\u00f3n PRO junto al plugin gratuito, ampliando su funcionalidad. Esto requiere que ambas versiones est\u00e9n presentes.<\/li>\n<\/ol>\n

    Sin embargo, el primer enfoque es incompatible con las directrices<\/a> para plugins distribuidos a trav\u00e9s del directorio de plugins de WordPress, ya que estas normas proh\u00edben la inclusi\u00f3n de funciones restringidas o bloqueadas hasta que se realice un pago o una actualizaci\u00f3n.<\/p>\n

    Esto nos deja con las dos \u00faltimas opciones, que ofrecen ventajas e inconvenientes. Las siguientes secciones explican por qu\u00e9 la \u00faltima estrategia, \u00abPRO sobre gratis\u00bb, es nuestra mejor opci\u00f3n.<\/p>\n

    Vamos a profundizar en la segunda opci\u00f3n, \u00abPRO como sustituto de gratis\u00bb, sus defectos y por qu\u00e9, en definitiva, no es recomendable.<\/p>\n

    Posteriormente, exploramos en profundidad la \u00abPRO sobre gratis\u00bb, destacando por qu\u00e9 se erige como la opci\u00f3n preferida.<\/p>\n

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

    Ventajas de la estrategia \u00abPRO como sustituto de gratis\u00bb<\/h2>\n

    La estrategia \u00abPRO como sustituto de gratis\u00bb es relativamente f\u00e1cil de aplicar porque los desarrolladores pueden utilizar un \u00fanico c\u00f3digo base para ambos plugins (free y PRO) y crear dos productos a partir de \u00e9l, con la versi\u00f3n gratuita (o \u00abest\u00e1ndar\u00bb) incluyendo simplemente un subconjunto del c\u00f3digo, y la versi\u00f3n PRO incluyendo todo el c\u00f3digo.<\/p>\n

    Por ejemplo, el c\u00f3digo base del proyecto podr\u00eda dividirse en los directorios standard\/<\/code> y pro\/<\/code>. El plugin cargar\u00eda siempre el c\u00f3digo est\u00e1ndar, y el c\u00f3digo PRO se cargar\u00eda condicionalmente, en funci\u00f3n de la presencia del directorio respectivo:<\/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
    Entonces, al generar el plugin mediante una herramienta de Integraci\u00f3n Continua<\/a>, podemos crear los dos activos myplugin-standard.zip<\/code> y myplugin-pro.zip<\/code> a partir del mismo c\u00f3digo fuente.<\/p>\n
    Si alojas el proyecto en GitHub y generas los activos mediante Acciones de GitHub, el siguiente flujo de trabajo realiza el trabajo:<\/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 con la estrategia \u00abPRO como sustituto de gratis\u00bb<\/h2>\n
    La estrategia \u00abPRO como sustituto de gratis\u00bb exige sustituir el plugin gratuito por la versi\u00f3n PRO. Como consecuencia, si el plugin gratuito se distribuye a trav\u00e9s del directorio de plugins de WordPress, su recuento de \u00abinstalaciones activas\u00bb descender\u00e1 (ya que s\u00f3lo rastrea el plugin gratuito, no la versi\u00f3n PRO), dando la impresi\u00f3n de que el plugin es menos popular de lo que realmente es.<\/p>\n
    Este resultado anular\u00eda el prop\u00f3sito de utilizar el directorio de plugins de WordPress en primer lugar: Como un canal de descubrimiento de plugins en el que los usuarios pueden conocer nuestro plugin, descargarlo e instalarlo. (Despu\u00e9s, una vez instalado, el plugin gratuito puede invitar a los usuarios a actualizarse a la versi\u00f3n PRO).<\/p>\n
    Si el n\u00famero de instalaciones activas no es elevado, es posible que los usuarios no se convenzan de instalar nuestro plugin. Como ejemplo de c\u00f3mo las cosas pueden ir mal, los propietarios del plugin Newsletter Glue decidieron eliminar el plugin del directorio de plugins de WordPress<\/a>, ya que el bajo recuento de activaciones estaba perjudicando las posibilidades del plugin.<\/p>\n
    Como la estrategia \u00abPRO como sustituto de gratis\u00bb no es viable, s\u00f3lo nos queda una opci\u00f3n: la estrategia \u00abPRO sobre gratuito\u00bb.<\/p>\n
    Exploremos los entresijos de esta estrategia.<\/p>\n
    Conceptualizaci\u00f3n de la estrategia \u00abPRO sobre gratis\u00bb<\/h2>\n
    La idea es que el plugin gratuito se instala en el sitio, y su funcionalidad puede ampliarse instalando plugins o addons adicionales. Puede ser mediante un \u00fanico plugin PRO o mediante una colecci\u00f3n de extensiones o addons PRO, cada uno de los cuales proporciona una funcionalidad espec\u00edfica.<\/p>\n
    En esta situaci\u00f3n, al plugin gratuito no le importa qu\u00e9 otros plugins est\u00e1n instalados en el sitio. Lo \u00fanico que hace es proporcionar una funcionalidad adicional. Este modelo es vers\u00e1til, ya que permite la expansi\u00f3n tanto por parte de los desarrolladores originales como de terceros creadores, fomentando un ecosistema en el que un plugin puede evolucionar en direcciones imprevistas.<\/p>\n
    Por favor, f\u00edjate en que no importa si las extensiones PRO ser\u00e1n producidas por nosotros (es decir, los mismos desarrolladores que construyen el plugin est\u00e1ndar), o por alguien m\u00e1s: El c\u00f3digo para tratar con ambos es el mismo. Por lo tanto, es una buena idea crear una base que no restrinja c\u00f3mo se puede ampliar el plugin. Esto har\u00e1 posible que los desarrolladores de terceros ampl\u00eden nuestro plugin de formas que no hab\u00edamos concebido.<\/p>\n
    Enfoques de dise\u00f1o: hooks y contenedores de servicios<\/h2>\n
    Hay dos enfoques principales para hacer extensible el c\u00f3digo PHP:<\/p>\n
      \n
    1. A trav\u00e9s de los hooks de acci\u00f3n y filtro<\/a> de WordPress<\/li>\n
    2. A trav\u00e9s de un contenedor de servicios<\/a><\/li>\n<\/ol>\n
      El primer enfoque es el m\u00e1s com\u00fan entre los desarrolladores de WordPress, mientras que el segundo es el preferido por la comunidad PHP<\/a> en general.<\/p>\n
      Veamos ejemplos de ambos.<\/p>\n
      Hacer extensible el c\u00f3digo mediante hooks de acciones y filtros<\/h2>\n
      WordPress ofrece hooks<\/a> (filtros y acciones) como mecanismo para modificar el comportamiento. Los hooks de filtro se utilizan para anular valores, y los hooks de acci\u00f3n para ejecutar funcionalidades personalizadas.<\/p>\n
      Nuestro plugin principal puede entonces estar \u00abplagado\u00bb de hooks por toda su base de c\u00f3digo, permitiendo a los desarrolladores modificar su comportamiento.<\/p>\n
      Un buen ejemplo de esto es WooCommerce<\/a>, que ha extendido un enorme ecosistema de add-ons, la mayor\u00eda de los cuales pertenecen a proveedores de terceros. Esto es posible gracias al amplio n\u00famero de hooks<\/a>\u00a0que ofrece este plugin.<\/p>\n
      Los desarrolladores de WooCommerce han a\u00f1adido hooks a prop\u00f3sito, aunque ellos mismos no los necesiten. Es para que otro los utilice. F\u00edjate en el gran n\u00famero de hooks de acci\u00f3n \u00abbefore\u00bb(antes) y \u00abafter\u00bb(despu\u00e9s):<\/p>\n