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이 승인 한 가장 깨끗하고 간단하며 가장 중요한 방법은 무엇입니까?

— 오카 바카
소스

이것이 왜 다운 보트인지 모르겠습니다. 예, 편집 핵심은 권장되지 않지만 @OhkaBaka는이를 관리하는 방법에 대한 제안을 요구하고 실제 사례를 제공한다는 점을 인정했습니다. 상황을 디버깅해야 할 필요성과 함께 핵심 편집의 합법적 인 이유가 있습니다. 이슈 큐의 핵심 패치에는 적용되지 않는 버그가 있으며 실제로 해결 방법이없는 몇 가지 사항이 있습니다.

— mpdonadio

아래 답변이 훌륭합니다. 그러나 내가 추가 할 한 가지는 라이브 사이트에서 항상 로깅을 켤 필요가 없다는 것입니다. 사용자 정의 모듈을 사용하지 않을 때는 비활성화하거나 패치 또는 모듈을 개발자 사이트에만 적용하십시오. 변경 사항을 최소화하고 신중하게 문서화하면 제정신이 유지됩니다.

— greg_1_anderson

@ greg_1_anderson-아래의 솔루션은 이미 log_level 변수를 사용 하여이 문제를 해결한다는 것을 알 수 있습니다 (상수를 사용하면 분명히 더 깨끗하지만 패턴을 강조하기 위해 생략했습니다). 이 방법으로 dev / live에서 동일한 래퍼 메소드를 사용할 수 있으며 나머지 코드는 함수 호출을 변경하지 않고도 메소드에 의존 할 수 있습니다. 필요한 variable_set()경우 내보낼 수있는 유사한 메커니즘을 사용하여 모듈의 로깅 수준을 설정하기 만하면됩니다 . :]

— David Watson

@David : 그렇습니다. dev 모듈을 실시간으로 비활성화하고 drupalcode.org/project/drush.git/blob/HEAD:/examples/ 에 따라 post-sql-sync 후크에서 활성화하는 것을 좋아합니다. 기능이 아닌 drush post-sync hook에서 variable_set을 수행한다고 생각합니다. 위에서 말했듯이 dev 시스템에만 패치를 적용하는 것은 시스템이 실제로 스크래치 시스템인지 확신하지 않는 한 나쁜 생각입니다. 그렇지 않으면 경기가 실수로 커밋되어 푸시 될 수 있습니다. 아야.

— greg_1_anderson

@ greg_1_anderson-나는 실제로 그러한 갈고리가 존재하는지 살펴보고자하는 의미를 가지고 있었으며 이미 그 예가 있다는 것을 몰랐다. 링크 주셔서 감사합니다! 이것이 가능하다는 것을 알았으므로 환경 수준에서 이것을 설정하는 것이 당신이 제안하는 이유와 일반 사이트 구성이 환경 별 구성에서 분리되도록 유지하는 데 도움이되는 방법이라는 데 동의합니다.

— David Watson

답변:

해킹 코어는 수천 명의 지원 커뮤니티를 하나의 지원 커뮤니티 (또는 팀 규모에 상관없이)로 효과적으로 줄이므로 시작하지 않은 사람에게는 강력히 권장하지 않습니다. 이 모범 사례가 없다면 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);
  }
}

요컨대, 모듈로 할 수있는 일을 최대화하고 많은 일을 할 수 있지만 코어를 변경해야하는 합당한 이유가 있습니다. 주의해서해야합니다. 그게 전부입니다.

— 데이비드 왓슨
소스

코어 또는 contrib 모듈 을 변경해야하는 경우 해야합니다.

변경 사항이 적용된 패치를 만듭니다.

코어 또는 모듈을 업데이트 할 때 패치를 자동으로 다시 적용하는 drush make와 같은 배포 시스템을 사용하십시오.

문서 문서 문서.

— 구글 토프
소스

나는 정말로 상상력의 확장으로 코어를 변경하는 것에 대한 유효성 검사를 기대하지 않았다. 그래서 나는 이제 두 번째 질문으로 넘어 가야한다.

— OhkaBaka