Как мне избежать редактирования ядра 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 способ сделать это?

Хакерское ядро ​​настоятельно не рекомендуется для непосвященных, потому что оно эффективно сокращает сообщество поддержки тысяч человек до сообщества поддержки одного (или любого размера вашей команды). Без этой лучшей практики помощь новичкам в Drupal была бы почти невозможна. Это также препятствует модульности и, в некоторых случаях, безопасности.

Как уже было сказано, хакерское ядро ​​не всегда так зло, как нам хотелось бы, чтобы это было. Без модификации ядра у нас не было бы таких дистрибутивов, как Pressflow и т. П., Которые расширяют ядро ​​интересными способами. Просто жизненно важно, чтобы вы точно знали, что делаете, что вы распространяете свои патчи вместе с вашим дистрибутивом (желательно таким образом, чтобы вы могли применить их снова автоматически после обновления), и чтобы вы хранили подробную документацию о том, что вы изменили и почему вы изменили это.

В зависимости от того, как у вас все структурировано, вы, безусловно, можете внести указанные выше изменения xmlrpc_request(), создать патч, а затем использовать что-то вроде Drush Make для автоматизации его применения (обратите внимание, что Drush Make перемещается в сам проект Drush для выпуска 5.x. ), предоставляя дополнительную документацию в make-файле и в других местах о том, что делает изменение и почему оно необходимо / желательно.

Другим распространенным шаблоном для улучшения основных функций является создание оболочки, которая добавляет к ядру небольшую функциональность, и вызывает реализацию оболочки вместо реализации ядра. Когда это возможно, это делает вещи намного более модульными. Учтите следующее:

/**
 * 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. Документ документ документ.