Una razón por la que Charitable es uno de los mejores plugins de WordPress para gestionar campañas y aceptar donaciones es su flexibilidad y su capacidad para permitir a otros personalizar varios aspectos clave de la experiencia, incluidos los correos electrónicos, los detalles de la campaña y el formulario de donación. Parte de esta flexibilidad reside en los "hooks y filtros" que Charitable tiene en su código y que están disponibles para los desarrolladores de WordPress. A través de ellos, un desarrollador puede personalizar un sitio para:
— Mostrar un campo personalizado en el formulario de donación a través de la API de Campos de Donación.
— Añadir nuevas etiquetas de correo electrónico o modificar las existentes con la API de Campos de Correo Electrónico.
— Personalizaciones de complementos como el complemento Ambassador y el complemento de Recibos Anuales.
El código para un plugin de WordPress se puede escribir de varias maneras y en diferentes lugares: parte del código se puede colocar en el archivo "functions.php" del tema activo de WordPress, parte se escribe en un plugin (que se puede activar y desactivar incluso si el usuario mantiene el mismo tema) y (lo que es cada vez más popular) el código se puede alojar en un plugin de fragmentos de código.
Independientemente de dónde resida el código, existen buenas prácticas que los desarrolladores y programadores de WordPress deberían utilizar para garantizar que el sitio web en el que se ejecuta permanezca seguro y no caiga en errores. Lo siguiente no es una guía completa ni exhaustiva, sino recordatorios generales para quienes escriben código O aceptan código de desarrolladores para insertarlo en su sitio web, especialmente si ese código depende de un plugin de terceros (como Charitable).
Archivo de Plugin Preferido
Si es posible, intente colocar el código personalizado en SU PROPIO plugin de WordPress. Esto facilita mantener el código en su lugar si cambia su tema de WordPress y también le permite activar/desactivar fácilmente el plugin que contiene las personalizaciones con fines de depuración. Hay muchas publicaciones y tutoriales en la web sobre cómo crear un plugin simple de WordPress como este.
No Asumas, Siempre Comprueba
Es importante que cualquier código personalizado NO ASUMA QUE CHARITABLE ESTÁ ACTIVADO Y FUNCIONANDO EN SU SITIO WEB. ¿Por qué? Porque si intenta llamar a una función en el código principal de Charitable, y el código no está allí, puede ocurrir un error... ¡un error que podría derribar su sitio web! A veces, WordPress puede poner su sitio en "Modo de Recuperación" y enviar un correo electrónico al administrador del sitio para notificarle sobre este error, pero no siempre es así. Por lo tanto, CUALQUIER código escrito para Charitable, independientemente de su propósito o de dónde se encuentre el código, debería "comprobar" para asegurarse de que Charitable está activado y/o de que la función que intentan llamar existe.
Observe nuestro primer ejemplo (¡malo!):
👎🏻 EJEMPLO MALO:
// Bad Example :-( Of Hooking Into Charitable
function charitable_add_donation_gateway_email_tag() {
charitable()->donation_fields()->get_field( 'gateway_label' )->email_tag = true;
}
add_action( 'init', 'charitable_add_donation_gateway_email_tag' );El propósito de este bloque de código es hacer que la "etiqueta de puerta de enlace" sea algo que se pueda agregar como una etiqueta dinámica en los correos electrónicos de Charitable. El desarrollador anterior está "enganchando" la función que hace esto en el "init" de WordPress, que se ejecuta cada vez que se carga una página en el sitio web, sin importar si está en el administrador o en el front-end. Tenga en cuenta que la función utiliza "charitable()"... pero si esta no existe, PHP generará un "error fatal" y, dado que el código anterior se carga en CADA Y TODAS las cargas de página, es muy probable que todo el sitio se bloquee sin la posibilidad de iniciar sesión como administrador, etc.
De nuevo, es una buena práctica no asumir nunca que una función existe si esa función forma parte de un plugin o tema (en otras palabras, si no forma parte del núcleo de WordPress). Asumir que la clase "charitable()" existe significa asumir que el plugin Charitable siempre estará ahí, pero si el plugin se desactiva (por un humano o por otro plugin) o si el plugin se está actualizando... la función no se encontrará y se encontrará un error (posiblemente "fatal"). Aquí está la misma función pero con una simple adición:
👍🏻 BUEN EJEMPLO:
// Good Example :-) Of Hooking Into Charitable
// Checking To See If The Class Exists!
function charitable_add_donation_gateway_email_tag() {
if ( class_exists('charitable') ) : // check for class
charitable()->donation_fields()->get_field( 'gateway_label' )->email_tag = true;
endif;
}
add_action( 'init', 'mysite_charitable_add_donation_gateway_email_tag' );Observe la declaración "if" que comprueba si existe la clase "charitable". Esta es una forma en PHP de comprobar de forma segura si la clase existe (en este caso, solo existirá si Charitable se está ejecutando activamente en el sitio web). Si no existe, el código no se ejecuta y todos están a salvo. Es común que los desarrolladores de PHP realicen comprobaciones como class_exists y function_exists como formas rápidas de garantizar que el código que están a punto de ejecutar no encontrará errores graves porque algo que asumen que existe no existe.
Utilice nombres únicos para las funciones
Como se señaló en los ejemplos anteriores, nunca dé a sus funciones nombres genéricos como "update_email" porque si otro plugin utiliza el mismo nombre (plugins actuales o futuros que pueda instalar), su sitio web podría sufrir problemas. Al crear una función, comience siempre con "miweb_charitable_" (como en el ejemplo anterior, reemplazando "miweb" con una cadena de longitud razonable del nombre de su sitio web) para asegurarse de que ha creado un nombre personalizado que no se repite (también puede utilizar la misma "lógica de comprobación de existencia" del paso anterior si desea ir un paso más allá).
Habilite la depuración y los registros de depuración de WordPress
Para cualquier cosa más allá de un script simple, a los desarrolladores de WordPress les gusta documentar y registrar advertencias y errores de PHP para "capturar" problemas (especialmente si no son aparentemente visibles en el sitio web). El equipo de soporte de Charitable recomienda las funciones base WP_DEBUG y WP_DEBUG_LOG, como se menciona aquí en la documentación de WordPress.
¿Usar un plugin de fragmentos de código?
Todo lo dicho anteriormente también es aplicable al código insertado en plugins de fragmentos de código. Si tiene un problema con Charitable y sabe que está ejecutando código personalizado en un fragmento de código, debería poder desactivar el plugin de fragmentos de código para ver si esto resuelve el problema o le ayuda a solucionar problemas más a fondo.
No pruebes en producción
Finalmente, es una buena idea probar el código personalizado en un entorno de desarrollo o staging y no en vivo en tu sitio web. Si desactivas Charitable aquí como prueba, es una buena forma "final" de determinar si tu sitio web podría experimentar problemas significativos. Esto mantiene tu entorno de producción seguro y aún capaz de aceptar donaciones.
Recuerda que si no estás seguro sobre el código que estás añadiendo a tu tema, tu propio plugin o un plugin de fragmentos de código, consulta con un desarrollador. Si tienes algunas preguntas generales, no dudes en contactar a nuestro equipo de soporte, que estará encantado de responder preguntas sobre cualquier código que puedas estar añadiendo a tu sitio web para extender Charitable. ¡Estamos aquí para ti y para apoyarte a extender tu sitio web para satisfacer tus necesidades!
Esperamos que compartir estas sugerencias te dé la confianza y asegure que tus personalizaciones de Charitable continuarán funcionando bien durante años.
