Hackear el núcleo está fuertemente desaconsejado para los no iniciados porque reduce efectivamente la comunidad de soporte de miles a una comunidad de soporte de uno (o lo que sea el tamaño de su equipo). Sin esta mejor práctica, ayudar a los nuevos en Drupal sería casi imposible. También dificulta la modularidad y, en algunos casos, la seguridad.
Dicho esto, el hackear el núcleo no siempre es tan malo como nos gusta hacer que parezca. Sin modificar el núcleo, no tendríamos distribuciones como Pressflow y similares que aumenten el núcleo de maneras interesantes. Es de vital importancia que sepa exactamente lo que está haciendo, que esté distribuyendo sus parches con su distribución (preferiblemente de una manera que le permita aplicarlos nuevamente automáticamente después de la actualización), y que esté manteniendo documentación detallada de lo que has cambiado y por qué lo has cambiado.
Dependiendo de cómo tenga estructuradas las cosas, ciertamente puede hacer el cambio anterior xmlrpc_request()
, crear un parche y luego usar algo como Drush Make para automatizar su aplicación (tenga en cuenta que Drush Make se está moviendo al proyecto Drush en sí para la versión 5.x) ), al tiempo que proporciona documentación adicional en el archivo MAKE y en otros lugares sobre lo que hace el cambio y por qué es necesario / deseado.
Otro patrón común para mejorar las funciones principales es crear un contenedor que agregue un poco de funcionalidad a una función central y llamar al contenedor en lugar de la implementación del núcleo. Cuando es posible, esto hace que las cosas sean mucho más modulares. Considera lo siguiente:
/**
* Wrapper function for xmlrpc_request() to provide logging.
*/
function mymodule_xmlrpc_request($method, $args) {
$xrr = xmlrpc_request($method, $args);
watchdog('xmlrpc', $xrr->xml);
return $xrr;
}
Nuevamente, dependiendo de lo que esté haciendo, esto puede ser factible o no, pero cuando lo hace, se ha ahorrado algunos dolores de cabeza al tratar de asegurarse de que el núcleo permanezca parcheado y documentado. Aunque en este caso, una función única como esta parece ser un candidato perfecto para tal envoltura. Si su implementación se captura en un módulo, incluso podría expandirse para controlar el nivel de registro de toda su solución, deshabilitando esta funcionalidad en los sitios de producción:
/**
* Wrapper function for xmlrpc_request() to provide logging (if enabled).
*/
function mymodule_xmlrpc_request($method, $args) {
$xrr = xmlrpc_request($method, $args);
if (variable_get('mymodule_log_level', 0) > 0) {
watchdog('xmlrpc', $xrr->xml);
}
}
En resumen, desea maximizar lo que puede hacer con los módulos (y puede hacer mucho), pero existen razones legítimas para alterar el núcleo. Debe hacerse con cuidado, eso es todo.