Filing bugs and issues/es

Para informar acerca de un bug (error de código) en el el bug tracker (herramienta de seguimiento de errores) de Joomla!, necesitará crear un elemento del tracker. Una vez el elemento es creado, los desarrolladores comprobarán su validez y actuarán en consecuencia.

Informando sobre bugs (errores)

Registrar una cuenta en GitHub

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

Cómo acceder al issue tracker de Joomla!

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

Compruebe si el error sobre el que quiere informar ya ha sido reportado.

Un serie de filtros muestran lo elementos del tracker 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 tracker para ver su contenido. Si el problema que está experimentando no ha sido reportado aún, haga click 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 tracker 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 tracker en busca de algo que arreglar.

Proporcione detalles sobre el error

Para proporcionar la mayor información posible, el tracker rellena el campo de descripción con una plantilla que contiene 5 sub-secciones:

• Pasos para reproducir el problema: pasos detallados sobre cómo otra persona puede reproducir el problema.
• 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 el error utilizando el ejemplo del sitio web de Joomla!, o con instrucciones claras, 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 el error con los datos que ya están disponibles en el sitio de muestra.

Ejemplo A

What I did

Started with sample website. Everything was ok. I enabled "nameofplugin". Try to save any article from back end.

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.

Enviar un pull request directamente al repositorio de Joomla! en GitHub

If you wish to propose a fix by directly providing the code within Joomla! itself, you may do so by issuing a "pull request" in Joomla!'s code repository on GitHub.com, located here: https://github.com/joomla/joomla-cms

This process requires some knowledge regarding Source Control Management systems and Git in particular. If you do know what the Git SCM is and how it works, the process is simple:

• Sign up for a free GitHub.com account
• Fork the Joomla! repo
• Switch to the "staging" branch if you wish to propose a fix for the current Joomla! 3.x release or to the "2.5.x" branch if you want to propose a fix for Joomla! 2.5.
• Add/update the related files in Joomla! in the right branch and the click on the "review & compare" button - more info on this here https://help.github.com/articles/using-pull-requests - to start the "pull request" issuing process.

Consejos y trucos adicionales

Los informes de errores bien escritos son increíblemente útiles. Sin embargo, trabajar con cualquier sistema de seguimiento de errores da 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:

• Do read the FAQ to see if your issue might be a well-known question.
• Do search the tracker to see if your issue has already been filed.
• 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.
• Don't use the tracker system to ask support questions. Use the Joomla! forums, or the #joomla IRC channel on freenode for that.
• 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.
• Don't reopen issues that have been marked "not a bug". This mark means that the decision has been made that we can't or won't fix this particular issue. If you're not sure why, please ask on developer forums.
• Don't use the tracker for lengthy discussions, because they're likely to get lost. If a particular tracker item is controversial, please move discussion to developer forums.

Informando sobre problemas de seguridad

Report security issues to security [at] joomla [dot] org. This is a private list only open to long-time, highly trusted Joomla! developers, and its archives are not publicly readable.

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.
• Halt all other development as long as is needed to develop a fix, including patches against the current and two previous releases.
• 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.
• Publicly announce the vulnerability and the fix on the pre-determined go-public date. This will probably mean a new release of Joomla! but in some cases it may simply be patches against current releases.