Blog

의식의 흐름대로 흘러가는 1일 1워프 중이다. 적당히, 진짜 적당껏 분량 조절해서 하루에 하나씩 원하는 내용을 적는 중이다.

오늘은 드디어 wp-cli의 이야기를 하게 된다. 워드프레스 개발자로서 반드시 숙지해야 할 녀석, 그리고 할 이야기가 무지무지 많은 녀석이다.

(더 보기…)

잘못된 방법

예전에 워드프레스 플러그인 만들기라는 문서를 작성한 적이 있다. 꽤 오래된 문서인데 (벌써 햇수로 6년 되었다!), 워드프레스 API는 여기서 그렇게 변경된 건 없는 것 같다.

이 문서는 귀찮아서 업데이트하지 않고 있는데, 여기서의 텍스트 번역 부분은 그 당시 워드프레스 환경 및 일반적인 PHP 애플리케이션에 대해서는 맞다. 그러나 더이상 이 방법이 올바르다고 보기 어렵다.

왜냐면 PoEdit을 이용한 소스 검색은 플러그인/테마의 헤더까지 번역문을 생성하지 않기 때문이다.

올바른 방법

플러그인 목록에 플러그인 제목과 나머지 헤더 내용까지 정확하게 번역하려면 wp-cli를 사용하는 것이 좋다. 이 앱에 대해서는 따로 소개하는 포스팅을 작성할 생각인데, 오늘은 맛보기로 미리 언급하기로 하자. 🙂

wp cli 에는 i18n 명령이 있다. i18n은 ‘internationalization’을 간단히 줄여 쓸 때 자주 사용한다. 욕 아니다. i와 n 사이에 정확히 18글자가 있기 때문이다. 굳이 번역하면 ‘국제화’ 정도?

사족으로, 이에 반대되는 개념이 지역화, 즉 ‘localization’ 인데 이것도 쓰기 어렵다고 ‘l10n’이라고 쓴다.

i18n 명령의 서브 명령어로 ‘make-pot’과 ‘make-json’ 둘이 있다.

make-json은 블록 에디터가 등장한 이후 자바스크립트에서 보다 편리하게 번역문을 처리하기 위한 새 방법을 지원하는 명령어고, 오늘 포스팅의 범위를 살짝 벗어난다.

그럼 make-pot을 살펴보자. foo라는 플러그인을 예시로 레시피를 만들어 보자. 참고로 도메인은 bar라고 가정하자. 즉 소스 코드에서 __( 'Hello, World!', 'bar' ); 처럼 번역 텍스트를 작성했다는 뜻이다.

cd <wordpress_path>/wp-content/plugins/foo
mkdir languages # 디렉토리가 만들어지지 않았다면.
wp-cli i18n make-pot . ./languages/bar.pot --domain=barCode language: Bash (bash)

wp-cli로 번역 텍스트를 추출하면 기특하게 헤더 텍스트까지 알아서 잘 고려한다. 게다가 커맨드라인 방식이라 스크립트 처리하기 용이하다.

이후 PoEdit을 이용해 번역문을 만든다. 만약 한국어로 번역했다면, 번역 파일의 이름은 bar-ko_KR.po 가 된다.

기타: XDebug 사용시 트러블슈팅

아마 xdebug를 사용하면 wp-cli로 pot 파일 생성시 ‘Maximum function nesting level of …’ 같은 에러를 만날 것이다. 이것은 xdebug가 디버깅을 위해 함수 호출 레벨을 낮춰 두기 때문이다. 아마도 소스 코드에서 번역문을 스캔할 때 꽤 많은 함수 중첩이 필요한가 보다.

에러가 발생한다면 아래와 같은 명령어를 사용해 보자.

php -d xdebug.max_nesting_level=512 $(which wp-cli) i18n [이후 동일]Code language: Bash (bash)

참고로 아래처럼 번역에 불필요한 모듈까지 제거하면 속도 향상이 있다고 한다.

php -n -dextension=phar.so \
    -dextension=json.so \
    -dextension=mbstring.so \
    -d xdebug.max_nesting_level=512 \
    $(which wp-cli) i18n (이후 동일)Code language: JavaScript (javascript)

출처: Invoking wp i18n make-pot fails when Xdebug is enabled

플러그인에는 플러그인 헤더가 반드시 필요하다. Header Requirement 코덱스에도 잘 나와 있지만, 몇가지 보충 설명을 더하고자 한다.

플러그인 헤더를 작성하면 몇몇 내용은 플러그인 목록 정보에 반영된다. 한편 몇몇 내용은 플러그인 활성화 때 플러그인이 정상적으로 동작하는 환경인지 점검하기 위한 용도로 사용되기도 한다.

목록 정보에 반영되는 필드들

• Plugin Name: 플러그인 필수 헤더. 플러그인의 제목으로 사용.
• Plugin URI: 기재하면 ‘플러그인 사이트 방문’이라고 나온다.
• Description: 제목 옆에 플러그인 설명란으로 사용.
• Version: 버전 정보로 표시.
• Author: 작성자 정보로 표시.
• Author URI: 기재하면 작성자 이름이 하이퍼링크로 변경. 클릭하면 해당 주소로 이동.

플러그인 활성화시 영향을 주는 필드들

• Requires at least: 플러그인이 요구하는 최소 워드프레스 버전이다. 만약 플러그인에서 사용하는 함수들을 워드프레스가 충분히 지원하는지 안전하게 확인하기 위한 용도로 사용된다. 만약 플러그인이 설치된 워드프레스가 이 버전보다 낮다면 활성화되지 않는다. 잘못하면 사이트 전체가 멈추는 불상사가 생길 수도 있기 때문이다.
• Requires PHP: 플러그인이 요구하는 최소 PHP 버전이다. 마찬가지로 활성화시 PHP 버전을 체크하여 서버의 PHP 버전이 이 값보다 낮다면 플러그인은 활성화되지 않는다. ‘Requires at least’ 필드와 마찬가지로 오작동하면 사이트 전체를 멈출 수도 있기 때문이다.

다국어 지원에 영향을 주는 필드들

• Text Domain: 플러그인이 사용하는 텍스트도메인을 정확히 기재한다. 다국어 파일이 제대로 만들어졌다면 플러그인이 해당 언어로 표시된다. 위 그림에서도 ‘나란 옵션 편집기’나 ‘아키스밋’이나 헤더는 영어로 작성되었지만, 한국어 번역 파일이 존재하기 때문에 해당 헤더 필드가 번역되어 출력된다.
• Domain Path: 플러그인의 번역 파일을 정확히 찾기 위해 도움을 주는 필드이다.

다음에는 플러그인 목록 표시에 잘 반영되는 정확히 번역 파일 제작 방법에 대해 포스팅한다.

지난 포스트에 이어 이번에는 wp.ajax 에 대해 포스팅한다. wp.ajax에 대해 소개하고 wp.ajax와 wp.template을 활용한 초간단 플러그인을 같이 제작해 본다.

(더 보기…)

오늘은 wp-util 스크립트를 소개하고자 한다. 경로는 /wp-includes/js/wp-util.js 이고, 이 스크립트 안에는 두가지 도구가 있는데, 하나는 wp.template, 나머지 하나는 wp.ajax이다. 간단하게 포스팅하는 것이 1일 1워프의 주제인데, 오늘 하루에 두가지를 다 포스팅하기는 내가 너무 힘들고 분량도 아까우므로 🙂 오늘은 그중 하나인 wp.template 만 알아보도록 하자.

(더 보기…)

코어 동작 어딘가에 적절히 콜백을 덧대 자신이 원하는 동작을 만들어내는 것, 이것이 플러그인 개발의 핵심이 아닐까 한다. 그러려면 코어가 어떤 흐름으로 동작하는지, 어떤 액션과 필터를 제공하는지 알아두는 것은 자명하다.

그런 흐름을 잘 정리해 둔 문서가 바로 이 액션 레퍼런스와 필터 레퍼런스이다. 모든 필터와 액션을 담은 것은 아니겠지만, 리퀘스트를 받아 리스폰스를 내기까지의 순서를 따라 잘 나열되어 있다. 가장 흔히 사용되는 대표적인 필터와 액션 흐름을 살펴볼 수 있는 좋은 문서이다.

프론트 기준으로 코어는 아주 대략적으로 이런 흐름으로 진행된다. 이 흐름을 생각하면서 훅을 훑어보면 코어를 이해하는데 많은 도움이 될 것이다.

• 설정 파일 로드, 필수 파일 로드, 데이터베이스 설정.
• MU 플러그인 로드.
• 플러그인 로드.
• 테마 로드.
• 로그인된 사용자 설정.
• 프론트의 주소에 따라 메인 쿼리 준비.
• HTTP 헤더 전송.
• 메인 쿼리 – 데이터베이스 쿼리.
• 메인 쿼리의 종류에 따라 어떤 프론트 템플릿을 불러올지 결정.
• 템플릿 인클루드.
  • 템플릿 헤더 출력.
  • 템플릿 본문과 설정에 따라 메뉴, 사이드바 출력.
  • 템플릿 푸터 출력.
• 어드민 바 출력.
• 종료.

이 대략적인 흐름이 중요한 이유가 있다. 이 흐름을 모르면 도대체 어떤 때 어떤 동작을 넣어야 하는지 이해하기 어려울 뿐만 아니라 원하는 동작을 제때 코어에 전달하지 못할 수도 있기 때문이다. add_action을 넣는 시점은 do_action이 일어나기 이전에 이뤄져야 한다. 예를 들어 푸터 출력 진행중에 ‘plugins_loaded’ 액션을 넣어도 절대 동작하지 않는다. 왜냐면 ‘plugins_loaded’ 액션은 그 이전에 끝났기 때문이다. 이런 워드프레스 동작 라이프사이클은 알아둘수록 도움이 된다.