워드프레스는 주소 체계를 이용자가 원하는 다양한 형태로 꾸릴 수 있는 기능을 제공한다. 이용자가 글 마다 주소를 만들어서 지정하거나 날짜, 혹은 글 번호 등 다양한 변수를 써서 주소를 꾸릴 수 있다. 한날의 낙서와 한날은 생각한다는 주소 체계를 /%postname%/ 라고 설정하고 글 마다 주소를 정하고 있다. (솔직히 아주 귀찮다. -_-)

이렇게 자유로운 주소 체계 가능하다보니 사람들이 워드프레스 주소 체계를 정확히 이해하지 않은 상태에서 주소를 만들어 쓰다가 낭패를 겪는 경우가 있다. 예를 들면, 글 주소 체계를 숫자로만 한 경우이다. 이 주소 체계는 글 숫자가 1000 미만인 경우 문제가 없지만 1000 이상이면 문제가 생긴다. 예를 들어보자.

“이 글은 존재하는 글이지만 접근할 수 없는 글입니다.”라는 글의 낱장 주소는 http://www.hannal.net/blog/1023 이다. 그런데 이 글의 낱장 주소인 http://www.hannal.net/blog/1023로 접근하면 그런 글이 없다고 나온다. 이 글 미리보기 기능 주소인 http://www.hannal.net/blog/?p=1153&preview=true 로 접근해야 글을 볼 수 있다. 왜 이런 일이 생기는 것일까? 워드프레스의 오류(버그)일까?

2. 문제 원인

결론부터 말하자면 오류가 아니다. 나 조차 워드프레스 구조와 흐름을 꼼꼼히 살펴보지 않았을 때에는 워드프레스 오류라고 생각했었다. 이 문제는 사실 워드프레스 주소 체계와 기계의 고지식함(?)을 생각하면 아주 당연한 것이며, 따지고보면 이용자 부주의로 생긴 일이다.

워드프레스 주소 종류는 다음과 같이 나뉜다.

1. 쪽 글(page) 주소 : /기본주소/쪽주소/
2. 관리자 영역 주소 : /기본주소/wp-admin/
3. 년도/달 단위 주소 : /기본주소/년도/달/
4. 글 갈래 주소 : /기본주소/category/ (혹은 따로 지정 가능)
5. 꼬리표 주소 : /기본주소/tag/ (혹은 따로 지정 가능)

이외 몇 가지 규칙이 더 나올 수 있는데 여기선 논외로 치자. 여기서 중요한 것은 바로 세 번째 항목인 “년도/달 단위 주소”이다. 만약 워드프레스를 “도메인/blog/”에 설치했을 경우 년도/달 단위 주소는 “도메인/blog/2008/04” 형태가 된다. 바로 이것이 문제(?)이다. 만약 글 주소 체계를 글 번호로만 하거나 혹은 글 주소 이름으로만 한 뒤 그 주소 이름을 1000 이상 숫자로 하는 경우, 그러니까 “도메인/blog/1000” 이런 식으로 할 경우 “년도/달 단위 주소”와 주소 규칙이 부딪히게 된다.

워드프레스는 기본주소 바로 뒤에 붙는 숫자가 1000 이상인 경우 이 숫자를 년도로 인식한다. 그러므로 글 주소가 워드프레스를 설치한 기본 주소 바로 뒤에 숫자 1000 이상인 경우 글로 접근하질 않고 1000년으로 접근을 한다. 당연히 1000년에 쓴 글이 없을테니 자료가 없다고 나오는 것이다.

3. 문제 해결

해결 방법은 간단하다. 글 주소를 기본 주소 바로 뒤에 숫자로만 붙게 하지 않으면 된다. 아니, 붙게 하더라도 그 숫자가 1000이상이 되지 않게 하면 된다. 혹은, 이 숫자 앞이나 뒤에 다른 문자열을 넣어서 년도와 구분을 해주면 된다.

해결 예제

• /%post_id%/ => /archives/%post_id%/ , /entry/%post_id%/ , /a/%post_id%/ , 이외 글 주소와 년도/달 단위 주소를 구분 지을 문자열이면 아무거나 무관. (숫자 빼고 -_-; )
• 혹은 아예 다른 주소 체계

굉장히 좋은 방법은 글 주소 구조에 해당 주소가 글 주소라는 걸 알 수 있는 낱말을 집어 넣는 것이다. /entry 라든가 /archives 같은 걸 넣는 것이다. 그렇게 하지 않고 나처럼 /%postname%/ 이렇게 하면 글 주소 이름을 숫자로 하지도 못하고, 그렇다고 글 주소를 한글로 하기도 애매해서 매번 글 주소 이름을 영문으로 짓느라 고생하게 될 것이다. -_-; 워드프레스 2.5에 주소체계 견본으로 /archives/%post_id%/ 가 괜히 있는 것이 아니다.

(굳이 변명을 하자면 난 워드프레스 1.2때부터 썼는데 당시엔 이런 배려가 없었으며, 예쁜주소(fancy url) 기능을 만들어주는 .htaccess 관리 정책도 지금과 완전히 달랐다)

덧쓰기 : 윽, 젠장. 이 글 주소에 wordpress를 오타 쳐서 wordpres 라고 쳤다. -_-

그러다 최근 몇 달 이런 마이크로 블로그나 사람 관계(인맥) 관리 서비스에 몇 가지 불편한 경험을 했습니다. 서비스 자체 문제라기 보다는 사람과 사람 사이에서 일어나는 일이 문제지요. 그래서 거리를 좀 둬야겠다는 마음을 먹었습니다. 제 개인 얘기를 굳이 다른 사람과 일부러(?) 잇지 말고 제 개인 공간에 하는 것이 제게도 좋고 절 불편해하는 사람에게도 좋겠다는 생각한 것이지요.

처음엔 중얼거림을 남길 공간을 직접 다 만들려 했습니다. 투자할 시간은 단 하루. 글을 써넣고 꺼내보는 기능이면 끝이니 하루 투자하면 후다닥 만들 수 있겠다 생각한 것이지요. 그런데 이 공간에 대한 궁리를 이리 저리 하다보니 점점 필요한 기능이 늘어나 마침내 히말라야 꼭대기에까지 올라 훌륭한(?) 마이크로 서비스를 만든 상상을 하고 있더라고요.

결국 다시 재미거리들을 다 쳐내고 꼭 필요한 것들만 골라 냈습니다. 그래도 하루 안에 다 만들긴 좀 벅차 보였습니다. 밖에 있는 다른 글에 글을 건다거나 파일을 첨부하거나 무단 자동 광고를 막는 기능은 이리 저리 시험 및 실험을 많이 해야 하기 때문이지요. 각 기능마다 하루씩 필요해 보였습니다. 흐음, 이를 어쩐다?

고민 끝에 내린 결론은 워드프레스를 활용하는 겁니다. 이유는 두 가지입니다. 첫째, 4년 가까이 써온 도구라서 구조를 거의 파악하고 있고, 둘째, 껍데기(template)와 부가기능(plug-in)으로 확장할 수 있는 범위가 아주 넓어서 제가 원하는 기능이나 꼴을 이끌어 낼 수 있기 때문이지요. 워드프레스는 블로그 저작 도구이지만, 이 경우엔 웹 프레임워크 역할을 하는 셈입니다.

웹 프레임워크로 워드프레스를 결정하고 바로 개발을 착수 했습니다. 개발이라고 해봐야 사실상 껍데기(template) 개발이 전부였습니다. 어제 점심 먹고 바로 시작해서 오늘 점심 먹을 때쯤 다 만들었으니 정말 하루 걸렸네요.

자, 여기 그 결과물입니다. 짠! 이름하여

중얼 중얼 한날

입니다. 관리자 권한으로 접근하면 아래와 같이 글쓰기 영역도 함께 나옵니다.

그럴 듯 하죠?

워드프레스는 댓글을 보려면 해당 글을 낱장으로 열어야 합니다. 요즘 유행하는 Ajax + DHTML 방식으로 열지 않지요. 그래서 약간 꼼수를 부려 구현했습니다. 워드프레스에는 댓글을 돌출창(pop-up window)으로 따로 가져와 볼 수 있는 기능이 있는데, 이 화면 자체를 Ajax 로 가져와 출력하는 것이지요. 실험해보니 잘 되네요.

댓글은 누구나 달 수 있게 할까 말까 고민하다가 OpenID에 접속한 사람만 댓글 달 수 있게 했습니다. 무단 광고(스팸)이 귀찮기도 하고, 혼자말이 목적이라 열렬하게 모르는 누군가와 토론을 할 생각이 없기 때문입니다(OpenID 접속이 필수이면 귀찮아서라도 제 혼자말에 굳이 토 달지 않을테니까).

아참, W3C XHTML 1.0 Transitional도 깔끔하게 통과 했습니다. 으하하. 어지간히 디자인 끝내고 혹시 하는 마음에 슬쩍 찔러봤는데 한 번에 통과 했네요. (하지만 역시나 인터넷 익스플로러에선 화면이 좀 깨지나 봅니다. 밤에 고쳐야지 -_-)

맥 운영체제(Mac OS X) 일 때는 웹에서 글을 쓰고, 윈도우 운영체제 일 때는 Windows Live Writer로 글을 씁니다. 블로그와도, 서비스형 마이크로 블로그와도 맛이 색달라서 묘하면서도 좋네요.

그냥 새 공간 하나 더 열었다고 알리는 글 치고는 참 길게 주절거렸네요. 요즘 천덕꾸러기처럼 구박만 받았지 칭찬에 목 말라서 그런가 봅니다. 하하.

그런데 몇 개월 전부터 나는 워드프레스가 불편하다고 느끼고 있다. 첫째는 자동 광고 등록기 때문이고, 둘째는 자잘한 오류나 문제점들 때문이다. 워드프레스는 이용자가 무척 많다. 그래서인지 워드프레스로 날아오는 광고 글은 무척 많다. 많은 것들을 akismet 이라는 거름기(filter)가 걸래내고 있지만, 그래도 제법 이 거름기를 뚫고 무사히(?) 광고 댓글이 달리곤 한다. 뭐, 이건 워드프레스만 안고 있는 문제가 아니라고 치고.

두 번째 불편함은 워드프레스의 강점이 문제가 된 상황이다. 이 글에서 도마 위에 올리려는 내용도 바로 이 부분이다. 워드프레스는 그 자체를 최대한 작게 만들었다. 요즘엔 기본 기능처럼 쓰이고 있는 꼬리표(tag) 기능도 워드프레스엔 아직도 없다. 워드프레스만 깔면 썰렁한 느낌이 들 정도로 기능이 아주 적다.

대신 여러 확장도구를 만들어 쉽게 붙여 쓸 수 있게 구조를 아주 잘 만들었다. 어지간한 거의 모든 것은 워드프레스에서 확장기능(도구)과 껍데기로 만들 수 있다. 놀라울 정도로 확장성 있는 구조 덕에 이용자들은 자신이 원하는 기능만 가져다 붙여서 쓸 수 있다. 확장 도구는 전 세계에 있는 수 많은 사람들이 만들어서 공개하고 있기 때문에 아주 다양하고 그 수도 많다. 바로 이 점에 내가 반해서 3년 가까이 써온 것이다.

그런데, 문제는 워드프레스 구조가 확정되어 고정된 상태가 아니라는 데에 있다. 워드프레스 구조는 지금도 꾸준히 조금씩 바뀌고 있으며 가끔 중요 정책이 바뀌기도 한다. 이렇게 구조나 정책이 바뀌면 예전 판에 호환되는 일부 확장도구는 호환성에 문제가 생기기도 한다. 예를 들면, 워드프레스에서 꼬리표(tag) 기능으로 널리 쓰이는 Ultimate Tag Worrior 3.x판은 워드프레스 2.1과 잘 어울리질 못했다. 그래서 글을 쓸 때마다 예전 글에 쓴 꼬리표들이 홀라당 날아가곤 했다. 물론, 이런 저런 문제점을 해결한 Ultimate tag worrior 최종판(final)이 나오긴 했지만, 한동안 이 문제로 괴로워했다.

즉, Wordpress를 개발하고 배포하는 곳에서는 그 작은(?) Wordpress만 보완할 뿐, 본체인 Wordpress에 붙어서 움직이는 확장 도구는 건드리지 않는다. 그래서 Wordpress가 기침이라도 한 번 하면 여러 확장도구들이 몸살을 앓는 경우도 있다.

또 다른 문제는, Wordpress 정책이나 구조 변화가 오래 전부터 Wordpress를 써오던 이용자에게 독이 되는 경우이다. 확장도구 문제가 아니라 바뀐 Wordpress 정책이 예전 Wordpress 정책과 충돌해서 Wordpress 안에서 문제가 발생하는 경우이다.

예를 들면, UTF-8를 지원하지 않는 mysql이 두루 쓰이던 Wordpress 1.5판 시절엔 Wordpress는 문자열을 어거지로 UTF-8 상태로 DB에 넣었다. 당연히 문자열은 깨져서 들어갔다. 그런데 시대는 변해서 요즘엔 UTF-8를 지원하는 mysql 깔린 곳이 많다. 무심코 옛 Wordpress 내용을 utf-8 를 지원하는 mysql로 옮기면 글을 검색하지 못하는 문제가 생긴다. 글자형이 다르기 때문에 일치하는 문자열을 찾는 Wordpress 검색 기능으로는 분명 존재하는 글인데도 찾지 못하는 문제가 생기는 것이다. 게다가 Wordpress는 아직도 DB 테이블을 만들 때 utf-8로 글자형을 지정하지 않고, mysql에서 설정한 기본 글자형을 그대로 쓰고 있다. T_T 만약 호스팅 업체에서 mysql 기본 글자형을 latin1 처럼 utf-8로 안할 경우 방금 얘기한대로 DB에는 글자가 깨져서 들어가게 된다. ㅜㅜ 범용성 때문에 이러는 것 같은데, 사실 이건 mysql 환경 설정 변수를 검색해서 utf-8가 아니면 set names utf8; 이라는 mysql 명령어 한 번 실행해주면 해결되는 문제이다! ㅜㅜ

물론, 정책이 바뀐다고 해서 언제나 안좋은 것은 아니다. 문자열 거름 정책이 바뀌어서 예전엔 쓸 수 없었던 > _ < 같은 글자(정확히는 < 이것)를 이젠 쓸 수 있다. 하지만, 크건 작건 정책이나 구조가 바뀌면서 혼란이 일어날 수 밖에 없다.

이외에도 글 낱장주소 구조를 /%postname%/ 으로 하고 글 slug(낱장주소 이름)를 숫자로 할 경우 999까지만 쓸 수 있고 1000부터는 워드프레스가 글을 찾지 못하는 증상도 문제이며, 이 문제는 아직 해결되지 않고 있다. 예를 들면, http://www.hannal.net/blog/999 는 접근이 되는데 http://www.hannal.net/blog/1000 엔 그런 것 없다는 오류를 만나게 된다. 숫자로 된 주소 앞이나 뒤에 문자를 넣어줘야 한다. /blog/a1000 나 /blog/1000a , 혹은 /blog/entry/1000 이런 식으로 말이다. 아마도 RewriteRule 과 관련된 충돌인 듯 하다. (물론, 몇 개월 전에 오류 보고를 했지만 답을 아직 받지 못했다)

정리하면 워드프레스의 강점인 작은 몸체와 유연한 확장 도구 구조가 여러 정책 변화나 상황에 맞물려 오히려 독이 되는 경우가 생기는 점이다. 그래서 나는 텍스트큐브로 옮기는 걸 고민하고 있다. 기존 낱장주소(permalink)를 보존하고 보장할 방법이 아직 마땅지 않아서 갈아타고 있진 않지만, 예전 주소를 보존할 수 있는 방법을 찾는다면 망설임 없이 텍스트큐브로 갈아타려 한다. 태터툴즈 시절엔 무겁고 느려서 쓸 생각도 안했는데(분석 차원에서 깔아다 끄적대긴 했지만), 태터툴즈부터 쌓인 개발자들의 개발/운영 경험이나 한결 가볍고 빨라진 구조를 보면 이제는 마음 놓고 쓸 수 있겠다.

언제쯤 예전 낱장주소를 보존할 수 있는 방법을 제시해줄 것인지 알 수는 없지만, 예전 낱장주소를 보존할 방법이 나온다면 바로 텍스트큐브로 갈아타련다.

덧쓰기 : 어째 글 마무리는 얼른 해결 방법 제시해달라고 떼 쓰는 것 같네? 히히.

안녕하세요.

혼자서 갖고 놀던 워드프레스용 Script 하나를 공개합니다. 심장에 바람이라도 들었나봅니다.

이 도구는 워드프레스에 써놓고 공개한 글 중 아무거나 하나를 골라 보여줍니다.

전 가끔 제가 쓴 지난 글을 읽으며 키득거리곤 합니다. 아~ 나도 참 가열차게 참견하고 다녔구나! 하는 생각이 들기도 합니다. 하지만, 블로그의 화면 구성 특성상 최근 글은 봐도 지나간 글은 잘 보지 않지요. 불편하달까요. 제 블로그가 지난 글 찾아보기에 불편한 구조라서 그런 걸지도 모르겠습니다. HTML이나 CSS 고치기 귀찮아서 좀 더 귀찮지 않은 방법을 생각하다가 워드프레스에 있는 기능을 이용했습니다. 이 도구 덕분에 지난 글을 읽기 편해졌습니다.

• 도구 이름 : Random article. …이라고 해두죠.
• 저작권 : 없습니다.
• 실험해본 곳 : Wordpress 2.0.3. 실은 1.5.2에서도 확인해볼 수 있었지만, 운영 정책상 1.5.2에선 실험해보기 귀찮아서 안했습니다. 아마 잘 될 겁니다.
• 내려받기 : random article 20060804판. 쓰는 법은 저 아래를 보세요.

쓰는 법

1. 아주 간단합니다. 이 파일을 여러분이 쓰고 있는 Wordpress의 template 디렉토리에 넣으세요. 저를 예로 들면, 제가 사용하는 껍데기는 almost-spring 이기 때문에 이 파일을 wp-content/themes/almost-spring 에 넣었습니다.
이것은 확장도구(plug-in)가 아니니 wp-content/plugins 에 넣으면 아무 일도 일어나지 않습니다. 그만큼 이것은 위험도가 낮습니다. (?????)

2. 이 파일의 확장자를 php로 바꾸십시오. 내려받을 때 확장자는 txt 입니다. 파일이름에 이상한 숫자도 붙고 했으니 아예 파일이름 전체를 바꿔봅시다. random_article.php로요. 원하는 다른 파일이름이 있다면 그걸로 해도 상관없습니다. 파일이름은 여러분의 마음 속에 있으면 그만입니다. 단, 파일 확장자는 반드시 php로 해야 합니다.

3. 이 파일은 정확히 말해서 Template 파일입니다. 때문에 ‘쪽 (page)’에다가 붙여야 합니다. 그러려면 ‘쪽’부터 써야 겠군요.
관리자 화면에 가셔서 ‘쪽 쓰기’로 가십시오. 아마 주소는 http://여러분의주소/워드프레스/wp-admin/page-new.php 일 겁니다. 남의 워드프레스 주소를 입력한게 아니라면 아마 쪽쓰기 화면이 잘 나올 겁니다. 거기에 잘 찾아보시면 ‘쪽 템플릿‘이라고 있을 겁니다. 거기에서 ‘펼침선택상자’(Select box)를 누르면 Random article이라고 보일 겁니다. 위에 있는 1~2번 과정을 정확히 했다면 분명히 Random article이라는 것이 나옵니다. 그걸 고르십시오. ‘쪽이름’은 적당히 짓고 ‘주소’도 예쁘고 지으십시오. 편의상 쪽이름은 ‘아무거나 읽기’로 하고 주소는 ‘random_article’이라고 해보죠.

4. 이제 여러분이 방금 만든 쪽을 열어보십시오. 다른 글로 이동할 겁니다. 제 블로그인 ‘한날은 생각한다‘에 와서 보시면 친절한 길라잡이에 ‘아무 글이나 읽기’라는 것이 있는데, 이것이 지금 제가 이렇게 배포하고 있는 걸로 작동하는 겁니다.

어때요. 참 쉽죠?

Bad behavior는 자동 광고(스팸, Spam) 등록기를 막아주는 도구(플러그인, Plugin)이다.

자동 광고 등록기에 대항하는 방법은 여러 가지이다. 광고 글이 등록될 때 광고 글들의 특성을 파악하여 이 글들을 일반 글들과 구분시켜 준다. 예를 들어, Akismet은 글에 특정 주소나 단어가 있으면, 혹은 글 등록자의 정보를 토대로 해서 광고 글로 구분시켜 놓는다. 이렇게 분류된 글들을 보고 이용자는 삭제할지 여부를 결정한다.

이 방식의 장점은 광고 글이 아닌데 광고 글로 판정 받아 억울하게 삭제 당할 수 있는 글들을 구제할 가능성이 높은데 있다. 단점은 광고 분류 규칙에서 벗어나서 광고 글로 분류되지 않는 것과 요즘처럼 어마 어마하게 광고를 등록해대는 곳들의 물량 공세를 이겨내기 버겁다는 점이다.

또 다른 방식은 자동 광고 등록기의 접근을 막아버리는 것이다. 아예 접근을 막아서 애초에 광고 글 게재 자체를 못하게 한다. 장단점은 위 방식과 반대.

Bad behavior는 접근 자체를 막는 방식이다. 이 도구가 판단했을 때, 누리집에 접근하는 이를 평가해서 평가 미달이면 접근을 막는다. 그 평가 기준은 이름(bad behavior : 나쁜 짓, 나쁜 행동)에서 알 수 있듯이 접근한 이의 행동이다. 접근한 이가 의심스럽게 생겼거나 나쁜 짓을 하려고 품을 잡으면 쫓아낸다.

Bad behavior는 여러 정보 게재 도구(블로그, 위키 등)를 지원한다. Wordpress를 비롯하여 DotClear, Drupal, Geeklog, MediaWiki를 지원하며, API 자체가 열려있기 때문에 이런 도구들을 쓰지 않아도 bad-behavior-generic.php 파일을 이용하여 Bad behavior 기능을 직접 써먹을 수 있다.

이 글에서는 Wordpress에서 쓰는 것을 전제로 한다.

• 제작 언어 : PHP
• 공식 누리집 : http://www.homelandstupidity.us/software/bad-behavior/
• 필요 DBMS : mysql

2. Wordpress에 설치하기

1. Bad behavior 공식 누리집에 방문해서 Bad behavior를 내려 받자. 여러 글 관리 도구를 지원하지만, 특정 도구 전용 꾸러미(package)는 따로 없다. 그냥 통짜 파일 하나를 내려 받으면 된다.

내려 받은 압축 파일을 Wordpress의 확장 도구 디렉토리에 압축을 푼다. 보통은 wp-content/plugins/가 Wordpress 확장 도구 디렉토리이다. 이곳에 압축을 풀면 bad-behavior라는 디렉토리가 생겨있다. 이곳에 Bad behavior 관련 파일들이 있다.

2. 이제 Wordpress에서 Bad behavior 기능을 활성화하면 된다. 관리자로 접속한 뒤 관리자 영역으로 가서 ‘플러그인‘ 영역으로 가면 Bad Behavior가 보일 것이다. 이걸 ‘쓸수있게‘를 눌러 활성화하면 할 일은 끝난다.

3. Bad behavior 작동 방식

“잘 작동하면 그만”이라는 생각을 하겠지만 Bad behavior는 작동 방식을 알아두는 것이 여러 모로 좋다. 정 귀찮으면 친절한 이 글(자동 광고 등록기 차단 도구, Bad behavior)을 잘 보이는 곳에 적어둬서 쉽게 찾아올 수 있게 하자.

Bad behavior는 Bad behavior 기능이 작동하고 있는 곳에 누군가 접근했을 때, 이 누군가의 정체와 행동을 정해진 규칙에 따라 판단한 뒤 접근 허가 여부를 결정한다. 규칙 몇 가지는 다음과 같다.

• 일정 시간 동안 너무 많이 접속을 시도하거나
• 접근자의 정보를 조작하거나(일부 웹브라우저는 브라우저 정보를 조작할 수 있다)
• HTTP 명세를 제대로 따르지 않거나
• 검색수집기/검색기가 robots.txt 를 따르지 않거나
• Bad behavior에 등록되지 않은 접근자 정보라면

접근을 하지 못할 수 있다. 대체로 ‘자동 광고 등록기’들은 위 규칙들을 위반한다. 그래서 아주 많은 ‘자동 광고 등록기’ 접근을 차단해내고, 덕분에 광고 글들은 현격하게 줄어든다. 내 경험을 예로 들면, Bad behavior 도입 전에는 하루에 500여개 광고 댓글이나 글걸기(trackback)가 들어왔었지만, 도입하고 약 30시간이 지난 지금까지 광고 글은 한 건도 등록되지 않았다. 고작 30시간 운영 갖고 성능을 판단하기엔 이르나 기능이 잘 작동한다는 건 알 수 있다.

4. 문제 해결

Bad behavior를 쓰다보면 난감한 경우를 겪을 수 있다. 하나 하나 살펴보자.

1. 접근을 할 수 없다.
나도 당했다. 꽤 많은 사람들이 당하고 있어서 공식 누리집에도 자신이나 주변 사람이 접근 거부 당했을 때 어찌 하라는 방법을 글로 제공하고 있다.
이 경우는 꽤 흔하게 발생하는 난감한 상황이다. Precondition failed 라는 오류(아파치 웹서버 오류 번호 : 412)를 뿜어대며 접근을 할 수 없다. 남이 그러면 어영 부영 넘어가겠는데, 내가 내 블로그에 접속하지 못하는 상황이 벌어질 수도 있다. 이럴 때는 Bad behavior 기능을 중단하면 된다. 그런데 블로그 접속 자체를 할 수 없는데 어떻게 Bad behavior 확장 도구(plug-in)를 중단하지?

방법은 두 가지이다. 첫번째 방법은 꼼수인데, ftp나 ssh/telnet 등으로 계정에 접속한 뒤 Bad behavior 디렉토리(wp-content/plugins/bad-behavior) 이름을 바꿔주거나 이 디렉토리 안에 있는 bad-behavior-wordpress.php 파일을 삭제하면 된다. 디렉토리 이름 바꿔주는게 더 간편하니 이 방법을 권장한다. 그러면 Bad behavior가 현재 작동되지 않는 것처럼 속일 수 있기 때문에 블로그 접근이 가능하다.

두번째 방법은 꼼수가 아닌 Bad behavior에 있는 기능을 활용하는 것이다. 아무리 Bad behavior 규칙을 어겨도 무조건 접근을 허용하게 해주는 기능이 Bad behavior에 있는데, 그 기능을 담당하는 파일이 bad-behavior-whitelist.php 이다. 이 파일에 접근을 허용할 자의 ip를 등록하거나 그 자의 정보(Agent information)를 등록하면 된다. 주의할 점은 자칫 정보를 잘못 입력하면 대문을 활짝 여는 것처럼 누구나 접근을 허용하는 결과를 초래할 수 있으니, 주의해서 정확한 정보를 입력해야 한다. 아주 중요하고 조심해야 할 사항인 탓에 bad-behavior-whitelist.php 파일 안에도 주석으로 DANGER!! 를 무지하게 외쳐대고 있다. (이용자들이 이 파일을 잘못 관리해서 문제를 일으켜놓고선 제작자에게 도와달라고 무지하게 졸라댔었나보다. 그렇지 않고서야 …)

접근을 허용할 자의 IP 주소 등록은 bad-behavior-whitelist.php 파일 안에서 $wp_bb_whitelist_ip_ranges = array( 라고 써있는 부분이다. $wp_bb_whitelist_ip_ranges = array( 이 아래에다가 접근을 허용할 IP 주소를 등록하면 되는데, IP 주소만 턱하고 적으면 PHP 문법 오류가 발생한다. 꼭 작은 따옴표나 큰 따옴표로 IP 주소를 묶어주자.

예시 :
$wp_bb_whitelist_ip_ranges = array(
‘211.218.236.252′,
‘211.218.236.253′,
);

IP 주소 맨 뒤에는 꼭 쉼표를 붙여주자. 만일, IP 주소를 두 개 이상 등록했는데, 각 IP 주소마다 쉼표를 찍어주지 않으면 PHP 문법 오류가 발생한다.

접근자의 정보를 추가해서 접근을 허용하려면 같은 파일 안에서 $wp_bb_whitelist_user_agents = array( 이 줄을 찾아 그 아래에다 같은 방법으로 정보를 추가한다. 예제는 해당 파일 안에 주석으로 잘 표현하고 있다.

2. Database 용량을 꽤 잡아먹는다.
Bad behavior는 누군가 접근을 할 때마다 접근 관련 정보를 일일이 Database에 기록(log)한다. 각종 검색기나 수집기, 혹은 자동 광고 등록기 대다수가 당신의 누리집이나 블로그를 매우 사랑해서 시도 때도 없이 방문하고, 수 많은 사람들이 RSS 구독기로 당신의 글을 구독하며, 역시 수 많은 사람들이 툭하면 등록해서 새 글 언제 올라오나 눈에 불을 켜고 F5 글쇠를 누르고 있다면, 아마 Bad behavior가 기록하는 정보만도 수~수십 메가바이트(megabytes)는 될 것이다.

하지만, 너무 걱정할 필요는 없다. 어지간히 많은 사람과 기계(bot)가 접근하는게 아니라면 접근 관련 정보를 한없이 기록하진 않는다. 스스로 일정 기간마다 쌓인 정보를 지우기 때문이다. 기본 설정 기간은 7일이며, 이 값 역시 이용자가 원하는 값으로 고칠 수 있다. 단, 단위는 일(日)이다.

bad-behavior-wordpress.php파일에 보면 아래와 같은 줄이 있다.

// How long to keep the logs around (in days).
// Lowering this may have profound negative effects!
$wp_bb_logging_duration = 7;

바로 $wp_bb_logging_duration 이 변수가 기간을 설정하는 것인데, 이 값에 해당하는 기간 동안만 정보를 보관하고, 이 기간을 넘기면 삭제한다. 단위는 앞서 말한대로 일(日)이며, 만일 값 단위를 시간이나 분 단위로 바꾸고 싶다면 bad-behavior-database.php파일에서 wp_bb_db_clear_old_entries() 함수를 고치면 된다. 자신 없으면 그냥 일 단위로 정리하게 냅두자.

참고로 접근 관련 정보가 기록되는 DB 테이블은 wp_bad_behavior_log이다. 물론, bad-behavior-wordpress.php 파일 안에 있는 define(‘WP_BB_LOG’, $table_prefix . ‘bad_behavior_log’);라는 부분을 고쳐 DB 테이블 이름을 취향에 맞게 고칠 수 있다.

3. 접근 거부 당했을 때, 안내 화면을 우리 말로 하고 싶다.
안타깝게도 Bad behavior 관련된 정보는 아직 영문으로 된 것이 대다수이다. 알파벳을 읽을 수 있고, 영어 낱말을 읽을 수 있다고 해도 괜히 영어라면 겁이 나고 소화가 안되는 사람들이 있을 수 있다. 그래서 Bad behavior 공식 누리집에 다 있을법한 내용을 내가 이렇게 친절하게 우리 말로 풀어서 쓰고 있다.

같은 이유로 접근 거부 당했을 때 나오는 안내 화면도 우리 말로 손본 파일을 나는 제공한다. Bad behavior가 접근 거부 당한 이에게 보여주는 안내 화면은 좋게 표현해서 안내이지 사실상 버럭 화를 내며 “저리가!” 라고 외치는 것이나 다름 없다. 더욱이 영어로 된 문장을 보면 속이 더부룩하고 글 읽는 속도가 매우 빨라지는 일부 사람들은 영어로 된 이 안내를 보면 면박 당한 무안함을 느낄지도 모른다. (실제로는 쉽고 이해하기 쉽게 안내문을 써놨다. 단지 영어일 뿐)

우리말로 바꿔놓은 접근 거부 안내 파일 내려 받기 : bad-behavior-banned.txt

위 파일을 내려 받은 뒤, 파일 확장자를 txt 에서 php로 바꾼다. 즉, 전체 파일 이름을 bad-behavior-banned.txt 에서 bad-behavior-banned.php로 바꾼다. 그런 뒤 이 파일을 Bad behavior가 있는 디렉토리에 덮어씌운다. 덮어씌우기 꺼림칙하다면 덮어씌우기 전에 원본 파일을 따로 보관한 뒤 덮어씌우면 된다.

보면 알겠지만, 원래 있던 영어로 된 안내문도 아래에 있다. 우리글이 깨져 보일 수 있는데 이는 UTF-8이라서 그렇다.

미안한 말이지만 실제로 잘 작동되는지는 확인해보지 않았다. 내가 접근 거부 당해야 저 화면을 확인할텐데, 내가 Bad behavior의 작동 원리를 이해했더니 놀랍게도 Bad behavior가 나를 접근 거부하는 일이 아예 없어졌다.

5. 마무리하기

Wordpress 공식 누리집에 podz님이 자동 광고 등록(spam)과 맞서싸우기 좋은 확장 도구를 세개 추천했는데 그 중 하나가 바로 이 Bad behavior이다. 현재(2006년 5월, 월급 이틀 전) 나도 저 세개를 모두 사용하고 있다. 이 세 도구가 힘을 합쳐 나쁜 자동 광고 등록기를 무찌르고 있다. 특히 Bad behavior의 공이 참 크다. 이 글을 쓰고 있는 와중에도 열심히 자동 광고 등록기들을 쫓아내고 있다. (불쌍하게도 가끔(‘항상’이 아니다) 올블로그의 RSS 수집기도 접근 거절 당하고 있다. ‘I know you and I don’t like you, dirty spammer.’라는 말을 들어가며 …)

만일, 자동 광고 등록기에 마음의 고통을 받고 있으며 일기장에 분한 마음을 쓰고 있다면 이 쓸만한 확장 도구를 추천한다. 만족할 것이라 생각한다.

워드프레스용 확장기를 건드리면서 워드프레스의 흐름 체계를 어느 정도 이해할 수 있게 되었다. 그래서 내린 결론은 워드프레스로 별의 별 걸 다 할 수 있다는 것이다. 별의 별 걸 다 할 수 있게 해주는 확장기가 이미 굉장히 많다. 그것들을 조합해서 나는 발상 관리를 위키위키에서 워드프레스로 하며, 일정 관리도 워드프레스로 한다. 만일 내게 PDA같은 휴대용 셈틀이 있었다면 일정 관리기를 만들어서 내 일정을 관리했을지도 모른다. 워드프레스의 RSS를 받아와 XML 정보를 분류하면(parsing), 언제나 서버에 있는 일정과 휴대용 셈틀에 있는 일정이 일치할 수 있으니 말이다.

녀석은 나의 찬양에도 불구하고 결국 직접 원하는 도구를 만들기로 한 거 같다. 녀석이 만들고 있는 기능들을 보니 워드프레스용 확장기로 똑같이 구현하고픈 생각이 든다. 이렇게 훌륭하고 늠름한 도구를 아직 우리나라에서는 100여명(참고 : hof님) 남짓이라는 얘기를 보니 참 가슴이 아프다. 태터툴즈가 좋지 않은 도구이고 이것을 사용해서 가슴이 아픈게 아니다. 태터툴즈는 판올림이 이뤄질 때마다 발전하고 있으며 지금은 다른 곳에서 쉽게 보기 힘든 블로그 사회를 형성하고 있다. 내가 안타까운 건 도구의 제한성(기능의 제한)을 넘어서 보다 자유롭고 개성있으며 다양한 배설을 할 수 있는 워드프레스를 쓰지 않는 사람이 많아서이다.

물론, 쓰기 나름이다만.

이 확장 기능 도구(Plugin)은 워드프레스용으로, 글의 목차를 만들거나 목차 번호를 매기는데 사용됩니다.
HTML tag인 <h>(예 : <h1> ~ <h5>) tag는 문단의 제목을 지정하는 용도로 본 확장기는 이 HTML tag를 본문에서 찾아내어 목차를 만들거나 목차 번호를 매깁니다.
실제로 이 글은 본 확장기를 사용한 예제입니다.

* 사용 예제

* 확장 기능 사용 전

* 확장 기능 사용 후

* 목차표 나타내기

저작권

본 확장 기능 도구는 저작권이 없으며, 마음껏 고치고 재배포 할 수 있으며, 상업 목적을 위해 사용할 수 있습니다. 또한, 재배포 할 시 본 파일의 제작자 이름만 고쳐서 자신이 만든 것이라고 주장하셔도 괜찮습니다.

확장기 내려 받기

내려 받기 : 20050720판 확장 기능 도구 내려 받기 (2005년 7월 20일 16시 05분판이 가장 최신판입니다)

사용 방법

1. 압축 파일의 압축을 푼 뒤, Hannal_Title_Table.php 파일은 Plugin 디렉토리에, Hannal_Title_Table.css 파일은 현재 사용하고 있는 Theme 디렉토리에 넣으십시오.
2. #
   # 워드프레스 관리자 영역에 접근한 뒤, 플러그인 관리 영역으로 가십시오. Hannal’s Rewrite Rules 라는 확장기(Plugin)이 추가되어 있는데, 이것을 사용할 수 있게 활성화하십시오.
3. 이제 본문에 <h> HTML tag가 있을 경우 자동으로 목차 기능이 작동됩니다.
4. 목차표는 사용하고 계신 Theme의 single.php이나 index.php 파일에 <?php if ( function_exists(‘print_index_table_htt’)==TRUE) echo print_index_table_htt(‘Index Table’, 1); ?> 라는 문자열을 본문이나 글 제목이 출력되는 부근에 넣으시면 됩니다. ‘Index Table‘은 목차표 이름으로 취향에 따라 변경할 수 있습니다.
5. 본문에 있는 문단 제목에 목차 번호를 매기고 싶으시다면, 글 쓰기 영역에서 Numbering을 Use로 하십시오.
   

활용하기

1. 목차 출력 제어하기
첨부된 CSS 파일을 수정하면, 보다 다양한 표현을 할 수 있습니다.

2. 세밀한 조정
Hannal_Title_Table.php 파일을 문서 편집기로 열면 다음과 같은 내용이 있습니다.

define('NUMBERING_TABLE_CODE_1', ' : ');
define('NUMBERING_TABLE_CODE_2', '. ');
define('KEYWORDS_META_NAME', 'numbering_htt');
define('STYLESHEET_NAME', 'Hannal_Title_Table.css');

이 내용들은 취향에 맞게 바꾸어서 사용하실 수 있습니다.

1. NUMBERING_TABLE_CODE_1 : 목차표에서 목차 번호와 목차 이름을 구분시켜줄 용도의 문자열 지정
2. NUMBERING_TABLE_CODE_2 : 글 본문에서 목차 번호와 문단 이름을 구분시켜줄 용도의 문자열 지정
3. KEYWORDS_META_NAME : 글 본문에 목차 번호를 지정하는지 여부를 DB에 저장하기 위한 접근(key) 이름. (Custom Field)
4. STYLESHEET_NAME : 본 확장기가 사용할 StyleSheet(CSS) 파일 이름.

이외

본 확장기는 성능보다는 기능 구현에 중점을 두었습니다. 성능이 떨어져도 저를 너무 구박마세요.

워드프레스의 문자형을 UTF-8로 지정할 경우, euc-kr로 RSS를 지원할 수 없습니다. 때문에 RSS 구독자가 사용하는 RSS 구독기가 euc-kr을 지원하지 못하는 경우 워드프레스를 사용하는 이용자 블로그의 RSS를 볼 수 없습니다.
이 글은 워드프레스에서 문자형을 UTF-8로 사용하는 이용자가 euc-kr형 RSS를 제공할 수 있는 방법을 제공합니다.
이 방법은 그다지 좋은 방법은 아니고 약간의 꽁수로 처리합니다. 더 좋은 방법이 있다면 그 방법으로 하시기를 권합니다.
마지막으로 본 확장 기능 도구(plugin)는 iconv 함수를 사용합니다. 만일, 서버가 iconv 함수를 지원하지 않을 경우, euc-kr을 지원하지 못할 겁니다.

저작권

본 확장 기능 도구는 저작권이 없으며, 마음껏 고치고 재배포 할 수 있으며, 상업 목적을 위해 사용할 수 있습니다. 또한, 재배포 할 시 본 파일의 제작자 이름만 고쳐서 자신이 만든 것이라고 주장하셔도 괜찮습니다.

확장기 내려 받기

내려 받기 : 20050702판 확장 기능 도구 내려 받기

사용 방법

1. 압축 파일의 압축을 워드프레스가 설치된 곳에 풉니다.
2. 압축 파일의 압축을 워드프레스가 설치된 곳에 풀면, hannal_merong.php 라는 파일이 index.php가 있는 곳에, createRewriteRules.php 파일은 ./wp-content/plugins 에 생성됩니다.
3. 워드프레스 관리자 영역에 접근한 뒤, 플러그인 관리 영역으로 가십시오. Hannal’s Rewrite Rules 라는 확장기(Plugin)이 추가되어 있는데, 이것을 사용할 수 있게 활성화하십시오.
4. ‘설정(option)’ 관리 영역에 가신 뒤 ‘변하지 않는 링크 (Permalink)’에 방문하십시오. 방문하면 .htaccess 파일이 재생성됩니다.

이제 ‘http://블로그위치/index.xml’로 접근하면 euc-kr로 된 RSS가 제공됩니다.

활용하기

1. 파일 이름 바꾸기
본 확장기는 hannal_merong.php 라는 실제 RSS 접근 파일과 createRewriteRules.php 라는 Rewrite Rules에 문법 추가 기능을 하는 파일로 구성되어 있습니다. euc-kr로 처리되는 RSS 파일인 index.xml 은 실제로 존재하는 파일이 아닌 가상 파일입니다.
이 중에서 hannal_merong.php 과 index.xml 은 파일 이름을 이용자가 원하는대로 변경할 수 있습니다.
createRewriteRules.php 을 Ascii 문서 편집기에서 열면

$feed_file_name = ‘index.xml‘; // feed file name
define(‘REAL_FILE_NAME’, ‘hannal_merong.php‘); // feed processor file name

라는 부분이 있습니다. index.xml는 외부에서 접근하는 파일 이름입니다. euc-kr_rss.xml 로 이름을 원하신다면 index.xml를 euc-kr_rss.xml 로 바꾸면 됩니다. 가상 파일 이름이므로 실제 파일 이름을 찾아 변경하실 필요는 없습니다.
hannal_merong.php 는 RSS 를 출력할 실제 파일입니다. 이 파일 이름이 마음에 들지 않는다면, 원하시는 파일 이름으로 변경하시면 됩니다. 단, hannal_merong.php는 실제 파일이므로 반드시 hannal_merong.php 이라는 파일 이름도 동일하게 변경하셔야만 합니다.
이제 ‘관리자 영역’의 ‘설정’ 영역에 가신 뒤 ‘변하지 않는 링크’에 방문하여, .htaccess 파일을 재생성하시면, euc-kr로 된 RSS 파일 이름이 변경됩니다.

만일, 사용하고 계신 서버가 Rewrite Rules(.htaccess) 기능을 제공하지 않는다면, euc-kr 로 된 RSS는 hannal_merong.php 가 됩니다. 이런 경우, ‘관리자 영역’의 ‘플러그인’에 있는 ‘Hannal’s Rewrite Rules‘ 확장기는 사용하실 필요가 없습니다. RSS 파일인 hannal_merong.php의 파일 이름을 변경해도, 특별히 설정을 건드릴 필요가 없습니다.

2. Atom 등 다른 Feed 방법을 euc-kr로 하기
이 확장기는 RSS 2를 기본으로 사용합니다. ATOM이나 RSS 0.92 등을 사용하시려 한다면 hannal_merong.php 파일 내용을 고치면 됩니다.
파일을 문서 편집기에서 열면

ob_start();

require(‘wp-rss2.php‘);

$str = ob_get_contents();

라는 부분이 있는데, 여기서 wp-rss2.php 라고 쓰여진 부분을 아래를 참고해서 고치면 됩니다.

• ATOM : wp-atom.php
• RSS 0.92 : wp-rss.php
• XML : wp-rdf.php

3. Wordpress 2.0에서도 작동되게 하기
http://prozac.pe.kr/bythelake/?p=194 참조.

하지만 얼마 전 발견한 마음에 들지 않는 워드프레스 정책을 발견했다. 관리자 영역에서 관련 설정을 아직 찾지 못한 걸 보면 이용자 차원에서 어찌 저찌 할 수 없는 워드프레스의 정책이라 생각한다.

단지 출력에서 < 이 글자가 사라진 것이 아니라 Database에 아예 없다.
? ? 쌡 이렇게 깨져보이는 것은 내가 사용하는 텔넷 도구가 UTF-8 출력을 지원 안해서 그러함.

위에서 별도로 표시한 부분을 보면 그들이 ‘>_< ‘ 이 글자표정(emoticon)을 쓰려 했음을 알 수 있다. 그러나 안타깝게도 < 는 어디로 사라지고 ‘>_’ 만 덜렁 있다. 이는 워드프레스가 < 으로 시작하는 부분을 HTML 태그(tag)로 인식하고 삭제한 현상이다. 이용자가 댓글을 쓸 때 악의를 가지고 <xmp> 태그나 자바 스크립트를 사용하는 걸 막기 위한 CGI의 기본 보안 정책이다.

문제는 워드프레스의 댓글에 대한 HTML 태그 정책은 허용하지 않은 HTML 태그는 아예 삭제하는 데 있다. 출력을 하지 않는 것이 아니라 데이터베이스(Database)에 댓글을 입력할 때 불안전하거나 불완전한 HTML 태그는 아예 삭제를 해서 입력을 하는 것이다. 워드프레스에서 ‘>_< 꺄하하하하 > 메롱롱‘이라고 댓글을 입력하면 실제로는 ‘>_ 메롱롱‘이라고 입력이 된다. ‘< 꺄하하하하 >‘가 삭제되었다.

불안전하건 불완전하건 이용자가 만든 자료(글)는 최대한 원본을 유지해야 한다. 설령 정책 때문에 출력을 할 때 최소한의 가공을 가할지라도 입력된 자료는 최대한 원본을 유지해야 한다. 그러나 워드프레스의 정책은 원본을 변경하여 데이터베이스에 저장하기 때문에 워드프레스 이용자가 어찌 손을 쓸 방법이 없다.

껍데기를 바꾸다보니 블로그 구성도 바꿔야 했다. 우선 갈래(category), 쪽(pages), 최근 댓글(recent reply) 등을 별도의 글로 뽑았다. 처음엔 어떻게 해야할지 당황했지만 WordPress의 껍데기(theme) 파일에서 is_single 이라는 함수를 활용하면 각 글마다 특정 기능을 적용할 수 있다는 걸 깨달았다. WordPress는 정말 쓰면 쓸수록 마음에 쏙 든다.

별 거 바꾼 건 없지만 7~8시간 동안 나름 신경 많이 써서 이곳 저곳을 다듬었다. WordPress의 본체를 수정하지 않고 껍데기(theme)와 확장 도구(plugin)만으로 필요한 기능 거의 모두 활용하거나 다듬을 수 있다는 걸 알게 된 계기였다. 정책과 흐름도 거의 모두 파악해서 강좌 하나 쓸 수준에 이른 거 같다(거만… 거만…). 이젠 WordPress에서 다른 블로그 도구로 이동할 이유는 전혀 없어졌다! 카카.

아직도 이 확장기능을 찾으시는 분들이 계셔서 알려드립니다. 이 확장도구는 워드프레스 1.5판을 기준으로 개발했으며, 최신판인 2.x 이상에서는 작동하지 않을 수 있습니다. 또한, 검색기 방문을 방문 수에 넣지 않는 기능이 없어서 실제 방문 수와 많은 차이가 있을 수 있습니다.
마지막 글 수정일 : 2009년 1월 21일

개요

본 도구는 워드프레스용 카운터/조회수 기능을 갖고 있는 플러그인입니다. 워드프레스 기본 기능에 없는 카운터(방문수) 기능과 글 조회수 기능을 이 도구를 이용하여 사용해보십시오.

1. 도구 이름 : 한날 카운터 (Hannal Counter)
2. 도구 판 번호 : 1.0 (20050429)
3. 공식 배포 주소 : http://www.hannal.net/blog/hannal_counter/
4. 만든 이 : 한날 ( http://www.hannal.net )
5. 저작권 : 이 도구로 나쁜 짓을 하지 않는 전제하에 저작권은 없습니다. 마음껏 제한없이 사용하고 재배포 하셔도 되며, 자신이 만들었다고 주장하셔도 됩니다. 나쁜 짓이란 공식 배포본처럼 꾸미고선 웹 개발을 모르는 이들에게 피해나 손해를 끼치는 일 등을 의미합니다.

설치 방법

1. 파일 내려 받기

* ZIP 파일
* Tar 파일

2. 파일 설치 하기

위 압축 파일을 워드프레스가 설치된 곳에 푸십시오. 정상적으로 설치하면 wp-admin 디렉토리에는 hannal_counter_site.php 파일과 hannal_counter_post.php 파일이 생기고, wp-content/plugins 디렉토리에는 Hannal_Counter.php 파일이 생깁니다.

3. 플러그인 작동 시작하기

이제 워드프레스 관리자 영역에 간 뒤, ‘플러그인’ 영역에 가시면 Hannal Counter라는 플러그인이 생겼음을 알 수 있습니다.

이곳에서 해당 플러그인을 ‘사용할 수 있게’를 눌러서 활성화 하십시오.

4. 데이터베이스 설정

본 플러그인은 필요한 데이터베이스 테이블이 없을 시 자동으로 생성하므로, 별도의 설정을 하실 필요가 없습니다.

사용 방법

1. 방문수와 조회수 보기

본 플러그인을 활성화하면 관리자 영역에 Counter라는 메뉴가 추가됩니다. 해당 메뉴로 들어가면 Site Counter라는 메뉴와 Post Counter라는 보조 메뉴가 나오는데, Site Counter는 워드프레스로 운영 중인 블로그의 방문 수를 볼 수 있으며, Post Counter는 각 글의 조회수를 볼 수 있습니다.

2. 조회수 증가 기능 작동시키기

방문수는 본 플러그인이 활성화되면서 자동으로 기록되기 시작하지만, 조회수 증가 기능은 저의 능력 부족으로 인해 이용자가 테마(스킨) 파일에 별도의 줄을 추가해야 합니다. 우선 사용하고 계시는 테마 중 single.php 파일을 여십시오. 그런 뒤
<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
라는 줄을 찾아 그 바로 아래에
<?php if ( function_exists(‘hannal_record_hits’) == TRUE ) hannal_record_hits(); ?>
를 적어 넣으시면 됩니다.

이렇게 하지 않으면 글을 읽어도 조회수는 증가하지 않습니다.

개요

워드프레스에 글의 조회수 기능을 추가하는 워드프레스 플러그인입니다.

• Plugin 이름 : Record hits
• Plugin 제작자 : 한날 (http://www.hannal.net)
• 가장 최신 버전 : 1.0 (20050424)
• Plugin 내려받기

http://www.hannal.net/blog/wp-content/old_uploads/Record_hits-20050424-1.0.php.txt

• 설치 방법

파일을 내려 받으신 뒤, 워드프레스의 wp-content/plugins 에 Record_hits.php 라는 파일 이름으로 위치시키면 됩니다. 조회수 기능 작동에 필요한 Database 테이블은 자동으로 생성됩니다.

사용법

워드프레스 관리자 영역에 가신 뒤 ‘플러그인’ 영역에 가시면 Record_Hits 라는 단어가 보이실 겁니다. ‘쓸 수 있게’를 누르면 해당 플로그인이 작동하기 시작합니다.
이후에는 테마(스킨) 파일에 적용하시면 됩니다. 예를 들어 single.php 에서 <?php view_hits_article(); ?>를 써넣으시면 해당 위치에 조회수가 출력됩니다. 단, 이용자 등급이 10인 admin만 볼 수 있으니, admin으로 접속한 뒤에 확인해야 합니다.

저작권

본 플러그인에는 아무런 저작권이 없습니다. 상업 용도로 사용할 일은 없을 거 같지만 그러고 싶으면 그러십시오. 또한, 수정해서 마음껏 재배포해도 되고 자신이 만든 거라고 주장하셔도 무방합니다.

건의 및 문제 보고

문의는 본 글에 ‘댓글’로 하시면 확인 후 답변을 드리며, 공식적으로 문제를 제기하시거나 알릴 시 가급적이면 엮인 글(Trackback)을 부탁드립니다.

1. 태터툴즈의 게시물을 워드프레스로 옮기기
워드프레스에는 게시물 이름(postname)이 존재합니다. 이걸 고유 주소(Permalink)로 사용할 수도 있지요. 이런 정책을 활용합시다.
태터툴즈의 게시물을 워드프레스로 옮길 때 게시물 이름(postname)을 태터툴즈의 글 번호(no)로 지정하면 됩니다.
곰님께서 만든 걸 제가 수정한 태터툴즈에서 워드프레스로 게시물 옮기는 도구에는 이런 지정이 되어 있습니다.

2. 변하지 않는 링크(Permalink) 형태 변경
이제 워드프레스의 관리자 영역으로 가서 “변하지 않는 링크” 형태를 수정합니다. [설정]-[변하지 않는 링크]로 가면 됩니다.
이곳에 가서 변하지 않는 링크 모양을 /%postname%/라고 입력하십시오.

3. index.php 수정
마지막 단계입니다. 워드프레스의 index.php 파일 내용 맨 위에 다음 내용을 넣습니다.

<br /> if ( $_GET["pl"] )<br /> Header(“Location: {$_GET["pl"]}/”);<br />

위 내용을 추가하면 워드프레스의 index.php 파일 내용은 다음과 같이 됩니다.

<br /> < ?php<br /> if ( $_GET["pl"] )<br /> Header("Location: {$_GET["pl"]}/");</p> <p>/* Short and sweet */<br /> define("WP_USE_THEMES", true);<br /> require("./wp-blog-header.php");<br /> ?><br />

4. 완료
모든 과정이 완료됐습니다. 이제 워드프레스이지만 태터툴즈 때의 고유 주소는 계속 유지됩니다. 만일 위 과정을 아무 문제 없이 완료했다면 태터툴즈 때의 고유 주소로 접근해보세요. 글이 잘 나옵니다.

2009년 3월 2일 추가 : -A2-님께서 텍스트큐브에 있는 자료를 워드프레스로 옮기는 변환기를 만드셨습니다. 기존 태터툴즈 클래식을 쓰시던 분들은 텍스트큐브로 판올림(migration)하신 뒤, 그 자료를 워드프레스로 옮기시길 적극 권장합니다.

아래 변환기는 워드프레스 옛날 판에서 작동하므로 현 2.0 이상인 워드프레스에 맞게 돌아가지 않습니다.

곰님께서 만드신 “태터툴즈(클래식) 게시물을 워드프레스로 옮기는 도구” 중 UTF-8로 게시물을 변환하며 워드프레스로 게시물을 옮기는 도구에 몇 가지 문제가 있어 수정했습니다.

발견된 문제점 (파일명 : import_tt_utf8.php)
• UTF-8로 변환해주는 카테고리 이름을 UTF-8로 변경하지 않는 문제
• 부모 카테고리 값이 0일 때 처리 문제
• 댓글 작성자 이름에 ‘ 들어갈 시 변환 오류나는 것 처리

위의 문제는 곰님의 실수같고, 두번째 문제는 흔히 일어나기 어려운 문제이지만 제 블로그에는 해당 경우가 있어서 예외 처리를 해놨습니다. INSERT INTO $wpdb->post2cat (post_id,category_id) VALUES (숫자, ) 이렇게 되어 category_id 쪽에 빈공백이 들어가서 SQL error가 나는 문제는 이제 생기지 않습니다.

또한 게시물을 워드프레스에 저장할 때 게시물 이름(postname)을 게시물 제목이 아닌 태터툴즈의 게시물 번호로 했습니다. 만일 태터툴즈에서의 게시물 번호가 566이었다면, 워드프레스에 저장된 해당 게시물의 게시물 이름은 566이 됩니다. 워드프레스에서 변하지 않는 링크(Permalink) 형태를 /%postname% 이런 식으로 하면 아주 손쉽게 태터툴즈 때 사용하던 Permalink를 변환할 수 있습니다.

- import_tt_utf8-20050423.php.txt 파일 받기 <- 클릭. (받은 뒤 파일 확장자인 .txt 를 없애서 import_tt_utf8-20050423.php 로 파일명을 바꾼 뒤 사용하십시오)

이 글에 접근하려면 글 낱장 주소에 바로 숫자 1000이 붙지 않게 주소를 고치거나 글 id 로 접근해야 합니다.