아직 로그인하지 않았습니다. 로그인 또는 회원 등록을 해 주시기 바랍니다.
TNF : Tatter Network Foundation forum » graphittie가 작성한 글
티스토리 스킨중에서 Vintage Black 이라는 스킨에서는 <s_t3>가 <body>아래 들어가 있는데..
그리고 티스토리에서 쓸 스킨을 만드는데 <s_t3></s_t3>가 없으면
코멘트도 안달리고, 검색도 안되고 방명록도 안써지고 티스토리 로그인하면 위에 생기는 메뉴바도 안생겨요.
그냥 Vintage 스킨처럼 body 맨처음과 맨끝에 붙여 써넣으시기만 하면 됩니다. 기능상 필요한 자바스크립트를 넣는 위치를 잡아주는 역할을 합니다. 디자인과는 하등 관계 없습니다...
제안이 없으면 제가 여태까지 논의된 것들을 바탕으로 기획서를 만들어보겠습니다. 주의하실 점은 2.0을 새로 제작하는 것은 결정된 사항이 아니며, 제가 작성하는 기획서는 2.0 제작 제안의 근거로 삼을 일종의 제안서라는 점입니다. 오해 없으시길 바랍니다.
음... graphittie님이 말씀하신 부분이, 위지윅 에디터와 관련된 부분인지(사실 위지윅 에디터 자체가 표준이 없기는 합니다-_-), 아니면 일반 DOM도 모두 포함하는 이야기인지, 좀더 객관적인 비교 자료 같은 것이 있으면 논의에 좀더 도움이 될 것 같습니다.
http://www.webdevout.net/browser_support_dom.php#about
이쪽 자료면 논의에 도움이 될 것 같습니다.:)
관리자 화면 구조와 디자인 분리도 제안합니다. Smarty를 쓰자고 우기고 싶지만, 반대하는 분들이 꽤 계시므로... PHP로 구현을 한다고 해도 좋으니 일단 모듈화가 가능하게 되었으면 합니다...
스킨구조가 많이 바뀌지 않길 기대해 봅니다.
스킨 치환자 바뀐 걸 억지로 찾아서 삽질한 기억이.. ㅜ_ㅜ
어떻게 좀 해봐야겠는데... 기존 것들이 구조적으로 문제가 되는 것들이 있어서요... 으음... 더 논의가 필요한데... 적절한 문서가 제공되면 그런 고생을 많이 덜어드릴 수 있을 거에요. 빨리 레퍼런스 사이트를 완성해야겠지요... -0-
완전 재작성.....;;
php5/6 대응도 들어가야 하지 않을까 생각해봅니다만 여전히 php4를 쓰고 있는 호스팅 환경들이 문제네요.;
그리고 DB 백엔드 추상화...도 어떻게든 시도해봤으면 합니다. 그렇지만 역시 MySQL 3.x 버전에 대한 하위호환성 지원 때문에 걸리는 게 문제군요.. -_-
가능해보이는 것으로는 1.2 버전 정도에서 본문 요약 기능을 제공하는 건 어떨까 싶습니다.
여기에 포함되었으면 하는 모든 요건을 쏟아 부어 보도록 하죠. 기획서 총대는 제가 매겠습니다.
100Mb 는 좀 그렇고; 개인적으론 20Mb 정도만 되어도 충분하리라 생각합니다. 팟캐스트는 전혀 써보질 못해서 잘 모르겠습니다만 모 지인께서 일반적인 Mp3 를 올리는데 11Mb~13Mb 가 되면 제한에 걸리고, 변환하자니 힘들고 해서 고생한다고 하더군요.
건의는 담당자 분께 전달해 드렸는데요, 반영이 될지는 모르겠네요...
태터툴즈 1.0이 나온지 1년이 되어가고 있습니다. 이제, 2.0으로 가야할 때가 아닌가 싶은데요, 1.x 버전에서 하위 호환성 때문에 수정/추가 되지 않은 부분이 많았습니다. 이제 '차기 메이저 버전에서 구현될 예정입니다'라고 답변 드렸던 데 대한 행동을 시작할 때가 아닌가 생각합니다. 현재 TNF의 개발 리소스로는 고생길이 훤히 보이지만, 새 버전의 구현은 현재 침체되어 있는 개발 자원 멤버들의 의욕을 다시 끌어올린다는 측면에서도 중요하지 않은가 합니다.
일단 저는
1. 스킨 시스템의 업그레이드(2.0으로?)
2. [##_category_##]의 대안 제시(레이블, 태그, 카테고리의 기능 관계 정리)
3. 데이터 백업 시스템의 강화
4. 팀블로그 및 강화된 다중사용자 모드(멤버 관리 기능 포함)
5. 설치 프로세스의 UI 변경.
6. 관리자 스킨에서 다국어와 텍스트 이미지의 병행 문제
7. 에디터의 모듈화 및 현 에디터의 재작성
8. 스팸 처리 기능의 일관성 향상 및 강화.
9. 자바스크립트 사용불가능 환경에 대비한 layer 차원의 지원 마련.
10. component의 적극적 도입.
등을 제안합니다. 새 버전의 소스는 완전 재작성을 기본으로 하되, 1.x 버전에서 안정성이 확보된 부분은 코드 재활용을 허용하도록 했으면 합니다. 아마 이 branch가 된다면 기획 단계부터 철저하게 시작해야겠지요.
2차 도메인으로 접속되는 것은 버그가 맞는 것 같군요. 티스토리 담당자 분께 전해 드리겠습니다.:)
PS : 앞 문장은 모니터링 했습니다. PAPACHA님이 크레임을 날리셔서...;; 이번 경우는 로직이 완벽하지 않아서 생긴 버그로 인식하시면 될 것 같습니다.
음. 저 둘 다 사용해 봤는데요, 저것들이 너무 민감한게 아닌가 하는 생각이 드는데요. 지원을 하려면 어떻게 해줘야 할 지 좀 난감한 상황이...
제가 태터툴즈를 개발하면서 가장 중요하게 생각하는 점이 시각장애인이 태터툴즈를 사용할 때 어떤 문제가 발생하는가 하는 점입니다. 생뚱 맞게 오페라 위지윅 지원에 무슨 소리를 하냐고 생각하시겠지만, 조금 장황하게 적겠습니다...;; 웹 브라우저에서 시각장애인 지원이라는 것은 사실, 일부 정부 사이트에서 제공하는 시각장애인용 ActiveX로 해결되는 것이 아닙니다. 시각장애인들은 스크린 리더라고 하는, 합성음성을 지원하는 특수 브라우저로 웹 서핑을 하지요. 이 스크린 리더가 사용하는 문법을 정의해 놓은 것이 HTML 스펙입니다. 쓸데 없는 ActiveX를 만드는데 돈을 쓰는 것보다 단순히 HTML의 정확한 사용법을 알고 올바르게 사용하기만 하면 세상 모든 스크린 리더들은 제대로 동작하게 되죠.
제가 이런 예를 들어 말씀 드리는 것은, 태터툴즈 개발의 철학 중 하나가 '표준'의 준수라는 것을 알려드리기 위함입니다. 더도 말고 덜도 말고 딱 표준만 준수하면 세상 모든 브라우저에서 정상적으로 동작하게 되는 것이지요. 비표준을 지원하기 시작하면 세상의 수많은 예외를 하나하나 따로 설명해줘야 한다는 것을 의미하고, 이 방식은 개발에 들이는 시간 면에서나 효율면에서 좋지 않다고 생각합니다. 따라서 요약하면 저희는 특정 브라우저에서 보편적으로 작동할 수 있는 '표준'을 개발의 근간으로 삼고 있다고 할 수 있겠습니다.
이야기를 다시 오페라로 돌려보면, 오페라의 DOM은 표준 사용법을 따르지 않는 경우가 많습니다. 따라서 현재 저희는 오페라를 지원하지 않고 있습니다. 이유는 위에 설명드린 것과 같습니다. IE처럼 비표준이라고 해도 사용자가 다수 존재한다면 사실상 그 비표준이 표준이기 때문에 그 방식을 지원할 수밖에 없겠지만, 오페라 사용자는 아주 소수이기도 해서 현재까지는 오페라 지원에 들일 수 있는 노력을 다른 쪽으로 투자하는 것이 효율이 높지 않은가 판단하고 있습니다.
충분한 답변이 되었는지 모르겠군요. 한 가지 변명을 더 드리자면, 저희가 결코 하기 싫어서 안 하고 있는 것이 아님을 알아주세요.T_T
PS. 이런 사항은 불변의 원칙이 아닙니다. 포럼에 오페라 위지웍 지원에 대해 공감대가 이뤄진다면 그 때는 군말 없이 오페라 지원을 시작할 수 있겠지요...
이게 http://forum.tattertools.com/ko/viewtopic.php?id=2182 이 논의에서 왜 사용자 피드백을 그대로 받아들일 수 없는가에 대한 실제 케이스가 되는 것 같군요. hyeonseok님의 제안은 내용상으로는 적절했다고 생각되지만, 태터툴즈의 역사와 하위 레거시 문제상 그대로 수용할 수는 없었다고 판단해야 할 것 같습니다. 저는 이게 논의가 어디서 되었던 것인지 본 기억이 없는데... 논의가 되었던 적이 있었나요?
index.xml에서 contentWidth를 조절해 보세요. 그 값을 읽어들여 자동으로 행/열 값을 계산하도록 되어 있다고 합니다.
2단으로 카테고리 자체를 제약한다는 것 자체가 테터툴즈의 무한한 가능성을 제약하는 결과가 되는것 같습니다.
2단에 있는 카테고리의 글을 다른 2단 카테고리의 밑으로 내려서 3단카테고리로 쓸수도 있고, 반대로 3단 카테고리를 2단, 1단까지 올릴수도 있도록 하는게 현재의 구조로 불가능 하다면, 더 낳은 카테고리의 구조를 확립하는것은 어떤지요?프로그래밍 힘든 부분이 카테고리가 선택될때, 상위 카테고리가 하위 카테고리를 포함하기 때문에, 하위 카테고리를 찾고 또 거기에 해당하는 글을 가져오는 부분에서 문제가 되는 것인가요.
분명 다같이 생각해 보면 지금 문제가 되는 부분에 대한 해답도 나올것이라 믿습니다. ^^
예. 지금 제가 생각하기에도 이 카테고리가 가장 낙후된 기능 중 하나 같습니다. 이건 뭐 살짝 건드릴 수준이 아니라 완전히 뒤집어야 하는 문제가 되나서요... 그럴라면... 이건... 버전 1.5나 2처럼 메이저 업그레이드에 해당하는 기능이라 안 건드리고 있는데, 아마도 하게 된다면 기존 카테고리 [##_category_##]는 그대로 놔두고 완전히 새로운 카테고리 치환자가 등장할 가능성이 높지 않은가 해요... 적어도 저는 지금 그런 식으로 틈틈히 구상하고 있습니다. 이게... 하위 레거시를 위해서도 좋지 않을까 해서요... 하여튼, 완전히 뒤집는다는 것은 변화가 크다는 것을 의미하기 때문에 적절한 타이밍을 기다리고 있습니다.:)
흠... 조금 있다가 좀 뒤져 보도록 하겠습니다아...
이것과 관련 있는 것인지는 모르겠으나 subdomain.tistory.com 및 2차 도메인으로 연결하고 있는 tistory 블로그가 접속 안되고 있습니다.
티스토리 공식 홈페이지 및 공식 블로그 역시 열리지 않고 있습니다. 공지가 올라왔었나요?
10시 무렵에 연결이 안 되는 것으로 파악되어 수선에 들어 갔었습니다. 지금은 잘 되는 것으로 알고 있어요.:)
PS. 10시쯤에 또 공격이 또 있었다는군요.
제가 잘 못이해하고 있는건지.
<body onload="">
이렇게 안되던가요?
저는 잘 쓰고 있는데.
플러그인에서 자동으로 body 안에 onload를 삽입하고 싶다는 말씀 같습니다.
플러그인을 하나 만들어 볼 요량으로
남의 코드를 짜집기 하다보니
body 태그에 onLoad 속성을 넣으려니
도저히 모르겠네요?
가능은 한건지요?
[##_SKIN_head_end_##] 이벤트를 이용하셔서 다음과 같이 onload 이벤트에 특정 함수를 붙일 수 있습니다.
니들웍스 window.addEventListener("load", execLoadFunction, false);
function execLoadFunction() {
xxx
}
window.addEventListener("load", execLoadFunction2, false);
function execLoadFunction2() {
xxx
}이렇게 하시면 <body onload="xx">와 같은 효과가 발생하고요, onload 이벤트에 저런 식으로 복수의 함수를 걸어주실 수 있습니다. 자바스크립트는 onload 이벤트를 제어할 수 있는 방법을 제공하고 있지만, 각 브라우저 별로 제어방법이 다르기 때문에 태터툴즈에서는 addEventListener() 함수를 자체적으로 내장하여 이 함수의 내부에서 브라우저별로 제어 케이스를 나누어 실행하도록 되어 있습니다. 당부 드릴 점은, 추후 이 함수의 사용법이나 기능이 변화할 수 있다는 점을 인식하시고 사용하셨으면 합니다.
[##_SKIN_head_end_##] 이벤트의 사용법은 BlogAPI 플러그인을 참고하세요.
핑백... 총대를 매신 분이 계시기는 계셨죠... 누군지는 직접 언급할 수 없고;;(콜록콜록) 포럼을 좀 둘러보시다 보면 알게 되실 거에요... 압박 좀 넣어주삼.:|
문제가 된 블로그 http://bumbum.tistory.com 는 28일 23시 무렵에 자진 폐쇄되었습니다.
제가 글을 좀 이상하게 쓰긴 했네요.:/
태터툴즈 1.1.1을 쓰고 있는데 원본크기와 글에서의 크기가 같은데도 리샘플링을 켜면 리샘플링을 하네요. jpg 이미지고요.
버그겠군요... 혼란을 드려 죄송합니다. 살펴 보겠습니다.:)
건더기 작성:무성의한 답변 같습니다만;
스킨 디자인 문제인 듯 싶습니다.제가 알기로는 댓글의 이름 치환자인 [##_rp_rep_name_##] 을 사용 했을 경우
블로그 아이콘 플러그인의 사용 유무에 따라 이름 앞부분에 아이콘이 붙느냐 안붙느냐가 결정 지어집니다.
아이콘 플러그인용 치환자가 따로 있는 것이 아니고요..스킨을 만들다 이런 고민에 부딛혀서 글을 남겼는데 딸랑 스킨의 문제라니.. ㅜㅜ
제 생각으로는 기껏해봐야 이미지에 display:block 를 적용해서 줄바꿈할 수 있는 정도밖에 안될거 같은데..
음... 약간 도움 말씀 드리면... position:relative를 사용하시면 어느 정도 제약 없는 레이아웃이 가능합니다. 장점도 있고 단점도 있는 방법이지요... 비슷하게 float:left(right)를 사용하실 수도 있고요... 사용법은 직접 조사해 보시는 편이 좋을 것 같습니다. 한 두 줄로 설명될 수 있는 속성들이 아닌데다, 비교적 CSS의 고급에 해당하는 기능이라(저 속성을 어떻게 이용하고 있는가에 따라 하수와 중수가 나뉩니다) 앞으로도 많이 다루시게 될 터이니 조금 공부를 해두시라는 의미에서요...
혹시 해당 블로그의 다른 글들이 다른 분의 글을 퍼온 것이라는 사실은 확인된 것이 없는지요? 금연을할까?님 이외에도 펌질이 이뤄진 것을 확인하면 상습으로 판단되어 보다 빠르게 대응할 수 있겠습니다.
포럼에 오래 있지않아서 스팸에 대해서 어떻게 진행되어 가는지는 잘 모르겠습니다.
많은 테터툴즈 사용자가 스팸때문에 많은 분들이 고생하고 계신게 아닌가..싶습니다.
프로그램으로 어떻게 처리해도 스패머들이 그 소스를 보고 다른 방법을 생각해낸다면.. 그 역시 방법이 없을것이라 생각합니다.
바이러스와 백신처럼 말이죠..
문득 이런 조건을 생각해봤습니다.
1. 하나의 IP에서 트랙백이 오는데 동일한 단어가 포함된 트랙백이 지속적으로 온다든지.
(예를 들면 1분에 몇개.. 이런식으로요..)
2. 트랙백을 보낸 사이트의 주소와 제목이 동일할 경우위와 같은 경우엔 트랙백을 거부하도록 하면 어떨까요? ..;;
1번의 경우라면, 1분에 1개로 제한하면.. 하루에 3600개로 제한(?)이 될테니까요....
-_-;;;;ps: 괜시리 휴지통에 있는 트랙백중에 혹시나!! 있을지 모르는 정상적인 트랙백을 찾는 것도 은근히 스트레스로 작용하네요..;;;
으음... 스팸이 점차 고도화 되고 있으니 필터 기능도 강화를 할 필요성은 있겠군요. 이 참에 이 글타래에서 필터에 대한 불만을 주욱 털어놓도록 해볼까요...;;
답변이 좀 늦었습니다...;; 첫 글에서 독해가 안 되는 부분이 있어서;;
블로그 설정의 리샘플링 체크박스가 리샘플링을 '아주' 끄고 켜는 것 같은데 원래 이렇게 작동하는 것인지요?
저의 경우에는 이미지 리샘플링과 관련된 체크박스에 체크를 하면 넣는 모든 이미지가 기본으로 리샘플링 체크되고 작동하는데 체크박스를 풀면 기본으로 리샘플링 체크가 되지 않고 작동하지 않습니다.
넵. 관리자 화면에서 환경설정 부분에 들어 있는 체크박스는 리샘플링 기능 전체를 끄고 켜는 기능을 합니다. 주의 문구에도 적혀 있는 것처럼 리샘플링 기능은 서버 리소스를 과도하게 사용할 수 있기 때문에 이런 상황이 발생했을 경우에 리샘플링 기능을 정지시킬 수 있도록 하기 위해 추가한 기능입니다.
그리고 리샘플링 기능과 관련해서 한가지 더 이야기 하자면 기본으로 리샘플링을 사용하게 해 두었을때, 워터마크 기능을 사용하지 않는다면 삽입되는 이미지들 중 크기가 본문 폭에 맞춰 줄어들지 않는 이미지는 리샘플링을 기본으로 사용하지 않도록 체크되지 않게 하는 것이 좋다고 생각합니다. 이미지 품질이 많이 떨어지니까요.
이 말씀은 이미지 리샘플링을 적용할 필요가 없는 이미지는 리샘플링을 하지 않도록 하자는 말씀이지요? 이미 그런 루틴으로 동작하고 있습니다. 안 그렇다면 그것은 버그지요......
TNF : Tatter Network Foundation forum » graphittie가 작성한 글