차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- wordpress:making_plugin_tutorial [2015/01/22 03:16] – [POST 액션] changwoo
+++ wordpress:making_plugin_tutorial [2015/05/01 20:50] (현재) – dw2pdf 파일 재생성을 위한 가짜 작업. changwoo
@@ 줄 2: / 줄 2: @@
 ===== 소개 =====
-워드프레스는 단순히 블로깅 용 툴이 아니라 상당히 방대한 규모의 콘텐츠를 수용할 수 있는 잘 짜여진 CMS입니다. 즉, 다양한 콘텐츠를 어떻게 웹 상에서 효율적으로 제공하기 위한 플랫폼입니다. '블로그'는 그러한 콘텐츠의 한 부분집합인 것이구요.
+워드프레스는 단순히 블로깅 용 툴이 아니라 여러 종류의 콘텐츠를 다룰 수 있는 잘 짜여진 CMS입니다. 즉, 다양한 콘텐츠를 어떻게 웹 상에서 효율적으로 제공하기 위한 플랫폼입니다. '블로그'는 그러한 콘텐츠의 한 부분집합인 것이구요.
-이것은 워드프레스를 통해 제작한 웹사이트는 만들기도 보다 간편하고 차후 유지 관리에도 유리하기 때문에, 워드프레스는 점차 많은 곳에서 채택되어 사용되고 있습니다((http://w3techs.com/technologies/details/cm-wordpress/all/all)). 제작 및 유지보수의 용이함도 있지만, 특히 플러그인을 통한 유연한 기능 확장은 워드프레스의 가장 매력적인 기능이 아닐까 생각합니다.
+워드프레스는 점차 많은 곳에서 채택되어 사용되고 있습니다((http://w3techs.com/technologies/details/cm-wordpress/all/all)). 제작 및 유지보수도 용이함도 있지만, 플러그인을 통한 유연한 기능 확장을 통해 손쉽게 원하는 기능을 구현할 수 있기 때문에 아닐까 생각합니다. 더구나 요즘은 다양한 플러그인들이 제작되어 있어, 뭔가 부족하거나 아쉬운 기능은 플러그인을 찾아 보면 구할 수 있는 경우가 아주 많습니다. 단순한 기능 추가부터, 쇼핑몰 구축까지 아주 다양한 분야에서 다양한 종류의 플러그인들이 구비되어 있습니다.
-요즘은 다양한 플러인들이 제작되어 있어, 뭔가 부족하거나 아쉬운 기능은 플러그인을 찾아 보면 구할 수 있는 경우가 아주 많습니다. 단순한 기능 추가부터, 쇼핑몰 구축까지 아주 다양한 분야에서 다양한 종류의 플러그인들이 구비되어 있습니다.
 그런데 이러한 플러그인 제작은 어떻게 하는 것일까? 내 입맛에 맞는 워드프레스 플러그인은 제작할 수 없을까? 본 문서에서는 그동안의 짧은 경험을 정리하고자 워드프레스 플러그인 제작 방법을 기술합니다. 짧은 경험이므로 혹여 워드프레스에서 권장할 만한 내용이 아닌 부분도 더러 있을 수 있습니다. 반드시 [[http://codex.wordpress.org/|Codex]]와 교차 검증하도록 하세요.
 ===== 플러그인 이름짓기 =====
@@ 줄 56: / 줄 53: @@
 이렇게 ~meta 접미사가 붙은 테이블은 그 접미사가 붙지 않은 테이블의 보조 역할을 맡은 테이블이라고 생각할 수 있습니다. 이러한 메타 테이블은 공통적으로 4개의 필드로 구성되어 있음을 알 수 있습니다.
   * meta_id: 각 테이블 내 레코드의 id입니다.
   * *_id: * 부분은 각 테이블의 상위 개념이 되는 테이블의 id입니다. wp_postmeta이 경우는 post_id, 즉 wp_post.ID를 말하는 것이겠죠.
@@ 줄 62: / 줄 58: @@
   * meta_value: 테이블에서 확장하고 싶은 데이터의 **값**을 정의하는 필드입니다.
-이렇게 키/값을 사용자가 임의로 설정할 수 있도록 구성했기 때문에 데이터베이스는 많은 필드를 정의하지 않아도 되고, 임의의 필드에 대해서도 잘 대응할 수 있습니다.
+이렇게 키/값을 사용자가 임의로 설정할 수 있도록 구성했기 때문에 데이터베이스는 많은 필드를 정의하지 않아도 되고, 임의의 필드에 대해서도 잘 대응할 수 있습니다. 보통 회원 정보를 담는 wp_users 테이블에는 회원의 이메일 주소는 기본적으로 저장할 수 있도록 해 둡니다. 그러나 그 이외의 여러 프로필, 가령 페이스북의 아이디나 카카오톡의 아이디, 약간 민감하긴 하지만, 회원의 전화번호 등등은 어떤 필드에 저장하두라고 특별히 정해 두지는 않았습니다. 허나 이런 필드가 필요할 경우 어떻게 해야 할까요? wp_users에 필드를 추가할까요? 그렇지 않습니다. 이렇게 부가적으로 불리는 데이터를 저장하라고 만든 테이블이 wp_usermeta 테이블입니다. 같은 방법으로 wp_commentmeta는 wp_comments에 대응되고 wp_postmeta는 wp_posts에 대응됩니다.
-메타 키/값의 예를 들어 보다 부연 설명을 하겠습니다. 보통 회원 정보를 담는 wp_users 테이블에는 회원의 이메일 주소는 기본적으로 저장할 수 있도록 해 두지만 예를 들어 페이스북의 아이디나 카카오톡의 아이디, 약간 민감하긴 하지만, 회원의 전화번호 등등은 어떤 필드에 저장하두라고 특별히 정해 두지는 않았습니다. 허나 이런 필드가 필요할 경우 어떻게 해야 할까요? wp_users에 필드를 추가할까요? 그렇지 않습니다. 이렇게 부가적으로 불리는 데이터를 저장하라고 만든 테이블이 wp_usermeta 테이블입니다.
+예를 들어, 서버 내 설치된 워드프레스를 개발하는 팀끼리 미리 어떠한 이름을 쓰기로 약속을 합니다. 이 이름을 메타 키로 정의합니다. 예를 들어 페이스북, 카카오톡, 전화번호에 대해 다음과 같이 메타 키로 쓰기로 합니다.
-서버 내 설치된 워드프레스를 개발하는 팀끼리 미리 어떠한 이름을 쓰기로 약속을 합니다. 이 이름을 메타 키로 정의합니다. 예를 들어 페이스북, 카카오톡, 전화번호에 대해 다음과 같이 메타 키로 쓰기로 합니다.
   * 페이스북 아이디: facebook_id
   * 카카오톡 아이디: kakaotalk_id
   * 전화번호: phone_number
 그러면 각 회원에 대해 테이블 작업을 하지 않고서도 얼마든지 확장된 정보를 저장할 수 있게 됩니다.
-예를 들어 다음과 같은 회원이 있다고 하죠. 편의를 위해 2개의 필드만 나열하겠습니다.
+다음과 같은 회원이 있다고 하죠. 편의를 위해 2개의 필드만 나열하겠습니다.
 ^ID  ^user_login  ^
 |1   |admin       |
@@ 줄 96: / 줄 88: @@
 이런 식으로 저장됩니다.
-이렇게 키와 값으로 임의의 데이터에 대해 저장할 수 있는 방법이 있으므로 기본 테이블의 구조를 변경하지 않고도 어지간한 데이터는 큰 문제 없이 처리 가능합니다. 주의할 점은 메타 키 값은 모든 데이터에 대해 공통적으로 사용해야 하며, 어떤 한 정보를 기록하기 위해 여러 가지 키를 섞어 쓰면 안 됩니다. 다시 말해 전화 번호를 저장하기 위해 'phone_number'라는 키를 쓰기로 약속했으면 끝까지 'phone_number'를 사용해야지, 'phonenum', 'phone', 'num', 'Phone_Number' 등등 원래 약속한 것과 다른 키 이름을 사용해서는 절대 안 됩니다.
+이렇게 키와 값으로 임의의 데이터에 대해 저장할 수 있는 방법이 있으므로 기본 테이블의 구조를 변경하지 않고도 어지간한 데이터는 큰 문제 없이 처리 가능합니다. 주의할 점은 메타 키 항목은 모든 데이터에 대해 공통적으로 사용해야 하며, 어떤 한 정보를 기록하기 위해 여러 가지 키를 섞어 쓰면 안 됩니다. 다시 말해 전화 번호를 저장하기 위해 'phone_number'라는 키를 쓰기로 약속했으면 끝까지 'phone_number'를 사용해야지, 'phonenum', 'phone', 'num', 'Phone_Number' 등등 원래 약속한 것과 다른 키 이름을 사용해서는 절대 안 됩니다. 이것은 데이터베이스에 'phone_number' 필드를 중복하는 것과 같은 행위입니다.
 메타 테이블은 어떠한 형태의 데이터라도 효과적으로 확장하여 데이터베이스에 기록할 수 있도록 해 주는 편리함도 있지만, 만능은 아닙니다. 개발하는 팀 내부에서 명확히 규약을 맞춰 두지 않으면 이름 파편화가 생길 수도 있고, 개별적으로 필드를 설정하는 것만큼 성능이 뒤따라주지 않을 수도 있습니다. 또한 모든 형태의 자료 구조에 대해 100% 효율적으로 딱 들어맞는다고 말하기도 어렵습니다. 이럴 때는 워드프레스가 제공하는 테이블이 아닌 별도의 테이블 형태를 만들어 사용하시면 됩니다. 워드프레스에서 기본적으로 주는 테이블 이외의 테이블을 사용한다고 워드프레스에서 사용할 수 없는 건 절대 아니니까요.
 === 포스트 타입과 커스텀 포스트 ===
-워드프레스는 기본적으로는 블로깅 저작 툴로 생각할 수 있습니다. 기본적인 동작은 거의 블로그로써 포스트를 작성하기 위해 있습니다.
+워드프레스는 기본적으로는 블로깅 저작 툴로 생각할 수 있습니다. 기본적인 동작은 거의 블로그로써 포스트를 작성하기 위해 있습니다. 그러나 워드프레스는 단순히 블로깅 뿐만 아니라 일반적인 형태의 웹사이트도 잘 지원하도록 확장이 가능합니다. 블로그의 게시물인 '포스트'뿐만 아니라 정적인 웹 페이지를 위해서도, 그리고 어느 정도는 일반적인 형태의 게시물을 저장하기 적절합니다.
-그러나 워드프레스는 단순히 블로깅 뿐만 아니라 일반적인 형태의 웹사이트도 잘 지원하도록 확장이 가능합니다. 블로그의 게시물인 '포스트'뿐만 아니라 정적인 웹 페이지를 위해서도, 그리고 어느 정도는 일반적인 형태의 게시물을 저장하기 적절합니다.
+워드프레스는 포스트를 작게는 한 블로그의 포스트로서, 크게는 어떤 작은 데이터 단위로서 취급합니다. 그리고 그 데이터 단위를 타입에 따라 구분하여 wp_posts 라는 테이블에 모두 저장하도록 합니다. wp_posts 테이블의 한 레코드는 블로그의 포스트가 될 수 있고, 정적인 페이지가 될 수도 있고, 굳이 웹페이지로 출력될 필요는 없지만 웹사이트 운영에 필요한 어떤 데이터의 한 단위가 될 수도 있습니다.
-워드프레스는 포스트를 작게는 한 블로그의 포스트로써, 크게는 어떤 작은 데이터 단위로 취급합니다. 그리고 그 데이터 단위를 타입에 따라 구분하여 wp_posts 라는 테이블에 모두 저장하도록 합니다. wp_posts 테이블의 한 레코드는 블로그의 포스트가 될 수 있고, 정적인 페이지가 될 수도 있고, 굳이 웹페이지로 출력될 필요는 없지만 웹사이트 운영에 필요한 어떤 데이터의 한 단위가 될 수도 있습니다.
+이 때 wp_post 내부에서 각 레코드가 어떤 타입인지를 정해주기 위해 'post_type'이라는 필드가 있습니다. 이 필드 값은 20자 내의 임의의 문자열을 저장할 수 있는데, 이를 통해 각 레코드의 정보가 어떤 목적을 위해 있는지를 구분해 줍니다.
+워드프레스에서 기본적으로 정의한 포스트 타입으로 post, page 두 개를 들 수 있습니다. post는 말 그대로 블로그 포스트를 위한 타입이며, page는 정적인 한 페이지를 위한 타입입니다. wp_post 필드를 적절히 활용하여 저장하고자 하는 데이터를 계획하는 것이 가장 워드프레스와 잘 어울립니다.
-이 때 wp_post 내부에서 각 레코드가 어떤 타입인지를 정해주기 위해 'post_type'이라는 필드가 있습니다. 이 필드 값은 20자 내의 임의의 문자열을 저장할 수 있는데, 이를 통해 각 레코드의 정보가 어떤 목적을 위해 있는지를 구분해 줍니다.
-예를 들어 워드프레스에서 기본적으로 정의한 포스트 타입으로 post, page 두 개를 들 수 있습니다. post는 말 그대로 블로그 포스트를 위한 타입이며, page는 정적인 한 페이지를 위한 타입입니다. wp_post 필드를 적절히 활용하여 저장하고자 하는 데이터를 계획하는 것이 가장 워드프레스와 잘 어울립니다.
 예를 들어 어떤 학교의 반에서 학급 신문을 만든다고 합니다. 이 때 워드프레스를 이용해 웹사이트 형태로 구축한다고 합니다. 학급 신문 기사들은 기사 나름대로의 데이터 구조를 가지고 있을 것입니다. 기사 발행 시간이나 수정 시간, 기사를 입력한 사람, 본문, 요약, 헤드라인, 또는 기타 여러 부가적인 정보들을 필요로 하겠죠. 이런 것들을 위해 테이블을 다시 만들 필요는 없어 보입니다. 이렇게 하면 어떨까요?
 ^필요한 정보    ^활용할 필드 ^
 |기사 발행 시간 |wp_posts.post_date, wp_posts.post_date_gmt 활용         |
@@ 줄 122: / 줄 110: @@
 |카테고리/태그  |워드프레스가 기본적으로 제공하는 카테고리, 태그 기능 활용  |
 |기사 타입     |wp_posts.post_type에서 기사 성격별로 정의. \\ 예) 새 소식: article_news, 사설: article_editorial, ...  |
+별로 힘들이지 않고 새로운 데이터 형태를 구축할 수 있습니다. 그리고 부족한 필드는 메타 필드를 이용하면 됩니다. 별도의 테이블을 쓰지 않고 포스트 타입을 확장하는 것이 멋진 이유는 이렇습니다. 워드프레스의 기본 타입인 post를 확장하는 것이기 때문에 워드프레스 내부에서 우리가 만든 타입은 post와 동등한 대우를 받습니다. 별도의 복잡한 로직을 재생산하지 쓰지 않고 워드프레스가 쓰는 방법 그대로 적용해서 데이터 작업을 할 수 있습니다. 또한 기존의 UI 요소를 완전히 재활용 할 수 있습니다.
 이렇게 커스텀 포스트를 만들기 위해서 워드프레스는 일련의 API를 제공하고 있습니다. 더욱 자세한 내용은 [[http://codex.wordpress.org/Custom_Post_Types | Custom Post Types]] 코덱스, 그리고 [[http://codex.wordpress.org/Function_Reference/register_post_type | register_post_type]] 함수 등을 참고하세요.
@@ 줄 164: / 줄 154: @@
 |65            |내 요리     |my-cooking-by-ingredients    |0                |
-그리고 내 요리의 하위 카테고리로 쇠고기를 다시 추가합니다. 이 작업을 모두 워드프레스 UI에서 할 경우에는 '쇠고기'라는 용어가 중복되어 기록될 수 있습니다. 그렇지만 여기서는 그냥 반복하지 않고 하나의 텀을 재활용하겠습니다.
+그리고 내 요리의 하위 카테고리로 쇠고기를 다시 추가합니다. 이 작업을 모두 워드프레스 UI에서 할 경우에는 '쇠고기'라는 용어가 중복되어 기록될 수 있습니다. 그렇지만 여기서는 그냥 반복하지 않고 하나의 텀을 재활용하겠습니다.((워드프레스 4.2 부터는 하나의 term을 복수의 taxonomy가 중복하여 사용하지 않고 분리하도록 변경되었습니다. [[https://developer.wordpress.org/plugins/taxonomy/working-with-split-terms-in-wp-4-2/|Working with “split terms” in WP 4.2+]]을 참고하세요.))
 **wp_term_taxonomy**
@@ 줄 197: / 줄 187: @@
   * 플러그인은 특별하게 어떤 페이지를 생성합니다.
     * 이 페이지는 특별히 어디에 노출되어 있지 않아서, 직접 다른 페이지가 링크를 걸어 주든지, 아니면 사용자가 명시적으로 URL을 타이핑해야 합니다.
-    * 페이지의 콘텐츠는 그냥 Hello, World를 출력하고 맙니다.
+    * 페이지는 단지 URL로 전달 받은 어떤 문자열을 출력해 보여줍니다.
   * 플러그인은 커스텀 포스트 타입을 하나 생성합니다.
     * 이 커스텀 포스트 타입은 기본 포스트처럼 대시보드에서 작성 가능합니다.
-    * 몇몇 메타 필드들이 표시됩니다.
+    * 몇몇 메타 필드들이 표시됩니다. 단 프로그램의 단순화를 위해 메타 필드를 직접 DB에 저장하지는 않습니다.
-이러한 기능을 위해 자잘한 설명을 모두 할 이유는 없습니다. 필요한 설명은 소스 코드에 모두 첨부해 두도록 하고 몇몇 함수에 대해서만 본 문서에서 언급하는 식으로 진행하겠습니다.
+플러그인이 할 만한 기본적인 동작이라 생각해서 구성해 보았습니다. 분량상 DB를 읽어 오거나 업데이트하는 부분은 넣지 않았습니다. 콜백 함수가 두드러지다 보니 소스를 볼 때는 텍스트 검색을 꼭 사용하도록 하세요 ^_^
 ==== 소스 설명 ====
-소스는 github에 별도로 저장해 두었습니다.
+소스는 [[https://github.com/chwnam/wp_plugin_tutorial.git|github]]에 별도로 저장해 두었습니다.
 당연한 말이지만 나열된 기능들은 워드프레스 기능의 아주 일부에 불과합니다. 더 자세한 내용은 코덱스를 참고하셔야겠죠. 하지만 거의 일상적으로 사용될 법한 기본적인 플러그인 기능만을 요점 정리 식으로 모아 보았습니다. 아마 플러그인을 제작할 때 참고하는 편리하리라 생각합니다. 별도의 기능을 위해 특정 도움 함수를 만들지 않고 거의 뼈대를 있는 그대로 노출하는 식으로 전개해 보았습니다.
@@ 줄 213: / 줄 203: @@
 사실 플러그인을 제작하다 보면 콜백 함수에서 다시 콜백 함수를 정의해 주어야 경우가 흔합니다. 이렇게 콜백의 깊이가 깊어지면 추적하기도 어렵고 때로는 코드가 지저분하게 될 수도 있습니다. 이 점을 유념하고 플러그인 제작을 하시는 것이 좋겠습니다.
-또한 플러그인에서는 MVC 패턴 등을 기본적으로는 지원하지 않습니다. 굳이 어떻게든 PHP 상에서 MVC를 도입하려면 별도의 PHP 프레임워크와 연동을 시키든지, 아니면 정말 하나하나 만들든지... 해야 합니다. 그런데 고작 플러그인 하나 만들자고 프레임워크까지 도입하기는 너무 무겁습니다. 이에 제가 별도로 워드프레스 플러그인과 테마를 위한 MVC 패턴을 도입하기 위한 실험적인 작은 프로젝트를 진행하고 있습니다. [[https://github.com/chwnam/axis|GitHub]]에 있으니 별도로 참고하시면 감사하겠습니다. 이에 대한 설명은 다음에 차차 적어 보도록 하겠습니다.
+또한 플러그인에서는 MVC 패턴 등을 기본적으로는 지원하지 않습니다. 굳이 어떻게든 PHP 상에서 MVC를 도입하려면 별도의 PHP 프레임워크와 연동을 시키든지, 아니면 정말 하나하나 만들든지... 해야 합니다. 그런데 고작 플러그인 하나 만들자고 프레임워크까지 도입하기는 너무 무겁습니다. 이에 제가 별도로 워드프레스 플러그인과 테마를 위한 MVC 패턴을 도입하기 위한 실험적인 작은 프로젝트를 진행하고 있습니다. [[https://github.com/chwnam/axis|GitHub]]에 있으니 별도로 참고하시면 감사하겠습니다. 이것은 다른 문서에서 차후 다루도록 하겠습니다.
 === 활성화, 비활성화, 제거 ===
@@ 줄 231: / 줄 221: @@
   * 하위 메뉴 페이지 삽입: [[http://codex.wordpress.org/Function_Reference/add_submenu_page|add_submenu_page]]
-{{ :wordpress:wp_plugin_tutorial_001.png?nolink |워드프레스 플러그인 메뉴}}
+{{ :wordpress:image:wp_plugin_tutorial_001.png?nolink |워드프레스 플러그인 메뉴}}
 그림은 플러그인 메뉴가 삽입되고 마우스 커서가 해당 메뉴 페이지 영역에 접근했을 때의 상황을 보여 주고 있습니다. 하나의 메뉴 페이지에 2개의 하위 메뉴 페이지가 삽입된 상태입니다. 그래서 커서가 근접하면 나오는 오른쪽 부분의 서브 메뉴 부분에 총 3개의 항목이 보이게 됩니다. 이렇게 메뉴 페이지를 삽입하면 항상 기본적으로 같은 이름의 하위 메뉴 페이지가 가장 먼저 삽입됩니다. 이 첫번째 메뉴가 의도한 동작이 아니라면 [[http://codex.wordpress.org/Function_Reference/remove_submenu_page|remove_submenu_page]]를 호출하 삭제하면 됩니다.
 === POST 액션 ===
-어떤 폼을 제작해서 사용자로부터 데이터를 받아 서버로 전달하게 해야 한다고 생각해 봅니다. 이 때 메소드를 지정해 주어야 하는데, 주로 GET이나 POST 방법을 사용합니다. 사실 어떤 주소를 사용하든지는 상관없습니다. 어떤 URL이든 서버가 올바르게 접근 가능한 형태로만 만들면 됩니다. 그리고 우리는 그 URL에 해당하는 곳에 적절하게 PHP 스크립트를 작성하면 되죠. 사용자가 보내준 데이터는 어쨌든 $_GET 변수나 $_POST 변수에 저장되어 있습니다.
+어떤 폼을 제작해서 사용자로부터 데이터를 받아 서버로 전달하게 해야 한다고 생각해 봅니다. 이 때 [[http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html|메소드]]를 지정해 주어야 하는데, 주로 GET이나 POST 방법을 사용합니다. 전달할 곳의 URL은 어떤 형태이든 접근 가능하기만 하면 됩니다. 그러나 우리는 워드프레스 플러그인에서 워드프레스의 기본적인 토대 위해 이러한 작업을 처리하고 싶습니다. 그래야 워드프레스에서 제공하는 기능을 활용할 수 있죠. DB 접속 등등의 코드를 우리가 다시 반복해야 할 이유가 없습니다.
+워드프레스는 GET/POST 전송에 대해 하나의 URL을 정해 두고 모든 요청에 대해 처리하도록 디자인되어 있습니다. 대신 각 요청에는 자신이 어떤 요청인지를 스스로 밝히는 식별자를 두고 이 식별자에 의해 어떤 종류의 요청인지 제각각 구분하도록 되어 있습니다. 보통 이 주소는 ''wp-admin/admin-post.php''입니다. 이 주소를 얻기 위해 워드프레스는 [[http://codex.wordpress.org/Function_Reference/admin_url|admin_url]]이라는 함수를 제공합니다. 보통 이렇게 사용해서 URL에 관계없이 일괄적으로 주소를 얻어 활용합니다.
+<code php>
+<?php echo admin_url( 'admin-post.php' ); ?>
+</code>
+모든 종류의 폼이 이 주소로 들어오므로 반드시 이 요청이 어떤 것인지를 구분해 주어야 합니다. 그러므로 모든 폼은 요청에 대한 식별자를 가지고 있습니다. 이 식별자는 'action'이라는 이름이며 이 이름으로 전달된 값으로 모든 요청을 구분합니다. 값은 그냥 문자열이므로 사용자가 알아서 고유하게 구분하기만 하면 됩니다. 이 값은 사용자에게는 보여질 필요가 없으므로 대부분 ''input'' 태그에 ''hidden'' 타입으로 미리 폼에 삽입되어 있습니다.
+한편 사용자가 이렇게 데이터를 처리해주기를 원한다는 사실을 코어도 알고 있어야 합니다. 액션을 등록해야죠. 이를 위해서 코어가 제공하는 훅이 바로 '[[http://codex.wordpress.org/Plugin_API/Action_Reference/admin_post_%28action%29|admin_post_$action]]'입니다. 여기서 ''$action'' 부분은 자신이 원하는 'action' 변수의 값으로 만들어야 하는 규칙이 있습니다. 이렇게 해 두면 코어는 알아서 폼을 전달 받았을 때 우리가 원하는 함수를 호출해 줍니다. 콜백 함수에서는 적절히 [[http://codex.wordpress.org/Class_Reference/wpdb|wpdb]] 같은 것을 이용해서 원하는 동작을 처리하고 원하는 곳으로 사용자를 리다이렉트 시키면 됩니다.
+당연하지만 폼으로 전달받은 값이 항상 올바른 값이라고는 가정해서는 안 됩니다. 항상 폼으로 전달된 변수가 혹시나 서버를 공격하는 위험한 코드가 아닌지 검증해야죠. 이에 대해서는 [[http://codex.wordpress.org/Data_Validation|data validation 코덱스]]를 참고하세요. 그리고 폼에 [[http://codex.wordpress.org/WordPress_Nonces|nonce]]를 넣어 보호하는 것도 잊지 마세요.
-하지만 우리는 워드프레스 플러그인 내부에서 데이터의 송수신을 모두 처리하기를 원합니다. 그래야 워드프레스에서 제공하는 기능을 활용할 수 있죠. DB 접속 등등의 코드를 우리가 다시 반복해야 할 이유가 없으니까요. 그러려면 우리는 워드프레스가 가이드하는 대로 맞춰서 데이터 전송을 준비해야 합니다.
-워드프레스는 GET/POST 전송에 대해 하나의 URL을 정해 두고 모든 요청에 대해 처리하도록 디자인되어 있습니다. 대신 각 요청에는 자신이 어떤 요청인지를 스스로 밝히는 식별자를 두고 이 식별자에 의해 어떤 종류의 요청인지 제각각 구분하도록 되어 있습니다. 보통 이 주소는 ''wp-admin/admin-post.php''입니다.
 === AJAX 액션 ===
+POST 방식은 간결하지만 페이지 전환이 일어난다는 단점이 있습니다. 한 페이지 안에서 보이지 않게 서버 요청을 하려면 AJAX 방식을 사용하는 것이 낫습니다. 워드프레스는 [[http://jquery.com/|jQuery]]를 기본으로 탑재하고 있으므로 자바스크립트에서는 큰 어려움 없이 AJAX 요청을 사용할 수 있습니다. 다만 '$'를 기본적으로는 허용하지는 않으므로((http://codex.wordpress.org/Function_Reference/wp_enqueue_script#jQuery_noConflict_Wrappers)) 항상 'jQuery'를 쓰는 것이 좋습니다.
+AJAX 요청 또한 미리 서버에 등록해 두지 않으면 올바르게 동작하지 않습니다. 세팅이 올바르지 않으면 서버는 항상 '0'만을 리턴합니다. 등록은 언제나처럼 액션을 등록해 주는 것으로 시작합니다.
+AJAX 요청을 등록하려면 [[http://codex.wordpress.org/Plugin_API/Action_Reference/wp_ajax_%28action%29|'wp_ajax_$action']] 훅 또는 [[http://codex.wordpress.org/Plugin_API/Action_Reference/wp_ajax_nopriv_(action)|'wp_ajax_nopriv']] 훅을 사용하시면 됩니다. wp_ajax와 wp_ajax_noprive의 차이는 wp_ajax는 권한 있는 유저에게만 사용 가능하며 wp_ajax_nopriv는 권한이 없는(로그인하지 않은) 유저도 사용할 수 있다는 점입니다.
+AJAX 액션 또한 어떤 특정한 URL에서만 요청을 받습니다. 일반적으로 이 URL은 ''wp-admin/admin-ajax.php''입니다. 보통 ''admin_url( 'admin-ajax.php' )'' 처럼 일관된 주소를 얻을 수 있게 씁니다. 그런데 POST 방식 때와는 달리 이 주소는 자바스크립트 코드 내에서 다루어져야 합니다. 이 주소는 보통 echo를 사용해 출력하기 보다는 워드프레스에서 스크립트의 로컬라이즈를 준비하는 [[http://codex.wordpress.org/Function_Reference/wp_localize_script|wp_localize_script]] 함수를 이용해 자바스크립트 객체에 삽입되어 전달됩니다. wp_ajax_$action은 이 객체가 기본값으로 등록되지만 wp_ajax_nopriv는 기본으로 등록되지 않으므로 항상 wp_localize_script 함수에 해당 URL을 삽입해야 합니다.
+이렇게 액션을 등록한 후, POST와 마찬가지로 AJAX 요청을 할 때 반드시 파라미터에 action 항목이 딸려 오고, 그 action은 훅에서 지정한 $action 문자열과 일치해야 합니다. 예제에서는 AJAX 호출을 할 때 action 이름을 'request_code'라고 이름지었습니다. 이 action을 서버에 등록하기 위해 다음처럼 코드를 넣었습니다.
+<code php>
+add_action( 'wp_ajax_request_code', ... );
+</code>
+폼에는 미리 숨겨진 input 요소를 넣었습니다.
+<code html>
+<input type='hidden' name='action' value='request_code' />
+</code>
+POST와 동일하게 action을 보고 우리가 등록한 콜백 함수를 호출해 줍니다. 함수 호출의 마지막에는 반드시 [[http://php.net/manual/en/function.die.php|die]]를 실행하여 AJAX 응답만 출력하게 한 뒤 다른 동작을 강제로 멈추도록 합니다.
+AJAX는 자바스크립트 기반으로 동작하므로 여기서 자바스크립트 삽입 방법 및 CSS 삽입 방법에 대해 언급하도록 하겠습니다. 물론 HTML 소스 안에 하드 코딩 방식으로 CSS와 스크립트를 우겨 넣어도 관계는 없습니다. 그러나 그다지 안정적인 방법은 아닙니다. 이를 위해 워드프레스에서는 [[http://codex.wordpress.org/Function_Reference/wp_register_script|wp_register_script]], [[http://codex.wordpress.org/Function_Reference/wp_enqueue_script|wp_enqueue_script]], [[http://codex.wordpress.org/Function_Reference/wp_enqueue_style|wp_enqueue_style]] 함수를 제공합니다. 이것으로 스크립트와 스타일 시트를 등록하세요. 예제에서는 스크립트에 대해서만 코드를 작성했는데, 스타일 시트는 이와 비슷하거나 더욱 쉽게 쓸 수 있으므로 생략했습니다.
+보통은 간단하게 wp_enqueue_script 콜 한 번으로 스크립트 삽입은 끝납니다. 그러나 다국어를 대비해야만 한다면 wp_localize_script가 필요합니다. 이 때 추가적으로 wp_register_script를 호출할 수도 있구요. 그래서 저는 아예 처음부터 스크립트를 출력할 때는 wp_register_script -> wp_localize_script -> wp_enqueue_script 순으로 호출합니다.
 === Rewrite ===
-=== 로컬라이즈 ===
+일단 이 기능은 서버에 rewrite가 가능해야만 동작합니다. 예를 들어 아파치 서버를 쓴다면 rewrite 모듈이 있어야 동작합니다.
+어떤 URL의 규칙을 다른 규칙으로 변경해주는 역할을 합니다. 보통 .htaccess 안에 많이 삽입하기도 하는데, 워드프레스에서 함수로도 이 기능을 제공합니다. [[http://codex.wordpress.org/Rewrite_API/add_rewrite_rule|add_rewrite_rule]]을 참고하세요.
+이 기능을 이용해서 지저분한 URL을 좀 더 깨끗하게 만들 수 있습니다. 예제에서는 ''/tutorial/(어떤 문자열)'' 방식의 주소를 허용하도로고 했습니다. 이런 형식의 주소는 자동으로 ''index.php?tutorial=(어떤 문자열)''과 같이 변형됩니다.
 === 쿼리 파싱 ===
-=== 템플릿 라우팅 ===
+rewrite를 이용해 ''/tutorial/(어떤 문자열)''은 ''index.php?tutorial=(어떤 문자열)''로 치환되었으나, 이것만으로는 부족합니다. 왜냐하면 워드프레스 코에에 파라미터인 ''tutorial=(어떤 문자열)''을 어떻게 처리할 것인지를 전혀 알려 주지 않았기 때문입니다.
+코어는 정해진 쿼리 변수 이외에는 반응하지 않도록 되어 있습니다. 우리가 임의의 파라미터를 처리하려면 미리 코어에 그 파라미터의 존재를 반드시 알려 주어야 합니다. 이를 담당하는 훅은 'query_vars' 훅입니다. 그리고 이 훅을 통해 제어하는 것은 사이트의 행동 방식이 아닌 데이터 자체이므로 add_action이 아닌 add_filter를 사용해야 합니다.
+add_filter에 등록한 콜백은 하나의 인자를 받는데, 여기에 쿼리로 받을 수 있는 파라미터의 목록(array)이 전달됩니다. 이 목록에 원하는 내용을 추가한 후 **반드시** 이 목록을 리턴하세요. 예제에서는 'tutorial'이라는 파라미터를 허용하도록 콜백을 구성했습니다.
+이제 쿼리 파라미터를 허용했으므로 파라미터의 값이 코어로 전달됩니다. 하지만 여기까지는 값이 전달된 것입니다. 이 값에 어떤 동작을 하라고는 정해 주지 않았습니다. 그러므로 액션을 추가하여 요청 파라미터를 분석 후 원하는 동작이 이루어지도록 해야 합니다. 이것을 위해 'parse_request'라는 훅이 있습니다. add_action을 통해 훅을 등록합니다. 이 훅의 콜백에 우리가 원하는 파라미터를 발견하면, 그 파라미터의 값에 따라 원하는 동작을 하도록 추가할 수 있습니다.
+예제에서는 parse_request 훅에 대한 동작을 다음과 같은 방식으로 추가했습니다. 쿼리 중 tutorial이라는 파라미터를 발견하면 특정 페이지로 이동합니다. 이 특정 페이지는 플러그인이 임의로 만들어내는 페이지입니다.
+=== 템플릿 리다이렉트 ===
+플러그인에서 특정 페이지로 이동을 시키기 위해서는 'template_redirect' 액션을 사용합니다. 이것으로 플러그인이 임의로 템플릿이나 워드프레스 기본 '페이지' 메뉴를 이용하지 않고도 어떤 페이지를 생성할 수 있습니다.
+=== 커스텀 포스트 ===
+플러그인은 tutorial 타입의 커스텀 포스트를 생성합니다. 관리자 메뉴에서 이 포스트 메뉴가 나오고, 이 타입으로 새로운 글을 작성도 가능합니다. 커스텀 포스트를 생성하기 위해서는 [[http://codex.wordpress.org/Plugin_API/Action_Reference/init|init]] 훅에 [[http://codex.wordpress.org/Function_Reference/register_post_type|register_post_type]] 함수를 호출하면 됩니다. 이 함수는 옵션의 개수가 엄청나게 많지만, 많은 값들은 적절히 기본값으로 써도 무방합니다.
+그리고 '메타 박스'라고 하여 커스텀 포스트에 항상 고정적으로 들어갈 수 있는 필드들을 미리 UI 상으로 만들어 주는 기능도 가지고 있습니다 그런데 이 UI 위젯을 모조리 사용자가 직접 디자인해 주어야 하므로 앞서 말씀드렸든 폼을 구성하기 위해 콜백 함수가 많이 등록됩니다. 이러한 위젯은 재사용성이 큰데, 일일이 만들기도 힘들고 어렵습니다. 그래서 왠만해서는 그냥 [[https://wordpress.org/plugins/types/|types]] 플러그인이 훨씬 편합니다.
+=== 로컬라이즈 ===
+== 텍스트 도메인 ==
+간단히 말해 플러그인이 출력하는 텍스트가 어떤 소속인지를 지정하는 것입니다. 이렇게 지정해 두지 않으면 모든 번역문이 뒤죽박죽이 되어 있겠지요. 이 텍스트 도메인은 미리 메인 파일의 [[http://codex.wordpress.org/Writing_a_Plugin#File_Headers|플러그인 헤더]]에 지정해 두고 사용하실 수 있습니다.
+== 코드 처리 ==
+워드프레스 로컬라이즈는 [[http://www.gnu.org/software/gettext/|gettext]]를 기반으로 합니다. 간단히 말해 출력되는 모든 문자열애 대해 다른 언어로 번역을 하고, 기본 언어가 아닌 다른 언어를 사용할 때 해당 번역을 출력하는 방식입니다.
+  * PHP 자체에 gettext 라이브러리가 있습니다. 텍스트 키워드를 위해 [[http://php.net/manual/en/function.gettext.php|_()]]가 있습니다. 언더스코어(_) 한 개입니다. 호환성을 위해 워드프레스는 언더스코어가 두 개인 [[http://codex.wordpress.org/Function_Reference/_2|__()]]를 별도로 정의해 사용합니다.
+  * 한편 [[http://codex.wordpress.org/Function_Reference/_e|_e]]도 있습니다. <nowiki>__</nowiki>()와 기능은 같지만 번역 문자열을 출력까지 해 주는 함수입니다.
+  * 단수/복수에 대한 출력을 고려해야 한다면 [[http://codex.wordpress.org/Function_Reference/_n|_n]] 함수를 이용하면 됩니다.
+이렇게 모든 출력되는 텍스트에 대해 미리 <nowiki>__</nowiki>(), _e(), _n() 등의 함수 처리를 해 두면, gettext를 활용한 텍스트 번역을 할 수 있습니다.
+== 텍스트 번역 ==
+번역은 [[http://poedit.net/|Poedit]] 같은 툴을 활용하는 것이 좋습니다.
+예제에서는 메인 페이지에 나오는 'Hello, World' 한 줄과 register_post_type을 선언하면서 만든 텍스트가 전부이지만 플러그인 번역에 대한 예제로는 충분할 것으로 생각합니다.
+{{ :wordpress:image:poedit_001.png?nolink&300 |}}
+위 그림은 Poedit 실행 화면입니다. Poedit은 인터페이스가 썩 좋은 편이 아니라 한 단계씩 자세히 설명하겠습니다. 예제 플러그인은 새롭게 시작하는 번역 작업이므로 새 카탈로그를 만들어야 합니다. File > New Catalog을 선택합니다.
+{{ :wordpress:image:poedit_002.png?nolink |}}
+Project 이름으로 적당히 지어 줍니다. 우리는 기본 영어에서 한국어로 번역을 할 것이므로 Language에는 ''ko_KR''을 입력합니다. Plural Forms란에는 ''nplurals=1; plural=0;''을 입력합니다. 다른 언어의 Pluram Form에 대해서는 [[http://docs.translatehouse.org/projects/localization-guide/en/latest/l10n/pluralforms.html?id=l10n/pluralforms|이 곳]]을 참고하세요.
+{{ :wordpress:image:poedit_003.png?nolink |}}
+이제 플러그인 소스 경로를 지정해 주어야 합니다. Sources paths 탭을 선택해 줍니다. 그리고 다른 파일 탐색기를 통해 플러그인 소스 경로를 **복사**한 후 경로를 지정해 줍니다. 직접 창에서 경로를 선택하는 방법이 없습니다.
+{{ :wordpress:image:poedit_004.png?nolink |}}
+그다음 번역할 텍스트를 스캔할 키워드(함수) 이름들을 선언해 줍니다. 기본으로 '_', 'gettext', 'gettext_noop'가 있지만 워드프레스에서는 다른 키워드를 사용하므로 위 그림처럼 '<nowiki>__</nowiki>', '_e', '_n'을 넣어 줍니다.
+확인 버튼을 누르고 po 파일을 다른 이름으로 저장하면 됩니다. 그리고 이렇게 만든 파일은 바로 .pot 파일로 만들어 템플릿으로 저장해도 됩니다. 이렇게 파일이 만들어진 후에는 소스에서 텍스트를 추출해 보여주게 됩니다. 혹시 보이지 않는다면 경로를 확인하고 Update 버튼을 눌러주세요.
+<WRAP center round info 60%>
+po 파일을 저장할 때, '(워드프레스의 텍스트도메인 이름)-(언어코드)' 식으로 짓는 것이 편리합니다. 왜냐하면 워드프레스에서 로컬라이즈가 완성된 형태인 .mo 파일을 읽을 때 반드시 저런 이름을 지킬 것을 요구하기 때문입니다((http://codex.wordpress.org/Installing_WordPress_in_Your_Language#Manually_Installing_Language_Files)). 예를 들어, 예제 플러그인의 텍스트 도메인은 'wp_plugin_tutorial'입니다. 이 때 한글 번역 파일 이름은 반드시 'wp_plugin_tutorial-ko_KR.mo'가 되어야 합니다. 비슷하게 플러그인에 대해 일본어로 번역을 했다면 'wp_plugin_tutorial-ja.mo'((http://wpcentral.io/internationalization/ja/))가 됩니다.
+</WRAP>
+{{ :wordpress:image:poedit_005.png?nolink |}}
+각 소스의 텍스트를 한국어로 변역해 주면 됩니다. Source Text를 보면서 하나하나 번역을 해 주면 됩니다. 아래처럼 Preferences 메뉴에서 'Automatically compile .mo file on save'를 체크하셨다면 저장 할 때마다 .mo 파일이 생성되므로 편리합니다.
+{{ :wordpress:image:poedit_006.png?nolink |}}
+모든 텍스트를 변역했으면 저장하고 poedit을 닫습니다. .mo 파일이 생성되면 플러그인에서 번역된 텍스트를 이용할 수 있습니다.
+== 번역문 출력 ==
+플러그인 로딩 때 .mo 파일을 로드하도록 하면 됩니다. 해당 훅은 'plugins_loaded'이고 이 훅의 콜백에서 [[https://codex.wordpress.org/Function_Reference/load_plugin_textdomain|load_plugin_textdomain]] 함수를 호출하면 됩니다.
+  * 첫번째 인자로 플러그인의 텍스트 도메인을 넣습니다. 여기서는 wp_plugin_tutorial을 텍스트도메인으로도 썼습니다.
+  * 두 번째 인자는 폐기되었기 때문에 그냥 false를 넣어도 됩니다.
+  * 세 번째 인자로는 .mo 파일이 있는 곳의 경로를 지정해 줍니다. .mo 파일의 파일 이름은 (텍스트도메인)-(언어코드)로 지으라는 규칙이 있으므로 그 파일이 있는 곳의 경로만을 입력합니다.
+워드프레스가 영어와 한글로 번역되는지를 확인하세요. Settings-General에 보면 Site Language라는 항목이 있습니다. 여기서 'English'와 '한국어'를 찾을 수 있어야 하죠.
+{{ :wordpress:image:poedit_007.png?nolink |}}
+워드프레스를 영문으로만 설치했으면 한글 번역이 별도로 설치되지 않았을 수도 있습니다. 서버 설정에 따라 언어를 자동으로 다운로드 받을 수 있고, 언어 파일을 별도로 설치해야 할 수 있습니다. 언어 팩은 [[https://make.wordpress.org/polyglots/handbook/about/teams/| 여기]]나 [[http://wpcentral.io/internationalization/|여기]]를 통해 개별적으로 다운로드 가능합니다. 플러그인의 언어는 워드프레스 사이트 언어에 종속됩니다. 각각 영어와 한글로 언어를 변경해서 플러그인에서도 언어가 변경되는지 확인해 보세요.
+===== 끝내며 =====
+그동안 워드프레스 플러그인에 대해 한 번 정리를 해 보고 싶었습니다. 플러그인 자체는 그다지 어려울 것이 없습니다. 코어에 원하는 기능을 등록하고, 그 등록된 기능에 대해 호출이 왔을 때 어떤 식으로 동작할지 정의해주는 것이 전부입니다. 여기서 어떤 때 어떤 훅을 써야 하는지, 어떤 API 함수를 써야 하는지 잘 알아 두는 것이 좋겠죠.
+플러그인은 워드프레스를 확장하는 데 있어 핵심적인 역할을 합니다. 이미 수많은 플러그인들이 개발하여 코어 자체로는 하지 못하는 일들을 보조해 주고 있습니다. 잘만 활용하면 워드프레스만으로도 엄청나게 많은 일들을 할 수 있습니다. 보고 있으면 하나의 플랫폼 같다는 생각이 들기도 합니다.
+조언해둘 것이 있습니다. 플러그인과 템플릿은 둘 다 워드프레스를 확장하는 기능입입니다. 그러나 둘의 역할은 분명히 다릅니다. 템플릿은 워드프레스를 어떻게 보여줄지에 더욱 집중이 된 요소이고, 플러그인은 기능적인 확장에 더 집중된 요소입니다. 다시 말해 잘못하면 둘의 역할을 구분 없이 섞어서 쓰는 것도 사실은 가능하다는 말입니다. 그렇지만 그렇게 기능을 섞으면 안 됩니다. 템플릿은 템플릿이 하는 것이 좋고, 플러그인은 플러그인이 하는 일로 제한해야 합니다.
+예를 들어 템플릿에서도 액션을 걸어서 유저가 프로필을 업데이트 할 때마다 특정 동작을 할 수 있게 만들 수 있습니다. 예를 들어 프로필의 업데이트된 내용을 다른 서버와 동기화 한다든지 같은 시나리오가 될 수 있겠네요. 그런데 이런 기능을 템플릿에서 꼭 해야만 할 이유가 없습니다. 만일 템플릿을 바꾼다면 그 기능이 동작하지 않게 될 수 있겠죠. 이와 반대의 경우도 마찬가지입니다. 템플릿에서 해야 할 일으르 플러그인에서 해 버리면 그것도 좋지 않습니다.
+이것은 플러그인 사용상의 조언입니다. 직접 플러그인을 만들어 보시거나, 만들어진 플러그인의 소스를 보면 아실 겁니다. 수많은 액션, 필터의 범벅으로 구성되어 있습니다. 이렇게 수많은 훅들이 걸리고, 또 그에 대해 서버가 이에 대응을 하는 방식으로 구성되어 있습니다. 그러므로 사용하지도 않는 플러그인을 무의미하게 활성화시켜 두면 그만큼 서버는 불필요하게 동작할 수 있겠죠? 그러므로 안 쓰는 플러그인은 비활성화 시켜 두는 것이 좋습니다.
+워드프레스 플러그인에 대해 정리를 했으니 다른 것도 차차 정리해 두고 싶습니다. 다음과 같은 내용들이 다음 타겟이 될 수 있겠네요.
+  * AXIS <del>영업</del> 소개
+  * 커스텀 포스트
+  * 주요 훅
+  * Option API
+  * WP Table