1 hannal이 작성한 주제

  • hannal
  • 익숙한 사용자
  • 오프라인
  • 가입일자 2007-08-20
  • 글: 8

주제: 이사해오고 나서 예전 낱장주소 유지하기

안녕하세요.

오늘 새벽 4시경에 Wordpress 2.x 를 Textcube 1.5로 옮기는 확장기능을 만들었습니다.
여러모로 부실하지만 이사하는 데 필요한 것들은 거의 만족하네요. ^^;

다만, 제가 부딪힌 부분이 예전 블로그 낱장 주소입니다.

예전 블로그 주소가 http://www.hannal.net/blog 일 때, 이 주소 구조를 계속 유지한 채
텍스트큐브를 깔려고 하니 영 난감하네요. 간편하게 /blog 를 /blog2 식으로 바꾸면
되겠지만, 그건 저 자신도 그렇고 주소 체계를 쉽게 바꾸지 않는 분들도 그다지
좋아하시진 않을 듯 합니다.

그래서 제가 처음 생각한 방식은

1. 예전 Wordpress 의 낱장주소를 모두 별도 DB테이블에 담는다. ( 예전주소 -> 그 주소를 가진 텍스트큐브 속 post id)
2. 어떤 페이지가 열릴 때 그 주소를 분석해서(plugin으로 만들며 binding/listener 로 처리)  예전 Wordpress 주소라고 판명되면, 1번 과정에서 만든 테이블을 참조하여 그 글로 보내준다.

였습니다. 그런데 텍스트큐브 .htaccess 를 보니 2번은 안되겠더군요. 문제가 되는 부분은

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule !^(blog|cache)/ - [L]
RewriteRule ^(thumbnail)/([0-9]+/.+) cache/$1/$2 [E=SURI:1,L]
RewriteRule ^(entry|attachment|category|keylog|tag|search|plugin)/? blog/$1/index.php [E=SURI:1,L]
RewriteRule ^(.+)/[0-9]+$ blog/$1/item.php [E=SURI:1,L]
RewriteRule ^(.+)$ blog/$1/index.php [E=SURI:1,L]

입니다. 맨 마지막 줄. 파일과 디렉토리가 있을 때 뜨는 요청인데 위 조건들을 만족하지 않으면 blog/$1/index.php 로 넘기는 부분이죠.

모든 요청(?)을 index.php 로 넘긴 뒤 index.php 가 이후 과정을 판단하는 방식이 아니고 .htaccess 에서 1차로 갈라주다보니
위 .htaccess 조건에 없는 주소 요청은 file not found 가 뜹니다. (저 맨 마지막 줄에서 걸려서)
Wordpress 2는 .htaccess 가

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /think/index.php [L]

이게 다입니다. 모든 요청 주소를 index.php 로 넘긴 뒤 이 index.php가(정확히는 index.php가 require 하는 어떤 파일이 ^^; ) 접근할 수 있는 주소인지 아닌지를 구분합니다. 확장기능(plugin)에서는 텍스트큐브의 lisnter 에 해당하는(fireEvent) add_action 을 통해 화면이 열리기 전에 어떤 행위를 지정할 수 있습니다. 그래서 워드프레스에선 제가 처음에 생각했다는 방식이 가능합니다. 


예를 들어 저는 wordpress 낱장 주소 구조를

/%post_name%

이라고 합니다. 텍스트큐브로 치면 slogan 을 블로그 바로 뒤에다 붙이는 셈이지요.

/blog/hello_hannal

이렇게. 그런데 텍스트큐브는

/blog/entry/hello_hannal

이런 정책을 따릅니다. 꼭 저처럼 하지 않더라도

/blog/archive/3415
/blog/2007/10/23/3415

이런 식으로 하는 경우도 모두 위 문제에 걸립니다.

즉, .htaccess 내용 중 맨 마지막에 있는 blog/$1/index.php 에서 $1 을 만족시켜주지 못하므로 현재 텍스트큐브 구조로는 예전 블로그 낱장 주소를 유지하는 것이 어렵다는 결론이 납니다.

.htaccess 를 고치도록 하면 되겠지만, 이걸 이용자에게 스스로 고치라고 하는 건 많이 찝찝해서 되도록 피하려니 답이 안나오네요. (실은 저 혼자라도 .htaccess 를 고쳐서 해보려고 했는데 잘 안되더라고요. ^^; 머리가 나쁜 지 rewriterule 문서를 보고 했는데도 안되네요. 쩝)

뭐, 얼마나 많은 사람들이 이사를 하고 낱장 주소 유지하려고 바득 바득 기를 쓰겠냐만은, 기왕이면 텍스트큐브에 관심을 갖고 있는데 다른 블로그 도구를 쓰는 여러 사람들이 부담없이 갈아탈 수 있게 하고 싶습니다. 제 이사 확장기능 소스가 개판이라 그렇지 그래도 다른 블로그 도구 옮기는 기능을 덧붙이기 쉽게(??) 소스 구조를 짠 것도 그런 이유고요.

어떻게 하면 현 텍스트큐브 낱장 주소 구조와 완전히 다른 주소 구조를 가진 옛 낱장주소를 유지할 수 있을까요?

hannal (2007-08-30 11:56:54)에 의해 마지막으로 수정

2 hannal이 작성한 답글

  • hannal
  • 익숙한 사용자
  • 오프라인
  • 가입일자 2007-08-20
  • 글: 8

답글: 이사해오고 나서 예전 낱장주소 유지하기

Creorix 작성:

이 방법을 가능하게 하는 건 어렵지는 않을 것 같습니다만, 어쨌든 .htaccess를 수정해야 하는 것은 사실입니다.

RewriteRule ^(.+)$ blog/$1/index.php [E=SURI:1,L] 이 부분을 대략 RewriteRule ^(.+)$ blog/preserveURL.php?redirect=$1 [E=SURI:1,L]과 같이 바꾸고

preserveURL.php에서 DB에 접근해서 slogan이 있으면 blog/entry/$1로 이동하고, 그렇지 않으면 blog/$1/index.php로 이동하도록 하면 될 것 같습니다만...;;

그러면 무한 반복에 빠지지요. ^^;

Creorix 작성:

RewriteRule ^(.+)$ blog/$1/index.php [E=SURI:1,L] 이 부분을 대략 RewriteRule ^(.+)$ blog/preserveURL.php?redirect=$1 [E=SURI:1,L]과 같이 바꾸고

이렇게 했기 때문에 blog/뭐시기 로 들어오는 건 모두 preserveURL.php 이 받는데, 이 파일 안에서 다시 blog/$1/index.php 로 날리면 또 다시 preserveURL.php?redirect=뭐시기/index.php 가 받아서

/blog/notice/index.php/index.php/ ...

이런 식으로 계속 붙습니다. 그래서

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d

이거 위에

RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} !-d

를 넣어서 실제 파일이나 디렉토리가 없는 완전 가상 주소로 접근하면 preserveURL.php 가 받고, 실제 파일이나 디렉토리가 있는 주소(owner, entry, trackback, notice, tag 등등)는 원래 있던 /blog/$1/index.php 가 받도록 했는데 제가 .htaccess 미숙한 탓인지 언제나

RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} !-d

이 놈이 받더군요. ^^; 딱 봐도 아닐 듯한

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d

아래에

RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} !-d

이걸 넣으면 예상대로

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d

이 놈이 다 받아버리고. ^^; 그것 참...

그래서 혹시나 하는 작은 마음으로 preserveURL.php 에서 slogan 검사를 한 뒤 있으면 그 글로 이동시켜주고, 없으면(tag, notice, owner 같은 주소) 해당 위치에 있는 index.php 파일을(blog/$1/index.php) 통채로 include 해봤습니다. 즉, preserveURL.php 파일이 주소를 거의 다 받아다 역할을 갈라주는 Wordpress 2.x과 비슷하게 한 것인데요. 작동은 전반에 걸쳐 잘 작동하지만 owner 는 로그인이 안되더군요. ^^;



덧쓰기 : 아~ wp2tt ... 예전에 얼핏 본 기억이 나는군요. 진작 찾아냈더라면 10시간 절약 했을텐데! ^^;

덧쓰기 2 :

Creorix 작성:

지금 상태로 머리를 쓰지 않고 가장 쉽게 해결하는 방법은 .htaccess에 모든 entry slogan에 대해서 RewriteRule을 추가하는 것이지만 -_- 아시다시피 사실 현실성이 없지요 -_-;;

Wordpress 1.5 는 실제로 이렇게 처리 했었습니다. ^^ 모든 글에 대해서 그렇게 한 건 아니고요. page 라고 하는 고정글(태터나 텍스트큐브에선 notice 에 해당하는)은 모두 저렇게 일일이 Rewriterule 을 더했습니다. 그래서 .htaccess 를 갱신하는 event가 발생할 때마다 제가 따로 더해 쓰는 RewriteRule 을 함께 더하는 확장기능을 만들어 썼었지요. (쪽 더하거나 뺄 때마다 .htaccess 내용이 바뀌니까^^)

hannal (2007-08-30 14:45:52)에 의해 마지막으로 수정

3 hannal이 작성한 답글

  • hannal
  • 익숙한 사용자
  • 오프라인
  • 가입일자 2007-08-20
  • 글: 8

답글: 이사해오고 나서 예전 낱장주소 유지하기

Creorix 작성:

그럼 RewriteMap을 이용하는 것은 어떨까요? .htaccess에 직접 쓰는 것보다는 효율적이고, map으로 사용될 파일을 DB에서 가져와서 생성하면(물론 캐시를 생성해서 하면 더 좋겠지요) 될 것 같습니다.

RewriteMap에 관련된 것은 http://www.lofer.apo.or.at/manual/mod/m … rewritemap 이쪽 참조해 주시구요.

이전 주소만 유지하면 되는 거라면 처음 한 번만 map을 생성해주시면 되고, 아니라면 위에서 말씀드렸던 것처럼 모든 slogan을 가져와서 파일을 만드는 방법도 있을 것 같습니다.

이렇든 저렇든 번거로워지는것은 마찬가지네요;;

네, 해보는데 번거롭네요. 제 능력이 부족해서 해보다가 전부 실패 흑. (RewriteMap 으로 하려는데 제가 잘 몰라서 잘 못건드렸는지 500 에러가 띠익 띠익)

그래서 말인데 TC 에서 정식으로 지원하는 건 어떨까요? {prefix}OldPermalinks 라는 테이블을 만들고 이 테이블은

| id | old_slogan | curr_post_id |

형태로 하고, 이용자과 환경 설정에서 OldPermalinks 테이블 뒤적이는 걸 켰을 경우, 블로그 접근이 일어날 때 OldPermalinks를 맨처음 뒤적여서 해당되는 내용이 있으면 연결된 새 주소로 Redirect 해주는 거죠.

이걸 제안하는 이유는, 이런 기능을 확장기능(plugin)으로 감당할 수 있는 부분이 아니고 결국 .htaccess 처럼 원래 TC소스를 건드려야 하는데 TC 판올림 할 때마다 이용자가 직접 고친 소스 부분을 신경 써야 하는 것이 딱히 좋아보이지 않아서요.

o.o?

4 hannal이 작성한 답글

  • hannal
  • 익숙한 사용자
  • 오프라인
  • 가입일자 2007-08-20
  • 글: 8

답글: 이사해오고 나서 예전 낱장주소 유지하기

Creorix 작성:

그러려면 먼저 다른 블로그 툴 -> TC 컨버터가 만들어져야할 듯 싶습니다..;;

아니면 대부분의 이용자가 사용하지 않는 반쪽 기능이 될지도 모르니까요;;

네. 워프 2 텍스트큐브는 제가 만든 것도 있고, 이미 예전에 만들어진 wp2tt(tc) 것도 훌륭하더라고요. big_smile (ttxml 이용하는 것)

무엇보다 블로그 도구는 국내에선 태터가 잡고 있지만 해외에선 워프가 대세인데 워프 2 텍큐만 해줘도 해외 진출(??)에선 많은 가치가 있을 거라 봅니다. (그 많은 워프 이용자에게 낱장주소 보장하며 텍큐 제시하면 그것으로도 뭐 +_+)

wp2tt 처럼 ttxml 이용하는 걸 활용하면 다른 도구에서 텍큐로 옮겨오는 확장도구 만들기도 수월할 듯 싶고.