[글쓴이:] changwoo

photo-of-the-day는 National Geographic photo of the day 페이지의 모든 서비스 사진들의 목록을 제공합니다.

드롭박스 링크는 매일 갱신되며 photo of the day 서비스를 시작한 2009년 01월 01일부터 현재까지 모든 사진의 URL과 이미지 링크 목록을 담고 있습니다.

CSV 목록 다운로드

역할과 권한에 대한 항목에는 다음 옵션들이 있다.

• capability_type
• capabilities
• map_meta_cap

전체 옵션은 이 포스트에서 확인할 수 있다.

역할과 권한

워드프레스의 권한(authority) 시스템은 매우 잘 구축되어 있다. 권한은 세부적으로 역할과 권한(capability)으로 쪼개어져 문맥(context)에 따라 어떤 작업을 허가할 수도, 거부할 수도 있도록 조직되어 있다.

역할 (Roles)

사실 ‘역할’은 ‘권한’보다는 커스텀 포스트와는 덜 밀접한 관계이긴 하지만 권한과 역할이 워낙 가까운 관계라 언급은 해야 할 것 같다. 쉽게 말해 사용자의 그룹이라 볼 수 있다. 한 사용자가 사이트 내부에서 어떤 담당인지를 나타내 준다.

각 역할 별로 일정한 권한의 목록이 기본으로 주어진다. 물론 새로운 역할도 추가할 수 있고, 특정 권한을 더 추가할 수도, 덜어낼 수도 있다. 역할에 대해서는 자세한 설명을 생략하도록 하겠다. 코덱스를 참고하기 바란다.

권한 (Capabilities)

워드프레스에서 동작에 대한 문맥을 나타낸다. 예를 들어 포스트를 편집, 삭제, 발행하는 각각에 대한 동작들을 의미한다. 역할과 마찬가지로 사용자별로 권한을 더해줄 수도, 덜어낼 수도 있으며 완전히 새로운 권한을 만드는 것도 가능하다. 단, 여기서는 커스텀 포스트 옵션과 관련된 사항에서만 설명을 하도록 하겠다.

커스텀 포스트의 권한 대응

커스텀 포스트는 기본 포스트 타입을 확장하여 사용하는 것이므로, 기본 포스트가 가진 권한 시스템을 그대로 물려받게 된다.

포스트, 혹은 페이지에 대해 다수의 권한이 있고, 커스텀 포스트를 생성하면서 이 권한들을 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이라는 문자열이 언급되는데, 워드프레스 코어에서 이 것이 세 가지 의미로 쓰이고 있다. 애매모호함을 없애기 위해 우선 이것부터 명확히 정의하고 넘어가자.

첫번째로 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와 대조하는 코드이다. 전체 권한 중에서 요구된 권한 하나라도 발견되지 않는다면, 해당 사용자는 권한이 없는 것으로 간주된다.

각 옵션 설명

권한은 그 수가 많고 만큼, 쉽게 사용할 수 있어야 한다. 쉽게 쓰려고 의도했으면 쉽게 사용할 수 있도록 되어야 한다. 권한에 대해 고민하지 않고 그냥 포스트나 페이지처럼 만드려면 권한 관련 옵션을 아예 언급조차 하지 않으면 된다. 그러면 포스트나 페이지에 의거해 동일한 권한으로 자동 생성된다.

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라인)

• read
• delete_posts
• delete_private_posts
• delete_published_posts
• delete_others_posts
• edit_private_posts
• edit_published_posts
• create_posts

capabilities 옵션

위 소스 코드 34라인이다.

$capabilities = array_merge( $default_capabilities, $args->capabilities );

$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 카테고리로 설정하고, 다음 코드를 작성한다. 접근 제한에 대한 세련된 예는 아니지만  권한에 대한 하나의 예제로써 이해하기를 바란다.

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가 해당 포스트의 편집 화면에 접근하면 다음과 같은 에러가 발생한다.

예제 코드 #2 읽기 전용 커스텀 포스트

물론 다른 웹프레임워크를 이용해 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 &#8220;%s&#8221;', '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개로 수가 적지만, 커스텀 포스트 옵션 중 서버의 기능과 밀접한 부분이다. 내가 포스트를 쓰면서 가장 염두에 둔 포인트이기도 하고.

• permalink_epmask
• rewrite

나머지 옵션에 대해서는 이 포스트를 참고하자.

워드프레스의 rewrite에 대해

커스텀 포스트의 옵션 값과는 약간 거리가 있지만, 우선 워드프레스가 어떻게 다시 쓰기를 하는지에 대해 이야기를 먼저 하고자 한다. 옵션이 워낙 적어 분량 채우기기도 하지만… 워드프레스의 다시 쓰기 원리를 이해하고 이 옵션을 보는 것이 더 낫지 않을까?

웹사이트를 돌아다니다 보면 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에 저장한 다음 동적으로 처리한다.

기본적인 컨셉은 이렇다.

1. .htaccess 파일에 rewrite 룰을 다음과 같이 설정해 둔다: URL의 경로를 모두 무시하고 무조건 /index.php 파일에서 요청을 처리하도록 서버 흐름을 조작한다. 어차피 클라이언트가 어떤 경로를 요청했는지는 PHP의 $_SERVER 변수에 다 기록되어 있다.
2. $_SERVER[‘REQUEST_URI’]에서 읽어온 URL과 데이터베이스에 저장된 rewrite 규칙을 대조한다. 여기서 규칙에 맞는 것을 찾는다면, 안 예쁜 URL로 변경한다. 즉, ‘index.php?param1=val1&param2=val2…’ 식으로 URL이 변경된다.
3. 파라미터에 맞게 데이터베이스 쿼리를 한다.
4. 템플릿을 불러와 적절히 응답을 한다.

워드프레스는 아파치를 서버로 사용한 경우에 내부에 .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 된 상태로 존재한다.

또다른 예로, 가끔 워드프레스를 이사하거나 정비하는 과정에서 전면 페이지(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이다.

마스킹을 위해 쓰이는 상수는 다음과 같다.

• EP_NONE
• EP_PERMALINK
• EP_ATTACHMENT
• EP_DATE
• EP_YEAR
• EP_MONTH
• EP_DAY
• EP_ROOT
• EP_COMMENTS
• EP_SEARCH
• EP_CATEGORIES
• EP_TAGS
• EP_AUTHORS
• EP_PAGES
• EP_ALL_ARCHIVES
• EP_ALL

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

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 문자열을 앞에 덧붙였는데, 이렇게 저장을 하면 워드프레스의 대부분의 기본적인 고유주소는 /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 만 붙이면 바로 해당 형식으로 콘텐츠를 지원한다.

pages

목록에서 페이징을 가능하게 한다. 이 항목이 true로 되어 있어야 <site_url>/ask/page/PAGE_NUMBER 처럼 된 URL로 접근 시 제대로 페이징된 목록을 보여 주게 된다.

페이지 기능 자체를 이 옵션으로 켜고 끄는 것이 아니다. 단지 URL 규칙을 제대로 설정하는 것이다.

ep_mask

워드프레스 3.4 이후부터 permalink_epmask 옵션을 대체하는 옵션이다.

마치며

3.4에 오면서 permalink_epmask 옵션이 rewrite 옵션과 통합되면서, 사실상 이 포스트에서 다룬 옵션은 고작 하나였다. 그렇지만 rewrite는 워드프레스 코어 기능과 매우 밀접한 중요한 기능이라 생각해서 별도의 포스트로 따로 작성한 것이다.

쿼리 문자열은 코어에 있어 엄청나게 중요한 부분이다. 어떤 콘텐츠를 어떻게 보여줄지는 모두 쿼리 파라미터에 달려 있기 때문에 사실 이 쿼리 파라미터가 워드프레스를 움직이는 중추라고 할 수 있다. 쿼리 문자열을 직관적인 URL로 변환시켜 주는 옵션이 rewrite이며 이것은 서버의 다시쓰기 기능을 필요로 하지만, 복잡한 다시쓰기 규칙은 워드프레스 코어 자체에서 별도로 수행하고 있다.

이 포스트에서는 분류(taxonomy) 및 기타 옵션에 대해 다루어 본다. 옵션 목록은 다음과 같다.

• can_export
• description
• hierarchical
• taxonomies

모든 목록은 이 포스트에서 확인할 수 있다.

can_export

내보내기 기능에 해당 커스텀 타입도 포함시키는 옵션이다. 이것이 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() 함수로 분류 체계를 등록해야 한다.

이 함수는 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면 단순 태그가 된다.

이 포스트는 커스텀 포스트의 관리 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>  // 추가

이 패턴 대로 URL을 입력하는 경우 위 그림처럼 익숙한 UI를 만날 수 있다. 만일 show_ui가 false이면 아래 그림처럼 권한이 없다는 메시지를 만날 수 있다.

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는 타입 저글링이 일어나 이 값을 문자열 형태로 입력해도 될 것 같지만, 실제로 해 보면 진짜 “정수형”만 가능하다는 점에 유의한다. 정수형이 아니면 기본값과 같게 동작하게 된다.

$args = array(
    ....
    'menu_position'    => 65,    // ok
    // 'menu_position' => "65",  // wrong
    ....
);

register_post_type( 'wphack', $args );

코덱스에서 수치에 대한 가이드라인을 참고할 수 있다.

menu_icon

메뉴 아이콘을 지정할 수 있다. 아이콘의 URL이나 dashicon id를 입력해 주면 된다. Dashicon 페이지에 들어가면 아래처럼 화면이 나온다.

여기서 사용하고 싶은 아이콘을 클릭한다. 예를 들어 ‘Admin menu’의 가장 처음 보이는 아이콘을 클릭하면 그림처럼 아이콘이 크게 보인다. 붉은색 사각형으로 하이라이트한 문자열을 여기에 적으면 원하는 아이콘을 메뉴 아이콘으로 지정할 수 있다.

$args = array(
    ....
    'menu_icon' => 'dashicons-menu',
    ....
);

register_post_type( 'wphack', $args );

supports

개체의 작성, 편집 화면에서 어떤 개체 작성 도구를 기본으로 지원할지 선택할 수 있다. 값으로 false나 배열을 입력할 수 있다.

false를 입력한 경우 어떤 작성 도구도 선택하지 않을 때 쓴다. 단, 기본 메타 박스인 ‘Publish’는 사라지지 않는다. 배열의 경우 아래의 항목을 입력 가능하다.

title

제목(post_title)을 편집할 수 있는 UI를 제공한다.

editor

본문 편집기를 그대로 재활용할 수 있다.

author

작성자를 변경할 수 있다.

thumbnail

특성 이미지(featured image)를 선택할 수 있다. 테마에서 지원해야 한다.

excerpt

요약글을 작성할 수 있다.

custom-fields

사용자 정의 필드(커스텀 필드 또는 메타 필드)를 직접 수정할 수 있다. 키와 값이 그대로 출력되는 형태라 편집하기 직관적인 형태는 아니다. 주의할 점은, 직렬화된(serialized) 값은 이 목록에 포함되지 않는다. 예를 들어 아래 코드처럼 array를 serialize 시킨 것이라면 목록으로 출력되지 않는다. 개발하면서 가끔 착각할 수도 있으니 참고하도록 하자.

comments

토론(discussion)관련 메타 박스를 출력하거나, 편집 화면에서 댓글(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 테마에서 포스트 포맷을 걸어 보면 이렇게 나온다.

표준 포맷

추가정보(aside) 포맷

상태 (status) 포맷

register_meta_box_cb

개체에 대한 세부적인 인터페이스를 위해 메타 박스를 추가할 수 있다. 포스트 타입을 설정하면서 메타 박스를 디자인하기 위한 콜백 함수를 값으로 입력하면 된다.

$args = array(
    ....
   'register_meta_box_cb' => 'wphack_meta_boxes',
    ....
);

register_post_type( 'wphack', $args );

function wphack_meta_boxes() {
    ....
}

위 코드 예제처럼 콜백 함수를 등록하면 된다. wphack_meta_boxes() 함수 내에서 remove_meta_box()나 add_meta_box()를 불러 메타 박스를 편집하면 된다.

예를 들어 기본적으로 삽입되는 슬러그(slug) 메타 박스를 삭제하고 싶다면 아래 코드를 삽입하면 된다.

remove_meta_box( 'slugdiv', $post_type, 'normal' );

한편 워드프레스에서는 해당 개체에 대해 읽기만을 허용하고 싶을 때에는 공개하기(Publish) 메타박스가 오히려 껄끄러울 것이다. 아래 코드처럼 사용해서 이를 삭제할 수 있다.

remove_meta_box( 'submitdiv', $post_type, 'side' );

이렇게 하면 슬러그와 발행하기 메타 박스는 화면에서 사라진다.

마치며

관리 UI 옵션은 커스텀 포스트의 여러 요소 중 관리자 화면에서 나타낼 유저 인터페이스와 관련 깊은 옵션들만 따로 모아 내가 임의로 그룹화한 것이다. 관리 화면 UI 관련 옵션인 만큼 워드프레스 관리자와 가장 밀접한 부분일 것이라 생각한다. 사용하는 목적에 따라 적절한 파라미터 값을 찾아 사용하기를 바란다.