워드프레스는 Portable PHP password hashing framework(phpass)를 사용하여 패스워드를 해싱한다. 이 프레임워크에서는 PHP5.5이후의 내장된 password_hash(), password_verify()를 사용하는 것이 권장하며, 자신들은 그 이전 프로젝트를 위한 호환성을 보장한다고 한다. 워드프레스 최소 환경이 5.2.9인 것을 감안하면 그렇게 해야 할 듯.
예를 들어 설명하는 것이 낫겠다. 워드프레스에서 시험적으로 ‘guest’라는 계정과 ‘guest’라는 매우 취약한 패스워드를 사용하여 계정을 만들었다. 그러면 패스워드 해쉬 값은 ‘$P$ByCNnCoqFGHDSjIkWjlf8heBFfLJLI1’로 나오게 된다.
불타는 금요일을 보내고 토요일 새벽까지 디버깅을 한 결과입니다.
Uncode 테마와 KBoard 게시판을 사용할 경우 워드프레스의 성능 저하를 유발시킬 수 있습니다. 둘을 따로따로 쓰면 문제가 없지만 같이 사용하는 경우 사이트에 로딩이 생기며, 특히 비주얼 컴포저 사용시 심각한 로딩 시간이 생기게 됩니다.
원인은 KBoard의 세션과 Uncode 테마의 ‘list_images‘ AJAX 동작 때문에 발생합니다. KBoard의 메인 파일인 kboard/index.php 파일의 초반에는 session_start()로 세션을 시작하는 구문이 있습니다. 그리고 이 세션은 KBoard 곳곳에서 활용됩니다.
한편 Uncode는 list_images라는 ajax 액션을 통해 uncode_list_images()라는 함수를 동작시킵니다(uncode/core/inc/admin.php: 1086). 이 함수는 무려 모든 이미지 파일을 불러와 그 이미지 파일의 용량을 계산합니다. 그리고 아래와 같은 메시지를 응답으로 넘깁니다.
The Adaptive Images system is using 87.6M of the 6.29G space left.
JSON 포맷이 아닌, 그냥 단순 텍스트 응답으로 날아옵니다. 이 응답이 자바스크립트 같은 곳에서 프로그래밍적으로 유의미한지는 확인하지 않았으나, 그렇게 보이지는 않습니다.
문제는 이미지의 양이 많아질 때 터집니다. 제가 작업 중인 사이트는 이미지 파일만 1만개에 가깝게 유지하고 있습니다. 사이트의 용량만도 기가바이트급입니다. 언코드는 무식하게도 이 1만개에 육박하는 이미지를 매번 관리자 화면 로딩시 별도의 AJAX 요청을 통해 모두 쿼리로 불러와, 용량을 계산하고, 위 메시지를 출력하고 있던 것입니다. 이 계산을 위해 대략 수 초, 심하면 저의 경우처럼 30~40초까지 걸리기도 합니다.
이제 이 상태에 KBoard가 끼어들면 문제가 정말 심각해집니다. KBoard는 로딩될 때마다 세션을 실행합니다. 세션에는 한 번에 하나의 연결만 접근할 수 있으므로 둘 이상의 연결을 동시 처리할 수 없습니다. 그런데 언코드는 파일 용량을 계산하는 AJAX를 페이지를 부를 때마다 자동으로 실행합니다. 병목구간이 발생하는 것입니다.
비주얼 컴포저로 각 위젯을 편집 버튼을 누르면 각 UI 정보는 AJAX를 통해 얻어 옵니다. 그러나 이미 이미지 용량 계산 때문에 다른 AJAX 요청에는 응답할 수 없는 상태입니다. 그래서 꽤 오랫동안 로딩이 걸리게 되는 것입니다. 아마 다른 페이지에 접근할 때도 마찬가지로 로딩이 심하게 발생할 수 있을 것입니다.
문제를 해결하려면
/* AJAX call to load all images */ add_action( 'wp_ajax_list_images', 'uncode_list_images' );
부분을 주석 처리.
add_action( 'plugins_loaded', 'my_uncode_kboard_fix' );
function my_uncode_kboard_fix() {
if( has_action( 'wp_ajax_list_images', 'uncode_list_images' ) {
remove_action( 'wp_ajax_list_images', 'uncode_list_images' ) ;
}
}
매번 이런 용량 계산을 하는 언코드도 문제지만, KBoard도 굳이 세션을 써야 했나 생각이 듭니다.
요즘은 웹 페이지들이 엄청 인터랙티브하다. 그만큼 비동기 호출, AJAX의 사용이 많을 수 밖에 없는 환경이다. 한편 워드프레스에서는 admin-ajax.php라는 곳에서 거의 모든 AJAX 요청을 처리하게 된다. 이 포스트에서는 워드프레스 플러그인에서 AJAX 요청을 작성할 때 참고하면 좋을 팁을 몇 가지 적어 보도록 한다.
REST API v2를 사용하면 프론트 구성을 대폭 간결하게 만들 수 있다. 그리고 워드프레스 자체에서 backbone.js, underscore.js를 내장하고 있고, 이를 곳곳에 활용하고 있으며, 심지어 backbone.js의 model과 collection 개념을 사용하여 REST API를 구성하고 있다. 아직 REST API의 여러 부분을 깊숙하게 파악하지는 못했지만, 얼추 프로그램을 작성해 보면 한결 가볍게 페이지 구성이 가능해짐을 직접 느낄 수 있었다.
이 포스트는 커스텀 포스트와 REST API를 사용하면서 삽질한 결과를 간단히 남겨 놓기 위해 작성한다.
이전 포스트에서 예고한 대로 이번에는 기본 권한과 메타 권한에 대해 포스팅해 보고자 합니다.
구 워드프레스에는 회원들의 권한을 구분하기 위해 ‘레벨’이라는 개념을 사용했습니다. 예전 제로보드4 에서도 볼 수 있었던 개념입니다. 레벨 1부터 숫자가 높을 수록 권한이 낮아지는 방식의 권한 테이블 방식으로, 방법은 간단하나 썩 훌륭한 방법은 아니었습니다. 왜냐면 한 회원은 반드시 어떤 레벨에 종속되어 버리는 문제가 있고, 또 실제 운영에 있어서 권한의 높낮이보다 각기 회원의 세밀한 권한 설정도 중요할 때가 많은데, 이를 확장할 방법이 부족한 것이었죠.
워드프레스 2.0버전부터 새로운 개념인 역할과 권한(roles and capabilities)이 생겼습니다. 이 달라진 권한 개념은 레벨이라는 개념을 완전히 버리고 새롭게 디자인된 권한 설정입니다. 그럼 역할과 권한이 어떤 특성을 가졌는지부터 간단하게 설명해 보도록 할께요.
자동 혹 전수자(AutoHookInitiator, 오토 훅 이니시에이터)의 메소드 이름 규칙에 의해 액션과 필터가 자동으로 등록됩니다. 동작은 자동 발견 개시자(AutoDiscoverLauncher, 오토 디스커버 론처)가 동적으로, 알아서 시켜 줍니다. 프로그래머는 자잘한 콜백 선언은 엔진에 맡겨 두고 콜백 로직에만 집중하면 됩니다.
개발하면서 느끼는 훅과 콜백의 문제점이 있습니다. 바로 훅의 선언과 콜백의 구현이 구현 차원에서 서로 떨어져 있다는 점입니다. 물론 액션 필터 선언 후 바로 콜백을 선언함으로써 그 코드의 거리를 좁혀 놓을 수는 있습니다. 그러나 코드가 점점 커질수록 이 거리를 완전히 붙여놓기 쉽지 않아집니다.
콜백끼리 서로 공유해야 할 데이터가 있는 경우나, 보다 좋은 코드를 위해 클래스를 사용하는 경우 액션, 필터의 선언과 그 콜백은 더욱 그 거리를 가까이 하기 쉽지 않습니다. 그래서 나중에 유지 보수를 하는 중에 계속 에디터 창을 위아래로 옮겨 가면서 훅 선언과 콜백을 대조해야만 합니다.
그런데 잘 생각해 보면 액션, 필터의 선언과 그 콜백은 거리로는 떨어져 있지만 의미적으로는 한 덩어리라고 볼 수 있습니다. 단지 언어적으로 그 둘을 한번에 표현할 방법이 없기에 구현상의 이유로 떨어진 것 뿐이라고 생각할 수 있습니다.
자동 혹 전수자(AutoHookInitiator, 오토 훅 이니시에이터)는 이런 문제를 해결하기 위하여 고안하였습니다. 제가 이전 포스팅을 통해 전수자란 존재를 소개하면서 전수자는 기능적으로 관련 있는 훅들을 하나의 클래스로 묶어 통일성을 꾀하는 장치라고 말씀드린 적이 있습니다. 그리고 이런 전수자를 잘 응용하면 꽤 재미난 것들을 보여줄 수 있다고도 하였는데요, 이번에 소개해드릴 이 자동 훅 전수자가 그 대표격입니다.
보통 훅과 콜백을 이렇게 선언합니다.
add_action( 'admin_init', 'my_callback' ) ;
function my_callback() {
....
}
앞에서 말씀드렸듯이 add_action()과 my_callback()의 가독성을 위하여 그 둘을 딱 붙여서 놓는 경우가 많습니다만, 어쩔 때는 거대한 함수들에 둘러싸여있는 통해 add_action()이 잘 보이지 않을 때도 있고, my_callback() 또한 항상 add_action()과 가깝게 있을 수 없는 경우가 많습니다.
그러나 AutoHookInitiator는 이런 개념을 송두리째 바꾸어버립니다. 단지 콜백 함수를 작성하는 것만으로도 액션과 필터는 자동으로 등록됩니다. 아래는 자동 훅 전수자의 예입니다.
class SampleInitiator extends AutoHookInitiator
{
public function action_init()
{
....
}
public function action_5_admin_init()
{
....
}
public function action_10_3_save_post($post_id, $post, $updated)
{
....
}
public function filter_the_title($title)
{
....
return $title;
}
}
…. 으로 생략한 부분은 콜백이 구체적으로 할 부분입니다. 클래스 코드 내부에서 전혀 add_action, add_filter를 쓰지 않았지만, 이 클래스를 통해 분명히 저는 3개의 액션과 1개의 필터를 선언하였습니다. 비밀은 메소드의 이름에 있습니다. 이 클래스 메소드의 이름을 부모 클래스인 AutoHookInitiator에서 정한 규칙에 맞게 지어주기만 하면 액션과 필터는 알아서 등록됩니다. 신기하지 않나요?
메소드 이름 규칙은 이렇습니다.
위 코드에서 선언된 훅을 분석해 보고, 종래의 방식으로 다시 풀어 쓰면 이렇습니다.
add_action( 'init', array( $this, 'action_init' ) );
add_action( 'admin_init', array( $this, 'action_init' ), 5 );
add_action( 'save_post', array( $this, 'save_post' ), 10, 3 );
add_filter( 'the_title', array( $this, 'filter_the_title' ), 10, 1 );
간결함
메소드의 이름을 지음과 동시에 액션/필터의 선언이 동시에 지원됩니다. 코드가 분리되지 않아 가독성도 좋습니다. 저는 어떤 기능을 구현하면서 몇가지 훅을 시험적으로 사용해 봅니다. 경험에 따라 최적의 훅을 단번에 지목해 구현하는 경우도 있지만, 어쩔 때는 몇 번이고 액션과 필터를 수정하면서 해당 기능을 개선하려고 애를 씁니다. 그럴 때마다 훅과 콜백을 수정하는 것도 상당히 귀찮은 일입니다. 그러나 AutoHookInitator를 이용하면 그 불편이 많이 완화됩니다. 메소드의 이름과 시그니쳐만 살짝 변경하면 되니까요.
콜백 메소드 작명도 상당히 귀찮은 일이고, 어쩌다 이름을 잘못 지으면 나중에 고치기도 쉽지 않습니다. 액션, 필터 선언한 곳까지 찾아가서 또 고쳐야 합니다. 그러나 AutoHookInitiator에서는 작명의 고통도 많이 완화됩니다. 별로 신경 쓰지 않아도 꽤 사려 깊게 이름이 지어집니다.
한편 PSR을 사용하여 메소드나 변수는 camelcase가 기본인데, 이렇게 언더바를 사용하면 상당히 이질적일 것입니다. 저는 오히려 이 이질적인 것이 더욱 “콜백”임을 강조하게 되어 긍정적으로 생각합니다. 이런 메소드를 보면 단박에 ‘아 이거 콜백 함수구나’라고 알아차릴 수 있습니다.
add_action, add_filter를 생략한다고 해서 개발 속도가 극적으로 빨라지는 것은 아닙니다. 그냥 기존의 방식을 써도 무방하지만, 그럼에도 불구하고, AutoHookInitiator는 편합니다. 사실 add_action, add_filter는 겉치레거든요. 이걸 생략하고 바로 콜백 구현에 들어가는 것은 개발 단계에 있어서는 상당히 실리적입니다.
아, 여기서는 add_action, add_filter 만 이야기했습니다. 그러나 엔진에 구현된 AutoHookInitiator는 activation, deactivation 훅에도 대응됩니다.
워드프레스 특성상 콜백의 역할이 그다지 두텁지 않은 경우에는 콜백에 로직을 모두 구현해도 큰 문제가 없는 경우가 종종 있습니다. 아니, 그냥 콜백에 로직을 구현해야 오히려 더 깔끔할 때가 있습니다.
반면 콜백에서 해야 할 일이 상당히 두터운 경우에는 별도의 뷰를 만들어 그 뷰에서 업무를 처리(dispatch)해야 할 경우가 생기기도 합니다. 예를 들어 어떤 어드민 메뉴를 만들 때입니다. 어드민 메뉴 페이지는 add_menu_page() 함수를 통해 삽입할 수 있습니다. 여기 인자 중에 콜백 함수도 포함되어 있는데, 이 콜백함수는 화면의 출력을 담당하므로 로직이 조금 복잡해질 가능성이 있습니다. 이걸 로직으로 작성하면 이렇게 됩니다.
class SampleInitiator extends AutoHookInitiator
{
public function action_admin_menu()
{
$view = new AdminMenuView();
$view->dispatch();
}
}
....
class AdminMenuView extends BaseView
{
public function AdminMenuView()
{
add_menu_page(
...
array($this, 'outputMenuPage') // 메뉴 페이지가 보여 줘야 할 내용을 출력하는 콜백
....
);
}
public function outputMenuPage()
{
// 페이지 렌더링
.....
}
}
콜백 함수에서 별도의 뷰를 사용할 때 상당히 많은 경우 뷰를 인스턴스화 하고, 약속된 메소드인 dispatch()를 호출하는 패턴을 만날 수 있습니다. 그렇다면 전수자에서 이렇게 축약할 수 있습니다. 저는 이것을 메소드 이름 앞에 ‘v_’를 붙였다고 해서 ‘v 액션’이나 ‘v 필터’라고 부릅니다.
class SampleInitiator extends AutoHookInitiator
{
public function action_admin_menu()
{
$view = new AdminMenuView();
$view->dispatch();
}
// 위 메소드와 같은 역할을 합니다.
public function v_action_admin_menu()
{
return AdminMenuView::getClass();
}
}
View 클래스가 BaseView를 상속받아서 dispatch()라는 메소드와 getClass()라는 FQCN을 리턴하는 스태틱 메소드를 선탑재하고 있습니다. 이렇게 전수자 – 뷰 간의 관계가 단순하게 명세됩니다. AdminMenuView또한 독립적인 뷰로서, 나중에 요구사항이 변경될 때, 이를 태면 AdminExtraMenuView 같은 객체로 대체되어야 할 경우 아주 간단하게 수정될 수 있습니다.
훅의 이름은 사실 동적입니다. 예를 들어 save_post_{$post_type} 같은 훅이나 , wp_ajax_{$action} 같은 것들입니다. 변수의 이름에 따라 훅 이름이 변경되는 경우입니다. 이럴 땐 AutoHookInitiator를 쓰기 곤란합니다. 함수 이름을 동적으로 변경할 수는 없으니까요.
이 때를 대비하여 AutoHookInitiator는 setReplacement() 메소드를 가지고 있습니다.
class SampleInitiator extends AutoHookInitiator
{
public __construct()
{
$this->setReplacement(
'wp_ajax_my_action',
'wp_ajax_action'
);
}
public function action_wp_ajax_action()
{
....
}
....
}
setReplacement()의 첫번째 인자가 코어에 전달될 진짜 훅 이름입니다. 두번째 인자는 우리 전수자에서 찾을 수 있는 가칭 훅 이름입니다. 바로 밑의 메소드가 action_wp_ajax_action인 것이 보이죠? wp_ajax_action이라는 훅 이름은 실제로 add_action() 함수를 호출할 때는 wp_ajax_my_action으로 변경됩니다. 이렇게 동적인 훅 이름에도 대처할 수 있습니다.
전수자는 단순히 훅만 그룹화하는 클래스가 아닙니다. 전수자 안에 조직화된 훅들은 문맥에 따라 그 실행을 조절할 수 있습니다. 엔진이 제공하는 기본적인 전수자 실행 문맥은 다음과 같습니다. 그리고 문맥은 사용자가 추가할 수 있습니다.
예를 들어 ‘<plugin-dir>/src/Initiators‘란 곳이 전수자들을 놓아 두는 디렉토리라면, 여기에 문맥과 동일한 이름의 디렉토리를 만들고, 그 디렉토리에 전수자 클래스를 배치하면 해당 전수자들은 해당 문맥에서만 실행됩니다.
이 디렉토리 아래 다음과 같은 상대 경로로 전수자가 존재한다고 생각해 봅니다.
admin, ajax, front는 기본 문맥입니다. 따라서 해당 디렉토리 안에 저장된 전수자는 각각 관리자, AJAX, 전단부 요청에만 훅을 등록하도록 동작합니다. 나머지 frontNoAjax, CustomPosts는 문맥에 포함되지 않으므로 ‘항상’ 훅을 등록하도록 동작합니다. 그러나 만일 frontNoAjax에 “front 요청이지만 AJAX 요청은 제외하는 문맥”이라는 문맥을 따로 정의하여 자동 발견 개시자(AutoDiscoverLauncher)에 등록하면 해당 문맥에서만 훅을 등록할 것입니다.
엔진에서 기본적으로 디렉토리에 기반하여 문맥 설정을 해 주므로 별도의 코딩 없이도 훅 등록을 적절히 조절할 수 있습니다. 가령 구분 없이 개발을 한 후, 재차 잘 정리합니다. 관리 화면에서만 등록해도 좋은 훅들만 따로 모아 하나의 전수자로 몰아 놓고, 이 전수자를 admin 디렉토리로 옮겨 두면 됩니다. 일일이 메인 로직에서 코딩하는 것보다 훨씬 더 간편합니다.
전수자가 하나의 클래스이고, 객체라는 존재를 잘 활용하면 단순히 훅을 그룹화하는 것 이상의 능력을 발휘할 수 있습니다. 저는 플러그인을 위한 엔진을 개발하고 있고 위 내용은 실제 제 엔진에서 구현되어 사용중인 기능들입니다. 아직 소스를 일반에게 공개 배포하는 단계는 무리이지만, 어떻게든 이런 개념들을 제가 만들고 있고 발전시키고 있다는 사실은 알리고 싶었습니다.
두서없이 글을 적고 있고 이 글을 누가 읽고 이해할까… 이런 생각입니다. 그렇지만 앞으로 이런 개념들은 Ivy-MU라는 플러그인 엔진, 그리고 킹콩보드3 등을 통해 세상에 공개될 날이 올 테니, 그 동안에 해 둘 수 있는 또 하나의 준비라고 생각하고 있습니다. 그 날이 오기를 고대하면서, 계속 정진하고 있겠습니다.
플러그인 엔진 컨셉 중 가장 먼저 언급하고 싶은 것들.
워드프레스는 나름의 Best Practice와 코딩 스탠다드가 있습니다. 그러나 플러그인 엔진은 PSR 1, 2의 코딩 스탠다드를 더 선호합니다. 사실 이렇게 작성해서 플러그인 제출에 탈락할지 말지는 잘 모르겠습니다만, 엄연히 오픈소스에 커뮤니티 기반의 프로젝트인 워드프레스가 단지 자신들의 스탠다드를 지키지 않았다고 해서 플러그인 제출을 막을 것 같지는 않을 거라 생각합니다.
파일 이름과 클래스 이름 모두 PSR을 따르는데, 이는 Autoloading을 사용할 때 이 쪽의 이름 규칙이 보다 편리하기 때문입니다.
PSR-1, PSR-2에 이어 PSR-4 또한 적극적으로 도입하여 사용합니다. 메인 파일 처음에 들어가는 “require_once vendor/autoload.php” 구문 이외에는 클래스나 함수를 부르기 위해서는 require, include 구문을 쓰지 않습니다. 이렇게 autoloading을 사용하면 코드 작성과 유지가 매우 쉬워집니다.
물론 autoloading을 위하여 컴포저 (composer)를 도입합니다. 컴포저가 있는 만큼 외부 라이브러리 관리도 한결 편리해집니다.
물론 기존의 워드프레스식 파일 이름과 워드프레스식 이름 관례를 쓰더라도 autoloading을 사용하지 못하는 것은 아닙니다. 그러나 워드프레스식 클래스 이름과 파일 이름의 명명법이 다르기 때문에 일일이 파일 이름과 클래스 이름에 대해 문자열 처리를 해야 하는 불필요한 비용이 발생합니다.
예를 들어 클래스 이름이 WP_Member_Contacts 라는 클래스를 만들었다고 합니다. 그러면 이 클래스의 파일 이름은 ‘class-wp-member-contacts.php’ 정도로 될 것입니다. 그러면 WP_Member_Contacts가 class-wp-member-contacts.php 파일에 대응된다는 사항은 ‘composer dump-autoload’ 명령을 통해 autoloading 라이브러리가 미리 잘 캐싱해 둡니다. 여기까지는 좋습니다. 아무 문제가 없습니다.
그러나 엔진을 제작하면서는 약간 고민거리가 생깁니다. 엔진에서는 class-wp-member-contacts.php 파일을 만나게 되면 이 파일은 어떤 클래스를 가지고 있는지를 알아야 할 때가 생깁니다. 아까의 반대입니다. 물론 규칙이 있으니 쉽게 변환할 수 있습니다. class- 접두를 빼고, 모든 하이픈을 언더바로 바꾼 다음 ucfirst를 적용하면 됩니다(사실 PHP FQCN(fully-qualified class name)은 대소문자를 가리지 않으므로 꼭 하지는 않아도 됩니다). 그러나 일일이 파일 이름에 대해 문자열을 계산해야 하는 것이 번거롭습니다.
PSR-4와 PSR-1 규칙에 따라 클래스 이름과 파일이름을 CamelCase로 통일하면 그런 문자열 계산 비용이 사라집니다. 그리고 namespace의 한 마디가 디렉토리 깊이 하나로 매핑되는 구조 또한 매우 합리적입니다.
이번 포스트에서는 만들고자 하는 플러그인 엔진에 대한 개략적인 컨셉을 적고자 합니다.
워드프레스 플러그인 제작을 시작한 것은 2014년입니다. 그동안 몇몇 플러그인을 제작하였고, 몇 번의 플러그인 강의를 한 적이 있습니다. 몇 번의 플러그인 개발을 해 보며 느낀 것이 있습니다. 워드프레스는 훌륭한 CMS이지만, 훌륭한 웹 프레임워크는 아닌 것 같다는 겁니다. 다른 웹 프레임워크와 비교하면 솔직히 좀 아쉬운 것들이 많은 것이 사실이죠.
사실 워드프레스를 위한 개발 프레임워크들이 여럿 있지만, 저는 그냥 제 플러그인 엔진을 만들기로 결심했습니다. 네, 바퀴를 재발명하는 것 같은 어리석은 일일 수도 있겠습니다. 사실 거창한 이유는 아닙니다. 워드프레스 플러그인 개발자로 지내며 제 나름대로 고민한 것을 정리하고 싶었고, 제가 저의 결과물을 얼마만큼 체계적으로 정리할 수 있는지 궁금했습니다.
프레임워크 비슷한 것을 만드는 것은 사실 처음이 아닙니다. 아마 아무도 모르시겠지만 “Axis”라는 프레임워크라는 이름을 붙이기도 민망한 것을 만들고 처참히 실패가 적이 있었습니다. 지금도 마찬가지입니다. 제가 무슨 깊은 경험이 있어서 프레임워크를 운운하겠습니까. 그저 해보면서 성장하기를 바라는 것이겠죠. 여전히 민망하고 또 어려움을 느낍니다.
현재 워드프레스 개발자로 지내고 있으며, 실무를 접하며 겪게 되는 문제들은 상당히 흥미롭습니다. 어떤 일들은 지엽적이지만, 때때로 클라이언트들은 지금껏 접해보지 못한 상황을 문제로 가져옵니다. 저는 제가 흥미로운 다양한 경험을 해 볼 수 있는, 나름대로 좋은 환경에 있다고 생각합니다. 그리고 이런 문제들은 제가 상상할 수 있는 가장 우아한 방법으로 해결하고 싶습니다.
물론 당장 그런 최상의 결과를 내는 것은 매우 어려운 일입니다. 그런 좋은 코드는 거저 만들어지는 것이 아닙니다. 꾸준히, 정말 꾸준히 여러 이슈를 거쳐 제련되어야 합니다.
불행히도 클라이언트들을 위해 만드는 소위 ‘남을 위해 짜는 코드’들은 그렇게 지속적인 관심을 쏟기 어렵습니다. 빠른 시간에 만들어야 하고, 또 한 번 데드라인에 맞춰 완성된 결과는 적절히 유지보수하는 것 말고는 지속적으로 업데이트하여 쓰기가 어렵습니다. 클라이언트에게 최상의 코드를 제공해 드리지 못하는 점 죄송하게 생각합니다. 그러나 저도 사람인지라, 만들고 나서야 결과를 아니까요. 사람의 최선에는 늘 한계가 있더군요.
엔진은 우선 저희 경험을 최대한 완성도 있게, 재활용될 수 있도록 레거시 코드를 정돈한다는 느낌으로 작성할 것입니다. 자주 반복되는 요소들은 그 다음에는 더욱 효율적인 방법으로, 간결하게, 이전보다 더욱 잘 작성될 것이라는 희망을 가지고 코드를 작성합니다.
‘MTIV’는 제가 생각한 플러그인을 위한 MVC류의 개발 패턴입니다.
저는 Axis라는 구작을 만들 때부터 워드프레스 플러그인에 최대한 MVC 패턴을 도입하려고 애를 썼습니다. 솔직히 지금도 MVC의 정수를 이해하지는 못한다고 생각하며, 타 프로그래머에 비해 오히려 많이 부족하다고 생각합니다. 그럼에도 불구하고 이것을 고집하는 이유는, 이것이 더 나은 방법이라고 생각하기 때문입니다.
개발을 하면서 코드를 이렇게 되도록 노력하고 있습니다. “처음에는 힘들고 귀찮지만, 한 번 짜 둔 코드는 유지보수하기 극도로 쉽게.”
확실히 MVC 류의 프로그래밍 패턴이 뛰어난 유연성을 가지고 있고, 유지보수하기 좋은 구조를 가지고 있습니다. 많은 웹 프레임워크들도 MVC, 또는 이에서 파생된 패턴을 사용하고 있습니다.
그런데 이 MVC를 바로 워드프레스 플러그인이나 테마 개발에 사용하려고 하면, 그다지 쉽지 않을 것입니다. 적어도 저는 그랬습니다. 이 부분은 저의 개발 엔진에 있어 가장 중요한 부분이기 때문에, 몇 가지 이유를 들어 그 이유를 자세히 설명해 보고자 합니다.
우선 워드프레스 코어 자체가 이런 패턴을 직접적으로 사용하지 않기 때문에, 좋은 코드 교범을 보기가 힘듭니다.
그리고 다른 웹 프레임워크와는 다른 워드프레스의 특성에서도 기인한다고 생각합니다. 다른 웹 프레임워크들은 사용자가 전달한 request 부터 서버가 도로 보낼 response까지의 작업을 온전히 개발자에게 맡깁니다. 웹 프레임워크들은 그 작업을 보다 편리하게 지원해주는 역할을 맡았죠. 설계도와 지휘봉은 모두 개발자에게 있습니다.
그러나 워드프레스는 그렇지 않습니다. 이미 코어가 request를 받아 response를 대부분 처리하는 상태입니다. 플러그인, 테마 개발자는 코어에 이미 코어 개발자가 만들어 둔 고리, 훅(hook)에 자신의 콜백을 등록하는 방법으로, 즉 이미 완성된 코어를 확장하는 방법으로 개발을 진행합니다. 이것이 워드프레스식 웹 개발입니다.
여기서의 예는 조금 복잡하니, 어려운 분들은 뛰어넘어도 됩니다.
보통 웹 프레임워크는 URL 라우팅 규칙을 설정하고, 그 라우팅 규칙에 따라 하나의 request를 하나의 함수로 대응하는 구조로 되어 있습니다.
여기서 제가 자주 사용하던 웹 프레임워크인 Django를 예를 들면, 장고는 MVC의 변종인 MTV 패턴을 사용합니다. Django의 URL 라우팅은 주로 각 앱의 urls.py 라는 파일에서 정합니다. 아래 코드는 그 예입니다.
from django.conf.urls import url
from . import views
urlpatterns = [
url(r'^$', views.index, name='index'),
]
어떤 도메인의 ‘/’ 경로로 접근한 request는 views.index라는 View 함수가 처리를 합니다.
from django.http import HttpResponse
from .models import Question
def index(request):
latest_question_list = Question.objects.order_by('-pub_date')[:5]
output = ', '.join([q.question_text for q in latest_question_list])
return HttpResponse(output)
index라는 View 쪽 함수 예입니다. 모델을 불러와 request가 원하는 방식으로 자료를 가공하여 response를 만들어내는 것입니다.
워드프레스의 주 진입점은 워드프레스 디렉토리 최상위의 index.php와 wp-admin 디렉토리의 index.php, edit.php, post.php 등등이 있습니다. 일반적인 프론트 화면의 진입점인 최상위의 index.php를 보면 wp-blog-header.php 파일을 읽어들이는 코드가 있습니다.
wp-blog-header.php 에서 WP 클래스의 main() 메소드가 실행됩니다. 이 메인 메소드는 아래처럼 되어 있습니다.
public function main($query_args = '') {
$this->init();
$this->parse_request($query_args);
$this->send_headers();
$this->query_posts();
$this->handle_404();
$this->register_globals();
/**
* Fires once the WordPress environment has been set up.
*
* @since 2.1.0
*
* @param WP &$this Current WordPress environment instance (passed by reference).
*/
do_action_ref_array( 'wp', array( &$this ) );
}
사용자의 request를 받아서 일괄적으로 처리하는 구조입니다. 여기서 우리가 코드를 함부로 변경할 수 없는 대신 action, filter를 사용하여 코어의 동작을 살짝살짝 변경시킵니다.
장고의 MTV라는 컨셉이 플러그인 개발에는 더 적절하다고 생각했습니다. M은 모델(Model)입니다. 데이터를 다루는 영역입니다. T는 템플릿(template)을 의미합니다. 화면을 어떻게 보여줄 지를 결정하는 시각적인 영역입니다. V는 뷰(View)로서 request를 받아 reponse를 생성하는 역할을 맡습니다. 뷰는 모델과 템플릿사이에 위치하며, 모델이 전하는 자료를 요청에 맞게 처리 가공하여 템플릿에게 넘겨주는 역할을 합니다. 템플릿은 뷰가 전해준 자료를 바탕으로 HTML 문서 등을 결과로 찍어냅니다.
물론 MTV 같은 패턴을 워드프레스에 도입할 수 없는 것은 아니지만, 그것이 약간은 껄끄럽습니다. 앞서 이야기하였듯 워드프레스는 타 웹프레임워크처럼 request 부터 자연스럽게 로직을 처리하는 구조가 아니기 때문이라고 생각합니다.
워드프레스 플러그인은 그 특성이 있습니다. 계속 이야기하였듯, 훅과 콜백입니다. 통상의 웹 개발자는 request에 초점을 맞추고 request에 맞춰 response를 작성하는데 온 힘을 기울인다면, 플러그인 개발자들은 코어에서 제공하는 (혹은 타 플러그인이 정의한) 훅에 관심을 두고, 원하는 기능을 작성하기 위해 적절한 훅을 탐색하고, 그 훅에 맞춰 적절한 콜백을 작성하는 데 노력을 기울입니다.
저는 Axis 때무터 이 훅과 콜백에 천착해 왔습니다. 이 훅과 콜백의 특성상 기존의 MVC나 MTV들을 여타 웹 프레임워크 처럼 플러그인에 쓰기 쉽지 않다고 생각하였습니다. 그 대안이 “MTIV“입니다. ‘I’가 하나 추가된 것이죠. 저는 이 ‘I’를 전수자, 또는 이니시에이터(initiator)라고 부릅니다.
전수자의 가장 기본적인 역할은 콜백을 문맥에 맞게 정리하는 것입니다. 그리고 전수자가 잘 정돈한 콜백 함수에서 비로소 MTV의 패턴 도입이 이루어집니다.
보통 어떤 구성 요소(component)들은 적어도 하나 이상의 액션, 필터를 조합하여 이뤄집니다. 그런데 이 액션과 필터들은 “어떤 상황에 대한 대응”을 설정하는 것이지 그 자체로 어떠한 구성 요소를 설명하는 것이 아니라, 차후 유지보수시 기능 분석이 약간 힘든 측면이 있습니다.
예를 들어
add_action( 'a_action', 'my_a_action_callback');
function my_a_action_callback () {
...
}
add_action( 'b_action', 'my_b_action_callback');
function my_b_action_callback () {
...
}
add_action( 'c_action', 'my_c_action_callback');
function my_c_action_callback () {
...
}
...
이런 식으로 평면적인 액션 선언 및 콜백 함수로만 코드를 짜게 된다고 생각해 보세요. 또 구성 요소에 쓰이는 훅들이 겹치지 않으리란 보장이 있나요? 어떤 훅이 어떨 때 쓰이는지 쉽게 추적이 가능할까요?
전수자는 이런 문제를 해결하기 위해 생각해 내었습니다. 한 구성 요소에 필요한 훅과 콜백을 의미 있게 하나의 클래스로 묶어 관리합니다. 훅, 콜백 선언이 한 클래스에 의미 있게 관리되므로 코드 유지보수에 더욱 편리합니다.
물론 전수자를 쓰는 것도, 또 전수자의 콜백에서 MTV를 사용해야 하는 것은 강제 사항이 아닙니다. 예를 들어 워드프레스에서 메일을 보낼 때 본문에 html 코드를 삽입하고 싶다면 아래 같은 코드를 쓰는데, 아무리 봐도 이런 콜백 때문에 뷰를 쓰는 건 닭 잡는 칼에 소 잡는 칼 쓰는 격입니다.
add_filter( 'wp_mail_content_type', 'set_content_type' );
function set_content_type( $content_type ) {
return 'text/html';
}
이럴 때는 그냥 전수자 콜백에서 그냥 처리해도 무방합니다.
또 이미 많은 사람들이 저와 같이 생각을 하고 있고 비슷하게 의미 있는 훅과 콜백을 클래스로 묶거나 적절히 모듈화 하는 것으로 알고 있습니다. 그것과 전수자는 거의 동일합니다. 그러나 제가 생각하는 전수자 개념의 핵심은 “모듈화”만을 위한 것이 아닙니다. 워드프레스 플러그인 구조에서 원할 때 제대로 MTV를 사용할 수 있도록 길을 연다는 점, 이것이 중요합니다.
제 경험에 미루어 보면 MTV 패턴은 플러그인 개발자가 원한다면 어떻게든 구현하여 사용할 수 있는 부분인 것 같더군요. 그러나 구현을 하게 되면 도대체 어디에서부터 뷰를 생성하고 그 로직을 전개할지 난감해질 때가 있었습니다. 모든 콜백에 대해 ‘뷰’라는 패턴을 가진 객체를 생성해야만 할까요? 애초에 훅, 콜백과 뷰는 잘 어울릴 수 있는 구조인걸까요? 설령 가능하다면 어떻게 뷰를 정돈된 형태로 유지할 수 있을까요?
다행히 MTIV 구조에서는 전수자가 가장 먼저 기능별로 훅과 콜백을 정리해 두고 있습니다. 그 콜백을 처리하는 것이 뷰이기 때문에, 자연스럽게 뷰의 생김새도 전수자의 파일 구성을 따라 갑니다. 그래서 기능별로 만들어진 전수자 파일 구조 및 코드를 따라가면 자연스럽게 해당 심화 로직인 뷰 코드를 추적할 수 있습니다. 코드의 흐름을 쫓아가기 매우 쉬우며, 따라서 유지보수도 어렵지 않게 될 수 있습니다.
아주 간단한 전수자 예제 인터페이스 코드를 작성해 보았습니다.
interface Initiator
{
public function init_hooks($main);
}
$main으로는 플러그인 메인 파일이 입력됩니다. 훅 작성시 때때로 저 메인 파일이 필요하거든요.
플러그인 활성화 때 어떤 역할(role)을 생성해야 한다고 가정합니다. 그러면 이 때 필요한 전수자를 작성한다면
class Roles_Caps implements Initiator {
public function init_hooks( $main = '' ) {
register_activation_hook( $main, array( $this, 'callback_activation_hook' ) );
register_deactivation_hook( $main, array( $this, 'callback_deactivation_hook' ) );
}
public function callback_activation_hook() {
$this->add_role();
}
public function callback_deactivation_hook() {
$this->remove_role();
}
private function add_role() {
add_role(...);
}
private function remove_role() {
remove_role(...);
}
// (이하생략)
}
이렇게 클래스를 작성하고, 메인 파일에서는
$initiator = new Roles_Caps(); $initiator->init_hooks(__FILE__);
처럼 실행할 수 있습니다.
보다 뷰와 템플릿 로직이 강화되어야 하는 경우를 생각해 봅시다. 아주 간단히 전수자 클래스의 내부 코드를 이렇게 작성할 수 있습니다.
class Menu_Initiator implements Initiator {
public function init_hooks($main = '') {
$this->view = new Menu_View();
add_action('admin_menu', array($this, 'callback_admin_menu'));
...
}
public function callback_admin_menu()
{
add_menu_page('title', 'title', 'manage_options', array($this, 'dispatch'));
}
}
뷰 코드를 간단하게 설명하자면 이렇습니다.
class Menu_View {
public function dispatch() {
$context = array(
'title' => 'Hello!';
...
);
...
render('menu.php', $context);
}
}
menu.php 는 템플릿 파일입니다. 콘텍스트에 따라 내용을 찍어냅니다.
<div class="wrapper"> ... <h2><?php echo esc_html($title); ?></h2> ... </div>
이렇게 전수자부터 그 틀을 잡고 시작하면 이 이후의 MTV는 보다 형태를 잡기 쉬워집니다.
이밖에도 전수자만이 가진 독특한 기능들이 있습니다. 이걸 설명하고 싶어 손이 근질거리만, 분량이 너무 많아지니 다음 포스팅으로 미루도록 할께요.
이제는 이런 개발 프레임워크가 더 등장할지 모르겠지만, 개발을 위한 프레임워크가 또다른 형태의 플러그인으로 제공되는 것이 있습니다. Piklist나 Genesis 같은 것들이 그 예입니다.
저의 플러그인 엔진은 사이트 동작을 위해 반드시 필요하고, 운영시 절대 비활성화 되어서는 안 되는 경우가 대부분이라 기본적으로는 엔진은 MU Plugin 형태로 동작되기를 권장합니다. 그러나 MU 플러그인이나 일반 플러그인이나 큰 차이가 없기 때문에 제작 자체는 일반 플러그인처럼 하고 있습니다.
그러나 개발 엔진 같은 라이브러리 같은 코드들을 플러그인으로 제공하게 되면 버전 충돌 문제를 피할 수 없습니다.
가령 제 플러그인 엔진이 굉장히 유명해져서 많이 사용된다는… 아주 즐거운 가정을 해 보자구요. A 플러그인은 제 엔진 1.8 버전을 사용합니다. B 플러그인은 제 엔진 2.0 버전을 사용한다고 해요. 그런데 1.8과 2.0버전은 엄청난 차이가 있어서 이 둘을 같이 사용할 수 없어요. 1.8 방식으로 코드를 쓰면 2.0에서는 오류를 뿜어내고, 그 반대로도 마찬가지입니다. 이 사이트는 A, B 플러그인을 둘 다 필요로 하는데… 어쩌죠?
이런 경우에 엔진은 서드파티 라이브러리처럼 쓸 수 있도록 할 것입니다. 해당 플러그인이 각 버전의 플러그인을 충돌하지 않도록 각자 독자적인 라이브러리로 내장할 수 도 있게 만들어 저의 엔진을 사용할 수 있도록 만들 것입니다.
개발에 관해 심각하게 글을 쓰려고 한 건 아닌데… 내용이 많이 길어집니다. 저도 가볍게 제 플러그인 엔진에 대한 컨셉을 정리하고, 기왕 정리한 거 여럿에게 보여 주는 것이 어떨까 싶었습니다. 딱딱하고 지루하게 컨셉을 쓰다 보면 아예 글을 작성할 수 없게 될 것만 같아 설렁설렁 대충대충 블로그 포스팅으로 남깁니다. 플러그인 엔진 버전이 거듭되어 제련되듯, 이러한 설명 자료들도 차차 탄탄하게 기록되었으면 좋겠습니다.
본 포스트는 UI 디자인 등에 대한 전문적인 의견이 아니라, 워드프레스 관리자 화면이 어색하다는 사람들을 설득하기위해 써 본 글임을 알려 드립니다. 올바르지 못한 점이 있다면 피드백 부탁드립니다.
처음 쓰는 툴이니 어색한 것은 당연하겠지만, 워드프레스를 초심자들은 많은 부분들을 어색해합니다. 그 중은 상당히 오랜 기간 학습을 필요로 하지요. 그 중 대표적인 하나로 “관리자 화면”을 들 수 있습니다.
대부분의 초심자들은 관리자 화면에 익숙해지기까지 상당한 인내심을 지불합니다. 약간 과정하면, 마치 웅녀가 곰에서 사람이 되기 위해 동굴에서 쑥과 마늘 먹으며 괴로움을 참아야 했던 것처럼요. 그 괴로움을 끝까지 참아내기 어려운 경우도 많고, “도대체 왜 도구 때문에 내가 바뀌어야 하는가?”라고 생각할 수도 있습니다. 참지 못한 몇몇 ‘호랑이’들은 참지 못하고 다른 CMS로 갈아탈 것이고, 이 분들 중에는 결국 워드프레스에 강한 거부감을 보일 수도 있을 것입니다.
반면 잘 적응한 사람들은 대부분 워드프레스 관리자 화면은 합리적이고 쓰기 편하다고 합니다. 아무리 적응하기 나름이라고는 하나, 단순히 적응도 때문에 불편함과 편함이 생기는 것은 아닐 겁니다. 그러면 과연 무엇 때문에 어떤 이들은 불편하다고 느끼고, 어떤 이들은 편하다고 생각하는 걸까요?
우선 워드프레스의 관리자 화면이 어색하고 불편하다면, 친숙하고 편한 스타일의 관리자 스타일이 존재할 것입니다. 그것을 무엇이라 칭하기 어렵지만 “기존 스타일”이라고 뭉뚱그려 표현해 보고자 합니다. 네, 우리 한국 사람에게 익숙한 문법과 문맥을 가진 바로 그 스타일입니다. 이 문법과 문맥을 거칠게나마 특성을 몇가지 나열해 보지요.
반면 워드프레스 관리자 화면을 보면 “~관리”라든지, “~설정”이라는 레이블을 찾을 수 없습니다. 특별한 플러그인을 설치하지 않은 이상은 말이죠. 그냥 알림판, 글, 미디어, 페이지, 댓글, 외모, 플러그인, 사용자, 도구, 설정 (아!), … 이렇게만 있을 뿐입니다.
워드프레스 메뉴들은 우리한테 뭔가 “관리”하라거나, “설정”하라는 요구를 하지 않습니다. 아마 기존의 스타일을 고수하셨던 분들은 여기서 혼란스러움을 느낄 수 있을 겁니다.
사실 “관리”나 “설정”이라는 말이 없다는 것만으로는 어색함을 극복하기는 어렵습니다. 기존 스타일과 워드프레스 스타일, 그 작은 차이를 이해한 것 가지고는 워드프레스식의 관리자 스타일을 납득하기란 어렵습니다. 그냥 관리, 설정 식으로 메뉴를 꾸며 주면 안되나요? 좋은 게 좋은 거고, 편한 게 편한 거 아닌가요?
그러나 그렇지 않습니다. 제가 이해한 바로는 이렇습니다. 기존의 스타일이 가진 ~~관리, ~~설정 같은 메뉴 구성은 그다지 좋은 메뉴 구성이 아닙니다. 저는 앞으로는 그런 스타일은 버리시기를 강력히 권하는 입장입니다. 앞으로의 글은 왜 기존의 스타일이 나쁜지, 그리고 왜 워드프레스 스타일이 권장할만한지에 대해 나열할 생각입니다. 만일 기존의 방법에서 더 이동할 생각이 없으시다면 이제 이 글을 그만 읽으셔도 됩니다.
관리자 화면 자체가 “관리(administration)”을 하기 위해 들어오는 장소입니다. 그런데 그 메뉴 하나하나에 죄다 그놈의 관리가 붙어야 하는 이유는 대체 뭔가요? 요즘은 데스크탑 뿐만 아니라 모바일 등등 여러 기기에서 웹에 접근합니다. 작은 화면에서는 집약된 정보가 중요합니다. 관리자 화면에서 관리라는 단어를 쓰는 것은 낭비입니다.
콘텐츠 관리 시스템(Contents Management System, CMS)에서 가장 중요한 것은 콘텐츠입니다. 그리고 콘텐츠가 존재해야 콘텐츠의 관리가 거론될 수 있는 법이죠. 그러나 기존 스타일은 콘텐츠가 무엇인지 명확히 알 수도 없는 상황에서 관리 내지 설정을 이야기합니다. 제가 기존의 스타일을 나쁘다고 말하는 이유 중 가장 주된 이유입니다.
사용자가 우선 관리자 메뉴에서 익숙해져야 하는 것은 무엇인가요? 관리 메뉴를 습득하는 것? CMS에서 가장 중요한 것은 다름아닌 콘텐츠입니다. 관리자는 자신이 관리하는 콘텐츠를 먼저 잘 파악해야 합니다. 그 다음에 그 콘텐츠를 어떻게 관리할까 하는 문제가 생기겠죠. 그러나 기존의 시스템은 다짜고짜 관리부터 하려 듭니다. 사용자가 그 관리 대상이 무엇인지 파악하지 못한 상태에서도요. 제 관점에서는 그런 메뉴들이 오히려 달갑지 않습니다.
CMS의 본질은 콘텐츠라고 반복하여 말씀드리고 있습니다. 먼저 콘텐츠라는 “모델”이 정의되어야 합니다. 그리고 나서 그 “모델”을 어떻게 처리해야 할지에 대한 “액션”을 논할 수 있습니다. 물론 거의 모든 경우 이 모델과 모델에 대한 행위는 붙어 있기 때문에 그 개념을 다 포괄하여 생각하는 경우가 많습니다만, 문법에서 명사와 동사가 다른 것처럼 모델과 액션은 엄연히 다른 개념입니다.
기존의 스타일이 나쁘다고 하는 이유를 모델과 액션, 혹은 명사와 동사의 측면으로 바꾸어 다시 강조해 볼까요? 행위는 행위의 대상이 존재해야 그 의의가 있습니다. 모델이 명확하게 인지되지 않은 상태에서 액션을 취하면, 그 액션은 올바르지 못할 때도 있습니다.
메뉴 설계적인 측면에서도 액션 위주의 메뉴는 비합리성을 가지기 쉽습니다. 행위는 행위의 대상인 모델이 존재해야 그 의의가 있습니다. 그리고 만일 모델의 구조가 변화하면 행위에도 영향을 끼칠 수 있습니다. 설계적으로 보면 행위는 모델에 종속되어 있는 셈입니다.
예를 들어 “A 관리”라는 메뉴를 만들었다고 생각해 보죠. 그리고 A 관리 메뉴의 실대상인 A 모델은 꽤나 복잡하기 때문에 B 모델 또한 같이 생각하여 “관리”되어야 합니다. 그러나 B 모델은 상대적으로 복잡하지 않습니다. 그래서 암시적으로 A관리 메뉴에서만 B 모델이 보이도록, 즉 관리되도록 설계됩니다.
그런데 말이죠, 프로젝트가 진행되다가 “C 관리”라는 메뉴를 또 추가되어야만 상황이 생겼다고 보죠. 그런데 대상이 되는 C 모델 또한 B 모델을 포함합니다. 자, 그러면 C 관리 메뉴에서도 B 모델에 대한 관리가 들어가야 하나요? 그러면 메뉴가 중복되겠죠? 그렇지만 C 메뉴도 B 모델을 처리하는 부분이 있는데…? 어떡하죠?
앞으로 이런 식으로 개발하면서 “행동”에 대한 요구는 점점 늘어갈 것입니다. 그러면 이 행동에 대한 메뉴를 만들어 나가게 되면 메뉴는 자연스럽게 복잡해집니다. 그리고 이 복잡함을 감추기 위해 “위계질서”를 도입합니다. 메뉴가 깊어지겠죠. 그러나 동족방뇨입니다. 당장은 깔끔해 보일지는 모르지만, 나중에는 원하는 메뉴가 어디에 붙어 있는지 찾기 어려울 정도로 복잡해지는 경우가 생깁니다.
물론 위 경우 사용자의 편의를 위해 A, C 메뉴 둘 다 B 모델을 편집할 수 있는 UI를 주는 것도 나쁘지는 않습니다. 그러나 B 모델이 간단해서 망정이지, B 모델 또한 상당히 복잡한 구조였다면 개발자도 괴롭고, 쓰는 사람도 괴로울 것입니다. (여기 예에서는 “B 관리 페이지를 넣어!”라고 하시겠죠? 그게 제가 의도한 바입니다. 단, 그놈의 “관리”라는 접미사는 좀 빼 주는 게 어떨까요?)
제 나름대로의 생각으로는 대기업 홈페이지나 금융권들의 메뉴가 쓸데없이 어려운 이유에도 이런 이유가 있다고 생각합니다. 아, 물론 그들의 업무 범위는 상상외로 크기 때문에 그것만으로도 머리가 터질 만큼 복잡한 게 사실입니다. 그러나 애초에 복잡한 것을 더 복잡하게 만드는 이유 중 얼추 이러한 요소도 있을 것이라는 개인적인 짐작입니다.
대개의 콘텐츠는 CRUD (Creation: 생성, Retrieval: 검색, Update: 수정, Deletion: 삭제) 이 네 가지 동작을 기본으로 합니다. 복잡한 동작도 알고 보면 이 4가지의 연장선이죠. 그런데 이 단순한 행위가 모델에 따라 여러 동선을 만들어낼 수 있습니다. 그러니 동선을 먼저 생각하기 전에 모델부터 생각해야 하는 것이 맞는 것이 아닐까요?
워드프레스의 관리자 화면이 심플하면서 직관적이라는 이유는 바로 이런 이유입니다. 메뉴는 행위에 초점을 맞추어 구성되어 있지 않습니다. 관리하고자 하는 콘텐츠에 보다 초점이 되어 있죠. 여러분이 어떤 플러그인을 설치해서 새로운 콘텐츠 형태를 추가한다 하더라도 이는 거의 변하지 않습니다.
예를 들어 Gravity Form을 설치하면 Form이라는 명사형의 메뉴가 등장하지, “Manage Form” 같은 동사형의 메뉴가 등장하지 않습니다. 우커머스 플러그인을 설치해도 마찬가지입니다. 상품, 주문 같은 명사형의 메뉴가 생깁니다. 설정 메뉴의 하위 메뉴도 마찬가지입니다. 대개 명사형의 하위 메뉴가 있죠. 그 메뉴에 들어가서야 비로소 추가, 수정, 삭제, 검색 등의 행동을 담은 페이지가 나오죠.
이제 워드프레스의 메뉴에 익숙해진 분들이 직관적이고 편하다는 이유가 무엇인지 이해하실 수 있으신가요? 이 분들은 “행동”을 먼저 생각하는 것이 아니라 관리하는 “모델”에 더 초점을 맞추고 메뉴를 보기 때문에 메뉴가 더 쉬운 것입니다. 이 관점에서 메뉴를 구성하면 그다지 메뉴가 깊어질 이유도 없습니다.
물론 우커머스 같은 상당히 복잡한 데이터를 다루는 플러그인은 실제로 메뉴가 많이 복잡합니다. 그러나 이런 복잡성이 좌측 주 메뉴에까지 슬슬 기어나온다면, 그건 문제겠죠. 위 그림처럼 워드프레스 관리자에서도 탭이라든지, 매니지 영역 등등을 사용해 더 깊은 메뉴를 처리할 수 있도록 하고 있습니다.
여기까지 읽어주셔서 감사합니다. ‘신문물’이란 게 대개 그렇습니다 . 새로운 것을 받아 들이려면, 기존의 것과 상충되는 것은 극복해야 합니다. 처음은 괴롭지만, 더 나은 방법임은 우리는 알고 있습니다. 애초에 그것을 더 낫게 하기 위해 도입하는 것이거든요. 물론 기존의 관성이 만만찮게 강력하기 때문에 변하는 것은 쉽지 않습니다.
그러나 본질을 놓치지는 말자구요. “왜 변해야 하는가?”, “이것을 변화하면 무엇이 나아지는거?”를 잘 이해하면 그 변화를 더 잘 받아들일 수 있습니다. “워드프레스의 관리자는 왜 그 모양새를 가지고 있는가?”를 더 이해하면 보다 워드프레스를 친숙하게 받아들일 수 있을 것 같아 글을 써 보았습니다. 전문적인 UI 디자이너의 의견이 아니라 틀린 점도 많고, 제가 제대로 이해하지 못한 점이 많을 것입니다. 틀린 점이 있다면 댓글로 피드백을 부탁드립니다.
개발 의도상 테마를 별도의 디렉토리에 두고 싶은 생각이 들었다. 플러그인을 놓고 쓰는 것처럼 말이다. 그런데 wp-config.php 코덱스를 참고해도 플러그인의 경로를 바꾸는 일은 허용되나, 테마에 대해서는 이런 설정이 공식적으로는 존재하지 않는다. 테마를 별도로 쓰려면, wp-contents 디렉토리를 벗어나지 않는 한에서 변경하기를 권장하기도 한다.
사실 실사용 서버에 이런 일을 할 필요는 없다. 단지 개발 서버상에서만 편하자고 하는 일이다.
나는 코어와 플러그인의 디렉토리를 분리해서 사용한다. 이렇게 해서 여러 사이트에 대해 개발을 할 때 단 한 벌의 코어로 대응할 수 있다. 이렇게 사용하는 법은 다른 포스트를 통해 소개한 바 있다.
테마 디렉토리는 플러그인과 같은 레벨에 둔다고 가정한다. 그리고 MU 플러그인을 하나 만들고 거기에 그냥 다음과 같이 적으면 된다.
register_theme_directory( dirname(__DIR__) . '/themes' );
이렇게 하면 이동한 테마 디렉토리에 있는 테마 목록이 워드프레스 ‘외모’메뉴에서 보이게 된다.
그런데 이렇게만 하면 문제가 발생한다. 왜냐하면 이 시점에서 정적 자원들을 웹서버로 접근할 때의 URL이 정해지지 않았기 때문이다. 테마가 나오지만, 이미지나 자바스크립트는 404 에러를 내면서 죽을 것이다. 당연히 웹서버에 현재 /themes 디렉토리에 대해 URL로 접근할 수 있도록 처리해야 한다. 플러그인의 WP_PLUGIN_DIR과 WP_PLUGIN_URL 설정이 두 개로 나뉘어져 있는 것과 동일한 이치다.
이 때는 아래와 같은 필터를 통해 해결할 수 있다.
add_filter( 'theme_root_uri', function( $theme_root_uri, $site_url, $stylesheet_or_template ) {
$theme_root_path = dirname( __DIR__ );
if( strpos( $theme_root_uri, $theme_root_path ) === 0 ) {
return substr( $theme_root_uri, strlen( $theme_root_path ) );
}
return $theme_root_uri;
}, 10, 3 );
합쳐진 MU 플러그인의 레시피는 아래와 같다. 단, 완벽한 동작을 보장할 수 없으니 개발용으로만 참고하시라.
<?php
add_filter( 'theme_root_uri', function( $theme_root_uri, $site_url, $stylesheet_or_template ) {
$theme_root_path = dirname( __DIR__ );
if( strpos( $theme_root_uri, $theme_root_path ) === 0 ) {
return substr( $theme_root_uri, strlen( $theme_root_path ) );
}
return $theme_root_uri;
}, 10, 3 );
register_theme_directory( dirname(__DIR__) . '/themes' );
User Role Editor 보다 더욱 세밀한 권한 체크를 진행시킬 수 있는 레시피. ‘user_has_cap’ 필터를 잘 활용하면 된다.
좀 더 구체적인 예로 설명을 하자. 만일 내가 포스트 아이디 1141번을 임시 글로 등록해 두었다고 가정하자. 그리고 단지 이 포스트에 대해서만은 editor들은 편집을 허용하지 않게 만들고 싶다. 그렇다면 다음처럼 코드르 만들 수 있다. 커스텀 포스트 타입은 ‘music_collection’이고 적절히 이에 따라 권한 세트를 생성했다.
add_filter( 'user_has_cap', 'my_user_has_cap', 10, 4 );
function my_user_has_cap( $all_caps, $caps, $args, \WP_User $user ) {
if ( sizeof( $caps ) && in_array( $caps[0], array( 'edit_music_collections', 'edit_others_music_collections' ) ) ) {
if ( sizeof( $args ) >= 3 && $args[2] == 1141 ) {
if ( $user->has_cap( 'editor' ) ) {
unset( $all_caps[ $caps[0] ] );
}
}
}
return $all_caps;
}
콜백 함수는 4개의 인자를 가지고 있으며, 이 인자의 확인이 은근히 복잡하다. 디버깅 및 설명의 편의를 위해 하나의 if로 처리하지 않고 3개의 if로 잘라 넣었다. 실전 코드에서는 당연히 하나로 붙이도록 하자.
첫번째 if는 현재 요구되는 primitive 권한을 체크한다. 어떤 커스텀 포스트에서 요구하는 권한이 내가 제어하고 싶은 범위의 것인지를 검사한다.
두번째 if는 특정 단일 포스트에 대한 권한 요구인지, 아니면 전반적인 복수의 포스트에 대한 요구인지를 체크한다. args에 인자로 0번째는 매핑되기 전의 권한 템플릿 이름, 1번째는 유저의 ID, 2번째로 post의 ID가 있다. 이 부분이 매우 중요하다. 단일 포스트의 권한 검사이므로 args 길이는 3이상이어야 한다.
세번째 if에서 다시 사용자의 권한 체크를 한다. 지금 권한 체크에 대한 콜백 함수인데, 다시 권한 체크를 재귀적으로 부르고 있다. 권한 필터링을 실제 구현하는 것이 은근히 쉽지 않음을 짐작할 수 있다. 물론 익숙해지면 이야기는 다르겠지만, 주 역할과 메타 역할의 개념 등등을 잘 이해하지 못하면 이 권한 체크에 번번히 실패할 가능성이 높다. 재귀 함수의 오버헤드를 줄이려면 바로 $user->caps 를 활용할 수도 있다.
이렇게 설정하면, edtor들은 1141번 포스트에 대해 다음과 같은 화면을 만나게 된다.
글에는 두 가지 draft가 있다. 첫번째 draft는 편집이 가능하지만, 두번째 draft는 접근이 막혀 있다. 이렇게 단일 포스트 단위로 접근을 제어하는 방법은 우리가 흔히 접할 수 있는 user role editor로도 쉽게 구현하기 어려운 기능이다. 게다가 코어의 자연스러운 접근 권한 체크를 하기 때문에 엉뚱한 곳에서 적당히 땜빵 코드로 접근을 막는 것보다 더욱 확실하고 자연스러운 제어가 가능하다. 스크린샷으로도 보이듯 접근 제어가 안 되는 항목은 확실하게 UI적으로도 막혀 있는 것이 보인다. 이렇게 구현하면 예상치 못한 URL로 접근하더라도 코어가 확실히 접근을 차단해 줌을 기대할 수 있는 것이다.
물론 보통은 커스텀 포스트에 이 정도로 세밀한 접근 제어 기능을 구현하지는 않으나, 이와 유사한 요구 사항은 실무에서 많이 발생할 수 있을 것이라 생각한다. 이걸 자유자재로 사용할 수 있다면 정말 훌륭한 플러그인 구현이 되리라 생각한다.
워드프레스의 역할과 권한은 잘 이해하는 사람도 흔치 않을 것 같다 코드가 지저분하든 더럽든 어쨌든 간에, 나는 워드프레스가 훌륭한 CMS라고 생각하며 그 근거 중의 하나로 이 강력하고 유연한 역할과 권한 시스템을 든다. 이걸 사용자가 쉽고 간편하게 쓸 수 있는 UI가 없는 것은 아쉽지만 (아니, 그런 UI를 쉽게 사용하게 만드는 것 자체가 미친 난이도지만) 이러한 시스템이 기저에 있다는 것 자체가 놀라움이다.
덧글 ) 권한 체크는 상당히 어렵다. 비활성화된 항목에 마우스를 가져다 대어 보자.
어이쿠, 이게 뭔가. Trash? 편집은 못하지만 지울 수는 있다. 편집자 역할은 휴지통에 있는 글도 영구 삭제 가능하다. 물론 같은 스태프끼리 그럴 일은 없겠지만… 아, 권한 체크는 세심해야 함을 강조한다. 해당 권한 목록을 꼼꼼하게 살펴서 이런 구멍이 없도록 잘 대비하기를 권한다.
add_filter( 'screen_layout_columns', function ( $columns ) {
$screen = get_current_screen();
$columns[ $screen->id ] = 1;
return $columns;
} );
add_filter( 'get_user_option_screen_layout_kpm_paper', function ( $value ) {
return 1;
} );
add_action( 'in_admin_header', function () {
$screen = get_current_screen();
if ( $screen->id == 'kpm_paper' ) {
$screen->remove_option( 'layout_columns' );
}
} );
커스텀 포스트에 활용할 수 있다.
팁이라고 하기는 너무 거창하고… 현재의 내 상태를 기록해 두는 뜻으로 포스팅을 해 봅니다. 워드프레스를 개발할 때 즐겨 사용하는 세팅을 기록합니다. 고도로 숙련된 세팅이라고 할 수는 없으니, 저 아닌 다른 분들은 “아, 얘는 이런 식으로 쓰는 구나” 하고 참고만 해 두셨으면 합니다.
OS는 리눅스 민트를 사용합니다. 리눅스 중에서는 가장 대중적이고, 무탈하고 쓰기 편합니다. 여러 리눅스 OS를 거쳐가며 삽질을 해 봤지만, 초기 부팅 및 설치 후 사용성까지 생각하면 민트를 따라잡을 OS는 없다고 개인적으로 생각합니다.
윈도우 10이 리눅스 서브시스템을 지원하고, 윈도우에서 apt나 bash를 실행시킬 수 있도록 많이 변화하기는 했지만, 아직 안정적이라고 볼 수 있는 단계는 아닙니다. 개인적으로 윈도우는 게임을 할 때 사용하는 OS로 굳어져 있습니다.
물론 맥OS도 좋은 개발 환경을 제공합니다만, 리눅스를 택하는 이유는 강력한 패키지 매니저 때문이죠. apt로 엄청나게 빠르고 편하게 패키지 설치를 할 수 있습니다. 개발 환경은 이렇게 무난하게 꾸미는 것이 최선이라고 생각합니다.
한때는 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 버전을 설치할 수도 있습니다. 소스 컴파일 설치는 별로 선호하지 않습니다.
에디터로 Atom이나 Sublime Text도 선호되고 있지만, 저는 IDE는 PhpStorm을 사용하고 있습니다. 몇 년째 사용 중인 훌륭한 IDE입니다. 제게는 다른 대안이 없습니다.
플러그인을 몇 번 제작해 보니 경로를 조직적으로 구성하는 편이 효율적으로 보였습니다. 그래서 머리를 굴려 나름 레이아웃을 구상해 보았습니다.
기본적인 경로는 이렇게 되어 있습니다. .php, .dist 확장자를 제외한 항목은 모두 디렉토리입니다.
. ├── apache2 ├── bin ├── db-conf.php ├── db-conf.php.dist ├── niu-plugins ├── plugins ├── scripts ├── wp-config.php ├── wp-core └── wp-settings
각 워드프레스 환경은 아파치의 가상호스트로 구분합니다. 각 호스트는 apache2 디렉토리 안에 .conf 파일을 두어 설정합니다. 이 설청 파일을, /etc/apache2/sites-available에 심볼릭 링크를 걸고, a2ensite로 활성화 시켜 줍니다. 아래 코드는 예입니다.
ln -s ./apache2/wordpress-vhosts.conf /etc/apache2/site-available sudo a2ensite wordpress-vhosts.conf
이렇게 하면 본래 wordpress-vhosts.conf는 내 계정 소유의 파일이기 때문에 일일이 관리자 권한 없이도 편집이 가능하죠.
wordpress-vhosts.conf 파일은 비교적 단순하게 구성하면 됩니다. 예입니다.
Alias /plugins <path-to-root>/plugins
<Directory "<path-to-root>">
Require all granted
Options +FollowSymlinks -Indexes
AllowOverride All
php_admin_value open_basedir "<path-to-root>"
</Directory>
#####################################################################
<VirtualHost *:80>
ServerAdmin <email>
DocumentRoot <path-to-root>/wp-core/4.7.1
ServerName wp.4.7.1
ServerAlias wp.latest
ErrorLog ${APACHE_LOG_DIR}/wp.4.7-error.log
CustomLog ${APACHE_LOG_DIR}/wp.4.7-access.log combined
</VirtualHost>
#####################################################################
<VirtualHost *:80>
ServerAdmin <email>
DocumentRoot <path-to-root>/wp-core/4.6.2
ServerName wp.4.6.2
ErrorLog ${APACHE_LOG_DIR}/wp.4.6.2-error.log
CustomLog ${APACHE_LOG_DIR}/wp.4.6.2-access.log combined
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
이후 다시 설명하겠지만, 위 코드는 워드프레스를 버전별로 수동 관리하는 케이스입니다. 각 버전별로 “http://wp.<버전 번호>/” URL로 접근하도록 처리했습니다.
wp-cli와 phpunit 같은 바이너리 파일을 여기에 두었습니다. wp-cli는 사용할 때마다 헷갈립니다만, 가끔씩 워드프레스 동작을 스크립트화 해 두기에는 좋을 겁니다.
디렉토리 중 mu-plugin (must-use plugin)이라고 해서, 항상 사용하는 플러그인을 넣어 두는 곳이 있습니다. 그걸 따서 niu-plugin (not-in-use plugin) 디렉토리를 별도로 만들었습니다. 큰 의미는 없고 잠시 사용하지 않을 플러그인을 이 쪽에 놓아 둘 목적으로 만든 것입니다. 활성/비활성 차원이 아니라 아예 존재를 이 쪽으로 옮겨 두는 거죠.
플러그인만 이 곳에 놓아둡니다. 모든 워드프레스 개발 사이트는 이 플러그인을 공유합니다. 활성/비활성으로 적절히 조절하면 되니까 이렇게 몽땅 놔두는 것도 큰 문제가 없습니다.
wp-cli를 위한 bash-completion 스크립트나 유용한 쉘 스크립트들을 저장하기 위한 디렉토리입니다.
워드프레스의 코어가 여기 있습니다. 코어를 관리하는 방법은 크케 나눠 두 가지가 있습니다.
코어 버전이 업데이트될 때 종종 데이터베이스도 업데이트됩니다. 큰 변화는 별로 없지만, 그래도 테이블이 한 번 업데이트되면 되돌리기 어렵습니다. 개인적으로는 예전에는 단순한 까닭에 1번 방식을 썼는데, 버전별 차이에도 좀 대응하고 싶어 이제는 손이 좀 더 가더라도 2번을 쓰려고 합니다.
도메인별 워드프레스 설정을 놓아두는 디렉토리입니다.
wp-config.php 파일은 워드프레스 코어에 있어도 되지만, 보안상 코어 하나 위 디렉토리에 두어도 무방하도록 되어 있습니다. 여러 사이트가 특별히 각자의 세팅을 가질 필요 또한 크지 않으므로 wp-core의 상위 디렉토리에 wp-config.php 파일을 위치시켰습니다.
만약 버전별로 코어를 관리하는 경우, wp-core 하위에 각 버전별 코어가 위치하므로 wp-congif.php가 1계층이 아닌 2계층 차이가 납니다. 이 때에는 wp-core 디렉토리에 wp-config.php의 심볼릭 링크를 설정해 주면 됩니다.
서버 도메인인 $server_name 변수와 세팅 디렉토리를 얻는 코드를 둡니다.
$server_name = $_SERVER['SERVER_NAME'];
$setting_path = __DIR__ . "/wp-settings/{$server_name}.php";
설정 파일에서 중요한 것은 공통의 플러그인 경로를 지정하는 것입니다. 그러므로 다음과 같은 플러그인 설정을 넣습니다.
define('WP_PLUGIN_DIR', __DIR__ . '/plugins');
define('WP_PLUGIN_URL', "http://{$server_name}/plugins");
개발 환경이므로, 디버깅은 항상 켜 둡니다. 단, 디버깅 용 로그를 웹브라우저로 띄우면 화면이 매우 지저분해지므로 로그로만 볼 수 있도록 만듭니다. wp-content 디렉토리는 기본적으로는 각 코어별로 사용하도록 두었으므로 로그 파일은 각 <코어>/wp-content/debug.log가 됩니다. 스크립트 디버깅도 켜 둡니다.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', true);
포스트 리비전이나 업데이트 관련 사항을 세팅해 두면 됩니다. 코어를 수동으로 관리한다면 자동 업데이트 항목도 꺼 두어야 할 것입니다.
define('WP_POST_REVISIONS', 0);
define('AUTOMATIC_UPDATER_DISABLED', true);
define('WP_AUTO_UPDATE_CORE', false );
이렇게 해도 워드프레스 코어를 업데이트하라는 알림이 관리자 화면에 출력될 수 있습니다. 워드프레스 업데이트를 완전히 꺼 두는 플러그인이 있습니다. 이런 플러그인을 활용해 혹시 실수라도 업데이트를 진행하지 않도록 처리하면 좋겠죠.
도메인별로 다른 데이터베이스 테이블을 관리할 수도 있고, 또 모든 도메인이 같은 테이블을 공유할 수도 있습니다. 그러나 버전별로 워드프레스를 관리하려면 반드시 버전별로 다른 테이블을 사용해야 합니다. 앞서 말씀드렸듯 워드프레스 버전마다 데이터베이스 버전도 달라자기 때문입니다.
버전별로 워드프레스를 관리하기 위해 다음과 같은 도메인 규칙을 만들었습니다.
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)는 사실 같은 존재라는 걸. 워드프레스는 미리 시나리오를 다 짜놓고 필요한 구간에 ‘훅’ 이란 것을 걸 수 있도록 장치했다. 이 훅에 대한 콜백 함수를 편리하게 쓸 수 있도로 만든 장치가 액션과 필터이다. 다시 말하지만 액션과 필터는 같은 콜백 함수이며, 단 하나의 차이점은 액션은 리턴이 없고, 필터는 값을 리턴한다는 점 뿐이다.
웹 프레임워크들은 모든 기능들을 블록처럼 만들어 놓고 개발자가 의도에 맞게 그 모든 블록을 완전히 구현시켜 쌓아가는 방식이다. 반면 워드프레스는 이미 워드프레스 코어라는 완성품을 만들어 놓은 상태이다. 단, 그 코어에는 아주 많은 ‘구멍’을 뚫어 놓았다. 플러그인이나 테마는 그 구멍에 맞춰 적절히 콜백 함수를 끼워 넣는다. 이미 완성된 덩어리에 개발자가 자기 의도대로 부가 확장하는 방식이다.
기존 혹 관련 API는 wp-includes/plugin.php 파일에 있으며, 4.7 버전에도 변함없이 존재한다. 단 WP_Hook이 있으므로 직접 $wp_filter를 조작하는 코드 일부를 WP_Hook에 넘겨 주었다. 이를 테면, 4.6 버전에서는 add_filter 함수의 구현은 이렇게 되어 있다.
function add_filter( $tag, $function_to_add, $priority = 10, $accepted_args = 1 ) {
global $wp_filter, $merged_filters;
$idx = _wp_filter_build_unique_id($tag, $function_to_add, $priority);
$wp_filter[$tag][$priority][$idx] = array('function' => $function_to_add, 'accepted_args' => $accepted_args);
unset( $merged_filters[ $tag ] );
return true;
}
함수 내부에서 $wp_filter에 훅 이름($tag)과 우선순위($priority)에 맞춰 콜백이 등록된다. array가 잔뜩 들어간 지저분한 구현이고, 개인적으로 PHP의 array는 정말 이상한 물건이라 생각하지만, 아무튼 그렇다. $wp_filter는 무려 4중첩의 array이다.
4.7.1 버전의 add_filter()는 이렇게 되어 있다.
function add_filter( $tag, $function_to_add, $priority = 10, $accepted_args = 1 ) {
global $wp_filter;
if ( ! isset( $wp_filter[ $tag ] ) ) {
$wp_filter[ $tag ] = new WP_Hook();
}
$wp_filter[ $tag ]->add_filter( $tag, $function_to_add, $priority, $accepted_args );
return true;
}
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‘라는 항목을 따로 두어 주의를 주고 있다.
코덱스에서 서술하는 것과 같이 무한 루프만을 막기 위한 일시적인 필터 등록 해제, 재등록 정도는 아무런 부작용이 없다. 그러나 해당 콜백 내부에서 자신의 필터를 변경하려고 하는 경우에는 문제가 발생하게 된다. 자세한 것은 실험을 통해 알아보자.
WP_Hook 클래스의 도입 후 변경된 훅의 동작을 실험해 보기 위해 실험 플러그인을 작성하여 gist에 등록해 두었다.
플러그인에서 ‘wph47_test01’이라는 훅을 실행한다. 이 훅의 콜백에서는 자기 자신을 변경한다. 또한 콜백 함수 안에서 다시 필터를 적용하는 기행(?)을 저지른다.
add_action( 'wph47_test01', 'wph47_test01', 10);
/**
* 재귀적인 do_action 호출
*/
function wph47_test01_body() {
error_log('test begin');
do_action( 'wph47_test01' );
error_log("test end");
}
function wph47_test01() {
static $flag = false; if ( $flag ) return; $flag = true;
add_action( 'wph47_test01', 'wbh47_cb_9', 9 );
add_action( 'wph47_test01', 'wbh47_cb_11', 11 );
add_action( 'wph47_test01', 'wbh47_cb_12', 12 );
add_action( 'wph47_test01', 'wbh47_cb_13', 13 );
do_action( 'wph47_test01' );
$flag = false;
}
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)에 따라 어떤 작업을 허가할 수도, 거부할 수도 있도록 조직되어 있다.
사실 ‘역할’은 ‘권한’보다는 커스텀 포스트와는 덜 밀접한 관계이긴 하지만 권한과 역할이 워낙 가까운 관계라 언급은 해야 할 것 같다. 쉽게 말해 사용자의 그룹이라 볼 수 있다. 한 사용자가 사이트 내부에서 어떤 담당인지를 나타내 준다.
각 역할 별로 일정한 권한의 목록이 기본으로 주어진다. 물론 새로운 역할도 추가할 수 있고, 특정 권한을 더 추가할 수도, 덜어낼 수도 있다. 역할에 대해서는 자세한 설명을 생략하도록 하겠다. 코덱스를 참고하기 바란다.
워드프레스에서 동작에 대한 문맥을 나타낸다. 예를 들어 포스트를 편집, 삭제, 발행하는 각각에 대한 동작들을 의미한다. 역할과 마찬가지로 사용자별로 권한을 더해줄 수도, 덜어낼 수도 있으며 완전히 새로운 권한을 만드는 것도 가능하다. 단, 여기서는 커스텀 포스트 옵션과 관련된 사항에서만 설명을 하도록 하겠다.
커스텀 포스트는 기본 포스트 타입을 확장하여 사용하는 것이므로, 기본 포스트가 가진 권한 시스템을 그대로 물려받게 된다.
포스트, 혹은 페이지에 대해 다수의 권한이 있고, 커스텀 포스트를 생성하면서 이 권한들을 1:1로 모두 새롭게 재정의해 주어야 코어 내부에서 올바르게 권한을 체크할 수 있다.
예를 들어 publish_posts 권한을 살펴 보자. 이 권한이 주어지지 않은 사용자는 글을 쓰고 편집할 수는 있어도 편집 화면에서 ‘공개하기(publish)’ 버튼이 나오지 않는다.
위 그림을 보자. 어떤 기여자(Contributor) 역할의 사용자가 새 포스트를 작성 중이다. Publish 메타 박스를 보면 보통 볼 수 있는 ‘Publish’ 버튼 대신 ‘Submit for Review’라는 버튼으로 변경되어 있다. 왜냐하면 기여자는 새 글을 쓸 수는 있고 그 글을 편집할 수는 있지만 글을 최종 단계인 발행 상태로는 만들 수 없기 떄문이다.
자, 이제 커스텀 포스트를 생성해야 한다고 보자. 그럼 publish_posts 권한에 대해 두 가지 결정을 할 수 있다. 기존의 포스트(혹은 페이지)와 동일한 권한을 가질 것인가, 아니면 별도의 권한으로 나누어야 할 것인가.
동일한 권한이라면, 글(혹은 페이지)를 편집, 수정 발행할 수 있는 권한을 가진 사용자는 커스텀 포스트에 대해 동일한 작업이 될 것이다. 반면 별도의 권한을 가지도록 처리한다면, 조금 성가시기는 하겠지만, 보다 세밀하게 권한을 나누어 원하는 대로 분업을 진행할 수 있을 것이다.
그럼 이제 PHP 코드 관점에서 권한의 구조를 생각해 보자. 권한은 연관 배열(혹은 stdClass)을 사용한다. 권한의 공통적인, 즉 ‘문맥상’의 호칭은 연관 배열의 키(혹은 속성)로, 해당 실제 권한명은 값으로 기록한다. 아래는 그 예이다.
register_post_type(
'sample_audio',
array(
....
'capabilities' => array(
....
'publish_posts' => 'publish_posts',
....
),
....
);
register_post_type(
'sample_video',
array(
....
'capabilities' => array(
....
'publish_posts' => 'publish_videos',
....
),
....
);
두 포스트 타입, ‘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은 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 );
// capabilities.php, map_meta_cap() return apply_filters( 'map_meta_cap', $caps, $cap, $user_id, $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() 함수를 호출한다.
public function has_cap( $cap ) {
....
$args = array_slice( func_get_args(), 1 );
$args = array_merge( array( $cap, $this->ID ), $args );
$caps = call_user_func_array( 'map_meta_cap', $args ); // 여기
....
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와 대조하는 코드이다. 전체 권한 중에서 요구된 권한 하나라도 발견되지 않는다면, 해당 사용자는 권한이 없는 것으로 간주된다.
권한은 그 수가 많고 만큼, 쉽게 사용할 수 있어야 한다. 쉽게 쓰려고 의도했으면 쉽게 사용할 수 있도록 되어야 한다. 권한에 대해 고민하지 않고 그냥 포스트나 페이지처럼 만드려면 권한 관련 옵션을 아예 언급조차 하지 않으면 된다. 그러면 포스트나 페이지에 의거해 동일한 권한으로 자동 생성된다.
권한 설정에 관련된 함수는 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 옵션에 대해 다음 권한을 기본적으로 생성한다.
위 세 권한은 메타 권한이다. (소스코드 9~12라인)
이 네 권한은 기본 권한으로, map_meta_caps() 함수 내부에서는 언급되는 일이 없다. 그러나 코어 구석구석에서 권한 검사에 사용되고 있을 것이다. (소스코드 13~17라인)
만일 map_meta_caps 옵션을 적지 않거나(null), true로 설정했다면 7개의 기본 권한이 별도로 생성된다. 다음은 그 목록이다. (소스코드 20~32라인)
위 소스 코드 34라인이다.
$capabilities = array_merge( $default_capabilities, $args->capabilities );
$args->capabilities가 capabilities 옵션이다. 여기서는 권한의 종류를 더욱 자세하게 정의할 수 있다. 보다시피 capability 옵션으로 인해 생긴 기본 설정에 더불어 별도의 권한을 추가할 수도 있고, 기본 설정을 변경할 수도 있게 짜여 있다.
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 레이블에 구현되어 있다.
메타 권한에 대한 설명에서 에디터 B에 대해 특정 카테고리의 글은 편집 제한을 거는 실제 코드를 구현해 보자.
에디터 B의 ID는 ‘5’이고, 카테고리의 택소노미 이름은 ‘wphack_taxonomy”이고, 카테고리 이름은 ‘a-only’이다. 포스트를 적당히 만들고 a-only 카테고리로 설정하고, 다음 코드를 작성한다. 접근 제한에 대한 세련된 예는 아니지만 권한에 대한 하나의 예제로써 이해하기를 바란다.
add_filter( 'map_meta_cap', 'wphack_meta_cap', 99, 4 );
function wphack_meta_cap( $caps, $cap, $user_id, $args ) {
global $pagenow, $post_type;
if ( $pagenow == 'post.php' && $post_type == 'wphack' && $cap == 'edit_post' ) {
$post_id = $args[0];
$categories = wp_get_post_terms( $post_id, 'wphack_taxonomy', array( 'fields' => 'names' ) );
if ( in_array( 'a-only', $categories ) ) {
$a_blacklist = array( 5, 10, 11, 12, );
if ( in_array( $user_id, $a_blacklist ) ) {
$caps = array( 'do_not_allow' );
}
}
}
return $caps;
}
에디터 B가 해당 포스트의 편집 화면에 접근하면 다음과 같은 에러가 발생한다.
물론 다른 웹프레임워크를 이용해 UI를 다 만들 수도 있겠지만, 워드프레스를 사용하면 나름 괜찮은 UI를 손쉽게 가져다 쓸 수 있다. 이 UI를 통해 개체 수정 및 임의 작성도 가능하니 금상첨화다.
다만, 어떤 다른 후단부(backend)가 존재하여 포스트의 데이터를 모두 일괄적으로 생성하는 시나리오가 있다고 가정하자. 이 커스텀 포스트는 워드프레스 UI 상에서 읽기, 조회만 가능하고 포스트의 생성과 수정은 별도의 스크립트에서 담당해야 한다. 단, 삭제의 경우는 UI 상에서 데이터를 체크하고 수동으로 지우는 일이 가능하다고 하자.
이러한 시나리오에서 커스텀 포스트는 포스트의 목록과 상세 화면 UI가 필요하다. 그러나 커스텀 포스트의 상세 화면에서는 포스트의 어떤 필드도 수정할 수 없도록 처리해야 한다.
먼저 커스텀 포스트 타입을 생성해 보자. ‘init’ 훅에서 register_post_type의 인자를 설정해 준다. 여기서 레이블을 바꿔치기했다. ‘edit’은 이제 편집이 아니라 세부항목을 보는 것으로 의미가 변경된다. 주석 부분을 해제하면 삭제도 불가능하게 만들 수 있다.
$args = array(
'labels' => array(
'name' => 'RO Posts',
'signular_name' => 'RO Post',
'edit_item' => 'RO Post Details',
),
'capabilities' => array(
'create_posts' => 'do_not_allow',
// 'delete_posts' => 'do_not_allow',
// 'delete_private_posts' => 'do_not_allow',
// 'delete_published_posts' => 'do_not_allow',
// 'delete_others_posts' => 'do_not_allow',
),
'map_meta_cap' => TRUE,
'public' => TRUE,
'show_ui' => TRUE,
'supports' => FALSE,
'register_meta_box_cb' => 'rocp_customize_meta_boxes',
);
$rocp = register_post_type( 'rocp', $args );
그리고 activation 훅과 deactivation 훅에서 적절히 예제 포스트를 생성하고 삭제하는 코드를 넣는다.
register_activation_hook( __FILE__, 'rocp_activation' );
function rocp_activation() {
rocp_register_post_type();
for ( $i = 1; $i <= 5; ++ $i ) {
wp_insert_post(
array(
'post_title' => sprintf( 'Read Only Custom Post Sample #%02d', $i ),
'post_status' => 'publish',
'post_type' => 'rocp',
'comment_status' => 'closed',
'ping_status' => 'closed',
'post_name' => sprintf( 'rocp-%02d', $i ),
'meta_input' => array(
'rocp_meta_01' => "meta_01_$i",
'rocp_meta_02' => "meta_02_$i",
),
)
);
}
flush_rewrite_rules();
}
register_deactivation_hook( __FILE__, 'rocp_clear' );
function rocp_clear() {
$query = new WP_Query(
array(
'post_type' => 'rocp',
'nopaging' => TRUE,
'fields' => 'ids',
)
);
$posts = $query->get_posts();
foreach ( $posts as $post ) {
wp_delete_post( $post, TRUE );
}
}
그리고 나머지 UI를 조정해 문맥에 맞지 않은 행동은 삭제한다. 우선 row action 항목에서의 edit도 detail로 변경한다.
function rocp_row_actions( $actions, $post ) {
if ( $post->post_type == 'rocp' ) {
if ( $actions['edit'] ) {
$actions['edit'] = sprintf(
'<a href="%s" aria-label="%s">%s</a>',
get_edit_post_link( $post->ID ),
/* translators: %s: post title */
esc_attr( sprintf( __( 'Detail “%s”', 'rocp' ), $post->post_title ) ),
__( 'Detail', 'rocp' )
);
}
if ( $actions['inline hide-if-no-js'] ) {
unset( $actions['inline hide-if-no-js'] );
}
}
return $actions;
}
그리고 목록 UI에서 벌크 작업 목록에서 편집 항목을 제거한다.
add_filter( 'bulk_actions-edit-rocp', 'rocp_remove_bulk_edit' );
function rocp_remove_bulk_edit( $actions ) {
if ( isset( $actions['edit'] ) ) {
unset( $actions['edit'] );
}
// if ( isset( $actions['trash'] ) ) {
// unset( $actions['trash'] );
// }
return $actions;
}
Detail 스크린에서 어떤 메타박스도 볼 수 없도록 register_post_type의 ‘register_meta_box_cb’ 콜백 함수에서 지저분하게 남아 있는 메타 박스를 모조리 제거한다.
function rocp_customize_meta_boxes() {
// disable slug metabox
remove_meta_box( 'slugdiv', 'rocp', 'normal' );
// disable post update metabox
remove_meta_box( 'submitdiv', 'rocp', 'side' );
}
화면 상단의 스크린 옵션을 제거해 보았다. 메타 박스 등을 고려한다면 나타나게 할 수도 있을 것이다. 또한 예제에서는 어떤 메타박스도 쓰지 않기 때문에 화면을 1열로만 쓰는 것이 더 깔끔하기 때문에 화면 레이아웃도 1단으로 고정시켰다. 포스트 타입에 따라 적절히 조절할 수 있을 것이다.
add_filter( 'screen_options_show_screen', 'rocp_disable_screen_option', 10, 2 );
function rocp_disable_screen_option( $show_screen, $wp_screen ) {
if ( $wp_screen->id == 'rocp' ) {
$show_screen = FALSE;
}
return $show_screen;
}
add_filter( 'screen_layout_columns', 'rocp_screen_layout_columns', 10, 2 );
function rocp_screen_layout_columns( $columns, $screen_id ) {
if ( $screen_id == 'rocp' ) {
$columns['rocp'] = 1;
}
return $columns;
}
add_filter( 'get_user_option_screen_layout_rocp', 'rocp_user_option_screen_layout' );
function rocp_user_option_screen_layout( $result ) {
return 1;
}
상세화면의 본문 구성은 ‘edit_form_after_editor’ 훅을 이용해 삽입 가능하다. 물론 메타 박스를 이용해 구성하는 것도 관계 없다.
add_action( 'edit_form_after_editor', 'rocp_display_detail' );
function rocp_display_detail( $post ) {
$rocp_meta_01 = get_post_meta( $post->ID, 'rocp_meta_01', TRUE );
$rocp_meta_02 = get_post_meta( $post->ID, 'rocp_meta_02', TRUE );
echo '<table class="widefat">';
echo '<thead><tr><th>Name</th><th>Value</th></tr></thead>';
echo '<tbody>';
echo '<tr><th>ROCP Meta 01</th><td>' . esc_html( $rocp_meta_01 ) . '</td></tr>';
echo '<tr><th>ROCP Meta 02</th><td>' . esc_html( $rocp_meta_02 ) . '</td></tr>';
echo '</tbody>';
echo '</table>';
echo '<p><a href="' . esc_url( admin_url( 'edit.php?post_type=rocp' ) ) . '"><button type="button" class="button button-primary">Go back</button></a></p>';
}
코드 전문은 여기서 확인할 수 있다. 이 플러그인을 활성화시키면 다음과 같은 화면을 볼 수 있다.
말단지점(endpoint) 및 다시 쓰기(rewrite) 기능은 URL 축약과 고유주소 생성과 관련 깊은 옵션이다.
여기에 해당하는 옵션은 단 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 파일을 생성한다. 생성하지 못하면 .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
예를 들어 ‘<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 된 상태로 존재한다.
또다른 예로, 가끔 워드프레스를 이사하거나 정비하는 과정에서 전면 페이지(frontend) 홈은 보이지만 네비게이션 메뉴에 있는 다른 페이지로 옮기면 404 에러가 발생하는 경우가 있다. 이 문제는 .htaccess에서 존재하지 않는 서버상의 경로를 무조건 index.php로 처리하라는 명령이 누락되어 있기 때문이다.
Nginx도 크게 다른 것이 없다. 아파치처럼 .htaccess를 활용하지는 않지만, 어떤 URL로 요청이 들어오든지간에 처리를 index.php에 맡긴다는 점은 동일하다.
사실 이 옵션을 별로 건드려야 할 이유는 거의 없다. 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( 'init', 'wphack_ep_title' );
function wphack_ep_title() {
add_rewrite_endpoint( 'title', EP_PERMALINK | EP_PAGES );
}
말단지점에 대해 선언한다. 이 말단지점을 인식하고 동작시키는 코드는 아래와 같다.
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’ 플러그인을 사용해 진단해 볼 수 있다.
rewrite 옵션은 하나의 배열을 값으로 받으며, 이 배열은 아래의 키를 가진다. 이 값을 변경하면 반드시 새로 고침 레코드를 갱신해 주어야 한다.
query_var 옵션이 질의 문자열에 쓰이는 반면, slug 옵션은 rewrite에 사용된다. 만약 slug의 값으로 ‘ask’라는 문자열을 사용했다면 커스텀 포스트 타입 wphack은 전단부에 다음과 같은 URL로 접근 가능해진다.
<site_url>/ask/ # 목록 (아카이브) <site_url>/ask/page/PAGE_NUMBER # 페이지 번호로 <site_url>/ask/slug/ # 특정 개체만
true/false를 가질 수 있는다. Front라는 것은 고유주소 설정에서 태그 항목 이전에 고정으로 생성한 문자열을 말한다. 아래의 그림을 보면 이해가 빠를 것이다.
고유주소에 /with-front 문자열을 앞에 덧붙였는데, 이렇게 저장을 하면 워드프레스의 대부분의 기본적인 고유주소는 /with-front로 시작한다. 그러나 이 값을 false로 설정하면 현재 동록하는 커스텀 포스트만큼은 이 문자열을 허용하지 않는다.
slug가 ‘ask’로 설정되었고 front가 ‘/with-front’라면
포스트 타입을 만들면 이에 대한 피드도 간단하게 만들어진다. 피드는 atom, rss, rss2 , rdf 다 지원을 한다. 이 값을 true로 하면 주소 끝에 /feed, /rss, /rss2 만 붙이면 바로 해당 형식으로 콘텐츠를 지원한다.
목록에서 페이징을 가능하게 한다. 이 항목이 true로 되어 있어야 <site_url>/ask/page/PAGE_NUMBER 처럼 된 URL로 접근 시 제대로 페이징된 목록을 보여 주게 된다.
페이지 기능 자체를 이 옵션으로 켜고 끄는 것이 아니다. 단지 URL 규칙을 제대로 설정하는 것이다.
워드프레스 3.4 이후부터 permalink_epmask 옵션을 대체하는 옵션이다.
3.4에 오면서 permalink_epmask 옵션이 rewrite 옵션과 통합되면서, 사실상 이 포스트에서 다룬 옵션은 고작 하나였다. 그렇지만 rewrite는 워드프레스 코어 기능과 매우 밀접한 중요한 기능이라 생각해서 별도의 포스트로 따로 작성한 것이다.
쿼리 문자열은 코어에 있어 엄청나게 중요한 부분이다. 어떤 콘텐츠를 어떻게 보여줄지는 모두 쿼리 파라미터에 달려 있기 때문에 사실 이 쿼리 파라미터가 워드프레스를 움직이는 중추라고 할 수 있다. 쿼리 문자열을 직관적인 URL로 변환시켜 주는 옵션이 rewrite이며 이것은 서버의 다시쓰기 기능을 필요로 하지만, 복잡한 다시쓰기 규칙은 워드프레스 코어 자체에서 별도로 수행하고 있다.
이 포스트에서는 분류(taxonomy) 및 기타 옵션에 대해 다루어 본다. 옵션 목록은 다음과 같다.
모든 목록은 이 포스트에서 확인할 수 있다.
내보내기 기능에 해당 커스텀 타입도 포함시키는 옵션이다. 이것이 true 이면 도구(tools) > 내보내기 (export) 메뉴에서 커스텀 타입도 포함된다.
내보내기를 하면 XML 형태로 사이트의 콘텐츠를 다운로드 받을 수 있다. 단, 주의해야 할 점이 있다. 이것은 콘텐츠를 내보내기 위한 용도이며 범위는 콘텐츠에 한해 진행된다.
백업을 하려면 데이터베이스를 sql 형태로 백업받고, FTP 등을 이용해 사이트 전체 파일을 받아 두는 것이 낫다. 사이트 전반에 걸쳐 저장된 옵션, 예를 들어 테마 설정 및 업로드된 첨부 파일의 원본까지 보관해 두어야 하기 때문이다.
이 커스텀 포스트 타입이 어떤 것인지 기술하기 위한 용도로 사용된다. 이 옵션 자체가 어딘가 직접적으로 사용되는 일은 없다.
True 이면 ‘페이지’ 타입처럼 처럼 상위/하위 개념이 존재하는 개체로 만들 수 있다. 반대로 false이면 ‘포스트’ 타입처럼 모든 포스트는 동등한 위치를 가진다.
True/false 값의 차이는 supports 옵션에서 ‘page-attributes’를 넣었을 때 확연이 난다. true일 때는 (parent) 옵션이 나타나고, false일 때에는 이것이 보이지 않는다.
또 true면 목록을 출력할 때 하위 개체는 상위 개체에 그룹이 지어져 나온다.
배열로 값을 채워 넣을 수 있다. 이 커스텀 포스트에 대한 분류 체계를 설정해 줄 수 있다. 그렇지만 이렇게 분류 체계를 연관지어 주려면 먼저 분류 체계를 미리 등록해야 한다. 만약 새 분류 체계를 사용하나면 별도로 register_taxonomy() 함수로 분류 체계를 등록해야 한다.
이 함수는 register_post_type()과 꽤 유사한 형태를 가진다. 예제 코드로 살펴 보자.
add_action( 'init', 'wphack_taxonomy' );
function wphack_taxonomy() {
$args = array(
'labels' => array(
'name' => 'HackTaxoes',
'singular_name' => 'HackTaxo',
),
'hierarchical' => TRUE,
);
register_taxonomy( 'wphack_taxonomy', 'wphack', $args );
}
이렇게 코드를 추가하면 wphack 타입을 위해 ‘카테고리’형태의 분류 체계가 추가된다.
register_taxonomy의 옵션 인자에도 ‘hierarchical’을 발견할 수 있다. 이것이 true이면 분류 체계가 상/하위로 구분되는 ‘카테고리’형태로 구성된다. 반대로 false면 단순 태그가 된다.
