eval-file 스크립트가 인자를 셋 넘게 받기 시작했다면, 그 작업은 스크립트의 크기를 넘었습니다. 자체 명령으로 승격하면 인자 파싱 · 검증 · 도움말 · 출력 형식을 전부 WP-CLI 가 대신해 줍니다.
등록은 세 줄
플러그인 안에 가드와 함께 넣습니다.
if ( defined( 'WP_CLI' ) && WP_CLI ) {
WP_CLI::add_command( 'acme checklist', 'Acme_CLI_Checklist' );
}클래스를 넘기면 public 메서드가 하위 명령이 됩니다. run() 메서드는 wp acme checklist run 이 되고, list() 는 wp acme checklist list 가 됩니다. 하위 명령이 필요 없으면 __invoke() 하나만 두면 됩니다.
테마가 아니라 플러그인에 두는 것이 중요합니다. 명령은 운영 도구이고, 테마를 교체하는 날 운영 도구가 함께 사라져서는 안 됩니다.
문서 주석이 그대로 도움말이 된다
WP-CLI 는 메서드의 PHPDoc 을 읽어 wp help 화면과 인자 검증 규칙을 만듭니다. 주석을 쓰는 일이 곧 인터페이스를 정의하는 일입니다.
/**
* 사이트 진단을 실행한다.
*
* ## OPTIONS
*
* [--format=<format>]
* : 출력 형식.
* ---
* default: table
* options:
* - table
* - json
* ---
*
* ## EXAMPLES
*
* wp acme checklist run --format=json
*
* @when after_wp_load
*/
public function run( $args, $assoc_args ) { /* … */ }여기서 $args 는 위치 인자, $assoc_args 는 플래그입니다. 4회차의 제약이 사라지는 지점입니다 — 자체 명령에서는 -- 플래그를 마음껏 쓸 수 있고, 심지어 허용값 밖의 입력은 WP-CLI 가 먼저 거부해 줍니다.
log · warning · error 를 구별해서 쓴다
이것이 이 회차의 핵심입니다. 넷은 목적지와 결과가 다릅니다.
선택 기준은 “이 상황에서 나머지를 계속 도는 것이 의미가 있는가” 하나입니다.
800건을 도는 루프에서 항목 하나가 실패했다면 warning 입니다. 여기서 error 를 부르면 첫 실패에서 멈춰, 나머지 799건의 상태를 알 수 없게 됩니다. 반대로 API 자격증명이 없어서 모든 항목이 실패할 것이 확실하다면 error 입니다 — warning 으로 두면 같은 실패 메시지가 800번 쏟아지고 진짜 원인이 그 안에 묻힙니다.
이 구분은 취향이 아니라 계약입니다. 8회차에서 보겠지만, CI 는 사람이 아니라 종료코드를 봅니다. error 로 끝난 명령은 빌드를 떨어뜨리고 warning 은 로그에만 남습니다. 즉 여기서 무엇을 부를지 정하는 일이 무엇을 배포 차단 사유로 삼을지를 정하는 일입니다.
출력 형식과 확인 절차
결과가 표 형태라면 직접 그리지 말고 유틸리티에 넘깁니다.
WP_CLIUtilsformat_items( $assoc_args['format'], $rows, [ 'item', 'status', 'note' ] );이 한 줄로 table · csv · json · yaml 이 한꺼번에 지원됩니다. --format=json 이 되는 순간 그 명령은 다른 스크립트의 입력이 되고, 명령 하나가 파이프라인의 부품이 됩니다.
되돌릴 수 없는 동작에는 확인을 답니다.
WP_CLI::confirm( '정말 삭제하겠습니까?', $assoc_args );$assoc_args 를 함께 넘기는 것이 요령입니다. 그러면 --yes 플래그로 확인을 건너뛸 수 있어, 사람에게는 안전장치이면서 자동화는 막지 않습니다.
이런 방식으로 만든 진단 명령들은 무료 도구에서 소스와 함께 배포하고, 설계 배경은 개발 워크플로우 아카이브에 정리돼 있습니다.
다음 회차
명령을 만들었으면 그것을 정기적으로 돌려야 합니다. 다음 회차는 워드프레스의 크론이 왜 트래픽에 매달려 있는지, 그리고 그것을 시스템 크론으로 옮기는 절차입니다.