¿Cómo evito editar el núcleo de Drupal?

21

Estaba creando un intercambio con un servicio XML de socios, y no pude obtener el XML correcto, pero como con todo lo relacionado con Drupal, el registro de errores y acciones de xmlrpc es menos que robusto.

Así que hice esto en incluye / xmlrpc.inc.

function xmlrpc_request($method, $args) {
  $xmlrpc_request = new stdClass();
  $xmlrpc_request->method = $method;
  $xmlrpc_request->args = $args;
  $xmlrpc_request->xml = <<<EOD
<?xml version="1.0"?>
<methodCall>
<methodName>{$xmlrpc_request->method}</methodName>
<params>
EOD;
  foreach ($xmlrpc_request->args as $arg) {
    $xmlrpc_request->xml .= '<param><value>';
    $v = xmlrpc_value($arg);
    $xmlrpc_request->xml .= xmlrpc_value_get_xml($v);
    $xmlrpc_request->xml .= "</value></param>\n";
  }
  $xmlrpc_request->xml .= '</params></methodCall>';

  /* This part here */
  watchdog('xmlrpc',$xmlrpc_request->xml);
  /* End ridiculously tiny hack */

  return $xmlrpc_request;
}

Obtuve los datos que necesitaba y en 10 minutos la interfaz del socio respondió adecuadamente a mi solicitud porque (sorprendentemente lo sé) los registros son buenos.

Me gusta el registro adicional y quiero mantenerlo. ¿Cuál es la forma limpia, directa y, lo más importante, aprobada por Drupal de hacer eso?

OhkaBaka
fuente
2
No veo por qué esto fue rechazado. Sí, se desaconseja editar core pero @OhkaBaka reconoció que está pidiendo sugerencias sobre cómo gestionar esto y proporcionó un ejemplo del mundo real. Junto con la necesidad de depurar situaciones, existen razones legítimas para editar core. Hay algunos errores en el núcleo con parches de trabajo en la cola de problemas que simplemente no se aplicarán, y hay algunas cosas que realmente no tienen soluciones.
mpdonadio
1
Las respuestas a continuación son geniales. Sin embargo, una cosa que agregaré es que no necesita activar el registro todo el tiempo en su sitio en vivo. Desactive su módulo personalizado cuando no lo esté utilizando, o aplique su parche o módulo solo a su sitio de desarrollo. Minimizar los cambios y documentar cuidadosamente te mantendrá cuerdo.
greg_1_anderson
@ greg_1_anderson: encontrará que mi solución a continuación ya aborda esto mediante el uso de una variable log_level (aunque el uso de constantes obviamente sería más limpio, los omití para poner énfasis en el patrón). De esta manera, puede usar el mismo método de envoltura en dev / live y el resto de su código puede depender de él sin cambiar las llamadas de función. Todo lo que necesita es establecer el nivel de registro de su módulo utilizando variable_set()o un mecanismo similar que se puede exportar si es necesario. :]
David Watson
1
@David: Sí, eso es increíble. Me gusta mantener los módulos de desarrollo deshabilitados en vivo y habilitarlos en un enlace de sincronización posterior a sql, según drupalcode.org/project/drush.git/blob/HEAD:/examples/… Su técnica también obtiene las mejores calificaciones, aunque yo Creo que también haría el variable_set en un gancho drush post-sync en lugar de una característica. Aplicar un parche solo en el sistema de desarrollo, como dije anteriormente, es probablemente una mala idea a menos que esté seguro de que el sistema es realmente un sistema de memoria virtual; de lo contrario, el partido podría ser cometido y empujado accidentalmente. Ay.
greg_1_anderson
@ greg_1_anderson: he tenido la intención de investigar si existen tales ganchos, y no me di cuenta de que ya había ejemplos; ¡Muchas gracias por el link! Sabiendo ahora que esto es posible, estoy de acuerdo en que establecer esto en el nivel del entorno es definitivamente el camino a seguir, tanto por las razones que sugiere como para ayudar a mantener la configuración genérica del sitio desacoplada de la configuración específica del entorno.
David Watson

Respuestas:

11

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.

David Watson
fuente
9

Si necesita modificar los módulos principales o contrib debería hacerlo.

  1. Crea un parche con cambios.
  2. Utilice un sistema de implementación como drush make que volverá a aplicar parches automáticamente cuando actualice el núcleo o los módulos.
  3. Documento documento documento.
googletorp
fuente
1
Realmente no esperaba una validación de alterar el núcleo por ningún tramo de la imaginación ... así que ahora me veo obligado a pasar a una pregunta secundaria: ¿es esto de alguna manera mejor que hacer lo mismo en un módulo independiente?
OhkaBaka