Share
Cuando se está acercando a completar su complemento de WordPress, es hora de comenzar a pensar en lanzarlo al público en general. Prepararse para publicar un complemento requiere mucho pulido, prueba y ajuste fino, y es fácil olvidar algunos pasos en el proceso. Este tutorial lo guiará a través de la publicación del complemento en el directorio de complementos de WordPress y funcionará como una lista de verificación para ayudarlo a asegurarse de que su complemento esté listo para el horario de máxima audiencia en el momento en que presione publicar.
Algunos de los pasos, como la configuración del proyecto, se realizan una vez en la vida de cada complemento, mientras que muchos son importantes cada vez que lanzas una nueva versión de tu complemento. Por eso puede ser una buena idea marcar este tutorial y volver a él cuando sea el momento de hacer su próxima actualización..
El directorio de complementos en WordPress.org es para WordPress lo que AppStore es para el iPhone: la forma más fácil y rápida de encontrar complementos para WordPress. Si bien es posible publicar su complemento como un archivo zip descargado desde su propio sitio web, con cada versión, la integración entre WordPress y su directorio de complementos se está haciendo más estricta..
Al lanzar su complemento a través del directorio de complementos, le facilita a sus usuarios potenciales encontrar su complemento y mantenerlo actualizado a medida que crea nuevas versiones. Podrán instalar el complemento sin tener que salir del panel de administración de WordPress y, naturalmente, la mayoría de los usuarios de WordPress ya conocen el directorio de complementos y lo buscarán cuando busquen complementos que coincidan con sus necesidades. Por otra parte, obtendrá estadísticas de descarga, comentarios de los usuarios a través de la página del complemento en el directorio de complementos y un repositorio de subversión gratuito para almacenar los archivos de su complemento y el historial de versiones..
¿Hay alguna razón para no alojar su complemento en el directorio de complementos? Si su complemento es comercial, es posible que desee alojarlo en otro lugar (su propio sitio o mercado, como Codecanyon de Envato) ya que el directorio de complementos está abierto y no tiene soporte para hacer dinero con sus complementos. Todo lo publicado en el directorio de plugins de WordPress se puede descargar libremente por todos..
Estas son las reglas para los complementos alojados en el directorio, tomadas de las instrucciones del Director del complemento:
Sólo hay unas pocas restricciones:
Una vez que haya decidido alojar su complemento en el directorio de complementos de WordPress, el primer paso es crear una cuenta de usuario de WordPress.org. Para obtener uno, visite el directorio de complementos y haga clic en "Registro" enlace en la parte superior derecha de la página, justo al lado del indicador de inicio de sesión.
Después de registrar su cuenta de usuario, puede solicitar a WordPress que agregue su complemento siguiendo este enlace que conduce a una página que se parece a la siguiente captura de pantalla.
Rellene el formulario y explique brevemente de qué trata su complemento. Sea lo más específico que pueda mientras se mantenga dentro de un tiempo razonable. Si su complemento ya tiene un sitio web, ingrese la URL en el campo "URL del complemento".
Antes de crear su proyecto, alguien del personal de WordPress leerá su solicitud y la aprobará. Si bien WordPress no hace promesas sobre el tiempo que puede tardar, diciendo que se recuperarán en "una cantidad de tiempo vagamente definida", el tiempo se calcula en horas o días en lugar de semanas; lo más probable es que tenga su complemento configurar dentro de 24 horas desde la presentación de la solicitud.
Una vez que se apruebe su complemento, recibirá un correo electrónico con el sitio web de su nuevo proyecto y la URL de SVN en él. Observe la URL del repositorio, ya que la usaremos en gran medida en los próximos pasos.
En los siguientes pasos, asumiré que está al menos algo familiarizado con SVN, por lo que si no tiene idea de qué es SVN, hojee un tutorial antes de continuar con el siguiente paso.
En Mac y en la mayoría de las versiones (si no todas) de Linux, un cliente SVN de línea de comandos viene con el sistema operativo. En Windows, puede instalar el cliente de línea de comandos usted mismo o ir con un cliente gráfico como Tortoise SVN. En Mac, Versiones es un cliente gráfico muy agradable..
Para aprovechar al máximo el repositorio SVN provisto por WordPress, lo configuraremos para que la versión de desarrollo del complemento se guarde en
El directorio de complementos lee la etiqueta desde la cual se debería distribuir su versión estable actual al revisar el archivo readme.txt en el maletero. Cubriré esto con más detalle en el siguiente paso a medida que pasemos por los contenidos de la readme.txt Archivo que debe incluirse con el plugin..
Primero, sin embargo, repasemos los comandos SVN que usarás la mayor parte del tiempo. No se preocupe si no le gusta escribir comandos en el terminal, simplemente siga adelante y use su cliente gráfico favorito de SVN..
Vamos a empezar por revisar el proyecto de SVN. En este momento, el proyecto todavía está vacío, por lo que no se agrega nada más que un directorio vacío a su computadora.
$ svn co http: //[email protected]/your-plugin/trunk local-path
Copie o mueva su código de complemento a ese directorio (ruta local) creado por el comando svn, y agregue los archivos a SVN. Dentro del directorio, escriba:
$ svn agregar ruta de archivo
ruta de archivo puede ser una ruta a un archivo específico, o un comodín como * .php. Esto marcará los archivos que se agregarán al repositorio de SVN en su próximo svn commit: aún no se ha confirmado nada. Si no está seguro de qué archivos ha agregado ya, puede verificar el estado de SVN de cada archivo en el directorio de trabajo actual:
estado $ svn
Finalmente, cuando todo esté listo para ser enviado al repositorio SVN, confirme los archivos. No tenga miedo de comprometerse con frecuencia: mientras la "etiqueta estable" apunte a algún otro directorio que no sea el enlace troncal, sus confirmaciones no tendrán efecto en la versión ya publicada. Al hacer esto, estará seguro en caso de que pierda su copia local del código por algún motivo..
$ svn commit -m "Una breve explicación de lo que se cambió"
Antes de que su proyecto se pueda mostrar en el Directorio de Complementos, aún deberá agregar el archivo readme.txt. Pero antes de entrar en eso, es hora de probar tu complemento.
A pesar de que sus usuarios no pagan por usar su complemento, lanzar un complemento sin probarlo primero nunca es una buena idea. En código abierto, la gente tolera algunas versiones con errores de vez en cuando si corrige sus errores rápidamente y responde rápidamente a sus informes de errores, pero si cada versión se libera con errores graves, tarde o temprano, sus usuarios se moverá a otros complementos similares.
Al mismo tiempo, debemos tener en cuenta que, como únicos desarrolladores o pequeños equipos, nuestros recursos para realizar pruebas son limitados. Si tiene suerte, puede hacer que alguien fuera del equipo pruebe su complemento, pero a menudo, solo usted es el desarrollador que está haciendo las pruebas. Es por esto que es importante crear un plan de prueba claro y simple que se pueda poner en práctica..
Para crear uno, siga los siguientes consejos y elija los consejos que más le convengan, y personalícelos de acuerdo con su propia experiencia y los detalles del complemento que está a punto de lanzar..
Soy el primero en admitir que no soy un desarrollador perfecto. Aunque conozco mis puntos débiles, tiendo a repetir mis errores. Es por eso que, en mi procedimiento de prueba, trato de mantener una lista actualizada de los tipos de error que ocurren con mayor frecuencia en mi código y pruebas que debo hacer antes de cada lanzamiento para detectar mis errores más comunes.
Se llama pruebas de regresión, y es una de las formas más importantes de prueba: por lo general, las nuevas funciones se prueban bastante bien a medida que las desarrolla, pero al mismo tiempo, puede que esté introduciendo errores en otras partes del código que ya consideraba completas..
Para detectar estos errores, cree una lista de pruebas para verificar la funcionalidad principal de su complemento, y revise la lista antes de cada lanzamiento, incluso si sus cambios no deberían haberlos tocado..
Algunos de los errores solo aparecen para los nuevos usuarios que están instalando el complemento por primera vez, mientras que otros solo molestan a los usuarios que están actualizando desde una versión anterior. Algunos errores solo aparecen en un entorno multiusuario, etc..
Para asegurarse de detectar tantos problemas como sea posible, es una buena idea crear diferentes entornos de prueba, al menos uno con una versión existente de su complemento y la otra una instalación de WordPress limpia..
Cuando sepa que su próxima versión crea nuevas tablas de base de datos o cambia las existentes, pruebe con cuidado para ver si el cambio que espera que ocurra en realidad lo hace y la base de datos llega al estado final correcto. Mi procedimiento de prueba dice acerca de la estructura de la base de datos:
Si la estructura de DB ha cambiado:
- Probar la actualización de la base de datos sin desactivar el complemento
- Actualización de la base de datos de prueba con desactivación / reactivación
Estos son estados en los que no se da cuenta si ejecuta el complemento de la forma en que fue diseñado, y por lo tanto, puede pasar mucho tiempo antes de que note los errores, a menos que los pruebe intencionalmente..
Esto no es algo que desee ver en un código de manejo de errores destinado a manejar el caso de error con gracia:
Para asegurarse de que su complemento funcione con los cambios introducidos en la última versión de WordPress, siempre es bueno actualizar su entorno de prueba a la última versión antes de realizar la última ronda de pruebas..
Revise los comentarios de los usuarios y vea si hay errores que aún no ha solucionado. Ignore las solicitudes de funciones por ahora (pero escríbalas para poder usarlas como entrada cuando planifique su próxima versión) ya que no puede hacer todo en una sola versión de todos modos. Siempre crea a tus usuarios cuando dicen que han encontrado un error, pero no tengas miedo de pedir más información para resolverlo..
Si su complemento escribe cualquier HTML o CSS, decida sobre un conjunto de navegadores que admita y pruebe su complemento en esos navegadores antes de cada lanzamiento.
Algunos problemas potenciales son más fáciles de encontrar mirando el código que a través de las pruebas, así que nuevamente, al igual que en las pruebas, es una buena idea hacer un seguimiento de sus puntos débiles y escribir una lista de cosas para volver a verificar antes de publicar el complemento. A medida que lanza más versiones, adquiere más conocimientos sobre lo que es importante probar en este mismo proyecto, así que actualice la lista a medida que aprende, elimine algunas cosas y agregue otras..
Aquí hay algunas ideas para revisar, recopiladas de mi propia experiencia:
Cuando maneje los formularios publicados por el usuario, asegúrese de validar los atributos correctamente, en su forma más simple utilizando el esc_attr método.
$ user_name = esc_attr ($ _ POST ["username"]);
Si su complemento no se escribe usando objetos, cada una de sus funciones se encuentra en el mismo espacio de nombres con el resto del código en WordPress y los complementos instalados. Para evitar que los nombres de sus funciones coincidan con los de WordPress u otros complementos, prefiéstelos con un nombre corto del complemento.
function pluginname_print_error ($ message) ? // es más seguro que: function print_error ($ message) ?
Revise todos sus comentarios TODO o FIXME para ver que no se ha perdido nada de lo que planeaba trabajar más adelante.
Si su complemento es compatible con la localización, antes de cada lanzamiento, lea toda la cadena del complemento para asegurarse de que estén correctamente marcados para la localización. Es fácil olvidarlo al agregar nuevas cadenas a un complemento.
Accentsconagua
// use $ text = __ ("Hello, world", "my_plugin"); // en lugar de solo $ text = "Hello, world" // y _e ("Hello!", "my_plugin"); // en lugar de echo "Hello!"; En el Códice de WordPress, puede encontrar un documento que describe el estilo de codificación que se debe seguir al desarrollar complementos para la plataforma de WordPress. Aunque seguir este documento no es obligatorio, hacerlo facilitará a otros desarrolladores el ayudarlo con el complemento.
Compruebe que cada archivo en su complemento contenga el encabezado GPL y que la licencia.txt de la licencia GPL esté incluida en la carpeta principal de su complemento.
/ * Copyright (c) 2011, Tu Nombre. Este programa es software libre; puede redistribuirlo y / o modificarlo según los términos de la Licencia Pública General de GNU publicada por la Free Software Foundation; ya sea la versión 2 de la Licencia, o (a su elección) cualquier versión posterior. Este programa se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA; sin ni siquiera la garantía implícita de COMERCIABILIDAD o APTITUD PARA UN PROPÓSITO PARTICULAR. Vea la Licencia Pública General de GNU para más detalles. Debería haber recibido una copia de la Licencia Pública General de GNU junto con este programa; Si no, escriba a la Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, EE. UU. * /
Todos los complementos comprometidos con el directorio de complementos de WordPress deben tener un readme.txt Archivo formateado de acuerdo a las reglas definidas por esta plantilla. Es importante seguir el formato tal como se define, cuando confirma su complemento en el directorio de complementos, este archivo se convierte automáticamente en la descripción del complemento que se ve al buscar complementos en el directorio de complementos..
Por ejemplo, vea cómo este fragmento de código desde el principio de la plantilla readme.txt se convierte en información presentada al usuario del directorio de complementos:
=== Nombre del complemento === Colaboradores: markjaquith, mdawaffe (debe ser una lista de los ID de usuario de wordpress.org) Donar enlace: http://example.com/ Etiquetas: comentarios, spam Requiere al menos: 2.8 Probado hasta: 3.1.3 Etiqueta estable: 1_5_4
Copie la plantilla a su directorio de complementos y comience a editarla con información específica de su complemento. Una vez que esté satisfecho con su readme.txt, pruébelo con el validador readme.txt proporcionado por WordPress antes de enviarlo a SVN.
Cuando vea esto en la parte superior de la página del validador, estará listo para confirmar:
Mencioné la etiqueta estable en el paso donde hablamos sobre la forma correcta de usar SVN en el desarrollo de complementos. Ahora es el momento de comenzar a usarlo: ha probado su complemento, ha inspeccionado su código y ha escrito la documentación. No hay nada más que liberar el plugin:
Busque el archivo PHP principal de su complemento y actualice el comentario ingresando su número de versión al "Versión:" campo:
/ * Nombre del complemento: Una versión del complemento: 1.0 URI del complemento: http://wp.tutsplus.com Descripción: Mi gran complemento Autor: Jarkko Laine URI del autor: http://jarkkolaine.com * /
En readme.txt, hay dos secciones dedicadas a documentar los cambios de versión: "Registro de cambios"y"Aviso de actualización."Agregue una sección para su nueva versión a Changelog, que proporciona información detallada sobre los cambios y las correcciones de errores que se incluyen en esta versión. El aviso de actualización es un resumen más breve (a más de 300 caracteres) de por qué vale la pena actualizar a esta versión del complemento.
Aquí hay un ejemplo para una fila de registro de cambios de mi complemento de donación:
= 1.5.2 = * Corrección de errores: Se corrigió un error de actualización de la base de datos de errores introducido en la versión anterior * Solución de errores: Se corrigió un error relacionado con pasar la moneda seleccionada a PayPal
Todavía en readme.txt, busque en la fila (casi en la parte superior del archivo) que dice "Etiqueta estable:"y actualice la fila con el nombre de la etiqueta que usará para su próxima versión. Mi convención ha sido nombrar la etiqueta igual que el número de versión con puntos reemplazados por guiones bajos (por ejemplo, la etiqueta para la versión 1.0 sería 1_0) Esto funciona bastante bien, pero aún mejor es simplemente hacer que sea el mismo que el número de versión:
Etiqueta estable: 1.0
De esta manera, cuando alguien busque una versión anterior de su complemento en la página "Otras versiones", fácilmente descubrirá qué etiqueta pertenece a qué versión, como en este ejemplo del complemento más popular en el directorio de complementos:
Confirme sus cambios en el archivo principal de PHP y el archivo readme.txt. Luego cree la etiqueta que eligió para su próxima "etiqueta estable":
$ svn copy http: //[email protected]/your-plugin/trunk http: //[email protected]/your-plugin/tags/1.0 -m "Etiquetando una nueva versión "
Esto es: el readme.txt en el maletero apunta a la etiqueta correcta y todo lo que tiene que hacer es esperar hasta que el software automático en el directorio del complemento note sus cambios y actualice el directorio. La nueva versión tardará aproximadamente media hora en descargarse desde el directorio del complemento y un par de horas más antes de que su blog de WordPress advierta que hay una actualización disponible para el complemento (si se trata de una actualización en lugar de la primera confirmación).
Una vez que note la actualización en el directorio de complementos, descárguela y pruébela una vez más para asegurarse de que cada cambio y corrección se hayan incluido correctamente en la versión. Cuénteles a sus amigos y seguidores sobre el complemento, luego espere a recibir comentarios para ver cómo aumentan sus estadísticas de descarga.
Una vez que comience a recibir comentarios, o si tiene sus propias ideas para mejorar el complemento, es bueno seguir lanzando nuevas versiones cada pocas semanas. Esto le mostrará a sus usuarios que su complemento aún está vivo y en desarrollo activo, y hará que sea más probable que inviertan su tiempo en él..
