두 분 접수되셨습니다

꼭 삭제하지 않으셔도 됩니다. 그냥 링크 두 개 있으니까 이상할까봐 그런거겠죠^^ (아니면 그냥 존재하는 링크 테이블에 prefix를 끼워넣는 방식이라거나?)

지금도 플러그인이 고유의 데이터베이스를 가질 수 있으므로 해당 기능들을 대신하는 플러그인을 만들기는 쉽습니다. (통계기능 플러그인을 참조해주세요^^) 관련해서 관리자 화면에서의 인터페이스도 제공할 수 있고, 사이드바 형식으로 스킨에 끼워 넣는 것도 제공할 수 있으므로 사실상 현재도 다 가능합니다. 아직 잘 알려지지 않아서 (documentation의 문제가 큽니다만 ㅠ_ㅠ) 시도를 안 할 뿐이죠.

기존의 치환자를 대치하여 뿌려주는 방식은 오히려 자유도에 영향을 더 준다고 생각이 듭니다. 현재 스킨 시스템의 상하위 호환성이 관련 부분의 발전을 완전히 붙잡고 있는 상황인데 계속 그 레거시를 강요하게 되니까요. 새로 생기는 기능들도 그 치환자들을 사용하게 한다면 더 종속성이 강해지게 될겁니다. 지금부터 해당 기능의 발전들을 사이드바 쪽으로 활용하도록 하는 것이 낫다고 생각합니다. 이제... 새 스킨 시스템으로 이전해야죠.

여담이지만, 1.1 알파때에는 스킨 안에 캘린더나 링크, 카테고리 부분이 아예 없었습니다. 전부 플러그인으로 빠져 있다가 스킨으로 도로 끌려 들어간 경우들입니다. ㅠ_ㅠ

그 경우라면 스킨에서 그냥 그 위치에 사이드바 속성을 지정해 버리시면 됩니다. 그럼 그 부분이 사이드바 1이 될 겁니다^^ 그 후에 구겨넣어도 되겠네요.

(생각해보니 어차피 스킨을 수정하는건 똑 같네요. 하하)

옙^^ 좋은 아이디어네요.

문제라면 다중사용자를 위해선 굉장히 복잡해집니다. 현재 변경된 파일은 customize/유저번호 디렉토리 아래로 들어가게 됩니다만, 위의 기능을 지원하려면 그 아래 하위 디렉토리들이 더 만들어져야 하겠네요. 그리고 스킨이 지워졌을 경우 모든 유저의 해당 변경 스킨도 지워줘야 합니다.

예를 들어, 천명이 쓰는 태터 블로그에 스킨이 15개 설치되어 있으면 (....)

그냥 지금 편집한 파일을 백업해서 사용자가 가지고 있을 수 있게 하는 것으로는 안될까요? 태터툴즈 데이터 백업처럼 현재 편집한 스킨의 설정과 백업을 사용자가 가질 수 있도록 지원하는게 나을 것 같다는 생각이 듭니다. 이 경우 스킨 배포 및 업로드나 다운로드가 자유로와지는 장점도 있겠네요.

http://dev.tattersite.com/svn/universe/ … /outlogin/ 을 참조하셔도 될 듯 합니다. 치리님의 outlogin 플러그인의 universe 버전인데, 말씀하시는 기능이 다 들어있습니다.

직접 세션키를 따오는 방식이라 소스가 좀 깁니다. J.Parker님의 방법을 사용하시는 것이 간단하실거에욥^^

그리고 J.Parker님의 index.xml에서 <sidebar 로 지정해주면 스킨에 특별한 치환자를 넣지 않아도 사이드바 구성요소로 추가해서 사용할 수 있습니다.

현재 사이드바의 갯수는 스킨에 따라 다르게 지정할 수 있도록 되어 있습니다. (스킨에 사이드바 영역을 몇 번 지정했느냐에 따라 안 써도 되고 세 개 써도 됩니다. 더 써도 되려나?)  말씀하신대로 사이드바 갯수를 고정하는 방법도 있겠지만, 사이드바 갯수의 자유도는 유지해 줘야 하지 않나 싶습니다.^^

그리고 사이드바 아이템의 경우 스킨에 내장되어 있는 사이드바 패널과 플러그인이 만든 패널을 함께 사용하도록 되어 있습니다. 스킨이 변경될 경우에도 사이드바 설정을 유지하면 스킨에 내장된 사이드바 아이템의 처리가 미묘해집니다. 본질적으로, 이 스킨에서 구현하고 있는 사이드바 패널에 들어있는 '최근 트랙백' 이 저 스킨에 구현되어 있는 '최근 트랙백' 과 같을 필요가 없기 때문입니다. 그것들이 같은 패널인지에 대해서도 판단을 해야겠죠.

각 사이드바가 어떻게 출력되는가에 대한 아웃라인은 스킨에서 어떻게 표현하고 지정하느냐에 따르는 구조입니다. (완전히 디자인 요소이죠) 말씀하신 경우라면 3단 스킨의 양쪽에 사이드바 영역을 지정하고, footer영역에 사이드바 영역을 지정한 후 스킨 제작자가 거기에 들어가면 좋을 부분을 구현한 후 그냥 패널 치환자 (<s_sidebar_element> 였을거에요)로 묶으면 됩니다. 가로세로도 스킨에서 디자인 하는대로 들어갑니다. 현재 사이드바의 자유도 부분은 스킨에 다 주어져 있습니다.

편집 초기화 문제는 대안을 생각 중입니다. 스킨 편집하면서 스킨에 내장된 사이드바의 기본값이나 위치도 변경할 수 있기 때문에 (뭣하면 만들어 넣을 수도 있죠) 이걸 어떻게 해야 할지 참 어렵네요.

저 분 지금 이글루스 아니라 워드프레스 스킨 이야기 하고 계십니다.

전혀 딴 내용의 댓글을......

dress를 동적으로 삽입하여 스킨의 특정 영역을 해석하도록 만드는 방법이 있겠군요. 관련한 플러그인 이벤트를 기존에 존재하던 SKIN_head_end 등과 같은 메타 이벤트 형식으로 삽입해서 적용할 수 있을 것 같습니다. 방법은 좀 생각이 필요하겠군요. 작동을 위한 시나리오를 묘사해 주시면 함께 생각을 정리할 수 있겠습니다. 부탁드려요

이후 스킨과 플러그인이 셋으로 묶여 일종의 템플릿을 구현하는 것으로 가게 될텐데, 그럴 경우 의존성 검사등의 부분이 추가적으로 필요하겠군요.^^

해당 기능에 대한 요청이 많았으므로 다음 주 중에 우선 샌드박스 쪽으로 구현해 보겠습니다.
(다음주까지 기다리기 힘드시면 누가 구현을 좀... 그라피티에님?)

블로그 방문해 보니 이미 용궁에 가 계신 것으로 아뢰오

iendev님 반갑습니다^^

DNS 문제네요. 갱신했습니다. 아마 오늘내일중으로 인터넷 전체가 갱신될거에요.

말씀하신대로 어렵지는 않습니다. 만드는 것도 어렵지 않습니다. 태터툴즈의 소스 버전을 받으셔서 blog 디렉토리의 하위에 keyword 정도로 하나 만드시고, 역시 blog 하위의 notice의 내용을 복사해서 집어넣고 좀 수정해 주시면 가능합니다. 스킨의 해당 부분 파서도 있어야 겠네요. lib/model/skin.php 에서 지정해 줄 수 있습니다. 문제는 블로그에 그게 필요한 이유를 source moderator 에게 설득해야 한다는 점입니다. moderator 그룹의 회의때 키워드 기능을 되살리려고 엄청나게 고생했던 경험에 비추어 봤을 때, 굉장히 설득이 힘들것 같애요. 태터툴즈를 복슬복슬한 나무가 아니라 잘 빠진 나무로 키우는 것이 방향성이기 때문에...

말씀하신 부분의 구현은 구태여 키워드 기능까지 사용하지 않아도 모두 플러그인으로 구현이 가능합니다. 그냥 글들을 이용해도 되지요. viewcontentpost였나? 하는 이벤트에서 본문을 받아 와서 플러그인에 본문 파서를 만들고 현재 글들의 제목을 DB에서 읽어와 리스트로 만들고, [[ ]] 로 표시된 단어들을 읽어와서 그게 목록에 있는 경우 해당 글로의 링크를 만들어 주는 식으로 가능합니다. 키워드를 포함시키려면 카테고리값이 -1인 글들의 제목까지 읽어오면 됩니다. 키워드 글을 본문처럼 보이게 하는 것도 사실 이벤트 후킹을 통해서 현재 글 보여주는 부분에 키워드를 끼워 넣는 방법이 가능할겁니다. htna님과 함께 예전에 버린 위키 파서 주워다가 함께 짜 보고 싶지만 지금 시간이 너무 없어서... ㅠ_ㅠ

12월 말에 저와 함께 짜보시는 것은 어떨까요?