개발 레시피 Archives

페이지 목록 관리의 깨알 팁

사이트 페이지 목록을 만들 때 정돈되어 있으면 더욱 효율적입니다. 메인 페이지나 중요한 페이지를 1페이지에 빠르게 로드할 수 있다면 더 좋겠지요? 이럴 때 쓰는 것이 페이지 “순서” 속성입니다.

페이지 순서는 기본이 0입니다. 그래서 보통보다 뒤로 보내려면 양수를, 반대로 앞으로 가져오려면 음수로 둡니다. 그러면 1페이지 상위에 가장 자주 관리하는 메뉴를 먼저 볼 수 있게 되어 편리합니다.

메인 페이지나 자주 편집하는 주요 페이지를 먼저 출력해 두면 편리합니다.

디버그 로그는 가려놓읍시다!

워드프레스는 흔히 카페24 같은 호스팅을 사용한다든지, 이런 오픈된 개발 서버에서 작업되는 경우도 흔합니다. 그리고 워드프레스의 동작을 보다 정밀하게 파악하기 위해, 아래 같은 설정을 사용하기도 합니다.

wp-login.php 직접 접근을 리다이렉트

wp-login.php 파일에 직접 접근하면 워드프레스의 기본 로그인 창이 뜨는데, 몇몇 고객들은 이것을 달가워하지 않는다. 그래서 이것을 막아달라는 요청을 하는데, wp-login.php는 사실 로그인, 로그아웃에 대한 백엔드를 담당하는 역할을 맡고 있기 때문에 접근 자체를 차단하는 것은 바람직하지 않다.

커스텀 포스트가 관리자 페이지에서 일반 페이지처럼 템플릿을 선택할 수 있도록 하기

커스텀 포스트에서 페이지 템플릿을 선택하도록 만든다.

register_post_type() 함수 인자에서 ‘support’ 항목에 ‘page-attributes’를 추가한다. 그리고 아래의 필터를 추가한다.

<?php
add_filter( 'theme_' . 'custom_post_type' . '_templates', 'my_templates', 10, 4);

function my_templates( $post_templates, $wp_theme, $post, $post_type ) {
  if ( empty( $post_templates ) ) {
    $pt = $wp_theme->get_post_templates();
    $post_templates = $pt['page'] ?? array();
  }
  return $post_templates;
}

테마를 별도의 디렉토리로 옮기기

개발 의도상 테마를 별도의 디렉토리에 두고 싶은 생각이 들었다. 플러그인을 놓고 쓰는 것처럼 말이다. 그런데 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? 편집은 못하지만 지울 수는 있다. 편집자 역할은 휴지통에 있는 글도 영구 삭제 가능하다. 물론 같은 스태프끼리 그럴 일은 없겠지만… 아, 권한 체크는 세심해야 함을 강조한다. 해당 권한 목록을 꼼꼼하게 살펴서 이런 구멍이 없도록 잘 대비하기를 권한다.

어드민 화면의 열 수를 1개로 고정하는 레시피

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' );
  }
} );

커스텀 포스트에 활용할 수 있다.