원인은 대충 발견한 것 같습니다. 다음 버전쯤에 패치를 수행하도록 하겠습니다.

"트랙백 트랙커" 플러그인이 켜져 있는 경우 티스토리의 트랙백을 받을 수 없습니다. 아마 곧 공지가 나갈것입니다.

이벤트 추가가 아니라 치환자 추가만 하면 되는거 아닌가요? --????

안녕하세요 겐조입니다. @.@;

몇가지;;

1. 3단이 만들기 어려운 것은 언어의 문제는 아닙니다.
단순히 카테고리 핸들링 부분만이 아닌 많은 곳에서 2단에 맞추어져 있습니다. 그리고 태터를 이용한 수많은 사이트가 2단에 맞추어져 있는거죠.
그래서 간단해 보이는 이 변경조차 많은 리소스를 요구하고 따라서 위에 지적하였듯 정말 필요해서 작정하지 않는 이상 간단하게 변경될 요소는 아닙니다.
물론 결정이 내려지는 순간에는 또 어떻게든 해낼 수 있을 것입니다.

2. 고객이 원하는 것인가.
SI에서 개발자들이 일방적으로 당한다라고 생각을 하겠지만 오히려 갑-을 관계가 편합니다. 을-병 관계라면 좀 더 어렵긴 하지만 그래고 고객의 '갑'이나 '을'로 정의할 수 있는 순간 깔끔해 집니다. 정말 "꼴통"집단이라고 정의가 된다 하더라도 그런 특성 답게 해결이 되니까요.
허나 태터처럼 불특정 다수를 위한 프로그램에 있어서는 피쳐 하나를 정하는 것이 매우 어렵습니다. 누군가 3단을 원한다고 했을 때 그것이 고객군 전체의 요구사항과 맞는지를 검사해야 합니다. 3단으로 변하는 것에 대해 직접적으로 거부를 할 고객은 없습니다만 그 변화가 만들어 낼 사이드 이펙트로 인해 다른 부분에서 어떤 고객군에게 마이너스 요소를 줄 수 있기 때문입니다.
모두들 만족할 수 없겠지만 항상 기능은 원하는 군과 싫어하게 될 군의 저울질의 연속이겠지요.

3. 3단이냐 n단이냐.
어떤 사람은 3단을 원합니다. 어떤 사람은 4단을 원합니다. 그리고 또다른 사람들은 무한의 분류를 원하죠.
어떤 한 선택이 결정되는 것은 커녕 이것조차 정의하지 못하고 있는 상태입니다. 무한의 분류가 앞의 것들을 포함한다라고 생각할 수 있을지 모르지만 그 변경에 의한 영향을 볼때 전혀 다른 요구사항이 됩니다.
혼자만 풀 수 있게 선택권을 달라는 것에 대해 개인적으로 소스를 수정해서 사용하는 것은 문제가 없지만 태터 전체로 봐서는 결국 3단도 지원하게 되는 셈이 됩니다. 많은 사람들이 2단도 아닌 1단을 쓰고 있지만 태터는 현재 2단을 지원하므로 2단까지 문제 없도록 구현되고 있는데 이를 3단도 일부 사람들은 쓸 수 있다라고 하는 순간 태터는 3단 지원이 되는 것입니다. 스킨제작자들도 3단까지 고려해서 만들어야 하죠.

뭐 그래도.. 카테고리 관련해서 아직 결정이 안되었다 뿐이지 계속 의견 수렴은 하는 부분이니 개인 의견 개진에 이은 전체적인 요구사항 분석을 해 주시면 되겠습니다. 3단으로 충분한가나, 3단을 갔을 때 얻는 이점, 단점 등등.

그건 AMG가 아닐까요? ㅋ

패딩, 마진으로 조정하기엔 브라우저 디펜던시가 있지 않을까요?

그냥 캡션에 BR을 허용하면 되지 않으려나.. --?

카테고리와 관련해서 3~4단 정도가 아닌 무한을 원하는 케이스도 있었습니다만 이때 얻는 것 보다 잃는게 더 많아서 현재가 유지되고 있을 것입니다. 파일 정리할때도 계속 폴더를 나눠 봐도 한계에 부딪혀 버립니다. 오히려 검색할 때 불편해 지고 파일 하나를 대체 어디에 넣어야 할지 망설여 질때가 점점 증가됩니다.

최근 시스템들이 제시하는 방법으로는 결국 태그가 방법일 것 같습니다. 글 하나에 멀티 카테고리를 지정하는 방법도 있겠지만 저장소의 구조는 간단하게/그리고 검색으로 해결.

뭐 카테고리내 태그로 검색 기능이 필요할지는 모르겠네요.

Zend 셋팅해서 프로파일링 한번 돌려봤는데, 가끔 -1500 이런 식의 맛이 간 데이터를 보여주긴 했지만 아무튼 대충 보니;;

GetRandomTags라던가, 태그 클라우드 계산해 주는 부분 로드가 좀 있군요. 특히 비관리자 모드에서는 암울.
태그 많이 쓰신 분들의 사이트 태그 페이지 로딩 속도도 아마 기가 막힐껍니다.

블로그 1초대 잡으려면 아마 이놈 캐슁이라도 해 줘야 할듯.

PS.
그전에 -1500ms이라고 주장하는 Zend는 버리고, 좀더 깔쌈한 Profiler가 필요한데 말이죠 @.@;

새로운 블로그로 이동하면서 이전 블로그의 이름을 적었다면 문제가 되겠죠.

치환자가 아닌 일반 데이터를 핸들링 하는 것은 좀 어렵습니다. @.@;

어차피 공지랑 키워드가 카테고리로 구현되고 있는 만큼, 그 카테고리도 받아주면 될 것 같군요.

-1, -2 같은 음수 인덱스를 받아 주려나 --?