Як я можу уникати редагування ядра Drupal?

Я будував обмін з сервісом XML партнерів, і я не міг отримати право XML, але як і у всіх випадках Drupal, реєстрація помилок xmlrpc та реєстрація дій є менш ніж надійною.

Тож я зробив це у включенні / 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 спосіб цього?

Хакерське ядро ​​сильно не рекомендується для непосвячених, оскільки воно фактично скорочує тисячу спільнот підтримки до спільноти підтримки (або будь-якого розміру вашої команди). Без цієї найкращої практики допомогти новим в Друпалі було б майже неможливо. Це також заважає модульності та, в деяких випадках, безпеці.

Це вже було сказано, що зламане ядро ​​не завжди є таким злим, як ми хотіли б це зробити. Без зміни ядра у нас не було б таких дистрибутивів, як Pressflow тощо. Просто життєво важливо, щоб ви точно знали, що ви робите, що ви розповсюджуєте свої патчі своїм дистрибутивом (бажано таким чином, що дозволяє вам знову застосовувати їх автоматично після оновлення), а також зберігати детальну документацію що ви змінили і чому ви змінили.

Залежно від того, як ви структуровані речі, ви, безумовно, можете внести вищезазначені зміни до xmlrpc_request(), створити патч, а потім використовувати щось на зразок Drush Make для автоматизації його застосування (зауважте, що Drush Make переходить до проекту Drush для випуску 5.x ), надаючи додаткову документацію в 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);
  }
}

Коротше кажучи, ви хочете максимально збільшити те, що ви можете зробити з модулями (а ви можете зробити багато чого), але є законні причини зміни ядра. Це слід робити обережно, ось і все.

Якщо вам потрібно змінити модулі core або contrib, слід.

1. Створіть виправлення із змінами.
2. Використовуйте систему розгортання, наприклад drush make, яка автоматично повторно застосовуватиме патчі при оновленні ядра чи модулів.
3. Документ документа документ.