Jak uniknąć edytowania rdzenia Drupal?

21

Budowałem wymianę z usługą XML partnerów i nie mogłem poprawnie uzyskać XML, ale tak jak w przypadku wszystkich rzeczy Drupal, błąd xmlrpc i rejestrowanie działań jest mniej niż niezawodny.

Zrobiłem to w pliku / 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;
}

Dostałem potrzebne dane i po 10 minutach interfejs partnera odpowiednio zareagował na moje żądanie, ponieważ (szokujące, że wiem) dzienniki są dobre.

Lubię dodatkowe logowanie i chcę je zachować. Jaki jest czysty, prosty i co najważniejsze, zatwierdzony przez Drupala sposób?

OhkaBaka
źródło
2
Nie rozumiem, dlaczego zostało to odrzucone. Tak, rdzeń edycyjny jest odradzany, ale @OhkaBaka przyznał, że prosi o sugestie, jak to zarządzać i podał prawdziwy przykład. Oprócz konieczności debugowania sytuacji istnieją uzasadnione powody do edycji rdzenia. Jest kilka błędów w podstawowych poprawkach / działających poprawkach w kolejce problemów, które po prostu nie zostaną zastosowane, i jest kilka rzeczy, które tak naprawdę nie mają obejść.
mpdonadio
1
Odpowiedzi poniżej są świetne. Dodam jednak, że nie trzeba włączać rejestrowania przez cały czas w witrynie na żywo. Wyłącz moduł niestandardowy, gdy go nie używasz, lub zastosuj łatkę lub moduł tylko w witrynie deweloperskiej. Minimalizowanie zmian i staranne dokumentowanie zapewni ci rozsądek.
greg_1_anderson
@ greg_1_anderson - Przekonasz się, że moje rozwiązanie poniżej rozwiązuje to już za pomocą zmiennej log_level (chociaż użycie stałych byłoby oczywiście czystsze, pominąłem je, aby położyć nacisk na wzorzec). W ten sposób możesz użyć tej samej metody opakowania w dev / live, a reszta kodu może na nim polegać bez zmiany wywołań funkcji. Wystarczy ustawić poziom rejestrowania modułu za pomocą variable_set()lub podobnego mechanizmu, który w razie potrzeby można wyeksportować. :]
David Watson,
1
@David: Tak, to jest niesamowite. Lubię utrzymywać moduły deweloperskie wyłączone na żywo i włączać je w trybie synchronizacji post-sql, na drupalcode.org/project/drush.git/blob/HEAD:/examples/… Twoja technika też ma najwyższe noty, chociaż ja myślę, że zrobiłbym również zmienny_zestaw w drak haczyku po synchronizacji zamiast funkcji. Zastosowanie łaty tylko w systemie deweloperskim, jak powiedziałem powyżej, jest prawdopodobnie złym pomysłem, chyba że jesteś pewien, że system jest naprawdę systemem scratch; w przeciwnym razie mecz może zostać przypadkowo popełniony i przeforsowany. Ojej
greg_1_anderson
@ greg_1_anderson - chciałem sprawdzić, czy takie haki istnieją, i nie zdawałem sobie sprawy, że istnieją już przykłady; wielkie dzięki za link! Wiedząc teraz, że jest to możliwe, zgadzam się, że ustawienie tego na poziomie środowiska jest zdecydowanie najlepszym rozwiązaniem, zarówno z powodów, które sugerujesz, jak i w celu utrzymania ogólnej konfiguracji witryny oddzielonej od konfiguracji specyficznej dla środowiska.
David Watson,

Odpowiedzi:

11

Rdzeń hakerski jest zdecydowanie odradzany dla niewtajemniczonych, ponieważ skutecznie redukuje społeczność wsparcia tysięcy do społeczności wsparcia jednego (lub jakiejkolwiek wielkości twojego zespołu). Bez tej najlepszej praktyki pomoc nowym osobom w Drupal byłaby prawie niemożliwa. Utrudnia to również modułowość, aw niektórych przypadkach bezpieczeństwo.

To powiedziawszy, rdzeń hakerski nie zawsze jest tak zły, jak nam się wydaje. Bez modyfikacji rdzenia nie mielibyśmy dystrybucji takich jak Pressflow i tym podobne rdzenie rozszerzające w interesujący sposób. Bardzo ważne jest, abyś dokładnie wiedział, co robisz, że rozprowadzasz swoje łatki wraz z dystrybucją (najlepiej w sposób, który pozwala na ich ponowne zastosowanie automatycznie po aktualizacji) i że przechowujesz szczegółową dokumentację tego, co zmieniłeś i dlaczego to zmieniłeś.

W zależności od tego, jak masz strukturę, z pewnością możesz wprowadzić powyższą zmianę xmlrpc_request(), utworzyć łatkę, a następnie użyć czegoś takiego jak Drush Make, aby zautomatyzować jej stosowanie (zwróć uwagę, że Drush Make przenosi się do samego projektu Drush w wersji 5.x. ), dostarczając dodatkową dokumentację w pliku makefile i gdzie indziej, co robi zmiana i dlaczego jest to konieczne / pożądane.

Innym powszechnym wzorcem do ulepszania podstawowych funkcji jest tworzenie otoki, która dodaje odrobinę funkcjonalności do podstawowej funkcji, i wywoływanie otoki zamiast implementacji rdzenia. Gdy jest to wykonalne, sprawia, że ​​rzeczy są znacznie bardziej modułowe. Rozważ następujące:

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

Ponownie, w zależności od tego, co robisz, może to być lub nie być wykonalne, ale kiedy już to zaoszczędzisz, masz kilka kłopotów z próbą upewnienia się, że rdzeń pozostaje załatany i udokumentowany. Chociaż w tym przypadku taka jednorazowa funkcja wydaje się idealnym kandydatem na takie opakowanie. Jeśli twoja implementacja jest przechwycona w module, możesz nawet ją rozwinąć, aby kontrolować poziom rejestrowania całego rozwiązania, wyłączając tę ​​funkcję w witrynach produkcyjnych:

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

Krótko mówiąc, chcesz zmaksymalizować to, co możesz zrobić z modułami (i możesz dużo zrobić), ale istnieją uzasadnione powody, aby zmienić rdzeń. Należy to robić ostrożnie, to wszystko.

David Watson
źródło
9

Jeśli trzeba zmienić podstawowe lub contrib modułów należy.

  1. Utwórz łatkę ze zmianami.
  2. Użyj systemu wdrażania, takiego jak drush make, który automatycznie zastosuje łaty po aktualizacji rdzenia lub modułów.
  3. Dokument dokument dokument.
googletorp
źródło
1
Naprawdę nie spodziewałem się zatwierdzenia zmiany rdzenia przez jakąkolwiek część wyobraźni ... więc jestem teraz zmuszony przejść do drugiego pytania: czy jest to w jakikolwiek sposób lepsze niż robienie tego samego w samodzielnym module?
OhkaBaka,