우리는 왜 핵심을 해킹하지 않습니까?

이 사이트에서이 질문에 대한 답변이 아직 없다고 믿을 수 없었지만 검색 할 때 찾지 못했습니다.

왜 핵심을 해킹하는 것이 자연에 대한 나쁜 생각 범죄입니까?

• 코어 버전을 업그레이드 할 수있는 것이 정말 좋은가요? 어쨌든 대부분의 사이트는 결국 오래된 코어를 사용하게되므로 왜 귀찮게합니까?
• 사이트 소유자에게 너무 나쁘더라도 커뮤니티가 왜 그렇게 많은 관심을 줍니까? 왜 "죽이는 새끼 고양이"라고 불리는가? 오히려 쌍곡선 아닌가요?
• 해킹 코어는 매우 쉽습니다. 문제 해결을위한 더 쉬운 길을 가고 싶지 않습니까?
• 해킹 코어 로만 해결할 수있는 문제가 없습니까? 그럼 뭐야?

일반적으로 Drupal 핵심 코드를 변경하지 않는 데는 세 가지 이유가 있습니다.

• 필요한 단계를 수행하지 않으면 Drupal을 업데이트 할 때마다 변경 사항이 손실됩니다. 사용중인 현재 Drupal 버전에 대한 패치를 작성하는 경우에도 패치가 최신 버전에 적용되지 않으며 새 버전에 대한 패치도 작성해야합니다.

• 보안 수정 사항은 Drupal.org에서 유지 관리되는 Drupal 코어에는 적용되지만 해킹 된 버전에는 적용 할 수 없습니다. 즉, 버전이 Drupal 코어에 대해 제기 된 보안 문제의 영향을받지 않는지 확인해야합니다.
  해킹 된 버전에 다른 보안 문제가 발생하는 경우 Drupal 코어 코드 및 타사에 존재하는 보안 결함을 조사하는 보안 팀의 지원이 없기 때문에 사용자는 자신이 찾을 수있는 유일한 사람입니다. Drupal.org에서 호스팅되는 모듈.

• 도입 한 변경 사항은 Drupal 자체와 호환되지 않을 수 있으며 타사 모듈과도 호환 될 수 있습니다.이 모듈은 생성 된 해킹 된 버전이 아니라 Drupal 코어와 함께 작동해야합니다.
  Drupal은 새로운 기능 (Drupal 7과 Drupal 6에서 빈도는 낮지 만 여전히 발생 함) 또는 새로운 API 변경을 도입 할 때마다 해킹 된 버전이 최근 변경 사항과 호환되지 않을 가능성이 있습니다.

즉, 해킹 된 버전을 만들 수는 있지만 단일 개발자가 Drupal을 유지 관리하지 않는 것과 같이 단일 개발자가 수행 할 수있는 작업은 아닙니다. 실제로 Pressflow는 성능을 염두에두고 만들어진 Drupal 의 해킹 된 버전이며 Drupal 사이트에서 발생할 수있는 일부 성능 문제를 해결합니다.

해킹 코어로만 해결할 수있는 문제가 없습니까? 그럼 뭐야?

대부분의 경우 Drupal 코어 코드를 편집하지 않고 기능 / 동작을 변경할 수 있습니다. Drupal의 기능 / 동작을 변경할 수있는 후크가 항상 있으며, 이것이 선호되는 방법입니다.

나는 여기에 거대한 대답을 쓸 수는 있지만이 링크를 게시 할 것입니다 : 절대 핵을 해킹하지 마십시오 !

내가 추측하는 주된 이유는 코어를 해킹하여 필요한 것을 수행 한 다음 업데이트하는 것입니다. 변경 사항이 사라졌습니다. 잃어버린. 그런 다음 VCS에서 코드를 롤백하고 롤백 할 수 있지만 Drupal 코어에서 데이터베이스 업그레이드를 롤백 할 수 없는지 확인하십시오. VCS에서 모든 코드를 복원 한 다음 백업에서 데이터베이스를 복원하는 중입니다. 코드를 롤백 할 때마다 마지막 사전 업데이트 데이터베이스 백업이 실패했음을 알 수 있으며 이전에 맹세했던 것보다 더 많이 맹세합니다.

또한 가장 중요한 것은 코어를 해킹하면 Dries와 Webchick가 새끼 고양이를 죽이는 것입니다.

"해킹 코어가 개발자를 위해 무엇을 할 수 없습니까?"

• 보안 릴리스를 위해 사이트를 업그레이드 할 수 있습니다
• 핵심에서 성가신 버그를 해결하기 위해 사이트를 업그레이드 할 수 있습니다
• 새 모듈을 지원하도록 사이트를 업그레이드 할 수 있습니다
• 핵심 및 contrib에 대한 버그 보고서 및 지원 요청에 응답 할 수 있습니다.
• 지원되는 CMS를 사용하려고하므로 Drupal을 선택했습니다. webchick 의 말에 따르면 코어를 해킹 할 때 "핵심을 해킹하면 축하합니다! 당신은 드루팔 포크를 만들었습니다.

"해킹 코어가 클라이언트를 위해 무엇을 할 수 없습니까?"

• 고객을 해고하거나 복권 당첨 / 버스로 타격을받은 후에 다른 사람이 사이트를 관리 할 수 ​​있습니다

"핵심 해킹 코어가 할 수없는 것은 무엇입니까?"

• 버그 리포트는 실제로 코어 또는 contrib 모듈의 관리자에게 유용한 정보를 제공합니다.
• 코어에서 패치해야하는 합법적 인 버그를 발견 한 경우, '핵심 해킹'과 '핵심 기여자가되는 것'사이의 경계는 변경 사항을 간단히 파악하여 관련 문제에 패치로 업로드하는 것만 큼 좋습니다. 비올라! 핵심은 귀하의 노력에 더 좋고 귀하의 이름은 커뮤니티에 코드를 제공하는 것과 관련이 있습니다.

코어를 해킹하지 않으면 모두가 승자입니다!

현재 해킹 된 핵심 웹 사이트에서 작업하고 있습니다. 글꼴처럼 간단한 것이 어떻게 설정되는지 찾기가 어렵습니다. 또한 핵심 해킹으로 인해 발생한 버그를 수정하는 데 며칠이 걸렸습니다. 전체 drupal 코드에서 문자열을 검색하여 찾았습니다.

drupal에서 프로그래밍의 표준 구조를 따르지 않으면 다른 사람이 어떻게 변경 내용을 찾고 편집 할 수 있습니까? drupal에서 모든 단일 PHP 파일이 후크를 구현할 수 있기 때문에 이것은 특히 고통 스럽습니다. 어느 것이 문제를 일으키는 지 알아보십시오.

"핵을 해킹해서 만 해결할 수있는 문제가 없습니까? 그렇다면 무엇입니까?"

이 질문에 대답하기 위해, 때로는 코어 (또는 contrib 모듈)를 해킹해야한다는 의미에서 극복해야 할 문제가 있습니다.

이 경우 해킹 된 코드에 많은 주석을 넣고 변경 한 모든 내용을 문서화하는 한 해킹하는 것이 좋습니다.

예를 들어, 핵심 또는 구성 요소 변경에 대해 패치를 작성합니다. 그것이 다른 사람들에게 일반적이고 유용하다면 문제에 drupal.org에 제출하십시오. 그렇지 않으면 내 용도로 사용됩니다.

그런 다음 코드 변경과 함께 패치 파일을 버전 관리에 커밋합니다.

이것은 뭔가 해킹당한 경우 패치 파일을 찾아 볼 수 있음을 의미합니다.

그 외에도 사이트의 개발자 문서에 해킹 목록을 추가합니다 (사이트에서 작동하는 다른 사용자를 위해 그리고 불가피하게 잊어 버렸을 때 자신을 위해 개발자 문서가 있어야 함).

이 핵 문서에서 나는 핵이 무엇을하는지, 왜 영향을받는 모듈 / 파일, 핵 코드가 들어있는 패치 파일의 이름, 그리고 관련된 drupal.org 문제에 대한 링크가 있다면 각 핵을 나열합니다. 내 경우에는).

그러면 앞으로 사이트에서 일하는 다른 사람이 해킹에 대한 전체 목록을 가지고 있으며 실수로 업데이트를 통해 무언가를 깨뜨릴 염려가 없습니다.

그런 다음 업데이트 프로세스를 위해 해킹 목록을 확인하고 업데이트중인 모든 모듈에서 패치 파일을 빠르게 살펴 봅니다. 해킹이 있고 drupal.org 문제가있는 경우 최신 버전에 패치가 포함되어 있는지 확인하십시오.이 경우 업데이트로 해킹을 날려 내 해킹 목록에서 제거하십시오 (make drupal.org 커밋 메시지를보고 커밋 된 것이 사용중인 패치 버전과 같거나 최소한 기능적으로는 동일하다는 것을 확인하십시오.

패치가 커밋되지 않은 경우 모듈을 업데이트하고 패치를 다시 적용하기 만하면됩니다. 많은 경우에 패치는 여전히 깨끗하게 적용되며 프로세스는 쉬워 지지만 때로는 새 버전의 패치를 다시 롤업 한 다음 새 버전의 패치를 로컬 리포지토리에 커밋해야합니다. 해당되는 경우 drupal.org 문제).

모듈 (또는 drupal.org 모듈 위로 확장되는 사용자 정의 모듈)의 핵심 기능과 상호 작용하는보다 실질적인 패치 또는 패치가있는 경우 업데이트하려는 모듈의 릴리스 정보를 확인하는 것이 좋습니다. 즉, 현재 버전과 업데이트하려는 버전 사이의 모든 버전을 의미하고 코드를 손상시킬 수있는 항목이 없는지 확인하십시오. 참고 : 요즘에는 완전한 릴리스 노트를 제공하여 많은 모듈 유지 보수 담당자가 유용하지만 여전히 쓰레기 릴리스 노트를 수행하는 많은 것이 있습니다. 이 경우 현재 버전 이후 모든 커밋 메시지를 통과하는 경우가 있습니다 (일반적으로 다른 모듈과 깊이 상호 작용하는 복잡한 코드가있는 경우에만 해당). 노트 :

그런 다음 사이트의 개발 사본에서 업데이트 한 후 철저히 테스트하십시오. 결국 몇 가지 버그가 발생한 후 철저한 의미를 배우게됩니다.

그런 다음 테스트가 충분히 완료되면 라이브 사이트를 업그레이드하거나 로컬 업데이트를 배포하거나 배포 프로세스에 관계없이 진행하십시오.

더 쉬운 경우에도 모두가 그렇게하지 않는 이유 : 대부분의 사람들은 내가 설명한 것과 같은 시스템을 가지고 있지 않기 때문에 업데이트를해야 할 때가되거나 사이트를 다른 사람에게 건네주기 때문에 그것은 악몽이되고 많은 시간 (때로는 엄청난 시간)이 버그를 해결하고 해킹을 추적하고 그 이유가 무엇인지 등을 해결하는 데 소비되어야합니다.

그런 사이트를 상속 받았다면 완전히 이해할 것입니다 :)

Drupal 웹 사이트를 설치하고 생성하여 생계를 유지하려면 최신 상태로 유지해야합니다. 대부분의 사이트가 끔찍하게 구식 인 경우 전문가가 아닙니다.