inureyes 작성:

<s_login>과 <s_logout>은 대안이 있는 상태에서 추가할 필요성을 못 느끼고 있습니다... 그걸 추가한 스킨은 1.0에서 쓰질 못하게 되니까요. 굉장히 어려운 일인데, 지금 규격은 태터툴즈 1.1 스킨을 태터툴즈 1.0에서 돌려도 되도록 '상하위 호환성' 을 보장하도록 만들어져 있습니다. (그래서 1.1 알파시절 추가된 부분이 많이 잘려 나갔습니다.) 말씀하신 치환자는 그 제약조건에 위반되죠.

<s_ad_div>의 경우에,
<s_ad_div>는 <s_login>의 대안이 될지는 몰라도,
<s_logout>의 대안이 되지는 않습니다.

더구나
<s_guest>, <s_article_rep> 등과 같은 것의 범위 내에서만 활성화가 됩니다.
즉 저 범위를 벗어나는 위치에는 전혀 효과가 나오지 않습니다.

즉, 대안이라고 보기에는 부족하고, tatter의 임의의 위치에서의 표현은 불가능한,
location / keylog / guestbook 등의 위치에는 넣을 수 없는 상황 입니다.

하위호환성 이란게, 상위버전의 스킨이 하위버전에서 완전히 똑같이 나온다는 말인가요?
그렇다면, 1.0과 1.1의 차이는 성능개선 외에, 기능추가는 없다는... ?????

77

(3 답글들, 잡담하기에 작성)

posting category로 keyword, notice, post 가 있지 않습니까..

notice 에 게시를 위해서는...
즉 notice sicebar에 항목 하나를 넣기 위해서는
posting category를 notice로 해야하는데...
이 notice를 원래는 keyword 혹은 post로 하고 싶다는 것이죠.
즉. keyword로 하면, keyword검색이 되되, notice에서 클릭하면 keyword 로 뜨고,
post로 하면, blog에 나오되, notice에서 클릭하면 역시 뜨고...

실은 하고싶은게...
Resume 를 keyword로 구현했습니다만,
이를 notice에 같이 공지하고싶은 겁니다.
왜 keyword로 유지하고 싶냐...
wiki형태의 링크를 가지고 싶어서 이거든요...
(위키 플러그인을 (좀 허접하지만) 만들어 쓰고 있다는...)

inureyes 작성:

요약하자면, 태터툴즈는 다중사용자 기반으로 설계되었기 때문에 관리자를 통하지 않고 php 스크립트를 직접 삽입하거나 수정할 수 있는 방법이 생기면 보안상 문제가 발생할 수 있습니다.  그럼 단일 사용자일때만 지원하면 되지 않느냐? 고 하시면, 아예 그 부분 설계를 이중으로 해야 하는 부담이 생기며 단일 사용자와 다중 사용자 모드 간의 호환성이 확 떨어지는 문제가 있습니다 - 정도로 답변 드릴 수 있겠습니다.

이해가 갈듯 말듯 합니다.

"다중 사용자 모드이기 때문에, php로 skin을 처리할 경우, 보안상의 문제가 간다"는 것은 어느정도 수긍할 수 있습니다.
그렇다면, 같은 문제로, "다중 사용자 모드이기 때문에, php로 된 plugin 역시, 보안상의 문제가 생길 수 있는것" 아닌가요?

<s_login>, <s_logout> 은 넣어주실거죠 ??
*^^*

79

(3 답글들, 잡담하기에 작성)

notice에 keyword posting과 특정날의 posting을 링크하려 합니다.
방법 없나요 ???

예전에 비슷한 질문을 한 적이 있어서.
찾아보려 했는데 찾을수가 없더군요...

원 목적은 티즈님의 말과 같은 <s_login>...</s_login>, <s_logout>...</s_logout> 이었습니다..
http://forum.tattertools.com/ko/viewtopic.php?id=2263
에서 얘기를 꺼냈었습니다.

"플러그인으로 처리하라"는 쪽으로 대세가 기우는 듯 해서...
skin.html 에서 해결할 수 있는 방법을 찾으려고, html에서 doesHaveMembership(), doesHaveOwnership() 호출할 수 있는 방법을 찾으려고 하던 중...
하지만 나중에 (login/out정도 뿐만 아니라..), php에서의 다른 기능들을 skin에서 사용하려고 하는 경우까지 간다고 봤을때,
skin.php 를 고려해보는 것도 나쁘지 않겠다 싶어서.
(어짜피 보안문제야, 플러그인역시 가지고 있고, 플러그인 사용에 관한 책임은 사용자에게 지워지기에...)
skin.php 까지 가게 되었습니다.

사실 앞서 얘를 든 1-6 까지의 경우나,
로그인 했을때만 보여지는 링크, 통계 등은 모두 <s_login>, <s_logout>가 지원된다면,
skin에서 이로 해결이 가능합니다.

<s_login>, <s_logout>의 필요성은 0.6x 버전때부터 느끼고 있었습니다만..
아직은 건의가 없었나보군요...

1.1.0.3 에서 반영이 되면, 제일먼저 사용할 기능이지 않을까 합니다.

나니 작성:
htna 작성:

플러그인을 따로 공부해서...
내가 사용하는 스킨과 내용에만 맞는 형태의 플러그인일 테니 말이죠..

그게 태터 사용하는 재미 아닐까요?
자기 입맛에 맞는 플러그인 제작. 이거야 말로 정말 태터를 재미있게 사용할 수 있는 방법 중 하나라고 생각합니다. smile

죄송합니다.
저는 tatter소스를 고쳐가며 사용하기 보다는.
가능한한 있는 부분을 이용해서, 쉽게 원하는 기능을 구현할 수 있는 방법이 더 좋다고 생각하고 있습니다...
각자간의 가치관이죠...

결론적으로, tatter login plugin 을 수정해서 처리했습니다.
그냥 플러그인 한번 손봐서 만들고 신경을 끄면 되는것을...

'태터' 죄송합니다. 그냥 발음하는대로 적다보니 '테더'가 되었군요...

일단은 확장가능성이 없다는 것으로 인지했습니다.
제가 접속한 admin 일때만 접근 가능한 링크를 tatter에 출력하기 위해서 플러그인으로 만들어야만 한다는사실과,
login logout 을 위해 맘에드는 형태로 만들기 위해서 역시 새로운 플러그인을 만들어야 한다는 사실두요.
플러그인을 따로 공부해서...

개인적으로, 플러그인 개발과 같은 큰 노력을 들이지 않고 나의 기호에 맞는것을 가져다 쓰려는 것 자체가 무리였나 생각이 듭니다.
아마 이런 플러그인은 만들어도 배포할 일은 없게되지 않을까 합니다.
내가 사용하는 스킨과 내용에만 맞는 형태의 플러그인일 테니 말이죠..

나니 작성:

치환자 같은 경우도 치환자가 아닌 함수로 써야할 수도 있겠네요.
(스킨 개발하는 입장에서는 좀 복잡해질 수도..)

호환성 레거시 문제도 걸리고..

한번에 너무많이 올리게 되는군요..
헉헉...

테더가 (skin.html)을 입력으로 브라우져에 뿌리는 것과,
테더가 (skin.php -> skin.html)을 입력으로 브라우져에 뿌리는 것은,
호환성의 레거시 문제와는 걸리지 않는다고 생각됩니다.

더 좋은방법이 있다면,
skin.html 안에서 php를 사용할 수 있도록 하는 방법일 듯 한데, 이런 방법은 없나요 ??
아니면, skin.html 안에서 script(java)에서 php의 특정 몇몇기능들을 함수호출로 사용할 수 있도록 하는 방법은.. ???

graphittie 작성:

skin.php를 허용한다고 해도 매 스킨마다 새로 짜야 하는 것은 마찬가지 아닐까요? 오히려 어느 정도 스킨 호환성이 보장되는 플러그인 시스템이 더 좋다고 생각되는데요.

그리고 laziel님 말씀처럼 보안 문제가 반드시 함께 이야기되어야 하는 이슈라고 생각됩니다.

특성화된 스킨을 만든다와,
그 특성화를 위해서, 스킨을 수정하고 플러그인도 만들어야 한다.
두가지가 아닌가 봅니다.

플러그인의 확장성은 당연하다고 봅니다.
하지만, 앞서 언급하였던것 처럼...
스킨에따라.. 지정된 출력이
(스킨 1)에는 텍스트로 사이즈가 10이고 글꼴은 굴림이며 글자색은 흰색이고 마우스가 올라갔을때 파란색으로 반전이 되는게 더 보기 좋고,
(스킨 2)에는 텍스트로 사이즈가 10이고 글꼴은 굴림이며 글자색은 검은색이고 마우스가 올라갔을때 노란색으로 반전이 되는게 더 보기 좋고,
(스킨 3)에는 텍스트로 사이즈가 11이고 글꼴은 굴림이며 글자색은 검은색이고 마우스가 올라갔을때 노란색으로 반전이 되는게 더 보기 좋고,
(스킨 4)에는 이미지로 흰색글씨에 검은색 바탕의 버튼으로,
(스킨 5)에는 이미지로 흰색글씨에 파란색 바탕의 버튼으로,
(스킨 6)에는 이미지로 검은색글씨에 흰색 바탕의 버튼으로, 마우스 반전이 있고

등과같이 스킨에 맞는 특성을, 플러그인으로 모두 소화한다는 것은 무리라고 보여지지 않은지요..
아니면, 저런 자신의 블로그를 특성화 하기 위해서, 플러그인의 소스를 분석해서 고쳐야만 한다면, 플러그인의 configuration이 무색하겠죠...

물론 덩치가 커다란 기능은 플러그인이 제공하는 범위내에서 사용하는게 나을것이라 보입니다.
하지만, 사소한 기능 역시 플러그인으로 해결하려 한다는게...
제가보기에는 '배보다 배꼽이 더 큰 형상'으로 보여지는 것이죠.

보안에 관련된 문제에 대해서는,
(먼저 올린 포스팅에서 볼 수 있듯이)
플러그인 사용시의 보안문제가 사용자에게 달려있듯이.
스킨의 사용시 보안문제 역시 사용자에게 달려있다고 봅니다.

laziel 작성:

그 정도라면 태터툴즈의 기능 자체의 추가를 고려해야 하지 않을까요.
스킨에서 php 를 허용해버리면 고려해야하는 보안이슈가 늘어나는거 아시죠?=_=;

분명히, 말씀하신 것 처럼 스킨을 php 로 하는 경우에 얻을수 있는 이익이 있을겁니다.
하지만 그로인해 잃게 되거나, 감수해야만 할 많은 문제점도 동시에 고려해야합니다.

물론 스킨에 php를 허용할 경우 발생할 수 있는 보안이슈가 있다는 것은 자명할 것입니다.
하지만 그와 더불어, 플러그인에 php를 허용할때의 보안이슈도 마찬가지라고 생각합니다.

스킨과 플러그인을 사용자들이 사용할 경우에 생기는 문제점 모두를 테더에서 책임질 수 없다고 봅니다.
그렇기에, 플러그인을 사용자가 선택해서 사용할 경우에 대한 보안문제를 테더가 책임지지 않듯이.
스킨을 사용자가 사용해서 생기는 보안문제 역시 테더가 책임져야 한다는 것은 맞지 않다고 봅니다.

그렇기에, 확장성을 위해서 스킨에 php를 추가해주는 것 역시 나쁘지 않다고 봅니다.
도리어, 블로그의 동적성격을 부여할 수 있기에 확장성 등에서 더욱 좋을것이라 봅니다.
더욱이, 이러한 결과로 더욱 쓸모있는 스킨이 많이 개발되지 않을까 합니다.

추가로...
저런 관리자모드일때 통계가 보이고, 게스트모드일때 통계가 안보이고 하는 것들을
기능으로 테더 자체에 추가한다면...
테더가 추구하고있는 가벼움의 원칙에서 벗어나지 않나요 ???
단시 스킨에서 조절하면 될 것을, 테더에서 조절한다는게...
어떤면에서는 한 기능의 가능한 모든 특성을 다 가지고있으려고 하는것처럼 보이는군요...

그럼 매 스킨마다 필요한 플러그인을 만들어야 한다는 말이 되는군요...
플러그인으로 빼기에는 빈약한 기능임에도 불구하고,
플러그인으로 처리해야 한다는...

물론 플러그인의 확장가능성이 좋은것은 사실입니다.
하지만, 단지
1) guest 일때 login 으로 찍고, admin 일때 logout 으로 찍으며,
2) guest 일때 통계를 숨기고, admin 일때 통계를 나타내고,
3) guest 일때는 없지만, admin 일때 지정된 텍스트와 링크 메뉴가 나오도록
만드려면, 1,2,3 에 해당하는 플러그인을 하나하나 만들어야 하고,
더구나, 각 스킨마다의 디자인이 다를것이기에, 각 플러그인을 특성화 할 수 있도록 하거나, 하니면 스킨마다 맞는 플러그인을 만들어야 한다는 결론이 나오는군요.

플러그인 물론 좋습니다.
큰 기능의 경우에 특히요.
하지만, 스킨과 맞물려 돌아가는게 좋은 부분들에서 역시 플러그인을 강요한다면.
매 스킨마다 그에맞는 플러그인을 만들어야 하거나, 한 플러그인을 모든 다변성을 가지는 정말 덩치가 큰 플러그인으로 만들어야 할 것입니다.

이런경우..
배보다 배꼽이 큰 경우가 되죠...

매우 간단한 기능지원, 혹은 스킨을 php로 지정할 수 있게해서, 스킨의 능동성을 부여하는방법이,
플러그인으로 처리하기 불편한 부분을 쉽게 해결하도록 지원할 수 있는 방법이 아닌가 생각합니다.

skin.html 대신 skin.php 를 사용할 수 있게 했으면 합니다.
아무래도 스킨에 동적인 요소를 가하려고 하니...
html과 javascript로는 한계가 있군요..

네 자바스크립트를 의미하는 겁니다.
자바스크립트 안에서 php함수나 변수를 이용할 수 있는지를...

script에서 doesHaveMembership(), doesHaveOwnership()  호출할 수 있는 방법 있나요 ???

링크를 카테고리화 해주는 플러그인이 있는듯 합니다.
이 특징이, 사이드바에 새로운 아이템을 추가하고, 기존의 링크를 삭제해야 하는 듯 하네요...

아예, 기존의 링크 등을 확장시킬 수 있는 방법을 제공해주는건 어떨까요?

XXX 이벤트를 처리하는 함수가 있으면, 그것을 통해서 링크를 출력하고,
없으면, 기존의 루틴을 통해서 링크를 출력시킬 수 있도록 하는...

이렇게하면, 위와같은 기능을 활성화시키기 위해서 별도의 노력이 필요없고,
또한 동시에 모든 스킨에 적용될 수 있으니.. 일석이조일듯 하군요...


물론 링크만의 얘기가 아닙니다.
Link, Comment, Trackback, Calender, Category, 통계, 등을요...
특히 링크, 통계, 캘린더, 카테고리 등의경우에는 많은 기능들이 플러그인으로 쉽게 개선되고, 쉽게 활용되지 않을까 합니다.

inureyes 작성:
htna 작성:
inureyes 작성:

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

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

customize/유저번호/skin.html
customize/유저번호/style.css
이렇게 되어있을 경우에 역시, 어드민이 스킨을 지울경우, 같은 문제가 생기지 않나요?
각 skin.html이 참조하고있는 image 등이 존재하지 않을테니 말이죠...

그렇기에...
customize/유저번호/스킨네임/skin.html
customize/유저번호/스킨네임/style.css
이렇게 진행한다고 해서 큰 문제가 되지 않을듯 합니다.

그게, 이미지까지 카피를 합니다....

그렇기에 문제가 됩니다 ~ 용량의 로드부터 주욱 -

흠야.. 설마 이미지까지 카피할 줄이야...
그렇다면, 걱정하시는게, 모든 사용자의 스킨 커스터마이징 디렉토리에, 모든스킨이 들어있을 것을 걱정하시는 거군요...
흐미...
그렇다면, 스킨을 지운다고 해도, 각 사용자가 사용하고 있는 스킨은 지워지지 않겠군요...

직접 대면하고 얘기하는게 훨씬 쉽겠습니다만..
우선 봐야할게...
skin/스킨네임/skin.html 이 있을때
1) skin/스킨네임/custom/유저번호/skin.html
2) customize/유저번호/스킨네임/skin.html
두가지 방법을 고려해 봐야 겠군요...

1) 유저를지웠을때, 사용자정보가 같이 지워지지 않는다는 단점이...
2) 스킨을 지웠을때, 사용자는 여전히 각 스킨을 커스터마이징 했다면, 쓸 수 있다는 단점이...

1의경우에는,
할당량과 관련된 문제이기에 그리 추천하는 방법은 아니겠군요.

2의경우에는,
이미, 기존의 스킨을 지운다고 해도, 멀티유저가 그 스킨을 복사해서 사용하고 있기에 (자신의 쿼터가 허락하는 한..)
각 유저가, 자신이 사용할 스킨'들'을 복사해서(커스터마이징 해서) 사용한다해도, 큰 문제가 되지 않으리라 봅니다.
이때 필요한 기능이...
시스템에 깔려있는 스킨을 내가 사용하도록 설정할지 -> 시스템의 스킨을 내 커스텀 스킨 디렉토리로 복사할지..
내가 사용하도록 설정한 스킨을 삭제할지 -> 내 커스텀 스킨 디렉토리를 지울지..
의 기능을 하는 것을 추가해주면 되지 않을까 생각되는군요...

물론 각 사용자가 사용하는 디스크용량이 늘어날 수 있다는 단점을 가지고 있지만...
각 사용자에게 약 5개의 스킨을 커스터마이징해서 사용할 수 있게 한다고 하면,
멀티유저들이 더욱 환영하지 않을까 합니다.

inureyes 작성:
htna 작성:

죄송합니다. 꼭 모양이 다이얼로그의 탭처럼 생겨서...
keyword, location, tag, guestbook, ...
의 위치 옆에 끼워넣으려 합니다.
"Login", 혹은 "Admin/Logout/Write" 을요..
가뜩이나 본문의 길이가 짧은데, 사이드바가 더욱 길어지는게 싫더라구요. ^^

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

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

저의 짧은 지식으로는...
"tag" 등의 위치에 사이드바를 넣고싶지는 않습니다.
사이드바이면 가뜩이나 height 등이 커서, 모양이 깨지기 쉬울텐데...

inureyes 작성:

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

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

customize/유저번호/skin.html
customize/유저번호/style.css
이렇게 되어있을 경우에 역시, 어드민이 스킨을 지울경우, 같은 문제가 생기지 않나요?
각 skin.html이 참조하고있는 image 등이 존재하지 않을테니 말이죠...

그렇기에...
customize/유저번호/스킨네임/skin.html
customize/유저번호/스킨네임/style.css
이렇게 진행한다고 해서 큰 문제가 되지 않을듯 합니다.

나니 작성:
htna 작성:

실은.
사이드바에 넣고싶은게 아니라, tab에 넣고싶습니다.
다만, 비슷한 예제가 sidebar 에 있기에...

정말 궁금해서 그럽니다만, tab..이 뭐죠..?;;;; (일반적으로 쓰이는 탭은 알겠는데 블로그에서 탭은...;; )

죄송합니다. 꼭 모양이 다이얼로그의 탭처럼 생겨서...
keyword, location, tag, guestbook, ...
의 위치 옆에 끼워넣으려 합니다.
"Login", 혹은 "Admin/Logout/Write" 을요..
가뜩이나 본문의 길이가 짧은데, 사이드바가 더욱 길어지는게 싫더라구요. ^^

실은.
사이드바에 넣고싶은게 아니라, tab에 넣고싶습니다.
다만, 비슷한 예제가 sidebar 에 있기에...

위와 같은 (사이드바&스킨특성화) 에 대해서 다을과 같이 처리하면 되지 않을까 생각합니다.

우선, 스킨마다 선호하는 사이드바의 구성이 다르리라 생각됩니다.
그리고, 각 스킨마나 지정하는 특성화가 다르리라 보구요.
이 문제를 해당 스킨디렉토리에 저장하는 방식이 어떨까 생각합니다.
예를들어...

custom.skin.html <- skin.html 을 사용자가 수정하였을 경우에 저장되는 파일 입니다.
custom.style.css <- style.css 를 사용자가 수정하였을 경우에 저장되는 파일 입니다.
cuntom.sidebar.xml <- 사용자가 사이드바의 위치 구성 등을 수정하였을 경우에 저장되는 파일 입니다. 이는 xml로 하지 않고 txt로 적당히 저장을 해도 될 듯 합니다.

이와같이 저장을 한다고 하구요...
사용자가 테더에서 스킨을 선택하는 순간,
저 화일들이 있으면, 그냥 그 화일을 오픈합니다.
저 화일들이 없으면, 스킨화일을 복사해서 저 화일들을 만든뒤, 오픈합니다.
블로그 홈페이지가 오픈되면, 기본적으로 저 화일들이 존재한다는 가정을 두고 이용합니다.

이렇게 하면, 속도문제와, 각 테마별 스킨화일 커스터마이징을 같이 할 수 있다고 보여집니다.
물론, 기존의 테마가 저 화일들을 가지고 있다면, 문제가 될 수 있습니다만, 우선 저런 이름을 가질일이 거의 없다고 보구요.
화일이름으로 custom.* 인 화일은 테더에서 기본적으로 customize를 위한 화일이므로, 임의로 스킨개발자가 만들지 말도록 하자 고 한다면, 앞으로의 확장에 여유가 생길 듯 합니다.

그리고, 앞서, sidebar 문제로 고민이 된다고 하셨습니다만,
custom.sidebar.xml 등과 같이 처리한다면, 각 스킨이 사용하고 있는 sidebar pannel의 처리 역시 쉽게 해결되지 않을까 합니다.

graphittie 작성:
htna 작성:

스킨을 변경할때마다, 사이드바가 초기화 되더군요.
초기화 되지 않도록 할 수 없나요???

음... 이런 상황이 있을 수 있지 않을까요. A라는 스킨 사이드바에는 달력 모듈이 있고, B라는 스킨 사이드바에는 달력 모듈이 없습니다. 사용자는 A 스킨을 쓰고 있었고, 지금 B라는 스킨으로 바꿨습니다. 이렇게 하면 달력 모듈의 정보는 증발해야 맞는 거죠. 사이드바 시스템에서 누락된 모듈을 찾아내 자동으로 제거해 주면 좋겠지만 사이드바 내부 시스템 상에서 개별 모듈은 아이덴티티를 가지고 있지 않습니다. 전부 order 값으로 구분되고 있지요. 이 문제점 때문에 스킨 변경시마다 초기화되고 있습니다.

네.
비슷한 문제로 이러한 처리가 골치아프리라 미리 생각하고 있었습니다.
1.1.0.2 깔아본 결과, 현재의 스킨은 sidebar를 dynamic하게 정리할 수 있는듯 합니다.
제 생각입니다만. (소스를 보고 이해하고 말씀을 드려야 옳은것으로 생각됩니다만. 현재 이해해 주시기 바랍니다.)
기존의 방법은 [##_달려_##], [##_트랙백_##] 등과 같이 처리하던것을.
현재의 방법에서는 [##_사이드바_##] 로 처리하면서, 내부적으로 순서를 DB등에 저장하고 있는듯 합니다만...

이렇다면,
[##_사이드바1_##], [##_사이드바2_##], [##_사이드바3_##]
와 같이 3개의 기본카테고리로 두고,
스킨편집자가 사이드바1 을 왼쪽, 사이드바2 를 오른쪽, 사이드바3 을 아래쪽 등에 배치하거나,
다른 스킨편집자는 사이드바1, 2, 3 을 모두 나란히 오른쪽, 혹은 왼쪽 등에 배치하게하면,
이런문제가 어느정도 해결되지 않을까 합니다.
물론 [##_달려_##] 등을 직접 사용하는 경우라면, 사이드바1 의 order는 남아있는다고 전제를 하구요.

추가로, [##_사이드바1_##] 의 아이템들인 [##_달려_##], [##_트랙백_##], [##_링크_##] 등이...
가로로출력 이면
[##_달려_##], [##_트랙백_##], [##_링크_##]
이렇게 (이경우는, 본문 밑에 리스트를 달 경우...)
세로로출력 이면
[##_달려_##]
[##_트랙백_##]
[##_링크_##]
와 같이 지정할 수 있게 된다면, (이경우는, 본문 좌/우 쪽에 리스트를 달 경우...)
스킨개발자와 사용자간의 자유도(??)도 높이고, 테더스킨의 사용자도 늘릴 수 있지 않을까 합니다.

네...
살펴보겠습니다.
감사합니다.

고맙습니다.

하지만, 가능하면 테더소스를 건들고 싶지가 않아요...
테더가 업그레이드 되면, 내가 변경한 부분을 모두 기억해서 다시 수정하고 동작확인을 해 줘야 하는데...
그런일이 너무 귀찮습니다.
가능하면, 스킨하고, 플러그인으로 처리되었으면 하는 바람...
^^

먼가 기능을 추가하기 위해서,
테더 소스를 건들어야 한다는게,
테더를 많은 사람들이 사용할 수 없게 만드는 단점이지 않을까 합니다.

스킨을 변경할때마다, 사이드바가 초기화 되더군요.
초기화 되지 않도록 할 수 없나요???
어느경우에 보니, 사이드바를 3단으로 할 수 있게 하고,
그 3단을 일렬로 표현해서, 1단형식을 취하는 경우를 본적이 있는데...

이와같이, 기본으로 3단으로 할 수 있게 하고, 각 구성을 기억하게해서.
이리저리 스킨을 테스트해보려 바꾸는중에, 사이드바 등이 초기화 되지 않도록 할 수 없을까 합니다.

역시, 스킨의 edit 모드에서 값을 변경하였을때,
다른 스킨으로 갔다가 다시 오면, 역시 초기화 되어 있는데...
이 문제도 해결할 수 없나요???