Directrices de contribución

Esta página explica cómo contribuir con cambios al plugin a un nivel seguro para el público. Los nombres de clases internas, las constantes internas y las referencias a la infraestructura de lanzamiento privada no se publican aquí.

Cuándo usar este documento

Lea este documento cuando vaya a:

• Abrir una pull request que corrija un error, añada una característica o mejore la documentación.
• Traducir el plugin a un nuevo idioma.
• Enviar un informe de seguridad.

Descripción general

Las contribuciones se aceptan a través de pull requests. Cada cambio debe:

• Coincidir con la estructura y las convenciones existentes (consulte Coding Standards).
• Estar cubierto por pruebas unitarias cuando sea factible (consulte Testing Guide).
• Incluir cadenas traducibles utilizando el text domain del plugin (consulte Internationalization For Developers).
• Aplicar la sanitización y el escapado correctos (consulte Sanitization And Escaping) y respetar el modelo de seguridad de alto nivel (consulte Security And Capability Checks).
• Actualizar la documentación relevante bajo docs/en/ cuando cambie el comportamiento observable públicamente, y mantener esa documentación segura para el público.

Requisitos o prerrequisitos

• Git instalado localmente y una bifurcación (fork) del repositorio.
• Las versiones de PHP y WordPress declaradas en la cabecera del plugin.
• Composer instalado para las dependencias de desarrollo (solo para el framework de pruebas).
• Una instalación local de WordPress en funcionamiento para validar los cambios que van más allá de la lógica de prueba unitaria (consulte Local Development Setup).

Instrucciones paso a paso

1. Bifurque (fork) el repositorio y cree una rama de características (feature branch).
2. Realice su cambio. Siga la guía de redacción segura para el público en cualquier actualización de la documentación: no añada nombres de clases internas, claves de opciones, nombres de rutas REST/AJAX, nombres de hooks de cron, identificadores de capabilities/nonces o detalles de la infraestructura de lanzamiento al conjunto publicado de docs/.
3. Añada o actualice las pruebas unitarias donde sea factible.
4. Ejecute la suite de pruebas localmente antes de abrir la pull request.
5. Abra una pull request desde su rama. Describa el cambio, las pruebas que realizó y cualquier actualización de la documentación.

Informes de seguridad

Si cree que ha descubierto un problema de seguridad, no abra una incidencia pública. Póngase en contacto con AD Promotion de forma privada para que el informe pueda ser evaluado y solucionado antes de su divulgación.

Traducciones

Si desea contribuir con una traducción, base su trabajo en el archivo POT del proyecto bajo /languages y envíe sus archivos .po / .mo a través del proceso normal de pull request. Consulte Internationalization For Developers.

Aviso de documentación pública. Esta página proporciona únicamente una descripción general de la integración a alto nivel. Los detalles de implementación interna, las API privadas, los aspectos internos del almacenamiento y la infraestructura de lanzamiento sensible a la seguridad se mantienen por separado y no forman parte de la documentación pública.