Filing bugs and issues/es

Para informar acerca de una incidencia en el gestor de incidencias de Joomla!, necesitará crear un elemento del gestor. Una vez el elemento es creado, los desarrolladores comprobarán su validez y actuarán en consecuencia.

Informando sobre incidencias

Registrar una cuenta en GitHub

Necesitará registrar una cuenta en GitHub; el Gestor de Incidencias de Joomla! usa estas cuentas para autenticarse en el sistema.

Cómo acceder al gestor de incidencias de Joomla!

• Joomla! Issue Tracker- Activo
• Joomla! CMS Issue Tracker - Inactivo - Por favor use el nuevo Gestor de Incidencias de Joomla!
• Old Joomla! 2.5 Bug Tracker - Inactivo - Por favor use el nuevo Gestor de Incidencias de Joomla!
• Joomla! 1.5 Bug Tracker - Inactivo
• Joomla! 1.0 Bug Tracker - Cerrado

Compruebe si la incidencia sobre la que quiere informar ya ha sido comunicada

Una serie de filtros muestran los elementos del gestor a los que se puede acceder haciendo clic en el botón "Herramientas de búsqueda" en la parte superior de la lista. Pase el ratón sobre el título de los elementos del gestor para ver su contenido. Si el problema que está experimentando no ha sido comunicado aún, haga clic en el botón "Nuevo elemento" en la zona principal de navegación.

Se mostrará una nueva pantalla y, una vez ahí, mientras más información proporcione más fácil será para los desarrolladores.

Introduzca tantos datos como pueda. Puede activar los consejos para cada campo cambiando el selector "Modo de vista" en la parte derecha de la pantalla de Pro a Ayuda.

• Prioridad: Use el nivel predeterminado "Medio" salvo que conozca el código lo suficiente como para elegir otro modo.
• Build: Escriba aquí la(s) versión(es) afectada(s) por el problema.
• Categorías: Este es un poco más complicado. Use "Adminsitración" si no conoce uno mejor.
• Título: un breve resumen del problema.
• Descripción: Detalles del problema. Consulte la sección siguiente para obtener más información.
• Subidas: A los usuarios se les permite subir imágenes en los informes. La información sobre los requisitos de carga aparece en el formulario del informe.

Proporcione un resumen

Describa en unas pocas palabras los problemas que ha encontrado. Normalmente es una buena idea usar elementos existentes del gestor como ejemplo si es la primera vez que informa de un fallo.

Ejemplos:

• Front-end: Advertencia tal y tal.
• Back-end: no se puede guardar el artículo cuando "nombredelplugin" está publicado.

Aviso: procure ser descriptivo en su resumen, pues este será lo primero que los desarrolladores verán cuando estén hojeando el gestor en busca de algo que arreglar.

Proporcione detalles sobre la incidencia

Para proporcionar la mayor información posible, el gestor rellena el campo de descripción con una plantilla que contiene 5 subsecciones:

• Pasos para reproducir la incidencia: pasos detallados sobre cómo otra persona puede reproducir su incidencia.
• Resultado esperado: lo que cree que debería ocurrir al realizar los pasos anteriores.
• Resultado real: lo que realmente sucede al realizar los pasos anteriores
• Información del sistema: información acerca del entorno en el que está configurado su sistema. Esto podría incluir el navegador que está usando, la versión PHP de su servidor o el tipo de base de datos que su sitio está usando. Para obtener resultados óptimos, debe copiar estos datos de la vista Información del Sistema de su sitio -puede acceder a dicha vista iniciando sesión en la parte administrativa del sitio.
• Comentarios adicionales: cualquier información adicional no proporcionada anteriormente que podría ser beneficiosa para la depuración y resolución del problema.

El formato general debería ser algo como:

1. "Esto es exactamente lo que hice."
2. "Esto es lo que pasó."
3. "Esto es lo que creo que debería haber pasado."
4. "Otra información, posible solución, parche de código propuesto."

Cuantos más detalles, mejor. También, es importante reproducir la incidencia utilizando los datos de ejemplo de Joomla!, o con instrucciones claras y fáciles de cómo configurarlo. Recuerde que los demás no tendrán acceso a la base de datos de su sitio, por lo que tendrá que ser capaz de decirle a alguien cómo ver la incidencia con los datos que ya están disponibles en el sitio de muestra.

Ejemplo A

Lo que hice

empecé con el sitio de prueba. Todo estaba bien. Activé "nombredeplugin". Intenté guardar cualquier artículo desde la interfaz administrativa.

Lo que pasó

me sale una pantalla en blanco y artículo no se guarda.

Lo que debería haber pasado

los artículos deberían guardarse correctamente.

Información adicional

Estos son los plugins habilitados al mismo tiempo. SEF está activado (o desactivado). Mi sitio está en una subcarpeta. También observo que... etc. Creo que tales y tales archivos son el problema (si sabe lo que está hablando).

Ejemplo B

Lo que hice

acceder a la interfaz administrativa. Clic en el menú "menu_name".

Lo que ocurrió

la que se abrió estaba en blanco.

Lo que debería haber sucedido

El Menú debería haber abierto correctamente.

Otra información

cualquier otro menú funciona correctamente, etc.

Ejemplo de la vida real

• Lo que hice

1. Comencé con el sitio web de muestra.
2. Añadí un artículo sin publicar desde la zona administrativa, con Sección=FAQ, Categoría=General
3. En los parámetros avanzados del artículo, establecí Mostrar Título como "No", e Iconos Imprimir, PDF y Email como "Ocultar".
4. Guardé el artículo y navegué a la parte pública del sitio. Inicié sesión en la parte pública como administrador y navegué al elemento de menú Páginas de Ejemplo > Categoría en formato Blog

• Lo que ocurrió: el artículo recién añadido es mostrado, pero no hay icono de editar en el que hacer clic en la parte pública.
• Lo que debería haber ocurrido: el icono de editar debería ser mostrado, permitiendo al usuario final de la parte pública editar este artículo.
• Otra información: esto sólo pasa con la plantilla rhuk_milkyway. Cambiando este código [código propuesto] en el archivo [nombre y ruta del archivo], línea(s) #, el problema parece resolverse en mi sistema.

Proponer un parche directamente al repositorio de Joomla! en GitHub

Si desea proponer una solución ofreciendo directamente el código dentro de Joomla!, puede hacerlo mediante la emisión de una "propuesta de parche" (pull request) en el repositorio de código de Joomla! en GitHub.com, ubicado aquí: https://github.com/joomla/joomla-cms

Este proceso requiere un poco de conocimiento acerca de los Sistemas de Control de Código Fuente (SCM por sus siglas en inglés) y de Git en particular. Si ya sabe qué es el SCM Git y cómo funciona, el proceso es sencillo:

• Regístrese para obtener una cuenta gratuita en GitHub.com
• Bifurque el repo de Joomla!
• Cambie a la rama "staging" si quiere proponer una solución para la versión actual de Joomla! 3.x o a la rama "2.5.x" si quiere proponer una solución para Joomla! 2.5.
• Añada/actualice los archivos de Joomla! relacionados en la rama adecuada y después haga clic en el botón "revisar & comparar" - más información sobre esto aquí https://help.github.com/articles/using-pull-requests - para iniciar el proceso de envío de "pull request".

Consejos y trucos adicionales

Los informes de incidencias bien escritos son increíblemente útiles. Sin embargo, trabajar con cualquier sistema de seguimiento de incidencias produce una cierta cantidad de sobrecarga de trabajo, por lo que se apreciará su ayuda en mantener nuestro gestor de tickets lo más útil posible. En particular:

• Lea las preguntas frecuentes para ver si su problema es uno ya conocido.
• Busque en el tracker para ver si su problema ya ha sido comunicado.
• Si no estás seguro de si lo que estás viendo es un error, primero pregunta en testing forums
• Escríbanos los informes de errores específicos reproducibles completos. Incluya tanta información como le sea posible, con fragmentos de código, casos de prueba, etc Un ejemplo mínimo que ilustra el error en un pequeño caso de prueba bueno es el mejor informe de error posible.
• No utilice el sistema de seguimiento para hacer preguntas de soporte. Utilice para eso Joomla! forums o el canal IRC en freenode #joomla.
• No utilizar los trackers para hacer peticiones de características a gran escala. Nos gusta hablar de grandes cambios para núcleo de Joomla! en los foros developers forums antes deponernos a trabajar en ellos.
• No reabra problemas que han sido marcados como "not a bug" (no es un fallo). Esta marca significa que se ha tomado la decisión que no podemos o no queremos solucionar este problema en particular. Si no está seguro del porqué, por favor pregunte en los foros de desarrolladores.
• No utilice el tracker para largos debates, porque son propensos a perderse. Si un elemento del registro particular es controvertido, mueva la discusión a developer forums.

Informando sobre problemas de seguridad

Informe sobre problemas de seguridad en security [arroba] joomla [punto] org. Esta es una lista privada accesible únicamente a desarrolladores de confianza que llevan mucho tiempo colaborando con el proyecto, y sus archivos no son accesibles públicamente.

En el caso de una vulnerabilidad en Joomla! confirmada, se realizarán las siguientes acciones:

• Acusar recibo, al informador, de la recepción del informe y que la solución está próxima. Se dará un calendario aproximado y se le pedirá al informador de que mantenga el problema secreto hasta que se haga público.
• Detener cualquier otro desarrollo mientras sea necesario para desarrollar una solución, incluyendo parches sobre la versión actual y las dos precedentes.
• Determinar una fecha de publicación para anunciar la vulnerabilidad y su corrección. Para tratar de mitigar una posible "carrera armamentista" entre los que aplicar el parche y aquellos que tratan de explotar el agujero, no vamos a anunciar los problemas de seguridad inmediatamente.
• Anunciar públicamente la vulnerabilidad y la corrección en la fecha públic predeterminada. Esto probablemente signifique una nueva versión de Joomla!, aunque en algunos casos puede ser simplemente parches para el lanzamiento actual.