wordpress
Sistema de licencias para plugins de WordPress: cómo diseñar un servidor de licencias
Vender un plugin implica algo más que cobrar: activar sitios, validar claves y entregar actualizaciones. Arquitectura, riesgos y decisiones de un servidor de licencias.
Por AYM FlowPublicado: Actualizado: 7 min de lectura
Quien desarrolla un plugin de pago pronto descubre que el código es la parte fácil. Lo difícil es todo lo que rodea la venta: emitir claves, limitar los sitios donde se usan, entregar actualizaciones solo a clientes con licencia vigente y gestionar renovaciones sin romper ninguna web. Un servidor de licencias resuelve eso. Aquí se explican su arquitectura, los puntos críticos de seguridad y los errores que conviene evitar.
Qué hace un sistema de licencias (y qué no)
Un detalle previo condiciona todo el diseño: los plugins de WordPress que se distribuyen deben ser compatibles con la licencia GPL, lo que significa que el código no puede ocultarse ni bloquearse legalmente. Por eso, el sistema de licencias no «protege» el código; controla el acceso a lo que sí tiene valor comercial: actualizaciones, soporte, servicios en la nube y funciones asociadas.
En la práctica, un sistema de licencias debe:
- Emitir claves vinculadas a un cliente, un plan y una fecha de vencimiento.
- Registrar en qué sitios está activada cada clave y respetar el límite de cada plan.
- Validar periódicamente que la licencia sigue vigente.
- Autorizar la descarga de actualizaciones solo a licencias válidas.
- Permitir al cliente desactivar un sitio y trasladar la activación a otro.
Arquitectura: cliente en el plugin y servidor central
El diseño habitual tiene dos piezas. El cliente es un módulo dentro del plugin que muestra la pantalla de licencia, guarda la clave y habla con el servidor. El servidor es una aplicación aparte, con su propia base de datos, que expone una API pequeña y estable:
- Activar: recibe la clave, el dominio y la versión del plugin; comprueba el plan y el límite de sitios y registra la activación.
- Verificar: confirma el estado (activa, caducada, revocada) de forma periódica.
- Desactivar: libera una activación.
- Información de actualización: devuelve la última versión, el registro de cambios y una URL de descarga temporal para licencias válidas.
El servidor puede ser un plugin de WordPress en un sitio propio, un servicio de terceros o una aplicación a medida. Una aplicación propia ofrece más control sobre planes, reglas y facturación; es la ruta que AYM Flow siguió para AYM Multilingual, con licencias de uno a cinco sitios descritas en la página de precios.
Modelo de datos y reglas de negocio
Un modelo mínimo con tres tablas cubre casi todos los casos: licencias (clave, cliente, plan, estado, vencimiento), activaciones (licencia, dominio normalizado, versión, fecha de la última comprobación) y planes (límite de sitios, funciones incluidas). Algunas decisiones merecen atención:
- Normalizar el dominio (sin protocolo, sin `www`, en minúsculas) para no contar dos veces el mismo sitio.
- Distinguir entornos de desarrollo y producción, para que un sitio de pruebas local no consuma una activación.
- Definir el periodo de gracia tras el vencimiento: qué pasa con las actualizaciones y con las funciones.
- Registrar los eventos (activación, revocación, reembolso) para atender al soporte con datos, no con suposiciones.
Entrega de actualizaciones desde el servidor propio
WordPress comprueba las actualizaciones consultando un transient del sistema. Para que un plugin privado aparezca en la pantalla de actualizaciones, el cliente se engancha a ese proceso con el filtro `pre_set_site_transient_update_plugins` e informa de la nueva versión y de la URL de descarga. El filtro `plugins_api` permite además mostrar la ficha con el registro de cambios.
La URL de descarga no debe ser un enlace permanente: debe generarse al vuelo, estar firmada o asociada a un token con caducidad corta y comprobar la licencia en cada petición. De lo contrario, un enlace filtrado equivale a una licencia gratuita para siempre.
Seguridad del servidor de licencias
Si el servidor falla o es vulnerable, los problemas llegan a todos los clientes a la vez. Los puntos mínimos:
- Comunicación solo por HTTPS y validación estricta de cada parámetro en el servidor.
- Limitar la tasa de peticiones por IP y por clave para frenar la adivinación de claves.
- Claves largas y aleatorias, generadas con una fuente criptográficamente segura; no basadas en el correo del cliente ni en fechas.
- Nunca confiar en el cliente: toda decisión de acceso se toma en el servidor, porque el código del plugin es legible y editable.
- Cumplir con las pautas generales de seguridad de plugins también en el módulo cliente: nonces, comprobación de capacidades y escapado.
Experiencia de usuario: fallar con elegancia
Un fallo del servidor de licencias nunca debe romper el sitio del cliente. Esto implica guardar en caché el último estado válido, reintentar con retroceso exponencial, mostrar avisos claros en el panel y degradar de forma suave: si la licencia caduca, se dejan de recibir actualizaciones y soporte, pero el sitio sigue funcionando. Bloquear de golpe funciones que ya estaban en producción es la mejor forma de generar reembolsos y reseñas negativas.
También hay que cumplir con la privacidad. Si el cliente envía el dominio, la versión del plugin y la clave, esto debe declararse en la política de privacidad, y no deben enviarse datos personales de visitantes. Basta con lo estrictamente necesario para validar la licencia.
Construir o contratar: cómo decidir
Para un único plugin con pocos planes, un servicio de licencias de terceros o un plugin de licencias ya hecho suele bastar y reduce el tiempo de lanzamiento. Cuando hay varios productos, reglas de plan complejas, integración con facturación propia o requisitos de privacidad estrictos, un servidor a medida compensa a medio plazo. La lógica es la misma que se analiza en la comparativa de software a medida frente a estándar.
El servicio de desarrollo de plugins WordPress de AYM Flow incluye activación, verificación y entrega de actualizaciones, apoyado en la experiencia de mantener nuestro propio producto con licencia, AYM Multilingual. Para quien está empezando el plugin, la guía para crear un plugin de WordPress cubre las bases antes de plantear la capa comercial.
Preguntas frecuentes
¿Se puede proteger el código de un plugin de WordPress con licencias?
No de forma legal ni técnica: los plugins distribuidos deben ser compatibles con GPL y el código es legible. Lo que se controla con licencia es el acceso a las actualizaciones, al soporte y a los servicios en la nube asociados.
¿Cómo se limitan los sitios por licencia?
El servidor registra cada activación con el dominio normalizado y compara el total con el límite del plan. El cliente puede desactivar un sitio para liberar el cupo y trasladarlo a otro.
¿Qué ocurre si el servidor de licencias deja de responder?
El plugin debe seguir funcionando con el último estado válido guardado en caché y reintentar más tarde. Un fallo del servidor nunca debe bloquear el sitio del cliente.
Artículos relacionados
wordpress
Cómo optimizar la velocidad y la conversión en WooCommerce: guía para tiendas online
En una tienda, la velocidad y la conversión van de la mano. Qué optimizar en catálogo, ficha de producto, carrito y checkout, y qué no cachear nunca.
wordpress
Cómo acelerar WordPress: guía práctica de Core Web Vitals (LCP, INP y CLS)
Qué medir, en qué orden corregir y qué suele estar detrás de un LCP lento, un INP alto o saltos de diseño en WordPress. Sin trucos mágicos ni plugins milagrosos.
wordpress
Cómo crear un plugin de WordPress paso a paso: guía de desarrollo profesional
De la cabecera del archivo principal a la seguridad y las actualizaciones: los pasos y las decisiones que separan un plugin de prueba de uno listo para producción.
