如何避免编辑Drupal核心？

我当时正在与合作伙伴XML服务建立交换，但我无法正确处理XML，但是与所有Drupal一样，xmlrpc错误和操作日志都不可靠。

所以我在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;
}

我得到了我需要的数据，并在10分钟内使合作伙伴界面正确响应了我的请求，因为（令人震惊的）日志很好。

我喜欢额外的日志记录，并且希望保留它。什么是干净，直接，最重要的是Drupal批准的方式？

对于初学者，强烈建议不要使用Hacking Core，因为它可以有效地将成千上万的支持社区减少为一个（或无论您的团队规模如何）支持社区。没有这种最佳实践，帮助Drupal的新手几乎是不可能的。它还会妨碍模块化，在某些情况下还会影响安全性。

话虽如此，黑客核心并不总是像我们想像的那样邪恶。如果不修改核心，我们将不会有像Pressflow之类的发行版以有趣的方式增强核心。至关重要的是，您必须确切地知道自己在做什么，要随发行版一起分发补丁程序（最好是一种允许您在升级后自动应用补丁程序的方式），并且要保留详细的文档您所做的更改以及更改原因。

根据结构的不同，您当然可以对进行上述更改xmlrpc_request()，创建一个补丁，然后使用类似Drush Make的方法来自动应用它（请注意，Drush Make即将进入5.x版本的Drush项目本身。 ），同时在makefile和其他地方提供其他文档，说明所做的更改以及更改的必要性/原因。

增强核心功能的另一种常见模式是创建一个包装器，该包装器向核心功能添加一点点功能，然后调用包装器来代替核心​​的实现。在可行的情况下，这会使事情更具模块化。考虑以下：

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

再次，这取决于您正在执行的操作，可能可行或不可行，但是当您这样做时，您在确保确保对内核进行修补和记录方面为自己省了一些麻烦。尽管在这种情况下，像这样的一次性函数似乎是此类包装程序的理想选择。如果您的实现是在模块中捕获的，则您甚至可以对其进行扩展以控制整个解决方案的日志级别，从而在生产站点上禁用此功能：

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

简而言之，您想最大限度地利用模块（并且可以做很多事情）进行操作，但是出于合理的原因，更改内核。应该小心，仅此而已。

如果您需要更改核心或贡献模块，则应该。

1. 创建具有更改的补丁。
2. 使用诸如drush make之类的部署系统，该系统将在您更新核心或模块时自动重新应用补丁。
3. 文档文档文档。