팁이라고 하기는 너무 거창하고… 현재의 내 상태를 기록해 두는 뜻으로 포스팅을 해 봅니다. 워드프레스를 개발할 때 즐겨 사용하는 세팅을 기록합니다. 고도로 숙련된 세팅이라고 할 수는 없으니, 저 아닌 다른 분들은 “아, 얘는 이런 식으로 쓰는 구나” 하고 참고만 해 두셨으면 합니다.
기본 환경
OS
OS는 리눅스 민트를 사용합니다. 리눅스 중에서는 가장 대중적이고, 무탈하고 쓰기 편합니다. 여러 리눅스 OS를 거쳐가며 삽질을 해 봤지만, 초기 부팅 및 설치 후 사용성까지 생각하면 민트를 따라잡을 OS는 없다고 개인적으로 생각합니다.
윈도우 10이 리눅스 서브시스템을 지원하고, 윈도우에서 apt나 bash를 실행시킬 수 있도록 많이 변화하기는 했지만, 아직 안정적이라고 볼 수 있는 단계는 아닙니다. 개인적으로 윈도우는 게임을 할 때 사용하는 OS로 굳어져 있습니다.
물론 맥OS도 좋은 개발 환경을 제공합니다만, 리눅스를 택하는 이유는 강력한 패키지 매니저 때문이죠. apt로 엄청나게 빠르고 편하게 패키지 설치를 할 수 있습니다. 개발 환경은 이렇게 무난하게 꾸미는 것이 최선이라고 생각합니다.
옵션: Vagrant
한때는 vagrant를 활용해서 개발 환경 세팅은 모두 vagrant를 활용한 가상 OS에 밀어 넣은 적이 있었습니다. 이것은 이것대로 엄청난 장점이 있죠. Provision 스크립트를 미리 만들어 둔 덕에, 초기 개발 환경 세팅이 단 2~3분안에 뚝딱 끝나는데다, 항상 균일한 환경을 유지할 수 있다는 점은 엄청나게 매력적이었습니다. 이 때는 가상 OS로 우분투 서버를 사용했습니다. 소스 코드, 웹브라우저, IDE는 호스트에 놓이고, 개발 환경만 게스트에 놓이도록 만들었습니다.
하지만 장점에는 단점도 있는 법. 개인적인 개발을 할 때는 조금 불편한 면이 종종 있었습니다. 호스트와 게스트는 별도의 OS라, 제대로 IDE에서 디버깅을 하기 위해서는 두 OS간 프로젝트의 경로 매핑이 필요합니다. 플러그인을 새로 제작할 때마다 경로 매핑을 하는 거나, 호스트와 게스트의 경로를 각각 숙지해야 하는 점은 좀 짜증나더군요.
개인적으로 워드프레스 플러그인 개발을 위해서 이렇게까지 vagrant 까지 도입해야할 필요성은 좀 없지 않나 하여 이제는 쓰지 않습니다.
개발 스택
Apache 2.4, PHP, MySQL을 사용합니다. 세 콤포넌트 모두 패키지 관리자의 기본 환경을 사용하고 있습니다. 개발 환경에서 그렇게 세세하게 세팅을 할 이유가 없다고 생각하기 때문에 nginx나 mariadb는 그렇게 고려하지 않고 씁니다. 가상호스트 설정 등등에서 apache가 세팅하기 수월하며, debian 설치 관리자 apt에서는 mysql-server 패키지를 설치할 때가 mariadb-server 패키지를 설치할 때보다 훨씬 간결하게 설치가 끝납니다. phpmyadmin 또한 설치 명령어 한 방에 끝납니다.
참고로 우분투 14.04에서는 PHP 5.6이 기본이지만 16.04에 와서 PHP 7.0이 기본입니다. 원한다면 리포지터리를 추가해서 가장 최신의 PHP 버전을 설치할 수도 있습니다. 소스 컴파일 설치는 별로 선호하지 않습니다.
IDE
에디터로 Atom이나 Sublime Text도 선호되고 있지만, 저는 IDE는 PhpStorm을 사용하고 있습니다. 몇 년째 사용 중인 훌륭한 IDE입니다. 제게는 다른 대안이 없습니다.
워드프레스를 위한 레이아웃
플러그인을 몇 번 제작해 보니 경로를 조직적으로 구성하는 편이 효율적으로 보였습니다. 그래서 머리를 굴려 나름 레이아웃을 구상해 보았습니다.
기본적인 경로는 이렇게 되어 있습니다. .php, .dist 확장자를 제외한 항목은 모두 디렉토리입니다.
각 워드프레스 환경은 아파치의 가상호스트로 구분합니다. 각 호스트는 apache2 디렉토리 안에 .conf 파일을 두어 설정합니다. 이 설청 파일을, /etc/apache2/sites-available에 심볼릭 링크를 걸고, a2ensite로 활성화 시켜 줍니다. 아래 코드는 예입니다.
이후 다시 설명하겠지만, 위 코드는 워드프레스를 버전별로 수동 관리하는 케이스입니다. 각 버전별로 “http://wp.<버전 번호>/” URL로 접근하도록 처리했습니다.
bin 디렉토리
wp-cli와 phpunit 같은 바이너리 파일을 여기에 두었습니다. wp-cli는 사용할 때마다 헷갈립니다만, 가끔씩 워드프레스 동작을 스크립트화 해 두기에는 좋을 겁니다.
niu-plugins 디렉토리
디렉토리 중 mu-plugin (must-use plugin)이라고 해서, 항상 사용하는 플러그인을 넣어 두는 곳이 있습니다. 그걸 따서 niu-plugin (not-in-use plugin) 디렉토리를 별도로 만들었습니다. 큰 의미는 없고 잠시 사용하지 않을 플러그인을 이 쪽에 놓아 둘 목적으로 만든 것입니다. 활성/비활성 차원이 아니라 아예 존재를 이 쪽으로 옮겨 두는 거죠.
plugins 디렉토리
플러그인만 이 곳에 놓아둡니다. 모든 워드프레스 개발 사이트는 이 플러그인을 공유합니다. 활성/비활성으로 적절히 조절하면 되니까 이렇게 몽땅 놔두는 것도 큰 문제가 없습니다.
워드프레스의 코어가 여기 있습니다. 코어를 관리하는 방법은 크케 나눠 두 가지가 있습니다.
1벌의 코어를 직접 디렉토리 아래에 두고, 워드프레스에서 코어 업데이트가 발표되면 같이 따라간다.
버전별로 코어를 관리. 업데이트는 막되, 버전별로 하위 디렉토리에 위치.
코어 버전이 업데이트될 때 종종 데이터베이스도 업데이트됩니다. 큰 변화는 별로 없지만, 그래도 테이블이 한 번 업데이트되면 되돌리기 어렵습니다. 개인적으로는 예전에는 단순한 까닭에 1번 방식을 썼는데, 버전별 차이에도 좀 대응하고 싶어 이제는 손이 좀 더 가더라도 2번을 쓰려고 합니다.
wp-settings 디렉토리
도메인별 워드프레스 설정을 놓아두는 디렉토리입니다.
워드프레스 설정
wp-config.php 파일은 워드프레스 코어에 있어도 되지만, 보안상 코어 하나 위 디렉토리에 두어도 무방하도록 되어 있습니다. 여러 사이트가 특별히 각자의 세팅을 가질 필요 또한 크지 않으므로 wp-core의 상위 디렉토리에 wp-config.php 파일을 위치시켰습니다.
만약 버전별로 코어를 관리하는 경우, wp-core 하위에 각 버전별 코어가 위치하므로 wp-congif.php가 1계층이 아닌 2계층 차이가 납니다. 이 때에는 wp-core 디렉토리에 wp-config.php의 심볼릭 링크를 설정해 주면 됩니다.
개발 환경이므로, 디버깅은 항상 켜 둡니다. 단, 디버깅 용 로그를 웹브라우저로 띄우면 화면이 매우 지저분해지므로 로그로만 볼 수 있도록 만듭니다. wp-content 디렉토리는 기본적으로는 각 코어별로 사용하도록 두었으므로 로그 파일은 각 <코어>/wp-content/debug.log가 됩니다. 스크립트 디버깅도 켜 둡니다.
이렇게 해도 워드프레스 코어를 업데이트하라는 알림이 관리자 화면에 출력될 수 있습니다. 워드프레스 업데이트를 완전히 꺼 두는 플러그인이 있습니다. 이런 플러그인을 활용해 혹시 실수라도 업데이트를 진행하지 않도록 처리하면 좋겠죠.
도메인별 세팅
도메인별로 다른 데이터베이스 테이블을 관리할 수도 있고, 또 모든 도메인이 같은 테이블을 공유할 수도 있습니다. 그러나 버전별로 워드프레스를 관리하려면 반드시 버전별로 다른 테이블을 사용해야 합니다. 앞서 말씀드렸듯 워드프레스 버전마다 데이터베이스 버전도 달라자기 때문입니다.
버전별로 워드프레스를 관리하기 위해 다음과 같은 도메인 규칙을 만들었습니다.
wp.<워드프레스 버전>
그러므로 워드프레스 4.6.2 버전은 “http://wp.4.6.2/”, 4.7 버전은 “http://wp.4.7/”로 접속합니다.
물론 이렇게 하려면 /etc/hosts 파일에 해당 도메인으로 접속할 수 있도록 추가해야 합니다.
127.0.0.1 wp.latest wp4.7 wp.4.6.2 wp4.6.1
그리고 wp-settings/wp.4.6.2.php, wp-settings/wp.4.7.php 같은 도메인 이름과 같은 php 파일을 두고, 그 안에 도메인별 설정을 넣으면 됩니다.
코어 하나만을 사용하는 경우에도 비슷합니다. /etc/hosts 파일 안에 각 도메인에 IP를 127.0.0.1로 대응시키고, wp-settings/<domain>.php 파일을 만들면 됩니다.
설정 파일에는 최소 하나의 변수가 있어야 합니다. 아래는 그 예입니다.
<?php
$table_prefix = 'wp471_';
마치며
위 설명한 구조는 제 github repository에 있습니다. 손은 좀 가지만 그리 어려운 것은 아니므로 다운로드 받아서 한 두번 살펴보면 쉽게 파악할 수 있을 것입니다.
그리고 이 곳에 우분투 16.04 서버를 위해 만든 provision 스크립트가 있습니다. 개인적으로는 APM 설치 및 세팅에 알찬 도움이 되고 있습니다.
테마는 제가 잘 다루지 않으므로 이 레이아웃이 테마까지 효율적으로 관리할 수 있을지는 모르겠습니다만, plugins 디렉토리를 응용해 테마 디렉토리를 별도로 관리한다면 플러그인과 큰 차이는 없을 것이라 생각해 봅니다.
요즘 워드프레스에 뜸했다. 며칠 전 워드프레스 4.7.1을 보다가 훅의 구현이 엄청나게 변한 것을 알게 되었다. 구체적으로 어떤 점이 변경되었는지 알아 보자.
우선 이 포스트에서 WP_Hook 이란 클래스가 새롭게 도입되었다는 사실을 발견할 수 있었다. 저 포스트에서 발견한 trac 페이지를 참고하면 대략 다음과 같은 이유로 도입이 되었다는 사실을 접할 수 있다.
필터와 액션은 아주 오래전부터 워드프레스의 플러그인 기능의 기반으로 있어 왔습니다. (중략) 하지만 몇 년동안 엣지 케이스(edge case)가 불거져 나오게 되었습니다. 특히 훅을 재귀적으로 실행하거나, 훅을 스스로 지우려고 하는 경우 기존의 구현은 매우 복잡한 노력을 기울여야만 했습니다 (중략)
사실 4.7에서 WP_Hook 클래스 때문에 발생할 수 있는 변경점은 크게 없다. 다만 $wp_filter 등 훅과 관련된 전역 변수에 직접적으로 접근한 경우, 인용한 글과 같이 훅을 재귀적으로 쓰는 코드는 더러 문제가 발생할 수도 있다. 허나 $wp_filter 등을 직접 접근은 완전 변태 코드. 피할 수 없는 문제가 아닌 이상 잘못된 접근이고, 또 훅을 재귀적으로 쓰는 일 또한 그리 흔치 않다. 그러니 기존의 코드는 거의 변함 없이 유지될 수 있을 것이다.
하지만 나는 궁금하다. 도대체 어떤 문제 때문에 훅 매커니즘은 이제 세대교체를 해야만 했을까? 그래서 알아 보기로 했다.
Action & Filter
다들 알 거라 생각하겠다. 액션(action)과 필터(filter)는 사실 같은 존재라는 걸. 워드프레스는 미리 시나리오를 다 짜놓고 필요한 구간에 ‘훅’ 이란 것을 걸 수 있도록 장치했다. 이 훅에 대한 콜백 함수를 편리하게 쓸 수 있도로 만든 장치가 액션과 필터이다. 다시 말하지만 액션과 필터는 같은 콜백 함수이며, 단 하나의 차이점은 액션은 리턴이 없고, 필터는 값을 리턴한다는 점 뿐이다.
웹 프레임워크들은 모든 기능들을 블록처럼 만들어 놓고 개발자가 의도에 맞게 그 모든 블록을 완전히 구현시켜 쌓아가는 방식이다. 반면 워드프레스는 이미 워드프레스 코어라는 완성품을 만들어 놓은 상태이다. 단, 그 코어에는 아주 많은 ‘구멍’을 뚫어 놓았다. 플러그인이나 테마는 그 구멍에 맞춰 적절히 콜백 함수를 끼워 넣는다. 이미 완성된 덩어리에 개발자가 자기 의도대로 부가 확장하는 방식이다.
기존 구현의 문제점
기존 혹 관련 API는 wp-includes/plugin.php 파일에 있으며, 4.7 버전에도 변함없이 존재한다. 단 WP_Hook이 있으므로 직접 $wp_filter를 조작하는 코드 일부를 WP_Hook에 넘겨 주었다. 이를 테면, 4.6 버전에서는 add_filter 함수의 구현은 이렇게 되어 있다.
함수 내부에서 $wp_filter에 훅 이름($tag)과 우선순위($priority)에 맞춰 콜백이 등록된다. array가 잔뜩 들어간 지저분한 구현이고, 개인적으로 PHP의 array는 정말 이상한 물건이라 생각하지만, 아무튼 그렇다. $wp_filter는 무려 4중첩의 array이다.
WP_Hook() 객체를 사용하고 WP_Hook::add_filter()를 사용하는 것이 보인다.
WP_Hook 클래스는 wp-includes/class-wp-hook.php에 구현되어 있다. 재미난 것은 이 클래스에 $nesting_level이라는 private 변수가 하나 있다. 만일 필터(또는 액션, 앞으로는 액션과 필터를 필터로만 언급)가 재귀적으로 실행되는 경우에 이전 구현에서는 이를 처리할 방법이 없었지만, 이제는 이것을 감지해 낼 수 있게 되었다.
필터가 재귀적으로 실행되는 경우 기존의 구현은 확실히 문제가 있다. 다음 4.6 버전의 appy_filters() 코드 조각을 살펴 보자.
...
do {
foreach ( (array) current($wp_filter[$tag]) as $the_ )
if ( !is_null($the_['function']) ){
$args[1] = $value;
$value = call_user_func_array($the_['function'], array_slice($args, 1, (int) $the_['accepted_args']));
}
} while ( next($wp_filter[$tag]) !== false );
...
약속된 모든 모든 콜백함수를 경유하면서 PHP의 call_user_func_array()를 이용해 콜백 호출을 하는 것이 보인다. 마지막 줄에서 do ~ while 루프 안에서 next()로 array pointer를 이용해 각 priority를 단순하게 순회하는 것이 보이는가? 여기서 재귀적인 apply_filter()가 호출되면 문제가 발생한다.
이 함수가 2번 재귀적으로 호출된다고 가정해 보자. 그러면 do ~ while 루프 안쪽에 같은 구조의 do ~ while 루프가 만들어지는 것과 비슷하게 된다. 그런데 next( $wp_filter )라는 부분은 두 함수가 공유하는 부분이다. 그러므로 안쪽의 루프가 먼저 array를 소진해버린다. 결국 번째 함수의 실행이 끝나고 첫번째 함수로 돌아온 시점에서 next( $wp_filter )는 첫번째 함수가 의도한 유효한 현재 이후의 순위를 가진 콜백 함수 목록을 가져오지 못한다.
필터 적용은 전역적이며, 일괄적으로 동작한다
필터의 콜백 선언은 전역적이며 일괄적이어야 한다. 만약 10개의 콜백 함수가 등록되었다면, apply_filters(), do_action() 호출로 필터를 적용하면 언제나 등록된 그대로 10개의 콜백이 실행되어야 한다.
그런데 기존의 구현은 어떤 조건에서 이 가정을 올바르게 지키지 못하는 경우가 있다. 그 대표적인 케이스로 ‘필터 적용이 재귀적으로 일어날 때’를 들 수 있다. 다음과 같은 조건이라면 이 현상이 일어난다.
콜백 함수가 종료되기 전에 해당 훅에 대한 필터를가 재차 적용된다.
콜백 함수에허 해당 훅에 대한 편집이 이루어진다.
흔히 잘 알려진 재귀적인 필터 사용의 예로 들 수 있는 것 중 하나는 ‘save_post‘ 액션이다. 이 액션은 포스트가 저장될 때 사용되며, 해당 콜백에서 포스트 저장 시 동작을 일부 변경, 확장 가능하도록 해 준다. 흔히 이 함수 내부에서 플러그인이나 테마의 특정 데이터를 데이터베이스에 저장하도록 프로그래밍을 하는데, 흔히 이 콜백에서 어떤 포스트를 업데이트하는 코드를 작성하곤 한다. 포스트를 “저장”하려는 시점에 실행 중인 콜백이 포스트를 재차 “저장”하려고 시도하는 것이다. 만약 부주의하게 프로그래밍하는 경우 콜백은 무한으로 증식해 에러가 난다. 그래서 save_post 액션에 대한 코덱스에서는 ‘Avoiding infinite loops‘라는 항목을 따로 두어 주의를 주고 있다.
코덱스에서 서술하는 것과 같이 무한 루프만을 막기 위한 일시적인 필터 등록 해제, 재등록 정도는 아무런 부작용이 없다. 그러나 해당 콜백 내부에서 자신의 필터를 변경하려고 하는 경우에는 문제가 발생하게 된다. 자세한 것은 실험을 통해 알아보자.
실험: 4.6과 4.7의 콜백 동작 차이
WP_Hook 클래스의 도입 후 변경된 훅의 동작을 실험해 보기 위해 실험 플러그인을 작성하여 gist에 등록해 두었다.
코드 설명
플러그인에서 ‘wph47_test01’이라는 훅을 실행한다. 이 훅의 콜백에서는 자기 자신을 변경한다. 또한 콜백 함수 안에서 다시 필터를 적용하는 기행(?)을 저지른다.
wph_47_test01_body()는 wph47_test01 필터를 적용한다. 콜백 함수인 wph_test01() 안에서 자신의 훅을 편집한 후 재차 wph47_test01 필터를 적용하고 있다. ‘wbh47_cb_x ‘ 함수들은 간단하게 ‘x’를 로그로 출력한다.
코드 결과
4.6 버전과 4.7 버전의 코드 결과는 약간 다르다. 먼저 4.6의 실행 결과는 이렇다
test begin
9
11
12
13
test end
그리고 4.7의 실행 결과는 이렇다. 4.6과 다른 부분은 별표를 뒤에 붙였다.
test begin
9
11
12
13
11 *
12 *
13 *
test end
9, 11, 12, 13은 각각 우선순위 9, 11, 12, 13에 의해 등록된 함수에 의해 출력된 것이다. 그런데 왜 버전 4.7에서는 11, 12, 13이 반복된 것일까?
위 코드에서 우선순위 10으로 실행된 콜백 함수 wph47_test01()안에서는 같은 이름의 wph47_test01 훅을 변경한다. 우선순위 9, 11, 12, 13의 액션을 등록하고, 다시 해당 액션을 재차 부르는 것이다. 그러면 재귀적으로 불려진 액션의 콜백에 의해 9, 11, 12, 13이 출력된다.
여기서 주의해야 한다. 이 시점에서 훅의 상태는 변경되었다. 콜백은 우선순위 9, 10, 11, 12, 13로 구성되어 있다. 우선 순위 10번은 무한 루프 방지를 위한 코드 때문에 한 번만 실행된다고 간주하더라도, 10번 이후의 11, 12, 13이 등록되어 있는 상태이다. 그렇다면, 재귀 호출이 끝나고 한 단계 위의 함수로 올라가게 되면 (콜스택이 하나 줄어들면) 저기서 등록된 훅들은 실행되어야 하는가? 아니면 무시되어야 하는가?
앞서 말했듯이 필터는 전역적이다. 필터를 명시적으로 해제하는 명령이 없는 이상, 프로그램이 마음대로 콜백을 호출하고 말고를 결정할 수는 없다. 그러나 잘 살펴보면 버전 4.6에서는 이를 무시하는 결과가 나오고 있다. 물론 훅의 변화가 재귀적으로 호출된 함수 내부에서 일어나는 것이 특이하긴 하다. 그러나 그깟 재귀함수가 뭐라고?
4.7은 콜백 내부에서 등록된 필터라도 그 콜백이 끝난 후에 잘 반영된다. 11부터 반복된 것은 wph47_test01() 함수가 우선순위 10을 가지기 때문이다. 훅의 증가 뿐만 아니라 훅의 감소에도 당연히 올바르게 동작한다.
변한 것은 없다. 더 정교해졌을 뿐.
워드프레스가 제공한 API 함수만을 이용해 플러그인을 작성한 경우 특별히 코드를 변경할 이슈는 거의 없으며, 이렇게까지 트리키한 코드를 사용하지 않는 이상 딱히 이 변경점을 고려할 이유는 없다.
WP_Hook을 부분적으로 이해한 현시점에서 어떠한 개선이 이뤄진 것인지 조목조목 파악하지는 못했지만 보다 정교해진 코드가 나로서는 반갑다. 사실 예전에 디버깅을 위해 콜백 함수를 덤프해 보면 array가 양파처럼 구성된 것을 보며 약간의 혐오감까지 느낀 적이 있던 터라, 오히려 “오 여기가 드디어 변경되었나?” 하는 반가움이 든다.
워드프레스의 권한(authority) 시스템은 매우 잘 구축되어 있다. 권한은 세부적으로 역할과 권한(capability)으로 쪼개어져 문맥(context)에 따라 어떤 작업을 허가할 수도, 거부할 수도 있도록 조직되어 있다.
역할 (Roles)
사실 ‘역할’은 ‘권한’보다는 커스텀 포스트와는 덜 밀접한 관계이긴 하지만 권한과 역할이 워낙 가까운 관계라 언급은 해야 할 것 같다. 쉽게 말해 사용자의 그룹이라 볼 수 있다. 한 사용자가 사이트 내부에서 어떤 담당인지를 나타내 준다.
각 역할 별로 일정한 권한의 목록이 기본으로 주어진다. 물론 새로운 역할도 추가할 수 있고, 특정 권한을 더 추가할 수도, 덜어낼 수도 있다. 역할에 대해서는 자세한 설명을 생략하도록 하겠다. 코덱스를 참고하기 바란다.
권한 (Capabilities)
워드프레스에서 동작에 대한 문맥을 나타낸다. 예를 들어 포스트를 편집, 삭제, 발행하는 각각에 대한 동작들을 의미한다. 역할과 마찬가지로 사용자별로 권한을 더해줄 수도, 덜어낼 수도 있으며 완전히 새로운 권한을 만드는 것도 가능하다. 단, 여기서는 커스텀 포스트 옵션과 관련된 사항에서만 설명을 하도록 하겠다.
커스텀 포스트의 권한 대응
커스텀 포스트는 기본 포스트 타입을 확장하여 사용하는 것이므로, 기본 포스트가 가진 권한 시스템을 그대로 물려받게 된다.
포스트, 혹은 페이지에 대해 다수의 권한이 있고, 커스텀 포스트를 생성하면서 이 권한들을 1:1로 모두 새롭게 재정의해 주어야 코어 내부에서 올바르게 권한을 체크할 수 있다.
예를 들어 publish_posts 권한을 살펴 보자. 이 권한이 주어지지 않은 사용자는 글을 쓰고 편집할 수는 있어도 편집 화면에서 ‘공개하기(publish)’ 버튼이 나오지 않는다.
Contributor의 글 작성 화면. Publish 대신 Submit for Review 버튼으로 나온다.
위 그림을 보자. 어떤 기여자(Contributor) 역할의 사용자가 새 포스트를 작성 중이다. Publish 메타 박스를 보면 보통 볼 수 있는 ‘Publish’ 버튼 대신 ‘Submit for Review’라는 버튼으로 변경되어 있다. 왜냐하면 기여자는 새 글을 쓸 수는 있고 그 글을 편집할 수는 있지만 글을 최종 단계인 발행 상태로는 만들 수 없기 떄문이다.
자, 이제 커스텀 포스트를 생성해야 한다고 보자. 그럼 publish_posts 권한에 대해 두 가지 결정을 할 수 있다. 기존의 포스트(혹은 페이지)와 동일한 권한을 가질 것인가, 아니면 별도의 권한으로 나누어야 할 것인가.
동일한 권한이라면, 글(혹은 페이지)를 편집, 수정 발행할 수 있는 권한을 가진 사용자는 커스텀 포스트에 대해 동일한 작업이 될 것이다. 반면 별도의 권한을 가지도록 처리한다면, 조금 성가시기는 하겠지만, 보다 세밀하게 권한을 나누어 원하는 대로 분업을 진행할 수 있을 것이다.
그럼 이제 PHP 코드 관점에서 권한의 구조를 생각해 보자. 권한은 연관 배열(혹은 stdClass)을 사용한다. 권한의 공통적인, 즉 ‘문맥상’의 호칭은 연관 배열의 키(혹은 속성)로, 해당 실제 권한명은 값으로 기록한다. 아래는 그 예이다.
두 포스트 타입, ‘sample_audio’와 ‘sample_video’를 등록할 때 publish_posts라는 문맥상의 권한에서 audio는 포스트의 것을 그대로 가져오는 반면 video는 ‘publish_videos’라는 새로운 권한 이름을 지어 냈다.
$caps[] = $post_type->cap->publish_posts;
반면 코어 코드에서는 이렇게 쓰이기도 한다. 내부적으로 array를 stdClass로 타입 변환하는 과정이 생겨 키가 아닌 속성으로 불리긴 하나, 이 코드에서 audio 포스트타입이라면 $caps[]에 저장되는 문자열은 ‘publish_posts’, video 포스트 타입이라면 ‘publish_videos’가 될 것이다.
map_meta_cap: 옵션, 함수, 그리고 필터의 이름
여기저기서 map_meta_cap이라는 문자열이 언급되는데, 워드프레스 코어에서 이 것이 세 가지 의미로 쓰이고 있다. 애매모호함을 없애기 위해 우선 이것부터 명확히 정의하고 넘어가자.
첫번째로 map_meta_cap은 register_custom_post() 함수의 옵션 인자로 쓰인다. 자명하다.
두번째로 map_meta_cap은 함수 이름으로 쓰인다. map_meta_cap() 처럼 뒤에 괄호를 붙여 구분하기도 한다. 이후 메타 권한 설명에서 설명하겠지만, map_meta_cap() 함수는 권한 판별에 매우 중요한 역할을 하는 함수이다.
셋째로 map_meta_cap은 필터 이름으로 쓰인다. map_meta_cap() 함수 내부에서 가장 마지막에 함수의 연산 결과를 재정의할 때 사용된다.
이 셋이 치명적인 오해를 불러일으키는 것은 아니지만, 코어 코드를 보면, map_meta_cap이 콜백 함수로 불리기 때문에 마치 이것이 필터처럼 보이기도 해서 처음 이 쪽 코드를 볼 때 오해하고 살짝 헤맨 경험이 있어 혹시나 해서 언급한다.
// class-wp-user.php, has_cap() function
$caps = call_user_func_array( 'map_meta_cap', $args );
코덱스에서 언급되는 이해하기 쉽지 않은 개념 중에 기본 권한(primitive capabilities)와 메타 권한(meta capabilities)가 있다. 말장난 같기도 하고 좀 어렵지만, 이해해 보면 워드프레스가 권한에 매우 세심하게 디자인을 했다는 것을 알 수 있다.
메타 권한이란 고정되어 있지 않은 권한들을 의미한다. 메타 권한은 조건에 때라 각각 다른 기본 권한으로 대응될 수 있다. 쉬운 예를 들어 설멍해 보자. 에디터 A, B 둘이 있다. 모든 포스트에 대해 A, B 동일한 권한이 있다. 그러나 어느 특정 카테고리에서만 A는 편집을 허용하고, B는 허용하지 않게 해야 한다고 하자. 이렇게 권한을 설정하게 하려면 어떻게 해야 할까? 이렇게 특정한 조건에 따라 유동적으로 설정 가능한 권한이 메타 권한이다.
반면 기본 권한은 고정된 권한이다. 메타 권한은 조건에 따라 기본 권한 하나로 대응된다. 일반적으로는 어떤 개체 하나에 대한 권한은 메타 권한, 복수의 개체에 대한 권한은 기본 권한으로 설정되어 있다.
메타 권한 동작의 예
메타 권한 중의 하나인 ‘edit_post’ 권한을 예로 들어, 이 권한의 코어 내부에서 어떻게 동작하는지 간략히 설명해 본다.
사용자가 포스트의 편집 화면을 접근한다고 하자. URL은 wp-admin/post.php?post=<post_id>&action=edit&…. 와 비슷하게 구성된다. wp-admin/post.php 스크립트는 편집 화면을 구성하는데, 먼저 사용자에게 포스트의 편집 권한이 있는지를 확인한다.
// wp-admin/post.php, Line 116
if ( ! current_user_can( 'edit_post', $post_id ) )
wp_die( __( 'You are not allowed to edit this item.' ) );
현재 사용자가 $post_id에 대해 ‘edit_post’ 권한을 가지고 있는지 물어보고 아니면 wp_die()에 의해 중단된다. current_user_can() 함수는 현재 사용자를 파악하고, 현재 사용자에 대해 class-wp-user.php의 WP_User::has_cap() 함수를 호출한다.
이어 WP_User::has_cap() 함수는 내부에서 map_meta_cap() 함수를 호출한다.
map_meta_cap() 내부에는 긴 switch ~ case 문이 있다. 여기서 case ‘edit_post’ 부분을 타고 들어가 보자. 해당 포스트의 작성자와 포스트의 상태에 따라 메타 권한의 결과가 변한다. if 분기를 세심하게 체크해 보면 어떤 경우에는 ‘edit_published_posts’, 또 어떤 경우에는 ‘edit_posts’나 ‘edit_others_posts’, 또 어떤 경우에는 ‘edit_private_posts’ 같은 기본 권한들로 대응되는 것을 확인할 수 있다.
// If the post author is set and the user is the author...
if ( $post->post_author && $user_id == $post->post_author ) {
// If the post is published or scheduled...
if ( in_array( $post->post_status, array( 'publish', 'future' ), true ) ) {
$caps[] = $post_type->cap->edit_published_posts;
} ...
} else {
// The user is trying to edit someone else's post.
$caps[] = $post_type->cap->edit_others_posts;
...
}
map_meta_cap() 함수는 $caps라는 배열을 리턴한다. 이 배열은 해당 문맥에서 사용자에게 요구하는 필수 요구 권한의 목록이다. 이 예에서는 $caps 배열의 길이가 아마도 1이겠지만, 조건에 따라 길이가 더 길어질 수도 있다.
$capabilities = apply_filters( 'user_has_cap', $this->allcaps, $caps, $args, $this );
// Everyone is allowed to exist.
$capabilities['exist'] = true;
// Must have ALL requested caps.
foreach ( (array) $caps as $cap ) {
if ( empty( $capabilities[ $cap ] ) )
return false;
}
위 코드는 WP_User::has_cap()의 마지막 부분이다. 사용자의 모든 권한을 가져와서 필수 요청 권한 목록인 $caps와 대조하는 코드이다. 전체 권한 중에서 요구된 권한 하나라도 발견되지 않는다면, 해당 사용자는 권한이 없는 것으로 간주된다.
각 옵션 설명
권한은 그 수가 많고 만큼, 쉽게 사용할 수 있어야 한다. 쉽게 쓰려고 의도했으면 쉽게 사용할 수 있도록 되어야 한다. 권한에 대해 고민하지 않고 그냥 포스트나 페이지처럼 만드려면 권한 관련 옵션을 아예 언급조차 하지 않으면 된다. 그러면 포스트나 페이지에 의거해 동일한 권한으로 자동 생성된다.
capapbility 옵션
권한 설정에 관련된 함수는 wp-includes/posts.php get_post_type_capabilities()이다. 소스 코드를 첨부한다.
function get_post_type_capabilities( $args ) {
if ( ! is_array( $args->capability_type ) )
$args->capability_type = array( $args->capability_type, $args->capability_type . 's' );
// Singular base for meta capabilities, plural base for primitive capabilities.
list( $singular_base, $plural_base ) = $args->capability_type;
$default_capabilities = array(
// Meta capabilities
'edit_post' => 'edit_' . $singular_base,
'read_post' => 'read_' . $singular_base,
'delete_post' => 'delete_' . $singular_base,
// Primitive capabilities used outside of map_meta_cap():
'edit_posts' => 'edit_' . $plural_base,
'edit_others_posts' => 'edit_others_' . $plural_base,
'publish_posts' => 'publish_' . $plural_base,
'read_private_posts' => 'read_private_' . $plural_base,
);
// Primitive capabilities used within map_meta_cap():
if ( $args->map_meta_cap ) {
$default_capabilities_for_mapping = array(
'read' => 'read',
'delete_posts' => 'delete_' . $plural_base,
'delete_private_posts' => 'delete_private_' . $plural_base,
'delete_published_posts' => 'delete_published_' . $plural_base,
'delete_others_posts' => 'delete_others_' . $plural_base,
'edit_private_posts' => 'edit_private_' . $plural_base,
'edit_published_posts' => 'edit_published_' . $plural_base,
);
$default_capabilities = array_merge( $default_capabilities, $default_capabilities_for_mapping );
}
$capabilities = array_merge( $default_capabilities, $args->capabilities );
// Post creation capability simply maps to edit_posts by default:
if ( ! isset( $capabilities['create_posts'] ) )
$capabilities['create_posts'] = $capabilities['edit_posts'];
// Remember meta capabilities for future reference.
if ( $args->map_meta_cap )
_post_type_meta_capabilities( $capabilities );
return (object) $capabilities;
}
capability 옵션은 문자열, 혹은 배열을 값으로 쓸 수 있다. 문자열은 단수형 단어(내부에서 문자 뒤에 s를 붙여 크기 2짜리 배열로 조정한다), 그리고 배열은 크기 2짜리로 단수, 복수로 권한에 대한 단어를 입력해 주면 된다. (소스코드 2~6라인 참고)
코어는 capability 옵션에 대해 다음 권한을 기본적으로 생성한다.
edit_post
read_post
delete_post
위 세 권한은 메타 권한이다. (소스코드 9~12라인)
edit_posts
edit_others_posts
publish_posts
read_privte_posts
이 네 권한은 기본 권한으로, map_meta_caps() 함수 내부에서는 언급되는 일이 없다. 그러나 코어 구석구석에서 권한 검사에 사용되고 있을 것이다. (소스코드 13~17라인)
만일 map_meta_caps 옵션을 적지 않거나(null), true로 설정했다면 7개의 기본 권한이 별도로 생성된다. 다음은 그 목록이다. (소스코드 20~32라인)
$args->capabilities가 capabilities 옵션이다. 여기서는 권한의 종류를 더욱 자세하게 정의할 수 있다. 보다시피 capability 옵션으로 인해 생긴 기본 설정에 더불어 별도의 권한을 추가할 수도 있고, 기본 설정을 변경할 수도 있게 짜여 있다.
map_meta_cap
map_meta_cap 옵션 값은 true/false, 그리고 기본으로는 null을 가질 수 있다. null로 값을 주면 내부에서 true로 변환시킨다. 즉 기본값이 true.
간단히 말해 이 옵션은 해당하는 커스텀 타입이 선언한 메타 권한이 기본 권한으로 대응시키는 작업을 허용할지 말지를 결정한다. 이 작업은 map_meta_cap() 함수에 정의되어 있다. 만일 false라면 일부 기본 권한은 수동으로 생성해야 하며, 메타 권한의 기본 권한 대응 작업은 별도로 제작해야 한다.
보다 세밀한 설명은 이렇다. 이 옵션은 다음과 같은 역할을 한다.
첫째로 get_post_type_capabilities() 함수 내부에서 true(혹은 null)일 때 일곱가지 기본 권한(read, delete_posts, 등…)을 설정해주는 역할을 맡는다. 만일 이 값이 false라면 이 일곱가지 기본 권한을 map_meta_cap 필터를 이용해 별도로 보충해 줘야 한다.
둘째로 이 값이 true(혹은 null)이어야 map_meta_cap() 함수 내부에서 post, page와 관련된 메타 권한 체크 로직에서 포스트와 페이지의 여러 상태에 따라 적절한 기본 권한으로 해석되도록 하는 코어의 기본 로직이 동작한다.
map_meta_cap() 함수의 메타 권한 체크 부분 중 포스트나 페이지와 관련된 곳을 보면 다음과 비슷한 코드가 있는 것을 볼 수 있다.
if ( ! $post_type->map_meta_cap ) {
$caps[] = $post_type->cap->$cap;
// Prior to 3.1 we would re-call map_meta_cap here.
if ( 'edit_post' == $cap )
$cap = $post_type->cap->$cap;
break;
}
map_meta_cap 옵션 값이 false가 되면 map_meta_caps() 함수 내에서 메타 권한은 더이상 메타 권한으로써 동작하지 않는다. 즉, 해당 capability를 액면 그대로 요구한다. 그러면 이렇게 반환된 capability에 대해서는 별도의 필터 콜백으로 검사해 주어야 한다.
셋째로 메타 권한인 read_post, delet_post, edit_post, 이 셋의 권한 이름을 변경했을 때 추적할 수 있도록 한다. _post_type_meta_capabilities() 함수와 map_meta_cap() 함수 switch-case 구문의 default 레이블에 구현되어 있다.
예제 코드 #1 특정 사용자의 특정 카테고리 편집 제한
메타 권한에 대한 설명에서 에디터 B에 대해 특정 카테고리의 글은 편집 제한을 거는 실제 코드를 구현해 보자.
에디터 B의 ID는 ‘5’이고, 카테고리의 택소노미 이름은 ‘wphack_taxonomy”이고, 카테고리 이름은 ‘a-only’이다. 포스트를 적당히 만들고 a-only 카테고리로 설정하고, 다음 코드를 작성한다. 접근 제한에 대한 세련된 예는 아니지만 권한에 대한 하나의 예제로써 이해하기를 바란다.
물론 다른 웹프레임워크를 이용해 UI를 다 만들 수도 있겠지만, 워드프레스를 사용하면 나름 괜찮은 UI를 손쉽게 가져다 쓸 수 있다. 이 UI를 통해 개체 수정 및 임의 작성도 가능하니 금상첨화다.
다만, 어떤 다른 후단부(backend)가 존재하여 포스트의 데이터를 모두 일괄적으로 생성하는 시나리오가 있다고 가정하자. 이 커스텀 포스트는 워드프레스 UI 상에서 읽기, 조회만 가능하고 포스트의 생성과 수정은 별도의 스크립트에서 담당해야 한다. 단, 삭제의 경우는 UI 상에서 데이터를 체크하고 수동으로 지우는 일이 가능하다고 하자.
이러한 시나리오에서 커스텀 포스트는 포스트의 목록과 상세 화면 UI가 필요하다. 그러나 커스텀 포스트의 상세 화면에서는 포스트의 어떤 필드도 수정할 수 없도록 처리해야 한다.
먼저 커스텀 포스트 타입을 생성해 보자. ‘init’ 훅에서 register_post_type의 인자를 설정해 준다. 여기서 레이블을 바꿔치기했다. ‘edit’은 이제 편집이 아니라 세부항목을 보는 것으로 의미가 변경된다. 주석 부분을 해제하면 삭제도 불가능하게 만들 수 있다.
화면 상단의 스크린 옵션을 제거해 보았다. 메타 박스 등을 고려한다면 나타나게 할 수도 있을 것이다. 또한 예제에서는 어떤 메타박스도 쓰지 않기 때문에 화면을 1열로만 쓰는 것이 더 깔끔하기 때문에 화면 레이아웃도 1단으로 고정시켰다. 포스트 타입에 따라 적절히 조절할 수 있을 것이다.
코드 전문은 여기서 확인할 수 있다. 이 플러그인을 활성화시키면 다음과 같은 화면을 볼 수 있다.
포스트 목록에서 ‘Edit’ 텍스트가 ‘Detail’ 텍스트로 변경되었다. 커스텀 포스트의 목록은 플러그인을 활성화하면 자동으로 생성되고, 비활성화하면 자동으로 삭제된다.Edit 화면의 레이블이 변경되었다. 어떤 입력 위젯도 출력되지 않으며, 스크린 옵션도 삭제되었다. 커스텀 포스트에 예제로 만든 2개의 커스텀 필드만 표로 출력되게 조작되었다.편집 권한이 없으므로 대량 편집 기능도 삭제하는 것이 맞다.
커스텀 포스트의 옵션 값과는 약간 거리가 있지만, 우선 워드프레스가 어떻게 다시 쓰기를 하는지에 대해 이야기를 먼저 하고자 한다. 옵션이 워낙 적어 분량 채우기기도 하지만… 워드프레스의 다시 쓰기 원리를 이해하고 이 옵션을 보는 것이 더 낫지 않을까?
웹사이트를 돌아다니다 보면 URL이 엄청나게 긴 것들을 볼 수 있다. 그에 비하면 엄청 양반이지만, 워드프레스에서도 이렇게 긴 URL로 쿼리를 할 수 있다.
/index.php?post_type=post&paged=1
위 URL예는 블로그 포스트 1페이지를 불러 오는 예이다. 파라미터가 단 두개 뿐이라 부담은 없지만, 이런 URL은 그다지 기억하기 쉽지도 않고, 예쁘지도 않다. 또 SEO (Search Engine Optimization) 관점에서도 이렇게 장황한 URL은 권장할 만한 사안은 아니다.
깔끔한 URL을 사용하게 되면 URL 자체로도 보다 의미 있어진다. 하지만 어떻게 하면 깔끔하고 좋은 URL을 만드는지 그 요령에 대해서는 논외로 하고, 어떻게 이렇게 URL을 쓸 수 있는지에 대해서만 쓰겠다.
웹서버가 서비스를 하는 가장 기본적인 방법은 파일 기반이다. 그림 파일, 자바스크립트 등등, 또 정적인 HTML 파일들이 그렇다. 그냥 있는 그대로 클라이언트들에게 전달하면 되는 구조다.
그러나 서버 사이트 스크립트 언어인 PHP로 짜여신 파일의 경우는 조금 다르다. PHP 파일 스크립트를 (소스) 그대로 클라이언트에게 전달하는 일은 없다. PHP 스크립트 또한 파일 기반이라는 점은 변함이 없지만, 그 파일에 접근할 때 어떠한 파라미터를 주는지에 따라, 또는 GET인지 POST인지 전달 방식에 따라 결과는 달라질 수 있다.
워드프레스에서도 마찬가지다. 단지 워드프레스 코어가 index.php 이외의 주소로 접근하는 것에 대해 잘 대비했을 뿐이다. 워드프레스의 index.php 외 여러 php 파일을 대상으로 웹브라우저에서 접근해 보라. 그저 빈 스크린만 나올 뿐이다. 물론 로그인이나 관리자 같은 몇몇 특별한 접근 포인트들은 예외지만.
그러면 워드프레스에서는 어떻게 깔끔한 URL을 처리하도록 만드는 것일까? 우선 웹서버에서 rewrite를 지원해야 한다. Apache나 nginx 둘 다 rewrite를 지원할 수 있으므로 이 기능에 의지해 URL을 찾아내는 것이다. 단, rewrite 기능에 모든 것을 의지하지는 않는다. 개략적인 룰만 지정하고, 나머지 복잡한 규칙은 내부의 DB에 저장한 다음 동적으로 처리한다.
기본적인 컨셉은 이렇다.
.htaccess 파일에 rewrite 룰을 다음과 같이 설정해 둔다: URL의 경로를 모두 무시하고 무조건 /index.php 파일에서 요청을 처리하도록 서버 흐름을 조작한다. 어차피 클라이언트가 어떤 경로를 요청했는지는 PHP의 $_SERVER 변수에 다 기록되어 있다.
$_SERVER[‘REQUEST_URI’]에서 읽어온 URL과 데이터베이스에 저장된 rewrite 규칙을 대조한다. 여기서 규칙에 맞는 것을 찾는다면, 안 예쁜 URL로 변경한다. 즉, ‘index.php?param1=val1¶m2=val2…’ 식으로 URL이 변경된다.
파라미터에 맞게 데이터베이스 쿼리를 한다.
템플릿을 불러와 적절히 응답을 한다.
워드프레스는 아파치를 서버로 사용한 경우에 내부에 .htaccess 파일을 생성한다. 생성하지 못하면 .htaccess 파일을 따로 업로드하라고 안내를 한다. 코덱스에서 기술하는 기본적인 .htaccess 파일 구조는 이렇다.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
‘<IfModule> … </IfMoudle>’은 아파치 서버의 rewrite 모듈이 동작하는 경우에만 그 안의 내용을 읽으라는 뜻이다.
‘RewriteEngine On’은 다시 쓰기를 작동한다는 뜻이다.
‘RewriteBase /’은 다시 쓰기를 ‘/’를 대상으로 이뤄 진다는 것이다.
첫번째 RewriteRule은 URL이 그냥 index.php로 시작하고, 또 그대로 끝난다면, 이 주소는 더 건드리지 않고 놔 두라는 뜻이다.
두 번째 RewriteRule 위에 두 개의 RewriteCond가 있다. 두번째 RewriteRule의 선결조건을 의미한다.
%{REQUEST_FILENAME}는 서버 내에서 가져와야 할 파일의 이름을 의미하는 변수이다.
‘!-f’, ‘!-d’는 각각 ‘파일이 아닌 경우’와 ‘디렉토리가 아닌 경우’를 뜻한다.
그래서 %{REQUEST_FILENAME}이 파일도 아니고, 디렉토리도 아니라면 URL은 무시하고 index.php로 들어와 처리하라는 뜻으로 해석된다.
예를 들어 ‘<home_url>/category/foods’라는 깔끔한 URL을 웹브라우저에서 요청했다. 사실 이런 경로는 서버에 존재하지 않는다. 그러므로 아파치 웹서버는 그냥 index.php 파일로 접속하도록 처리를 한다.
그리고 wp() 함수를 호출하고, WP::main()에서 WP::parse_request() 함수를 처리하는 동안 데이터베이스에 있는 다시 쓰기 규칙을 읽어와 ‘category/foods’라는 경로는 원래 어떤 index.php?쿼리 문자열이었는지를 조사한다.
아마 워드레스에서는 기본적으로 ‘category/food’를 ‘index.php?category_name=food’로 치환할 것이다. 그러면 예로 제시한 URL은 사실 ‘index.php?category_name=food’와 같으며 웹브라우저에서 이 URL로 요청을 해도 같은 응답이 오게 될 것이다.
이 다시 쓰기 규칙은 워드프레스 options 테이블의 ‘rewrite_rules’라는 이름으로 저장되어 있다. 규칙은 배열을 serialize 된 상태로 존재한다.
rewrite_rule들이 데이터베이스의 레코드로 저장되어 있다. 그 위 고유주소(permalinks) 메뉴의 옵션값도 저장되어 있는 것이 보인다.
또다른 예로, 가끔 워드프레스를 이사하거나 정비하는 과정에서 전면 페이지(frontend) 홈은 보이지만 네비게이션 메뉴에 있는 다른 페이지로 옮기면 404 에러가 발생하는 경우가 있다. 이 문제는 .htaccess에서 존재하지 않는 서버상의 경로를 무조건 index.php로 처리하라는 명령이 누락되어 있기 때문이다.
Nginx도 크게 다른 것이 없다. 아파치처럼 .htaccess를 활용하지는 않지만, 어떤 URL로 요청이 들어오든지간에 처리를 index.php에 맡긴다는 점은 동일하다.
permalink_epmask
사실 이 옵션을 별로 건드려야 할 이유는 거의 없다. register_post_type 함수 내부를 들여다 봐도 이 옵션은 단지 EP_PERMALINK라는 기본값을 채워 넣는 것 이외에 언급되는 일도 없고.
사실 epmask를 코어에 유효하도록 설정하려면 add_rewrite_endpoint() 함수를 써야만 한다. 또 이 옵션에 값을 집어넣는다고 해서 register_post_type이 별도로 이 함수를 쓰는 것도 아니다.
말단지점에 대한 부가 설명
말단지점(endpoint)란 http://example.com/service/path 처럼 웹서버의 어떤 경로라고 생각할 수 있는데 이것이 왜 생겼고, 어떻게 쓰여지는지는 여기에 간략히 설명되어 있다. 간단히 말해 서버의 어떤 단일 개체를 위한 엔드포인트에 별도의 패스를 덧붙일 수 있도록 한 것이다.
예를 들어 wphack 커스텀 포스트에 개체에 접근하기 위해서 ‘/wphack/<post-slug>’ 이라는 말단지점을 사용할 수 있다. 그런데 어떤 목적 때문에 포스트의 제목만, 정말 제목만 출력하는 URL이 필요하다고 가정해보자. 물론 URL을 별도로 꾸밀 수도 있지만, 이러한 URL이 포스트 타입이나 페이지 타입 전반에 걸쳐 필요로 하다면? 이러한 경우를 위해 도입된 것이 바로 endpoint api이다.
add_action( 'template_redirect', 'wphack_ep_title_redirect' );
function wphack_ep_title_redirect() {
global $wp_query;
if( !isset( $wp_query->query_vars['title'] ) || !is_singular() ) {
return;
}
global $post;
header( 'Content-TYpe: text/plain' );
echo $post->post_title;
exit;
}
이렇게 하면 wphack, 또는 어떤 포스트, 페이지 타입에 대해 /title/ 이라는 경로를를 추가로 입력하면 개체의 제목만 출력한다. add_rewrite_endpoint 함수에 EP_PERMALINK | EP_PAGES 마스크를 씌웠으므로 각각 포스트, 페이지에 적용되었다. 나머지 상수도 마찬가지이다. 예륻 들어 EP_DAY라는 마스크는 엔드포인트에 날짜가 사용된다면 그 엔드포인트에 추가 경로를 붙일 수 있도록 한다.
이렇게 코드를 짜면, 데이터베이스를 갱신해 주어 서버에서 인식되도록 처리해야 한다. 간단한 방법으로는 설정 (settings) > 고유주소 (permalinks)로 가서 저장 버튼을 한 번 눌러 주는 것이다. 내용을 변화시킬 필요는 없다. 이렇게 하면 options 테이블의 rewrite_rules 내용이 갱신된다.
그리고 이렇게 갱신된 내용은 ‘Debug Bar’와 ‘Debug Bar Rewrite rules’ 플러그인을 사용해 진단해 볼 수 있다.
두 플러그인을 받고 활성화 한다.로그인하면 어드민 바에 Debug 항목이 추가된 것이 보인다. 이 버튼을 누르면 그림과 같은 항목이 나온다. 좌측 메뉴에서 ‘Rewrite Rules’항목을 선택한다.title 부분만 골라 보았다. 이렇게 정규식 매칭 표현과 매칭된 규칙이 어떻게 변환될지 정의되어 있다.
rewrite
rewrite 옵션은 하나의 배열을 값으로 받으며, 이 배열은 아래의 키를 가진다. 이 값을 변경하면 반드시 새로 고침 레코드를 갱신해 주어야 한다.
slug
query_var 옵션이 질의 문자열에 쓰이는 반면, slug 옵션은 rewrite에 사용된다. 만약 slug의 값으로 ‘ask’라는 문자열을 사용했다면 커스텀 포스트 타입 wphack은 전단부에 다음과 같은 URL로 접근 가능해진다.
<site_url>/ask/ # 목록 (아카이브)
<site_url>/ask/page/PAGE_NUMBER # 페이지 번호로
<site_url>/ask/slug/ # 특정 개체만
with_front
true/false를 가질 수 있는다. Front라는 것은 고유주소 설정에서 태그 항목 이전에 고정으로 생성한 문자열을 말한다. 아래의 그림을 보면 이해가 빠를 것이다.
/with-front 부분이 front이다.
고유주소에 /with-front 문자열을 앞에 덧붙였는데, 이렇게 저장을 하면 워드프레스의 대부분의 기본적인 고유주소는 /with-front로 시작한다. 그러나 이 값을 false로 설정하면 현재 동록하는 커스텀 포스트만큼은 이 문자열을 허용하지 않는다.
slug가 ‘ask’로 설정되었고 front가 ‘/with-front’라면
with_front가 false 일 때: <site_url>/ask로 개채의 목록 접근
with_front가 true 일 때: <site_url>/with-front/ask로 개체의 목록 접근
feeds
포스트 타입을 만들면 이에 대한 피드도 간단하게 만들어진다. 피드는 atom, rss, rss2 , rdf 다 지원을 한다. 이 값을 true로 하면 주소 끝에 /feed, /rss, /rss2 만 붙이면 바로 해당 형식으로 콘텐츠를 지원한다.
/feed, /rss, /atom, /feed/rss, 같은 주소만 붙여주면 아주 쉽게 피드를 작성할 수 있다.
pages
목록에서 페이징을 가능하게 한다. 이 항목이 true로 되어 있어야 <site_url>/ask/page/PAGE_NUMBER 처럼 된 URL로 접근 시 제대로 페이징된 목록을 보여 주게 된다.
페이지 기능 자체를 이 옵션으로 켜고 끄는 것이 아니다. 단지 URL 규칙을 제대로 설정하는 것이다.
ep_mask
워드프레스 3.4 이후부터 permalink_epmask 옵션을 대체하는 옵션이다.
마치며
3.4에 오면서 permalink_epmask 옵션이 rewrite 옵션과 통합되면서, 사실상 이 포스트에서 다룬 옵션은 고작 하나였다. 그렇지만 rewrite는 워드프레스 코어 기능과 매우 밀접한 중요한 기능이라 생각해서 별도의 포스트로 따로 작성한 것이다.
쿼리 문자열은 코어에 있어 엄청나게 중요한 부분이다. 어떤 콘텐츠를 어떻게 보여줄지는 모두 쿼리 파라미터에 달려 있기 때문에 사실 이 쿼리 파라미터가 워드프레스를 움직이는 중추라고 할 수 있다. 쿼리 문자열을 직관적인 URL로 변환시켜 주는 옵션이 rewrite이며 이것은 서버의 다시쓰기 기능을 필요로 하지만, 복잡한 다시쓰기 규칙은 워드프레스 코어 자체에서 별도로 수행하고 있다.
내보내기 기능에 해당 커스텀 타입도 포함시키는 옵션이다. 이것이 true 이면 도구(tools) > 내보내기 (export) 메뉴에서 커스텀 타입도 포함된다.
내보내기를 하면 XML 형태로 사이트의 콘텐츠를 다운로드 받을 수 있다. 단, 주의해야 할 점이 있다. 이것은 콘텐츠를 내보내기 위한 용도이며 범위는 콘텐츠에 한해 진행된다.
백업을 하려면 데이터베이스를 sql 형태로 백업받고, FTP 등을 이용해 사이트 전체 파일을 받아 두는 것이 낫다. 사이트 전반에 걸쳐 저장된 옵션, 예를 들어 테마 설정 및 업로드된 첨부 파일의 원본까지 보관해 두어야 하기 때문이다.
description
이 커스텀 포스트 타입이 어떤 것인지 기술하기 위한 용도로 사용된다. 이 옵션 자체가 어딘가 직접적으로 사용되는 일은 없다.
hierarchical
True 이면 ‘페이지’ 타입처럼 처럼 상위/하위 개념이 존재하는 개체로 만들 수 있다. 반대로 false이면 ‘포스트’ 타입처럼 모든 포스트는 동등한 위치를 가진다.
True/false 값의 차이는 supports 옵션에서 ‘page-attributes’를 넣었을 때 확연이 난다. true일 때는 (parent) 옵션이 나타나고, false일 때에는 이것이 보이지 않는다.
또 true면 목록을 출력할 때 하위 개체는 상위 개체에 그룹이 지어져 나온다.
HackPost #6 (최상위)
HackPost #5 (부모: #6)
HackPost #4 (부모: #5)
HackPost #3 (최상위)
HackPost #1 (부모: #3)
HackPost #2 (부모: #3)
taxonomies
배열로 값을 채워 넣을 수 있다. 이 커스텀 포스트에 대한 분류 체계를 설정해 줄 수 있다. 그렇지만 이렇게 분류 체계를 연관지어 주려면 먼저 분류 체계를 미리 등록해야 한다. 만약 새 분류 체계를 사용하나면 별도로 register_taxonomy() 함수로 분류 체계를 등록해야 한다.
이 포스트는 커스텀 포스트의 관리 UI(admin UI)와 관련된 옵션을 다룬다. 목록은 아래와 같다.
public
show_ui
show_in_nav_menus
show_in_menu
show_in_admin_bar
menu_position
menu_icon
supports
register_meta_box_cb
public 옵션은 관리 UI 관련 옵션에도 관여하지만 가시성 관련 옵션에도 관계가 있다. 해당 포스트에서 확인할 수 있다. 전체 옵션은 이 포스트에서 확인할 수 있다.
public이 true이면 show_in_hav_menus, show_ui 옵션이 true. 반대로 false이면 모두 false로 설정된다.
show_ui
포스트 타입을 관리하는 기본 UI를 제공할지를 결정한다. 기본적인 포스트의 목록 확인, 생성, 편집 UI를 재활용할 수 있다. 이 UI는 다음과 같은 URL 패턴을 따라 제공된다.
<site_url>/wp-admin/edit.php?post_type=<post_type> // 목록
<site_url>/wp-admin/edit.php?post=<post_id>&action=edit // 편집
<site_url>/wp-admin/post-new.php?post_type=<post_type> // 추가
커스텀 포스트 목록 UI커스텀 포스트 편집 UI
이 패턴 대로 URL을 입력하는 경우 위 그림처럼 익숙한 UI를 만날 수 있다. 만일 show_ui가 false이면 아래 그림처럼 권한이 없다는 메시지를 만날 수 있다.
관리 UI에 접근 권한 없음
show_in_nav_menus
이 옵션은 기본값으로 public 옵션 값을 따라 간다. 이 값이 true이면 외모(appearance) > 메뉴(menus) 항목에서 커스텀 포스트 항목을 메뉴로 선택할 수 있게 된다.
show_in_menu
관리자 화면에 포스트 타입에 관한 메뉴를 출력할지 결정한다. show_ui는 반드시 true여야 한다.
이 옵션은 true/false, 혹은 문자열을 가질 수 있다.
true이면 관리자 화면에서 메뉴를 출력한다. 반대로 false면 관리자 화면에 메뉴는 출력하지 않지만 목록, 삽입, 편집의 URL을 알면 UI에 접근은 가능하다.
문자열은 이미 워드프레스에 등록된 메뉴 슬러그를 대상으로 한다. 예를 들어 ‘글’ 메뉴는 post.php이다. 워드프레스의 기본 메뉴 슬러그의 예를 들면:
글 (posts): edit.php
미디어 (media): upload.php
페이지 (pages): edit.php?post_type=page
댓글 (comments): edit-comments.php
외모 (appearance): themes.php
플러그인 (plugins): plugins.php
사용자 (users): users.php
도구 (tools): tools.php
설정 (settings): options-general.php
이렇게 메뉴 슬러그를 입력하면 그 메뉴의 하위 메뉴에 해당 개체의 관리 UI 항목이 삽입된다. 아래 그림은 플러그인 메뉴에 HackPosts 관리 메뉴를 삽입한 예이다.
show_in_admin_bar
어드민 바는 워드프레스에 로그인하면 생기는 화면 상단의 관리용 UI이다. 전단부(frontend) 및 관리자 화면 양측에 둘다 나오므로 보다 편리하게 관리 명령을 사용할 수 있다.
여기에 “+ 새로 추가 (+ New)” 버튼을 누르면 글, 페이지, 사용자를 쉽게 추가할 수 있다. 이 옵션이 true일 경우 해당 개체를 새로 추가할 수 있는 메뉴를 여기에 등록해 준다.
기본값은 show_ui 옵션값을 따라 간다.
menu_position
메뉴의 위치를 설정한다. 정수로 입력하는데, 기본값인 null로 입력하면 댓글 아래에 메뉴가 삽입된다. PHP는 타입 저글링이 일어나 이 값을 문자열 형태로 입력해도 될 것 같지만, 실제로 해 보면 진짜 “정수형”만 가능하다는 점에 유의한다. 정수형이 아니면 기본값과 같게 동작하게 된다.
사용자 정의 필드(커스텀 필드 또는 메타 필드)를 직접 수정할 수 있다. 키와 값이 그대로 출력되는 형태라 편집하기 직관적인 형태는 아니다. 주의할 점은, 직렬화된(serialized) 값은 이 목록에 포함되지 않는다. 예를 들어 아래 코드처럼 array를 serialize 시킨 것이라면 목록으로 출력되지 않는다. 개발하면서 가끔 착각할 수도 있으니 참고하도록 하자.
키로 hack_key_01, hack_key_02를 입력하고 값에는 일반 문자열과 직렬화된 PHP 배열을 주었다.hack_key_01은 문자열이라 UI에 표시된다. 그러나 직렬화된 값을 가진 hack_key_02는 키의 존재만 감지될 뿐 UI로 출력되지 않는다.
comments
토론(discussion)메타박스 새 개체 추가 및 편집 화면에서 나온다.
토론(discussion)관련 메타 박스를 출력하거나, 편집 화면에서 댓글(comments) 메타 박스를 출력해 댓글 관리를 할 수 있게 한다.
댓글(comments) 메타 박스. 편집 화면에서 나온다.
revisions
개정판(revisions) 목록을 조회할 수 있는 메타박스를 보여 준다. 개정판 목록은 함부로 수정할 수 없다. 혹시 너무 많은 개정판이 문제라면 별도의 워드프레스 최적화 플러그인을 설치해서 이를 제거해 주거나 wp-config.php 파일을 수정해 주어야 한다.
page-attributes
페이지의 속성을 지정해 주는 메타 박스를 출력한다.
상위(Parent) 항목은 커스텀 포스트의 다른 옵션인 ‘hierarchical’이 true인 경우에 출력된다. Order의 경우 테이블의 menu_order 값과 연결되는데, 이 값은 개체 목록 출력시 별도의 정렬 순서를 지정해 줄 수 있다. 예를 들어 다음과 같이 menu_order 값을 지정해 주었다.
포스트 목록의 기본 순서가 그대로 정렬되어 나온다. 전단부에서 아카이브 페이지로 접근해도 이 순서는 동일하다.
post-formats
포스트 포맷은 워드프레스 3.1에서부터 지원하는 테마 기능이다. 코덱스에서는 대략적인 가이드라인을 줄 뿐, 각 포맷을 처리하는 방식은 전면적으로 테마에게 달려 있다. 아래에 항목에 대한 간략한 설명을 추가했다.
추가정보 (aside): 올바른 번역인지는 잘 모르겠다. 페이스북과 같은 제목이 없이 콘텐츠만 나열하는 스타일로 사용된다.
이미지 (image): 이미지를 위한 포스트 스타일. 첫번째 img 태그의 이미지가 해당 이미지로 간주된다. 포스트 본문에 URL 하나만 있을 수도 있는데, 그러면 그 이미지를 사용하며 이미지의 title 태그는 포스트 제목으로부터 온다.
비디오 (video):비디오 혹은 비디오 재생 목록 스타일. 첫번째 video 태그나 object/embed 태그를 해당 비디오로 생락한다. 비디오와 마찬가지로 URL 하나만 있을 수도 있다.
인용 (quote): 인용에 관한 콘텐츠를 설정하는 경우이다. 이 때 제목은 인용의 출처나 인용구의 저자 정보를 담을 수 있다.
링크 (link): 다른 사이트로의 링크를 기록하는 스타일이다. 처음 <a href=”” 태그가 외부로의 링크를 의미한다. 이미지와 마찬가지로 포스트 본문에 URL 하나만 놓을 수 있는데 이 때 포스트 제목을 이 링크의 제목으로 설정한다.
갤러리 (gallery): 이미지의 모음 스타일. 포스트의 내용으로 갤러리 쇼트코드를 가지고 있고 이미지 첨부 파일을 가지고 있을 수 있다.
상태 (status): 트위터 스타일로 짧은 글을 작성하는 스타일이다.
오디오 (audio): 팟캐스트 같은 오디오 파일 및 재생 목록 스타일이다.
채팅 (chat): 채팅 목록 스타일.
예를 들어, twentysixteen 테마에서 포스트 포맷을 걸어 보면 이렇게 나온다.
표준 포맷
standard 포스트 포맷. 커서가 지나는 중 캡쳐하여 글자색이 다른 건 무시하자.
추가정보(aside) 포맷
aside 포스트 포맷. 제목이 작게 나오고 ‘Aside’ 포스트 포맷이라는 표시가 나온다. 표준 포맷에 대해 제목이 좀 더 작게 나온다.
상태 (status) 포맷
status 포스트 포맷. 제목 자체를 필요로 하지 않는다. 또 제목링크가 완전히 사라져 단일 포스트만 화면의 접근이 차단된다.
register_meta_box_cb
개체에 대한 세부적인 인터페이스를 위해 메타 박스를 추가할 수 있다. 포스트 타입을 설정하면서 메타 박스를 디자인하기 위한 콜백 함수를 값으로 입력하면 된다.
관리 UI 옵션은 커스텀 포스트의 여러 요소 중 관리자 화면에서 나타낼 유저 인터페이스와 관련 깊은 옵션들만 따로 모아 내가 임의로 그룹화한 것이다. 관리 화면 UI 관련 옵션인 만큼 워드프레스 관리자와 가장 밀접한 부분일 것이라 생각한다. 사용하는 목적에 따라 적절한 파라미터 값을 찾아 사용하기를 바란다.
