JavaScript 파일은 페이지 로딩 속도 측면에서 페이지의 body가 닫히기 바로 전에 추가해 주는 것이 가장 좋은데, WordPress에 기본적으로 추가된 jQuery는 꼭대기 head 부분에 붙어 있다.
이놈을 맨 아랫부분에 추가하려면, 테마 파일에 있는 functions.php 파일을 열고 WordPress의 wp_register_script()와 wp_enqueue_script() function을 사용하는 다음과 같은 코드를 추가해 준다.
<?php
function my_scripts_enqueue() {
wp_deregister_script('jquery');
wp_register_script('jquery', "http" . ($_SERVER['SERVER_PORT'] == 443 ? "s" : "") . '://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', false, NULL, true);
wp_enqueue_script('jquery');
}
if (!is_admin()) add_action('wp_enqueue_scripts', 'my_scripts_enqueue', 11);
?>
여기에 있는 wp_register_script() function의 parameter 중 네 번째와 다섯 번째가 중요한 요소인데, 각각 $ver과 $in_footer 변수를 의미한다.
$ver 변수는 보통 JavaScript 파일 경로의 마지막 부분에 query string처럼 붙으면서 JavaScript 파일이 갱신되었을 때 caching된 것의 사용을 막으려고 사용되는데, jQuery처럼 Google CDN에서 불러올 때는 오히려 방해되므로 NULL 값을 줘서 없애버린다. 그리고 $in_footer 값에 true를 주면 JavaScript가 body 맨 마지막 부분에 붙게 된다.
WordPress가 3.1로 갱신되었다는 소식을 듣고 얼른 갱신을 완료하였다. 그런데 한동안 있다 살펴보니 갑자기 블로그 옆구리에 달린 Category 링크가 작동하질 않았다.
문제의 원인을 알아보니, 평소 꼬리표 관리 기능 때문에 잘 쓰고 있는 Simple tags plugin과의 충돌로 밝혀졌다.
해결 방법은, Simple Tags 관리자 화면의 General 메뉴 속에 있는 Active tags for page 기능을 꺼주면 된단다.
아마 WordPress 2.6부터 새로 더해진 기능인 듯 한데, Post revisions은 모든 글을 작성할 때마다 매번의 수정 기록들을 버전 형태로 DB에 자동 기록해 주는 기능이다. 물론 여러명이 함께 글을 작성할 경우에는 관리적인 면에서 도움이 될까마는, 나 혼자서 글을 올리는 이 곳에서는 , 개인적인 글 쓰는 습관에 비추어 별 필요성을 느끼지 못할 뿐만 아니라 DB 공간만 차지하는 불필요한 기록들로 남게 된다.
결국, 이 Post Revisions 기능을 꺼주는 Revision Control Plugin을 설치하고, 이미 DB에 저장되어 있는 과거 revisions 기록들은 다음과 같은 SQL 명령으로 지워주었다.
DELETE FROM wp_posts WHERE post_type = "revision";
그 동안 스팸의 염려로 WordPress에서 기본적으로 제공하는 Akismet과 더불어서 강력하다는 Bad Behavior plugin을 사용하고 있었다. 하지만, 이 Bad Behavior란 놈은 정상적인 댓글마저도 스팸으로 오인하는 치명적인 부작용을 가끔씩 경험하게 만들었고, 또 웹 페이지에 뿌려대는 지저분한 코드들과 이로 인한 페이지의 로딩 속도를 상당히 지연시키는 단점을 가지고 있기도 해서, 이번에 WordPress 2.6 버전으로 갱신하면서 사용을 중단하고 대신 차선책을 살펴보았다.
찾아보니, 비슷한 이유로 Bad Behavior와의 작별을 고하면서 차선책들을 강구해놓은 글을 참고해서, 방어막 구축에 다시 손을 보탰다.
주요 방비책으로는 결국 .htaccess 파일의 수정으로 요약되는데, 아래의 내용은 POST 시 Referrer가 없는 request들을 차단해준다:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-comments-post\.php*
RewriteCond %{HTTP_REFERER} !.*mydomainname.com.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^(.*)$ ^http://%{REMOTE_ADDR}/$ [R=301,L] [R=301,L]
여기서, !.*mydomainname.com.* 부분은 자신의 도메인 이름으로 대치해주면 됨.
자, 이제 지켜볼 일만 남았군.
WordPress 2.2에서의 바뀐 점들을 살펴보면 전체적으로 커다란 변화가 있었음을 알 수 있다.
먼저, wp-config.php 파일에 DB 인코딩 관련 두 가지 새로운 설정 값이 추가되었는데,
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
이로써, 간단한 설정만으로 db에서 utf-8 인코딩을 사용할 수 있게 되었다.
그리고 부분적으로 관리자 User Interface 기능을 구현하는데 jQuery JavaScript 라이브러리가 사용되었으나, 아직 Prototype으로부터의 완전한 이주는 진행되지 못한 상태다.
눈에 보이는 새로 추가된 기능으로는 그 동안 plugin 형태로만 제공되던 Widgets이 기본 테마에 추가되면서 덕분에 옆구리 막대의 관리와 수정이 한결 손쉬워 졌고, 드디어 Atom 1.0 발신 신호도 공식 지원한다.
이번 갱신으로 그 동안 입맛에 맞게 수정해서 사용하던 기본 테마에도 커다란 변화가 생기면서 덩달아 변화를 주기 위해 WordPress 2.2와 호환되는 새로운 테마를 수소문하게 되었다.
그래서 새로 설치게된 테마가 iTheme 1.1이라는 테마인데, Mac의 UI를 닮아서 어쩌면 식상할 수도 있지만 개인적으로 익숙한 것이라서 오히려 보기에도 더 편안하고 깨끗한 느낌이 든다.
아래는 내 입맛에 맞게 iTheme 테마를 수정했던 내용을 적어놓는다.
- 먼저, 글의 고정된 연결 고리들(permalinks)을 더 뜻이 있고 접근성을 높이기 위해 다음과 같은 맞춤형 구조로 설정해주었다.
Custom structure: /%category%/%postname%/
이렇게 하면 예전 글의 링크들이 깨지는 부작용이 있지만, 진작에 고쳐주지 못한 책임으로 여길 수 밖에.
- 테마 파일에 쓰여진 get_settings 함수는 앞으로 지원이 중단될 예정이기 때문에 대신에 get_option 함수로 대체함(header.php).
- iTheme에는 기본 제공되는 blockquote 스타일이 없는 관계로 Shape Shed에 설명되어 있는 quotations 스타일을 빌려와 적용해 주었다.
- 접근성을 고려해서 검색 form에 label을 추가하고 jQuery를 이용해서 검색 input box 클릭시 자동으로 가려주도록 Hover 효과를 주었으며, 링크들이 모여 있는 곳으로 바로 이동할 수 있도록 평상시에는 감춰져 있는 건너뛰기 링크를 추가했다. 그리고 a:hover 스타일과 함께 a:focus에도 같은 스타일이 적용되도록 함.
- code 표시 block에 syntax highlight 기능을 구현하기 위해 전처럼 textmate 테마를 적용.
- background 그림을 Mac OS X의 기본 Aqua Graphite 배경 그림으로 교체
- 글의 내용이 들어가는 공간의 너비를 545px에서 600px의 크기로 약간 넓힘. 이에 따라, 글 내용을 감싸고 있는 테마에 사용된 몇몇 그림들(content-top-bg.png, content-bottom-bg.png, navigation-bg.gif)을 더 넓은 것으로 수정해서 교체해야 했고, 댓글 폼에 있는 submit 단추의 margin-left 값을 55px 더 큰 410px로 주었다.
이제야 밀린 숙제를 간신히 끝낸 기분이군.