WordPress 코어에 패치 제출: 변경 사항 생성 및 공유 프로세스

WordPress를 사용하여 생계를 유지하고 자신의 이야기를 전한다면, 작성한 변경 사항이 WordPress 코드베이스에 추가되는 것을 보는 것은 매우 흥미로울 것입니다. 나는 이것이 나를 위한 것이라는 것을 안다.

이 튜토리얼에서는 핵심 소프트웨어에서 허용되는 WordPress 패치를 만들기 위해 알아야 할 몇 가지 간단한 사항을 배웁니다.

WordPress는 누구나 다운로드하고 수정할 수 있는 오픈 소스 소프트웨어이지만 소수의 핵심 기여자만이 변경 사항을 WordPress 자체에 커밋할 수 있습니다. WordPress의 핵심 파일을 변경하려는 경우 제안된 변경 사항을 자세히 설명하는 티켓을 만들고 패치를 첨부하여 제안하거나 기존 티켓에 패치를 첨부하여 제안할 수 있습니다.

패치 또는 diff 파일은 소스 코드에 대한 변경 사항을 자세히 설명하는 파일이며 SVN 또는 GIT와 같은 버전 제어 시스템에서 변경 사항을 적용하는 데 사용할 수 있습니다. 패치는 명령줄이나 SourceTree와 같은 GUI 도구를 통해 쉽게 생성할 수 있습니다.

이 기사에서는 우수한 GIT GUI 애플리케이션 SourceTree를 사용하여 최신 버전의 WordPress를 확인하고 패치 파일을 생성하는 방법을 자세히 설명하겠습니다. 원하는 경우 원하는 GUI 도구나 명령줄을 사용할 수 있습니다.

Core Trac에서 티켓 찾기 또는 만들기

WordPress 코어에 패치를 제출할 때 WordPress 문제 추적기(trac라고 함)의 티켓에 패치를 첨부해야 합니다. 따라서 패치 제출의 첫 번째 단계는 티켓을 찾거나 생성하는 것입니다.

새로운 기능이 포함된 새 티켓이 승인될 가능성은 있지만 그럴 가능성은 낮습니다. WordPress에는 수백만 명의 사용자가 있으므로 주요 개발자가 새로운 기능 도입을 경계하는 것은 당연합니다. 이제 거의 모든 새로운 기능은 먼저 플러그인으로 별도로 개발되고 광범위한 테스트 및 개발 후에만 핵심에 병합됩니다.

패치를 승인받는 가장 좋은 방법은 기존 티켓에 대한 패치를 만드는 것입니다. 최근에는 간단한 수정 사항이 있고 WordPress의 다음 버전 및 버전에 포함될 가능성이 가장 높은 티켓을 더 쉽게 찾을 수 있도록 core trac이 재설계되었습니다.

버그 신고

core trac에서 새 티켓을 만들고 싶다면(새 버그를 발견하면 매우 좋습니다) 여기에서 만들 수 있습니다. 새 티켓을 만들기 전에 동일한 문제에 대한 보고가 있는지 추적을 검색하고 최신 버전의 WordPress에 버그가 있는지 확인하세요.

최신 버전이 아니라 GIT 용어로는 마스터 브랜치, SVN 용어로는 트렁크를 의미합니다. 이 튜토리얼의 뒷부분에서 최신 버전을 얻는 방법을 자세히 설명하겠습니다.

최소 요약 필드(티켓 제목)와 티켓 내용인 설명 필드를 반드시 작성해야 합니다. 티켓 설명에는 최대한 자세히 설명하세요.

내가 참석한 2013년 WordCamp 올랜도 기여자 워크숍에서 WordPress의 수석 개발자인 Mark Jaquith와 Andrew Nacin은 다음과 같은 훌륭한 버그 보고서 목록을 만들었습니다.

• 문제 재현 단계(가장 빠른 단계부터 시작)
• 오류 설명
• 보이는 것과 기대하는 것
• 오류 메시지 또는 오류 코드
• PHP 오류(페이지의 경고는 무엇이며 로그에 나타나는 내용은 무엇입니까? JavaScript 또는 Apache/nginx 오류가 있습니까?)
• 어떤 브라우저인가요?
• 환경(PHP 버전, MySQL Apache 또는 nginx 버전)
• 플러그인과 기본 테마가 없어도 이런 일이 발생하나요?
• UI 문제 스크린샷
• 명확하고 간결함
• 본론부터 먼저 설명하고 자세히 설명하겠습니다.
• 관련 티켓번호
• 티켓당 오류 1개
• 퍼머링크 설정
• 멀티사이트가 활성화되었나요?
• WP_DEBUG 또는 이에 상응하는 기능이 활성화되어 있습니까?
• 문제 발생 시 로그인한 사용자 역할(또는 데이터베이스에서 역할 변경)

이 모든 내용이 모든 오류와 관련이 있는 것은 아니지만 관련 정보를 더 많이 추가할수록 더 좋습니다.

여기에 무엇을 설정하고 싶은지 확실하지 않은 경우 아래 설명된 필드를 그대로 두고 핵심 기여자가 이를 사용하여 그에 따라 티켓을 분류하도록 해야 합니다. 버그 수정을 위해 패치를 첨부하는지 여부에 따라 "패치 있음" 또는 "패치 필요" 태그를 사용하는 것이 좋습니다.

GUI 도구를 사용하여 GitHub에서 최신 WordPress 보기

티켓에 대한 패치를 만들기 전에 WordPress의 최신 버전을 보유하는 것이 매우 중요합니다. WordPress에는 매일 많은 변경 사항이 적용되기 때문입니다. 최신 코드를 사용하지 않는 한 수정 사항이 작동했는지 또는 버그가 여전히 존재하는지 알 수 없습니다. 패치가 이미 변경된 코드를 수정하는 경우 승인되지 않을 수 있습니다.

WordPress는 SVN에서 관리되지만 코드는 두 위치에 GIT 저장소로 미러링됩니다.

1. git://core.git.wordpress.org/
2. https://github.com/WordPress/WordPress

GitHub 저장소가 가장 사용하기 쉽습니다. 공식 GitHub 저장소이더라도 여전히 문제 추적에 사용되지 않으며 여기에 풀 요청을 제출해서는 안 된다는 점을 명심하세요.

SVN 또는 Git을 통해 최신 버전의 WordPress를 다운로드하는 방법에는 여러 가지가 있습니다. 개인적으로 저는 뛰어난 GIT GUI 도구인 SourceTree를 사용하여 GitHub 이미지를 복제하는 가장 쉬운 방법을 찾았습니다. 이는 파일 메뉴에서 새로 만들기/복제를 선택하고, 소스 경로/URL 필드에 Git 저장소 주소를 입력하고, XAMMP 또는 Vagrant 테스트 환경 내에 있는 복제본의 로컬 경로를 지정하는 것만큼 간단합니다.

Vagrant에 대해 말하자면, 인기 있는 WordPress Vagrant 구성 VVV에는 최신 코드 및 단위 테스트를 포함하여 WordPress 코어에 대해 사전 구성된 테스트 환경이 있습니다.

패치 파일 생성

수정하려는 문제를 해결하는 데 필요한 WordPress 변경 사항을 적용하고 수정 사항을 테스트한 후에는 티켓에 업로드할 패치 파일을 만들어야 합니다. SourceTree에는 패치 파일을 생성하는 방법이 포함되어 있거나 명령줄을 사용할 수 있습니다.

SourceTree에서는 작업 복사본으로 이동하여 변경된 파일을 마우스 오른쪽 버튼으로 클릭하여 패치 파일을 만들 수 있습니다. 마우스 오른쪽 버튼 클릭 메뉴에서 "패치 생성"을 선택합니다.

또는 터미널에서 WordPress 저장소 루트로 이동하고 다음 명령을 사용하여 차이점을 만듭니다.

git diff —非前缀 ~/name.path

패치 파일을 어떻게 생성하든 대상 티켓 번호를 따서 이름을 지정해야 합니다. 티켓에 업로드된 두 번째 패치인 경우 번호 끝에 .2를 추가하고, 세 번째 패치인 경우 .3을 추가하는 식으로 진행합니다. 예를 들어 티켓 #12358의 다섯 번째 패치는 #12358.5

Trac에 패치 업로드

이제 패치가 준비되었으므로 이를 core trac의 티켓에 업로드해야 합니다. 기존 티켓에는 패치를 업로드하는 데 사용할 수 있는 설명 아래에 "파일 첨부" 버튼이 있습니다. 다음 화면에서 패치의 기능에 대한 설명을 추가하세요.

인내심을 가지고 이해해주세요

WordPress는 대규모 프로젝트이므로 패치에 대한 즉각적인 응답을 기대하는 것은 무리입니다. 또한 모든 사용자에게 최상의 서비스를 제공하려면 WordPress에 제출되는 패치 표준이 매우 높아야 한다는 점을 이해하시기 바랍니다.

패치를 제출한 후 받는 피드백을 인내심을 갖고 이해해 주시기 바랍니다. 주요 개발자는 매우 쉽게 접근할 수 있습니다. 패치에 대한 질문이 있거나 패치가 개선되지 않는 이유가 있으면 #wordpress-dev IRC 채널에서 그들 중 한 명에게 자유롭게 문의하세요.

응답을 기다리고 변경해야 하는 것이 답답할 수 있지만 패치가 WordPress에 제출되고 변경 세트 설명이 사용자를 인식할 때 그만한 가치가 있습니다.