Archive for the ‘weblog & wiki’ Category
Published by
Nineye under
weblog & wiki on
November 24, 2009
위키의 활용 용도 중 하나가, 특정 규정집 작성이다 보니, 입력한 문서들을 책과 같은 문서로 만들어 주는 기능이 필요하게 되었다.
일반적으로 책이나, 논문들은 pdf파일로 주로 작성되고 공유되기 때문에, 위키 페이지를 pdf파일로 만들어 주는 Pdf Export, Pdf Book, Wiki2LaTeX 등의 extension들을 찾게 되었다.
Pdf Export, Pdf Book extension은 문서 변환에 htmldoc 명령어를 사용하는데, htmldoc은 한글을 지원해 주지 않는다. 따라서 LaTeX 기반의 pdflatex 명령어를 사용하는 Wiki2LaTeX extension을 사용하기로 하였고, Wiki2LaTeX extension을 설치하고 사용하면서 발생한 문제들에 대해 정리해 본다.
설명
위키내의 각 문서를 LaTeX 문서로 변환한 뒤, LaTeX 어플리케이션을 이용하여 pdf 문서로 만들 수 있게 해준다. linux 명령어는 pdflatex을 이용하며, 이는 w2lConfig.php에서 변경할 수 있다.
Extension 위치
http://www.mediawiki.org/wiki/Extension:Wiki2LaTeX
준비작업
LaTeX의 설치
LaTeX을 이용하기 때문에 관련 어플리케이션을 설치해야 한다. 필자는 현재 계속적으로 유지되고 있는 texlive를 설치했다.
apt-get install texlive-full
or
apt-get install texlive
# 필요한 패키지들은 따로 설치
일단, 풀버전을 설치했는데, 풀버전의 사이즈는 거의 600mb정도되며, 사용하지 않는 패키지들도 많으니, texlive 패키지만 설치하고, 사용하면서 필요한 패키지만 따로 설치하는 것이 좋다.
설정하면서
한글(utf-8 인코딩) 문서의 적용
linux에서 개발 시, 가장 어려운 문제중의 하나가 바로 한글 문제이다. LaTeX에서는 다양한 한글 관련 패키지들이 존재한다. kotex, cjk 패키지들이 바로 그것들이다. 필자의 블로그에서는 kotex을 설치하여 한글을 이용했지만, w2l에서는 cjk 패키지에 대한 언급이 많아서 cjk를 설치하였다. cjk를 설치하며 utf-8 인코딩의 한글 문서 변환까지 많은 우여곡절이 있었는데, 내용이 너무 길어서 따로 포스팅하였다. http://nineye.net/blog/archives/1340 를 참고하자.
http protocol의 한글 파일명의 사용
w2l에서는 다운받는 pdf 문서의 파일명칭에 페이지 제목을 사용한다. 따라서 페이지 제목에 한글이 포함되는 경우도 고려했어야 했는데, w2l은 한글을 고려하지 않았다. …/extension/w2l/w2lSendFile.php 파일을 열어서 다음 부분을
$title = addslashes( $_GET['title'] );
다음과 같이 수정하자.
$title = addslashes(iconv("UTF-8", "EUC-KR", $_GET['title']));
http protocol에서는 파일명을 euc-kr 인코딩으로 처리하는 것 같다. 따라서 utf-8 인코딩의 페이지 제목을 euc-kr 인코딩으로 변환하여 파일명칭으로 넘기니 정상적으로 동작한다.
가끔 pdf 파일을 전송 받지 못하는 문제
해당 페이지의 pdf 문서 변환 후, 다음 페이지에서 pdf문서 링크를 클릭하면 w2lSendFile.php 페이지가 동작하는데, 이때 가끔 pdf문서의 전송이 되지 않을 때가 있다. 시간이 없어서 원인은 아직 찾지 못하였으며, 일단 다음의 코드로 변경하니 실패 확률은 줄었다.
header("Content-Type: ".$mime_type);
// Es wird downloaded.pdf benannt
header('Content-Disposition: attachment; filename="'.$title.'.'.$fmt.'"');
위의 코드 앞에, 다음을 붙여 넣자.
## nineye edit
#
# add checking
if (!is_file($file_loc)) {
header('HTTP/1.0 404 Not Found');
}
if (!is_readable($file_loc)) {
header('HTTP/1.0 403 Forbidden');
}
$stat = @stat($file_loc);
$etag = sprintf('%x-%x-%x', $stat['ino'], $stat['size'], $stat['mtime'] * 1000000);
header('Expires: ');
header('Cache-Control: ');
header('Pragma: ');
if(isset($_SERVER['HTTP_IF_NONE_MATCH'])
&& $_SERVER['HTTP_IF_NONE_MATCH'] == $etag) {
header('Etag: "' . $etag . '"');
header('HTTP/1.0 304 Not Modified');
} elseif(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])
&& strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE'])
>= $stat['mtime']) {
header('Last-Modified: ' . date('r', $stat['mtime']));
header('HTTP/1.0 304 Not Modified');
}
header('Last-Modified: ' . date('r', $stat['mtime']));
header('Etag: "' . $etag . '"');
header('Accept-Ranges: bytes');
header('Content-Length:' . $stat['size']);
# end edit
혹시 http protocol의 내용의 내용에 정보가 부족하여서 문제가 생길까.. 하여 더 많은 페이지 정보를 넣어봤다. 확실히 실패할 확률은 많이 줄어들긴 했지만 아직 문제가 있는 것으로 보아, 정답은 아닌 것 같다.
평가
안정성
한글 지원 문제와 파일 전송 문제를 제외하고는 문제가 없었다. 하지만 문제를 해결하기 위해 소스를 보다보니, 생각외로 오류 처리 코드가 많지 않아 잠재적인 위험도가 높은 것 같다.
기능
한 페이지의 위키 문서를 처리하기에는 알맞은 것 같지만, 다중 문서를 함께 처리하는 기능이 없다. 관련된 문서를 책처럼 만드는 기능이 필요할 것 같은데 없어서 아쉽다. 참고로 PdfBook, Book extension 들이 이를 지원하지만, htmldoc 명령어를 기반으로 하기때문에 한글이 지원되지 않는 문제가 있다.
html페이지의 변환은 약간 부족한 감이 있다. 단순한 페이지는 깨끗하게 변환하는 것 같지만, 약간 복잡한 페이지는 매끄럽게 변환하지 못한다. 전체적으로는 쓸만하게 변환하는 것 같다.
지원
현재 개발되고 있는 최근 버전이 2009년 7월 2일자인 것으로 봐서는 계속 개발 중인 것 같다. 다국어의 지원은 지켜봐야 할 일 같다.
Leave a Reply
Published by
Nineye under
weblog & wiki on
November 19, 2009
회사에서, 연구소간 공유할 수 있는 위키를 만들게 되어서, 전세계적으로 가장 널리 알려진 Wikipedia의 근간이 된 MediaWiki를 설치하면서 수행한 일들을 정리한다.
문서의 순서는 필자가 MediaWiki를 설치하면서 수행한 일들을 시간 순서대로 나열 할 것이다. 참고로 MediaWiki의 홈페이지는 http://www.mediawiki.org 이다.
환경
OS : Linux Cent-OS 64
php 버전 : 5.1.6
mysql 버전 : Ver 14.12 Distrib 5.0.45
GD 버전 : bundled (2.0.28 compatible)
MediaWiki 버전 : 1.15.1
설치 권한 : 사용자 user1으로 설치
MediaWiki 소스 설치 위치 : /home/user1/www/wiki 아래에 설치 (아파치 설정에서 사용자의 홈디렉토리 위치를 public_html에서 www로 바꾼 경우)
MediaWiki DB 설치 위치 : mysql database “mediawiki” 에 설치한다. 그리고 mysql의 user1 계정에 권한을 준다.
Install
1. MediaWiki 홈페이지에서 다운로드 받는다.
http://www.mediawiki.org/wiki/Download 페이지를 띄워서 Latest releae 버전을 다운로드 받는다. 다운 받은 MediaWiki 압축 파일을 설치할 위치(/home/user1/www/)에 업로드 한다.
2. 압축된 MediaWiki 파일을 원하는 위치에 압축 해제한다.
# mediawiki-1.15.1.tar.gz 가 /home/user1/www/ 에 있을 경우
tar xvzf mediawiki-1.15.1.tar.gz
mv mediawiki-1.15.1 wiki
3. MediaWiki 설정 전, 준비 작업을 한다.
1) mysql DB에 MediaWiki가 사용 할 정보를 만든다.
# MediaWiki 데이터를 담을 database를 만든다.
mysql> create database mediawiki;
# 생성한 "mediawiki" database에 grant ~ on 사이의 권한을 user1에게 부여한다.
# user1이 mysql 에 등록되어 있지 않은 경우, user1을 생성한 후 권한을 부여한다.
# user1이 mysql에 등록되어 있는 경우, 권한을 부여한다.
mysql> grant create, select, insert, update, delete, alter, lock tables on mediawiki.* to 'user1'@'localhost' identified by 'password';
# MediaWiki에서 사용 할 DB가 다른 서버에 위치 할 경우, 위의 명령에서 'localhost' 를 해당 서버의 주소로 바꿔준다.
2) config 디렉토리 설정
MediaWiki를 웹페이지에서 설정하기 위해, /home/user1/www/wiki/config 디렉토리에, others에게 쓰기 권한을 부여한다. 쓰기 권한을 부여하지 않았다면, “Can’t write config file, aborting”의 오류 메세지가 설정 페이지에 나타난다.
cd /home/user1/www/wiki
chmod 757 config
4. http://yourdomain/~user1/wiki/config/ 에 접속해서 MediaWiki를 설정한다.
1) 환경 체크 (Checking environment)
서버의 환경을 체크하여, MediaWiki를 설치할 수 있는 지 체크한다. MediaWiki가 정상적으로 동작하지 못할 수도 있는 환경이면 붉은 색 글자로 에러를 표시하나, 비정상적인 부분이 없다면 위와 같이 “You can install MediaWiki”를 표시한다. 참고로, Warnning이 뜰때도 있는데, 이는, MediaWiki의 메인 기능은 정상적으로 이용 가능하지만, 추가적인 기능은 이용할 수 없을지도 모른다는 것이다. 예를 들면, GD library가 설치되어 있지 않으면 다양한 이미지 변환 기능을 사용할 수 없다. 이럴 때 Warnnig이 뜬다. 서버의 관리자라면 MediaWiki가 필요로 하는 기능들을 서버에 다 설치하여 Warnning이 없도록 만든 후, 다시 환경 체크를 해서 정상적으로 통과 시키자.
2) 사이트 설정 (Site config)
- Wiki name : 위키의 명칭을 적는다. 이 명칭은 위키내에서 네임스페이스로도 사용되므로 되도록이면 짧고 공백없이 명명하도록 한다.
- Contact e-mail : 위키를 관리할 사람의 이메일이다.
- Language : 위키에서 표시할 언어이다. MediaWiki가 영문을 베이스로 하다보니, 영문을 선택하면 전체적으로 깔끔하지만, 한국어를 선택하면 좀 지저분해 보인다. 영문을 선택하더라도 한국어를 입력은 할 수 있다. 한국어를 선택하려면 “ko – 한국어”를 선택한다. 그리고 여기서 “en – English”를 선택해서 설치하고 나중에 위키 사용자 설정에서 다시 한국어로 바꾸지는 말자. 그러면 이상하게 꼬일 가능성이 많다. 예를 들면, 영문에서의 대문의 명칭은 “Main”이며, 한국어에서 대문의 명칭은 “대문”이다. 언어를 나중에 바꾸면 “대문”을 클릭해도 해당페이지가 없다고 나온다. 왜냐면 대문 페이지는 “Main”의 명칭으로 만들어져 있기 때문이다. 이런 문제가 페이지 명칭, 네임스페이스 명칭, 특수 페이지 명칭 등에 걸쳐 상당히 많이 존재한다.
- Copyright / license : 라이센스를 어떻게 표시할거냐는 건데… 필자는 그냥 “No license metadata”를 선택했다.
- Admin username, Password, Password confirm : 관리자로 사용 할 정보이다.
- Object caching : php에서 어떤 툴을 이용하여 object caching을 할 것이냐는 것인데, 이는 eAccelerator나 Turck MMCache등이 서버에 설치되어 있어야 한다. MediaWiki 설정 페이지에서는 이런 툴들이 설치되어 있는지 자동으로 감지해 주고 표시해 준다. 필자의 서버는 설치가 되어 있지 않기때문에 표시가 되지 않았다. 없으면 그냥 No caching을 선택해 주고, 있으면 있는 툴을 선택해 주자. 참고로 설명에 나와 있듯이, DBA는 No caching보다 더 느려서 테스트 용도로만 사용하니 선택하지 말자.
3) 이메일 설정 (E-mail, e-mail notification and authentication setup)
- E-mail features (global) : 모든 이메일 기능을 사용 가능하게 할 것인지, 아니면 사용 불가능하게 할 것인지 선택한다. 일반적인 설정은, 사용자끼리의 이메일은 그다지 많지 않고, 이메일 공지가 부하가 크기 때문에, 이 항목과 사용자끼리의 이메일은 활성화 시키고 이메일 공지는 비활성화 시키는 것으로 설정한다.
- User-to-user e-mail : 사용자끼리 이메일을 주고 받을 수 있게 할 것인지.
- E-mail notification about changes : 각종 토론 페이지나 주시 항목들의 변경을 이메일 공지로 알릴 것인지 선택.
- E-mail address authentications : 사용자 등록을 할 때, 이메일 인증을 하게 할 것인지 선택
4) 데이터베이스 설정 (Database config)
- Database type : 사용할 데이터베이스를 선택한다. 선택되는 데이터베이스는 서버에 설치되어 있어야 한다.
- Database host : 데이터베이스 접근 위치를 선택한다. 위키와 데이터베이스가 같은 서버에 있으면 “localhost”를 사용하고, 다른 서버에 있으면 데이터베이스가 있는 서버 도메인이나 IP주소를 적는다.
- Database name : 3.1) 단계에서 생성한 데이터베이스 명칭을 적어준다. 이 예제에서는 “mediawiki”라고 이름 지었다.
- DB 사용자 정보 : 3.1) 단계에서 “mediawiki” 데이터베이스로의 접근 권한을 준, 사용자 정보를 입력한다. 이 예제에서는 username – “user1″, password – “password” 였다.
- Superuser 정보 : 3.1) 단계에서 수동으로 데이터베이스를 만들어 주지 않았다면 이 설정으로 자동으로 만들게 할 수 있다. mysql서버에서 데이터베이스를 만들 수 있는 높은 권한을 가진 사용자 정보를 입력하자. 그정도의 권한이 없으면 3.1) 단계에서처럼 관리자에게 요청하여 수동으로 만들자.
- Database table prefix : MediaWiki에서 사용할 DB 테이블들의 접두어를 정한다. 필자의 경우는 “nmw_” (nineye media wiki) 라고 붙였다.
- Storage Engine : MyISAM은 디폴트 storage engine이며, 트랜젝션을 지원하지 않는다. InnoDB는 트랜젝션을 지원한다. 즉, MyISAM은 속도가 빠른 대신, 충돌이 발생할 가능성이 많기 때문에 위키를 혼자 사용할 때만 선택할 수 있다. InnoDB는 여러 사람이 위키를 동시에 이용해도 충돌이 발생하지 않는 대신, 속도가 느리다. 위키의 목적에 따라 설정하자. 단, MyISAM을 선택할 때는 반드시 혼자만 편집 가능하다는 것을 전제로 해야 한다.
- Database character set : 데이터베이스에서 사용할 문자 코드를 선택한다. 아래 설명에 보면 binary mode가 더 효율적이라고는 하는데, 필자는 귀찮아서 그냥 utf-8을 선택했다.
5) Install MediaWiki 버튼을 눌러서 설정을 적용 시킨다.
설명대로 설정을 했다면 위와 같이 “Installation successful!”이 뜰 것이다. 만약 에러가 발생하면 에러메세지를 읽고, 지시에 따라 다시 설정하자.
그리고 위 페이지에서 시키는 대로, config/LocalSettings.php 파일을 상위 디렉토리로 이동시키고 “chmod 600 LocalSettings.php”로 접근 권한을 설정해 주자. 이는, LocalSettings.php는 아파치가 생성한 파일이므로, 아파치를 제외한 그 누구도 이 파일에 접근하지 못하게 한다. 왜냐면 이 파일에는 위키를 설정한 사용자 정보가 암호까지 그대로 저장되어 있기 때문이다. 참고로 위처럼 권한을 변경하려면 관리자 권한이 있어야 한다.
5. http://yourdomain/~user1/wiki/ 로 접속하면 설치된 위키가 뜬다.
Extention
여기에서는 필자가 설치해 본 extention들을 적는다. 설명까지하면 너무 길기 때문에 간략하게 소개만 하고, 내용이 많은 경우 따로 링크를 건다.
각 문서의 토론 페이지에서, 댓글 형식으로 글을 달 수 있게 함
맨티스와 비슷한 이슈 추적기이며, 문서 마다 이슈를 추적할 수 있게 되어 있고, 아주 심플하게 구성되어 있음
WordPress의 SyntxHighlight와 같은 역할을 하며, 각종 코드를 코드 표현 방식에 맞게 표현해 줌
http://nineye.net/blog/archives/1355 여기 참조
결론
결론적으로는, MediaWiki 자체에는 문제가 거의 없었는데, extension들을 설치하다 보니 문제가 많았다. 우선, MediaWiki에서는, 등록된 각 extension들에 대해 사용자가 정확히 인지를 하지 못한다는 단점이 있었다. wordpress 사이트에서는 plugin들을 인기도에 따라서 정렬을 하고, 각 plugin들에 대해, 정해진 포맷대로 명확하게 설명을 해놓게 해서, plugin 사용자들이 뛰어난 기능의, 문제없는 plugin을 쉽게 선택할 수 있었다. 하지만 MediaWiki에서는 아무리 뒤져봐도 좋은 품질의 extension대로 정리해 놓은 곳이 없었다.
사용자들이 직접 만드는 plugin이나 extension에게 가장 중요한 것은 그것들의 품질이다. 품질을 평가하는 시스템이 없다면 사용자들은 수많은 plugin들을 설치해서 사용하기전까지는 어떤 plugin이 가장 좋은 지 알 수 없다. 이런 기본적인 부분도 소홀히 한 MediaWiki가 이해가 되지 않았다.
어쨌든 MediaWiki 자체는 정말 뛰어난 위키 툴인 것 같다.
Leave a Reply
Published by
Nineye under
weblog & wiki on
June 1, 2009
개인 블로그를 만들면서 고민했던 것이, 주 내용은 필자의 전문분야와 관련된 내용인데, 여기에 덧붙여서 개인적인 내용도 적을까… 하는 것이었다.
처음엔 전문분야와 관련된 내용만 있었는데, 이 내용만으로는 블로그가 너무 딱딱하다는 느낌을 받았다. 자신의 블로그도 재미없다고 느끼는데 타인은 당연히 재미없다고 느끼겠지..
그래서 개인적인 내용도 넣으려고 했는데, 문제는, 메인 내용은 전문분야로 하되, 개인적인 내용은 따로 존재하게끔 만들고 싶었다는 것이었다. 이 글은 앞의 내용을 어떻게 만들었는지에 대한 내용이다.
wordpress는 기본적으로 오직 하나의 post구조만 허용한다. 즉, 모든 기능들 및 애드온들이 하나의 post구조만을 가정하여 만들어 진다. 구글에서 검색을 많이 해봤지만, 대부분의 글들이 두 개의 post구조를 가질 수 없다는 내용이었다. 그래서 어떻게할까 생각하다가 두 가지 생각을 떠올렸다.
하나는, 블로그 유저를 한명 더 추가해서 추가된 유저의 post를 필자의 블로그 post로 올리는 것이었다. 하지만 우선, 필자가 설치한 것은 다중 사용자용으로 만들어진 wordpress가 아니었기 때문에 블로그 유저의 추가가 불가능했고, 필자의 블로그에서 수정한 내용이나 추가한 애드온들을 추가된 post구조에는 적용할 수가 없는 단점이 있었다.
또 다른 하나의 방법은, 개인적인 내용을 담을 카테고리를 하나 만들고, 블로그 메인 페이지에서는 그 카테고리를 제외한 post들만 보여주며 특정 page(wordpress정의 참조)에서 그 카테고리의 내용만을 보여주는 것이었다. 결국 차후의 유지보수 및 블로그 안정성을 생각해서라도 이것이 좋은 것 같아서 이 방법을 선택했다. 다음 내용부터는 적용 내용에 대해서 순서대로 나열한다.
1. page(wordpress정의 참조) template의 선택
우선 wordpress에서 기본적으로 정의된, post를 보여주는 방법에 대해 설명하도록 한다.
– 블로그 메인 페이지
선택된 테마 디렉토리내의 index.php에서 선택된 post들(query를 통해 정해지는데 정확히 어느 소스에서 결정되는지는 아직 알아보지 않았음)을 보여줌.
– 카테고리 페이지(카테고리 항목 클릭 시)
메인 페이지와 동일하게 index.php를 이용한다. 참고로 메인 페이지와의 구별은 is_front_page()함수를 통해 할 수 있다.
– archives 페이지
카테고리 페이지와 동일하나, query를 위한 환경변수는 다른 변수를 이용함.
– post 상세 페이지(post list에서 post의 제목 클릭 시)
선택된 테마 디렉토리내의 single.php를 이용함. index.php와 같이 query는 미리 실행된다.
– 댓글
댓글의 내용은 comments.php를 통해 보여지며, post를 보여주는 loop내에 comments_template()함수를 넣으면 해당 포스트내의 댓글이 보여짐.
page에서는 블로그 메인이 index.php를 사용하는 것과 같이 특정 php파일을 사용하며, 사용되는 php파일은 page들 마다 설정된 page template에 의해 결정된다. 페이지 생성 시, default로 선택되는 page layout은 page.php이며, 또 다른 page layout을 만들어서 사용하는 것도 가능하다. 필자는 wordpress sample 코드 중의 pageofposts를 수정하여 사용하였다. page layout을 만들 때 주의해야 할 점은, php파일의 첫째 줄부터 셋째 줄까지는 page layout의 명칭란인데, 이 세 줄의 포맷을 정확히 맞춰야 한다는 것이다. 정확히 맞추지 않으면 관리자 페이지에서 Attribute-template란에 나타나지 않는다. 정확한 포맷은 아래의 nineyepage.php의 소스에서 설명한다.
특정 page에 대한 page template의 선택 방법은, ‘wordpress 관리자 페이지 => 좌측 메뉴 중 page를 클릭 => 나열된 page list중 설정할 page를 선택 => page편집창에서 우측의 Attribute-template란 에서 선택’을 통해서 선택한다.
2. page template에서 post를 보여주기
특정 page template에서 post를 보여주기 위해서는 우선, 보여 줄 post들을 선택하는 query를 실행하고, 이 때 선택된 post들을 보여주는 loop가 삽입되어 있으면 된다.
query를 실행하는 방식은 여러 가지가 있는데, 이 중에서 두 가지만 나열하면, class WP_Query의 instance를 직접 생성하여 사용하는 방법과 query_post()함수를 이용하여 global query 객체를 이용하는 방법이 있다. 필자는 후자를 선택했는데, 그 이유는 wordpress 자체의 기능 및 특정 addon의 기능에서 query 객체를 global query객체로 명시적으로 이용하는 부분이 있어서, 따로 생성한 query 객체에 대해서는 그러한 기능들이 적용되지 않는다는 문제가 있어서였다. 하지만 global query 객체를 강제로 수정하면 문제가 발생하는 부분이 있을수도 있다고 하니까 조심해서 써야겠다. 다음은 두 가지 방식의 예제이다.
// WP_Query의 instance 생성 방식
...
$args=array(
'category__in' => $cat,
'posts_per_page' => $postsinpage
);
$my_query = new WP_Query($args);
if (have_posts()) : ...
...
// global query객체 수정 방식
...
query_posts('showposts='.$limit.'&paged='.$paged.'&cat=16');
$wp_query->is_archive = true;
$wp_query->is_home = false;
if (have_posts()) : ...
...
새로운 query 객체 생성에 들어가는 인자는 post 선택과 관련된 query이다. 여기서 조건은 두 가지(특정 카테고리 선택, 한 페이지에 보여질 post개수)를 주었다. query_post()함수에 들어가는 인자는 html주소창에 들어가는 인자들처럼 문자열로 주어진다. 여기서 조건은 세 가지(한 페이지에 보여질 post개수, paged는 소스 아래에서 설명, 특정 카테고리 선택)를 주었다.
그리고 선택된 post를 보여주는 부분은 일반적인 loop형식과 같기 때문에 아래의 소스를 참조한다.
3. 댓글 보여주기
page template에서 댓글을 보여주는 방식은 블로그 메인 페이지에서의 방식과 동일하다. 즉, post를 보여주는 loop내에 comments_template()함수를 사용하면 된다. 참고로 간혹 comments_template()함수를 사용해도 댓글이 보이지 않는 경우가 있는데, 이는 다음의 코드 때문이다.
if ( ! (is_single() || is_page() || $withcomments) )
return;
따라서 댓글을 보여주는 comments_template()함수 호출 앞에 $withcomments = 1;의 문장을 넣어주면 된다.
자, 이제 완성된 nineyepage.php 소스는 다음과 같다.
<?php
/*
Template Name: nineyepage
*/
?>
<?php get_header(); ?>
<div id="right">
<div class="leftcol">
<?php
$limit = get_option('posts_per_page');
$paged = (get_query_var('paged'))?get_query_var('paged'):1;
query_posts('showposts='.$limit.'&paged='.$paged.'&cat=16');
$wp_query->is_archive = true;
$wp_query->is_home = false;
?>
<?php
if (have_posts()) :
?>
<?php
while (have_posts()) : the_post();
?>
<a id="post-<?php the_ID(); ?>" href="<?php the_permalink(); ?>"
rel="bookmark" title="Permanent Link to <?php the_title(); ?>">
<h3 id="title"><?php the_title(); ?></h3>
</a>
<small><?php the_time('F jS, Y') ?> by <?php the_author() ?> | <?php the_tags('Tags: ', ', ', ''); ?> | Posted in <?php the_category(', ') ?></small>
<p>
<?php the_content(''); ?>
</p>
<?php $withcomments = 1; ?>
<?php comments_template(); ?>
<br /><br />
<?php
endwhile;
?>
<?php
else :
?>
<h3>Not Found</h3>
<p>Sorry, but you are looking for something that isn't here.</p>
<?php include (TEMPLATEPATH . "/searchform.php"); ?>
<?php
endif;
?>
<div style="clear:both"></div>
<div class="navigation">
<center>
<?php
if (function_exists('wp_pagenavi')) {
wp_pagenavi();
}
?>
</center>
</div>
</div>
</div>
<?php get_sidebar(); ?>
<?php get_footer(); ?>
2번째 줄부터 4번째 줄까지가 위에서 설명한 page template의 이름을 명시하는 부분이다. 다른 page template을 만들고 싶으면, 이 부분 중, nineyepage 부분만 수정하면 된다.
12번째 줄에서 13번째 줄까지 paged를 사용한 이유는 query_post()함수의 사용 때문이다. query_post()함수는 global query객체의 내용을, query_post()함수가 호출될 때 전달되는 인자로 생성되는 결과로 덮어버린다. 따라서 global query객체가 가져야 하는 중요한 내용의 보존을 위해, 새로운 query의 내용 내에 주요 내용을 생성할 수 있는 query를 추가하여야 하며, 이는 query_post()함수로 전달되는 인자로 이루어 진다. paged도 이와 같은 이유에서 포함되어야 하며, paged는 수많은 post들의 수많은 page들 중, 몇 번째 page를 보여주어야 하는지를 결정한다. 즉, paged를 추가하지 않으면 몇 번째 page를 선택하든지 무조건 첫 번째 page만 보여지게 되는 것이다. 필자의 블로그에서는 paged만 추가하면 정상적으로 동작했기 때문에 넘어갔는데, 혹시 다른 문제가 발생하면 그 문제가 발생한 원인을 paged의 추가와 같이 query_post()함수의 인자로 추가해야 한다.
13번째 줄에서 cat=16을 적용한 이유는 필자가 page에서 보여주고자 하는 카테고리인, nineye’s story 카테고리의 id가 16이기 때문이다.
50번째 줄에서 52번째 줄까지는 wordpress의 default page navigation이 아닌, wp-pagenavi plug-in에서 정의된 page navigation을 보여주기 위함이다.
어쨌든 위 방법대로 해서 필자는 성공적으로 원하는 카테고리를 특정 page에서 보여줄 수 있게 되었다. 많은 삽질이 있었지만…ㅋㅋ
일단 필자의 테마에서만 테스트 해 보았기에 다른 테마들에서도 동일하게 동작하리라는 보장은 할 수 없지만, 위에서 설명한, wordpress가 기본적으로 참조하는 블로그 메인 및 page template의 설명만으로도 이상한 부분을 손쉽게 맞출 수 있으리라 생각한다.
Leave a Reply
onlyyou 
BobMarche 
영구 여전히 열심이구나 보기좋다 ^^
열심이는요…ㅋ 몇달동안 바빠서 업데이트를 못해서… 쓸 건 많은데, 정리하기 귀찮네요…ㅋ 잘 지내고 계시죠? ㅋ
[...] MediaWiki Extension – Wiki2LaTeX [...]