Come posso evitare di modificare Drupal core?

Stavo costruendo uno scambio con un servizio XML dei partner e non riuscivo a ottenere l'XML giusto, ma come per tutte le cose Drupal, l'errore xmlrpc e la registrazione delle azioni sono meno robusti.

Quindi l'ho fatto in include / 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;
}

Ho ottenuto i dati di cui avevo bisogno e in 10 minuti l'interfaccia del partner ha risposto adeguatamente alla mia richiesta perché i registri (scioccanti lo so) sono buoni.

Mi piace la registrazione extra e voglio conservarla. Qual è il modo pulito, diretto e, soprattutto, approvato da Drupal per farlo?

L'hacking core è fortemente scoraggiato per i non iniziati perché riduce efficacemente la comunità di supporto di migliaia a una comunità di supporto di uno (o qualunque sia la dimensione della tua squadra). Senza questa best practice, aiutare i nuovi arrivati ​​a Drupal sarebbe quasi impossibile. Inoltre ostacola la modularità e, in alcuni casi, la sicurezza.

Detto questo, l'hacking core non è sempre così malvagio come ci piace farcela. Senza modificare core, non avremmo distribuzioni come Pressflow e simili che aumentano il core in modi interessanti. È di vitale importanza che tu sappia esattamente cosa stai facendo, che stai distribuendo le tue patch con la tua distribuzione (preferibilmente in un modo che ti permetta di applicarle di nuovo automaticamente dopo l'aggiornamento) e che stai mantenendo una documentazione dettagliata di cosa hai cambiato e perché l'hai cambiato.

A seconda di come hai strutturato le cose, potresti sicuramente apportare la modifica sopra a xmlrpc_request(), creare una patch e quindi utilizzare qualcosa come Drush Make per automatizzare l'applicazione (nota che Drush Make si sta spostando nel progetto Drush stesso per la versione 5.x ), fornendo al contempo documentazione aggiuntiva nel makefile e altrove su ciò che fa il cambiamento e perché è necessario / desiderato.

Un altro modello comune per migliorare le funzioni principali è quello di creare un wrapper che aggiunge un po 'di funzionalità a una funzione core e chiamare il wrapper al posto dell'implementazione del core. Quando possibile, questo rende le cose molto più modulari. Considera quanto segue:

/**
 * 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;
}

Ancora una volta, a seconda di cosa stai facendo, questo può o non può essere fattibile, ma quando lo fai ti sei risparmiato qualche mal di testa nel tentativo di assicurarti che il core rimanga patchato e documentato. Anche se in questo caso, una funzione unica come questa sembra un candidato perfetto per un tale wrapper. Se l'implementazione viene acquisita in un modulo, è anche possibile espanderlo per controllare il livello di registro dell'intera soluzione, disabilitando questa funzionalità nei siti di produzione:

/**
 * 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);
  }
}

In breve, vuoi massimizzare ciò che puoi fare con i moduli (e puoi fare molto), ma ci sono motivi legittimi per alterare il core. Dovrebbe essere fatto con cura, tutto qui.

Se è necessario modificare i moduli core o contrib , è necessario.

1. Crea una patch con le modifiche.
2. Utilizzare un sistema di distribuzione come drush make che riapplicherà automaticamente le patch quando si aggiornano core o moduli.
3. Documento documento documento.