Como evito editar o núcleo do Drupal?

Eu estava construindo uma troca com um serviço XML de parceiros e não consegui acertar o XML, mas como em todas as coisas do Drupal, o log de erros e ações xmlrpc é menos do que robusto.

Então eu fiz isso no includes / 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;
}

Obtive os dados necessários e em 10 minutos a interface do parceiro respondeu adequadamente à minha solicitação porque (chocante eu sei) os logs são bons.

Gosto do registro extra e quero mantê-lo. Qual é a maneira limpa, direta e mais importante, aprovada pelo Drupal de fazer isso?

O núcleo de hackers é fortemente desencorajado para os não iniciados, pois reduz efetivamente a comunidade de suporte de milhares a uma comunidade de suporte de um (ou qualquer que seja o tamanho da sua equipe). Sem essa prática recomendada, ajudar os novatos no Drupal seria quase impossível. Isso também dificulta a modularidade e, em alguns casos, a segurança.

Dito isto, o núcleo de hackers nem sempre é tão ruim quanto gostamos de fazer parecer. Sem modificar o núcleo, não teríamos distribuições como Pressflow e similares que aumentam o núcleo de maneiras interessantes. É extremamente importante que você saiba exatamente o que está fazendo, que esteja distribuindo seus patches com sua distribuição (de preferência de uma maneira que permita aplicá-los novamente automaticamente após a atualização) e que esteja mantendo a documentação detalhada do que você mudou e por que você mudou.

Dependendo de como você tem as coisas estruturadas, você certamente pode fazer as alterações acima xmlrpc_request(), criar um patch e usar algo como o Drush Make para automatizar a aplicação (observe que o Drush Make está se movendo para o próprio projeto Drush na versão 5.x ), enquanto fornece documentação adicional no makefile e em outros lugares sobre o que a alteração faz e por que é necessária / desejada.

Outro padrão comum para aprimorar as funções principais é criar um invólucro que adicione um pouco de funcionalidade a uma função principal e chamar o invólucro no lugar da implementação do núcleo. Quando possível, isso torna as coisas muito mais modulares. Considere o seguinte:

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

Novamente, dependendo do que você está fazendo, isso pode ou não ser viável, mas quando você se salvou de algumas dores de cabeça ao tentar garantir que o núcleo permaneça corrigido e documentado. Embora, neste caso, uma função pontual como essa pareça um candidato perfeito para um invólucro desse tipo. Se sua implementação for capturada em um módulo, você poderá expandi-lo para controlar o nível de log de toda a sua solução, desativando essa funcionalidade nos sites de produção:

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

Em resumo, você deseja maximizar o que pode fazer com os módulos (e pode fazer muito), mas existem razões legítimas para alterar o núcleo. Isso deve ser feito com cuidado, só isso.

Se você precisar alterar os módulos principais ou de contribuição, deverá.

1. Crie um patch com alterações.
2. Use um sistema de implantação como o drush make que reaplique automaticamente os patches quando você atualizar o núcleo ou os módulos.
3. Documento Documento Documento.