Feed crashed! Feedburner subscriber disappeared!

오랜만에 피드버너(Feedburner.com)에 들어가서 내 피드 현황을 확인해보니 갑자기 구독자가 0이 되었습니다ㅠㅠ. 그래서 제가 쓰는 RSS 리더를 총 동원해 테스트를 해보았습니다. 피드 버너(feedburner.com), 구글 리더(www.google.com/reader), 블로그라인스(bloglines.com), 한RSS(hanrss.com), 다음의 한메일(daum.net), 마이 야후(my.yahoo.com), 오페라 브라우저에 내장된 구독기, 인터넷 익스플로러에 내장된 구독기, 파이어폭스에 내장된 구독기, 올블로그(allblog.net), 그리고 피드 밸리데이터(feedvalidator.org) 등으로 모두 검사를 해보았는데, 모두 다 안 되고, 오직 브라우저에 내장된 구독기만 작동을 합니다.

워드프레스 피드 부분 소스가 잘못 되었나 몇 번을 봐도 답이 안 나오더군요. 혹시나 하는 마음에 많은 시간을 들여 워드프레스를 2.3으로 업그레이드했는데도...! 여전히 문제가 해결되지 않았습니다. 그래서 워드프레스 문제가 아니라면 아주 옛날 옛적에 홈페이지에 만든 제로보드 게시판에 붙은 RSS 피드는 잘 잡히는지 검사해보았습니다. 음... 제로보드 게시판에 붙은 피드도 작동을 안 하더군요. 아니 옛날 홈페이지는 소스 손보지 않은지가 수만년은 지났는데 어떻게 갑자기 이런 일이...

그렇다면 잠정 결론은 며칠 전에 호스팅 업체가 옮겨준 서버에 문제가 있다고 봐야겠군요. 모든 피드 검사기의 주요 에러 메시지가 대략 피드 URL이 틀린 것 같다., 서버 시간 초과 이런 식으로 나오는 것으로 봐서 호스팅 업체의 PHP 서버에 문제가 있는 것으로 추정됩니다. 혹시 이 문제를 해결하는 방법을 아시는 분 좀 도와주십시오.

Although there seems to be no errors in my feed URL or feeding XML source, both RSS and ATOM feeds are not working properly especially for the users of web-based RSS aggregator. A server misconfiguration or any unknown reason is suspected to cause this feed error and I asked my web hosting provider to check this. If you are a subscriber of my blog, your RSS reader will not update any posts from my blog for the time being. I feel really sorry about this.

October 17, 2007: Some aggregators including Google Reader, Bloglines, Allblog, and Feedburner returned to the normal status although I lost some subscribers. Feed Validator, My Yahoo! still cannot recognize the feed. Plus, the loading speed of the web pages became much slower again. Hosting provider seemed to do something on my request.

Read more "Feed crashed! Feedburner subscriber disappeared!"

Returned to a normal, actually better one

Thanks to one of the smartest guys, Jungshik (my brother at Google), I could come back to the better future! He found that the hosting service provider just generated the MySQL 3.x dump as it had been. It was actually encoded with utf-8 with no explicit encoding direction in it. One mistake I made is that I did not set the DB character set as utf-8 but it was still in euc-kr in WordPress configuration file in the WordPress root directory. Big mistakes the hosting provider made include that they set the default DB and connection character set as euc-kr and all collations configured for all tables were also euc-kr. Luckily enough, combining all these mistakes, the existing data displayed correctly while newly imported data cannot be stored properly. People tried to enter data with utf-8 encoding according to the web page encoding scheme and the DB interpreted them as euc-kr data which was wrong.

What Jungshik did was to backup the existing tables first. He found that the MySQL has a bug (that is, the last about 20 bytes were trimmed or tangled when exporting its tables to a local SQL file). He just made a shell script to fix this bug and also he converted the dumped SQL to a genuine utf-8 certainly specifying all necessary character sets using his script. Then he just changed the default table names for WordPress because it could be dangerous to replace directly with the old tables. (WordPress provides a configuration file for you to change the default table name prefix.) After successfully restoring the new tables, he and I tested writing, editing, and searching, etc. However, I came to have more tables than necessary. Just after identifying that everything worked fine, he finally replaced the old tables with the new tables.

All things are ok but some works including visitors' comments made during transition period were unrecoverable. I truly apologize for your efforts to enter your message which had gone away.

드디어 워드프레스 업그레이드를 모두 마쳤습니다. 호스팅 업체에 부탁해서 MySQL 4.1이 있는 서버로 옮기고 나서 한글이 입력되지 않을 뿐만 아니라, 기존 데이터를 수정하는 순간 그 데이터도 손상되는 문제가 생겨 호스팅 업체에 몇 번씩 전화와 게시판을 통해 문의했지만 워드프레스의 문제일 뿐 자기들은 아무 것도 잘못한 게 없다고 했습니다. 사실은 처음에는 기존에 입력한 데이터가 화면에 보이는 것도 깨져서, 이게 한글의 문제가 아니라 진짜로 다른 문제인 줄 알았습니다. MySQL 3.x 대는 문자 인코딩 방식을 지정하는 것이 없었지만 사실 워드프레스는 유니코드를 사용하고 있었고, 그것을 호스팅 업체가 서버를 이전하면서 euc-kr로 가져와버린 것입니다. 이 문제를 미국에 있는 형에게 물어봤더니, 일단 호스팅 업체는 손대지 못하게 하라고 말하더군요. 그렇게 하고 형이 작업을 했는데, 간단한 셸 스크립트를 짜서 새롭게 덤프받은 DB의 문자셋을 변경했습니다. 변경하는 과정에서 MySQL 4.1의 버그도 발견했는데 그것도 셸 스크립트를 이용해 복원했습니다. 혹시나 해서 변경된 테이블을 바로 옛 테이블에 덮어쓰지 않고 새로운 테이블을 생성하였습니다. 그리고 워드프레스에서 새로운 테이블을 인식할 수 있게 테이블 이름 기본값을 바꾸어주었습니다. 데이터 입력이 제대로 되는 것을 확인한 후, 마지막으로 기존 테이블에 새로운 테이블 내용을 덮어쓰고, 다시 테이블 이름 기본값을 바꾸었습니다. 그리고 이제 쓸모없게 된 테이블들을 다시 지웠구요.

놀란 가슴을 이제야 진정시킵니다. 호스팅 업체에서는 이런 문제를 해결해주었을 리가 만무하고, 형의 도움이 있어서 천만 다행이었습니다. 형은 구글에서 제품의 세계화(internationalization)와 지역화(localization)를 담당하고 있거든요. 아무튼 이렇게 요란하게 소란을 피운 후에라도 완전한 유니코드 체계로 정착이 되었고 워드프레스 2.2를 쓸 수 있게 되어 다행입니다.

시스템을 변경하는 동안, 일부 데이터가 손상되었습니다. 한글 입력에 문제가 있는 줄 모르고 마구 에디팅을 하다가 날아간 것도 있고, 또 방문하신 분들이 한글로 코멘트를 입력했다가 날아간 것도 있습니다. 입력한 것을 날린 것에 대해 정말 죄송합니다.

Read more "Returned to a normal, actually better one"

WP Unformatted 플러그인을 깔았습니다.

워드프레스 2.0에서 글을 쓸 때에 엔터키를 쳐서 줄을 바꾼 곳에 대해 무조건 <br /> 마크업을 넣어버려 지금까지 HTML 문서를 좀 복잡하게 만든 경우에는 엉뚱한 곳에 <br />이 들어가버려 심각한 문제가 생겼습니다. 그래서 나중에 일일이 엔터키를 쳤던 곳을 다 지워주는 번거로운 작업을 했었습니다. 그렇다고 모든 글을 한 줄로 만들 수도 없고... 그래서 위지윅 에디터도 알아보고, 몇 가지 알아봤는데 가장 단순하고 깔끔한 것을 선택했습니다. 알렉스 킹(Alex King)이 만든 언포맷티드(WP Unformatted)라는 것인데, 글을 쓸 때에 커스텀 필드 키로 sponge라고 넣고, 값을 1이라고 넣어주면, 사용자가 쓴 마크업을 그대로 보여주게 됩니다. 물론 이것은 타자기로 치듯이 보여준다는 뜻이 아닙니다. (아직도 사용자가 작성한 내용에 대해 <pre> 마크업을 씌워서 이상하게 보여주는 게시판이 일부 남아있는 것을 봤습니다.) 웹 호스팅 업체에 MySQL 4.0 이상이 지원되고 아파치 mod_alias와 mod_rewrite가 모두 지원되는 곳으로 옮겨달라고 요청했는데, 그 이후에 워드프레스 2.2 설치하면 별 필요없는 것일지도 모르겠군요.

Read more "WP Unformatted 플러그인을 깔았습니다."

워드프레스 2.2 업그레이드 실패

워드프레스 2.0을 쓴 지가 오래되어서 2.2가 최근에 나왔길래 맘먹고 업그레이드를 시도했다. 설명서를 보고 데이터베이스와 파일을 모두 백업받고, 그런대로 잘 진행이 되다가 업그레이드 스크립트를 실행하는데, 경고가 나왔다. 데이터베이스가 옛날 버전이니 먼저 업그레이드를 하라는 것이다. 이런~. 그래서 호스팅 업체(아사달)에서 제공하는 MySQL 버전을 확인해보니 3.23.58이었다. 워드프레스 업그레이드 설명서를 보니 MySQL 버전이 꼭 4.0 이상이어야 한다면서 낮은 버전에서는 절대 업그레이드 하지 말라고 되어 있었다. 다행히 백업을 받아놨으니 망정이지 마지막 순간에 큰 일 날 뻔 했다. 옛날 버전으로 다시 돌아가는데 계속 에러가 나서 긴장했다. 겨우 원상 복구는 시켰지만 아까운 시간 홀라당 까먹으니 기분이 별로다. 호스팅 업체를 바꿔야 하는 걸까?

Read more "워드프레스 2.2 업그레이드 실패"