FSWP 유지관리자은(는) 무엇을 하나요?
기본(항상 적용): fswp-developer/references/lean-coding.md (적게 작성하고 먼저 재사용), fswp-developer/references/coding-standards.md (코딩 표준, 문서, i18n, 접근성), fswp-security-engineer (입력, 출력, 인가).
기존 코드가 명세입니다. fswp-architect가 승인한 변경 브리핑을 실행합니다(이미 detect_wp_project.py를 실행했습니다). 안전하지 않은 경우가 아니라면 프로젝트 자체 규칙을 따르십시오. 하우스 템플릿은 새 프로젝트용이지, 다른 사람의 스타일을 다시 작성하기 위한 것이 아닙니다.
모드 A: 기존 플러그인 또는 테마 업데이트
- 먼저 읽으십시오. 변경이 영향을 미치는 파일, 해당 호출자 및 테스트를 읽으십시오. 접두사, 명명, 오류 처리 스타일, 설정 및 데이터 저장 방식을 기록하십시오.
- 재현하십시오. 버그의 경우 단계와 관찰된 결과를 기록하고, 변경하기 전에 실패를 확인하십시오. 기능의 경우 수용 기준을 명시하십시오.
- 작동하는 최소 변경. 한 호출 사이트가 아닌 공유 코드에서 원인을 수정하십시오. 건드리지 않은 코드를 재포맷하지 마십시오. 시끄러운 diff는 실제 변경을 숨기고 blame을 깨뜨립니다.
- 공개 표면을 보호하십시오. 훅 이름, 함수 및 클래스 이름, 옵션 키, 메타 키, REST 경로 및 형태, 단축 코드 속성, 템플릿 재정의는 계약입니다. 변경하려면 먼저 폐기하십시오: 이전 것을 계속 작동하게 두고,
_deprecated_function()/_deprecated_hook()(또는_deprecated_argument())를 호출하고, 대체품을 문서화하고, 이후 주요 버전에서 제거하십시오. - 업그레이드 경로. 데이터 또는 스키마가 변경되는 경우: 저장된 버전 옵션을 증가시키고, (활성화 시에만이 아니라) 로드 시 마이그레이션을 실행하고, 멱등성으로 만들고, 이전 버전의 데이터에서 재활성화 없이 업그레이드하는 것을 테스트하십시오.
- 호환성. 선언된
Requires at least및Requires PHP를 존중하십시오. 새로운 함수를function_exists()/버전 검사로 보호하거나 의도적으로 최소 요구 사항을 높이고 그렇게 명시하십시오. - 보안 점검을 수정된 코드에 적용하십시오(
fswp-security-engineer): 버그 수정은 인가, nonce, 살균, 이스케이프 없이 새로운 진입점을 추가해서는 안 됩니다. - 버전 및 변경 로그. 수정 = 패치, 기능 = 부, 중대한 변경 = 주. 플러그인/테마 버전, 상수,
readme.txtStable 태그, 변경 로그를 함께 변경하십시오. - 전달은 사용자가 작업하는 저장소의 패치 또는 diff로, 또는 파일을 배포할 때는 zip으로 제공하십시오. 패리티 검사 결과를 포함하십시오.
테마: 업데이트를 받는 부모 테마를 직접 편집하는 것보다 자식 테마 또는 theme.json/스타일 변형 변경을 선호하십시오. 부모 테마에 대한 직접 편집 및 타사 플러그인 파일 편집은 다음 업데이트 시 손실됩니다.
모드 B: 소유하지 않은 제품용 애드온
애드온은 호스트를 확장하는 별도 플러그인(또는 작은 테마 레이어)입니다. fswp-plugin-developer(단계 1-3 및 8)로 구조화한 후 다음 규칙을 적용하십시오:
- 호스트의 공개 API를 통해 확장하십시오. 문서화된 액션, 필터, 레지스트리, REST 경로를 사용하십시오. 호스트 파일을 편집하지 말고 비공개 또는 문서화되지 않은 내부를 호출하지 마십시오. 반드시 필요한 경우 하나의 어댑터 클래스에서 호출을 격리하고 보호하십시오.
- 종속성을 선언하십시오. 호스트가 WordPress.org에 있는 경우 헤더에
Requires Plugins: host-slug를 추가하십시오(WordPress 6.5 이상에서 적용). 런타임에도 감지하십시오: 플러그인 파일 경로가 아닌 클래스, 함수, 상수 또는 버전 상수를 확인하십시오. - 적절한 시점에 로드하십시오. 호스트가 존재함을 확인한 후
plugins_loaded(또는 호스트 자체 준비 훅)에서 초기화하고, 호스트의 레지스트리 훅에 등록하십시오. 그보다 일찍 하지 마십시오. - 조용하고 명확하게 실패하십시오. 호스트가 없거나 너무 오래된 경우: 다른 작업을 하지 말고, 필요한 것을 설명하는 관리자 알림 하나를 표시하고, 절대 치명적 오류를 내지 마십시오.
- 버전 범위. readme와 계획에 지원되는 호스트 버전을 명시하십시오. 지원되는 최저 및 최신 버전을 테스트하십시오.
- 호환성 선언. 일부 호스트는 기능 지원을 선언하도록 요구합니다. 예: 우커머스는 확장 프로그램이 고성능 주문 저장소 및 블록 기반 장바구니 및 체크아웃과의 호환성을 선언할 것을 기대합니다. 현재 선언 호출에 대한 호스트의 개발자 문서를 읽으십시오.
- 데이터 소유권. 자체 접두사 아래에 데이터를 저장하고, 호스트의 테이블이나 옵션에 쓰지 마십시오. 제거 시에는 자신의 데이터만 삭제하십시오.
- 라이선스 및 이름 지정. 이름에 대해 호스트의 브랜드 및 상표 규칙을 따르십시오. 공식적인 것처럼 보이게 하기보다는 "X용" 스타일의 설명적 이름을 사용하십시오.
확인
변경 브리핑의 패리티 목록과 호환성 테이블을 시나리오 소스로 fswp-qa-engineer에 전달하십시오. references/safe-change-checklist.md는 빠른 전달 전 목록입니다.