WordPress에서 장문의 긴 글을 작성했을 때, 만약 해당 글을 index 페이지에선 그 내용을 다 보여주지 않고 글 앞부분의 도입부만을 보여주고 싶을 때를 대비해 more tag로 처리하는 기능을 제공한다. 그런데 이 기능을 그대로 가져다 쓰면 웹 접근성 면에서 문제가 생길 수 있다.

이렇게 해서 자동 생성된 링크 텍스트는 기본적으로 그냥 무의미한 more…로 표시되는데, 만약 글의 앞뒤 문맥을 인지하지 못한 상태에서 해당 링크를 스크린 리더를 통해 접근했을 땐 해당 링크가 어느 곳을 가리키는지 알 수가 없는 것이다. 하지만, 다행히 WordPress의 the_content() 함수를 제대로 쓰면 이 more tag의 내용을 입맛에 맞게 수정할 수가 있다.

the_content() 함수는 일반적으로 WordPress에서 사용되는 The Loop라는 PHP 코드 안에서 쓰이는데, 보통 WordPress 테마 파일의 index.php나 혹은 최신 WordPress에서 기본 제공하는 Twenty Twelve 테마 같은 경우 post의 종류에 맞는 여러 군데의 템플릿(template)에 사용되고 있으며 상황에 맞게 각기 따로 수정해 주어야 한다. WordPress의 more tag 접근성 문제(이)란 제목의 글 마저 읽기 →

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 맨 마지막 부분에 붙게 된다.

내용 갱신(2014년 6월 25일): 현재 설치된 WordPress 3.9.1 버전에선 위에서 설명했던 방법이 제대로 적용되질 않아서, 해결책을 검색한 결과 다음 페이지에서 해답을 얻을 수 있었다.: Unable to move wordpress jquery library into the footer – Stack Overflow

그래서, 가령 jQuery를 Google에서 호스팅하고 있는 것으로 바꿔서 페이지 마지막 부분에 추가해 주려면 functions.php 파일에 다음과 같이 등록해 준다.

<?php
function my_footer_enqueue_scripts() {
    remove_action('wp_head', 'wp_print_scripts');
    remove_action('wp_head', 'wp_print_head_scripts', 9);
    remove_action('wp_head', 'wp_enqueue_scripts', 1);
    wp_deregister_script('jquery');
    wp_register_script('jquery', "http" . ($_SERVER['SERVER_PORT'] == 443 ? "s" : "") . '://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js', false, NULL, true);
    wp_enqueue_script('jquery');
}
 
if (!is_admin()) add_action('wp_enqueue_scripts', 'my_footer_enqueue_scripts');
?> 

나중에, Google에서 호스팅하고 있는 jQuery 버전이 갱신된다면, 위 코드에 작성된 jQuery의 호스팅 주소 중에 버전에 해당되는 부분만 새 것으로 바꿔주면 된다.

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들을 차단해준다:

# block comment spam by denying access to no-referrer requests 
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.* 부분은 자신의 도메인 이름으로 대치해주면 됨.

자, 이제 지켜볼 일만 남았군.