* AddPostEditorToolbox : 글관리에서 글 작성/수정시 위지윅/textarea 출력 후 발생
    $target : 공백
    $mother : null

AddPostEditorToolbox 의 경우도 $mother 속성으로 $id 가 넘어가는게 확장성에는 더 좋지 않을까 하는 생각을 해봅니다.

새 글 작성 / 수정 시에 모두 AddPostEditorToolbox 이벤트가 호출되니까 $suri[id] 를 이용하면 수정 모드일 때에 대해서도 (누군가가 원할 수 있는) 어떤 동작을 할 수 있지 않을까 싶은...

index.xml 에 추가 필드를 명시해주는 것은 좋은 아이디어인듯합니다.. ( 비슷한 피쳐도 있구요) 다만 이에 대해서 모든 부분에 대해서 오픈하기는 다른 측면에서 무리가 있지 않나 합니다..

inureyes 작성:

js로 값을 모아서 넘기는 이유는 보안에 관련된 여러 가지가 있습니다. 허용하지 않는 값 이상은 받지 않겠다는 것이고, js단이나 php단 모두에 해당 부분이 구현되어 있지요. 플러그인의 경우 그 벽을 넘기가 힘들기 때문에 json으로 serialize하는 방안이 논의되고 있었습니다만, 어느새 묻혀 버렸네요. 다시 끄집어 내야 할 듯 합니다.

add 나 update 의 $IV 변수를 통해 그런 동작을 하는 것은 알고 있습니다.

하지만 허용하지 않는 값 이상은 받지 않는 것이 얼마나 보안상의 도움이 될 지 의문이 드는군요.

별 도움이 되지 않는다면 js 를 이용하지 않고, 제한된 값말고도 넘어가는걸 허용하는 방향으로 가는게 확장성 측면에서 좋을거라 생각하고,

정말 허용하는 값 이상을 받지 않는 것이 보안에 도움이 된다고 하면 json 등으로 serialize 하기보다는 plugin 의 index.xml 에서 추가 필드들을 명시해줄 수 있도록 하는게 더 좋지 않을까 싶네요. (단 로딩한 플러그인 리스트가 구축된 후에 POST 값 체크를 해야하기 때문에 손이 좀 많이 간다는 문제가 있겠습니다.)

IV 부분이 항상 의미 있는 것은 아닙니다. 하지만 특정 PHP 버전에 보안 홀이 있기 때문에 그걸 해결하기 위한 장치로 필요합니다. 보안상에 도움이 됩니다. 사실 굉장히 됩니다. PHP언어는 보안 부분 구현이 매우 느리고 약하고 문제가 문제를 만들어내는 경우가 많습니다. 그것도 이유이지만 저러한 코드들이 태터 전반에 쫙 깔려있는 더 큰 이유는 호스팅 업체나 사설 서버들은 PHP나 MySQL 패치가 나와도 그게 또 다른 문제를 만들 가능성이 있기 때문에 업데이트를 잘 하지 않기 때문입니다. 그래서 들여다보면 그러한 경우들에 대한 대응이 여러군데에 여러 방법으로  있습니다.

배포용 프로그램이라는 특성 때문에 환경에 따른 예외가 하나라도 있는 경우 걷어낼 수가 없습니다. mysql 3.23 관련한 유니코드 테스트 및 에뮬레이션 처리 부분 들어내면 속도 향상이 상당하겠지만 그대로 유지하고 있는 이유이기도 하고, 특정 PHP버전과 mysql이 만나면 서버에 따라 이상한 결과를 만들어내는 부분들을 처리하기 위한 루틴이 들어있는 이유들도 같습니다.

이해해 주셨으면 합니다.

js로 값을 모아서 넘기는 이유는 보안에 관련된 여러 가지가 있습니다. 허용하지 않는 값 이상은 받지 않겠다는 것이고, js단이나 php단 모두에 해당 부분이 구현되어 있지요. 플러그인의 경우 그 벽을 넘기가 힘들기 때문에 json으로 serialize하는 방안이 논의되고 있었습니다만, 어느새 묻혀 버렸네요. 다시 끄집어 내야 할 듯 합니다.

add 나 update 의 $IV 변수를 통해 그런 동작을 하는 것은 알고 있습니다.

하지만 허용하지 않는 값 이상은 받지 않는 것이 얼마나 보안상의 도움이 될 지 의문이 드는군요.

별 도움이 되지 않는다면 js 를 이용하지 않고, 제한된 값말고도 넘어가는걸 허용하는 방향으로 가는게 확장성 측면에서 좋을거라 생각하고,

정말 허용하는 값 이상을 받지 않는 것이 보안에 도움이 된다고 하면 json 등으로 serialize 하기보다는 plugin 의 index.xml 에서 추가 필드들을 명시해줄 수 있도록 하는게 더 좋지 않을까 싶네요. (단 로딩한 플러그인 리스트가 구축된 후에 POST 값 체크를 해야하기 때문에 손이 좀 많이 간다는 문제가 있겠습니다.)

js로 값을 모아서 넘기는 이유는 보안에 관련된 여러 가지가 있습니다. 허용하지 않는 값 이상은 받지 않겠다는 것이고, js단이나 php단 모두에 해당 부분이 구현되어 있지요. 플러그인의 경우 그 벽을 넘기가 힘들기 때문에 json으로 serialize하는 방안이 논의되고 있었습니다만, 어느새 묻혀 버렸네요. 다시 끄집어 내야 할 듯 합니다.

넵 그런데  현재 상황으로는 저 이벤트의 파워가 '알림' 이외에는 없는듯합니다. 몇몇 이벤트들도 플러그인이 태터에 관여 할수 있는 여지를 주지 않은 경우가 보이네요..

이 의견에 동감합니다.

wordpress 의 경우 플러그인이 테이블에 임의의 필드를 추가시킨 후 (alter table...) 그 추가된 필드를 이용해서 여러가지 동작을 하는 것이 가능하지만 (실제 tag 관련된 플러그인들이나 related_post plugin 들이 비슷한 동작을 합니다.) 제가 지난 며칠간 테태툴즈를 이용해서 비슷한 것을 시도해본 결과...

1. AddPostEditorToolbox 를 이용해서 임의의 인풋 박스를 추가하더라도 실제 넘겨질 데이타들은 javascript 를 통해 수집되므로 실제 필드를 추가하기 위해선 blog/owner/post/entry/post 에 있는 javascript 를 hack 할 필요가 있게됩니다. (실제로는 저것만이 아니라 blog/owner/post/entry/add 와 blog/owner/post/entry/update 의 첫라인도 수정해야합니다.)

그냥 일반적인 textarea, input tag 등을 이용해서 쉽게 확장할 수 있는 구조로 가는 것이 더 좋지 않았을까 하는 생각을 해봅니다. 그렇다고 textarea, input tag 등을 이용해서 구현한다고 현재 지원하는 것들을 지원하지 못하는 것도 아닙니다.

2. blog/owner/entry/add/ 등에서 사용하는 insert query 에서는

insert into tablename (column_name1, column_name2,...) values (value1, value2,... );
식의 쿼리가 아닌

insert into tablename values (value1, value2,... )
식의 축약된 쿼리이기 때문에 alter table 등을 사용해서 필드를 추가하게 될 경우 글을 추가하는 것이 불가능하게 되는 문제가 있습니다. (처음부터 이런 식의 확장은 고려를 하지 않은 설계로 보이긴 합니다만)

3. 위와 같은 문제로 인해 테이블에 필드를 추가하기보다는 새로운 필드들을 집어넣은 테이블을 새로 만들고, 그 테이블을 이용하려해봤습니다.

하지만 AddPost 만이 존재하고, UpdatePost 이벤트는 존재하지 않기 때문에 값을 넣을 수는 있어도 수정까지는 할 수가 없네요. 또 한 번 막혀버렸습니다.

만약 AddPost 와 UpdatePost 등의 이벤트가 모두 존재하고, javascript 를 이용해 값들을 모아 넘겨주는 구조가 아니며,  축약된 쿼리를 사용하지 않았다면 alter table 을 통해 필드를 만들고 AddPost, UpdatePost 등의 이벤트에서 값을 Update 해주는 것을 통해 tatter 에는 전혀 손을 데지 않고도 플러그인 형태로 간단한 구현이 가능했을텐데 이래저래 처음 생각했던 것과는 많이 달라 결국 테터를 hack 해야겠네요. 흑;;

플러그인쪽 보면서 생각이 드는 것이 Tatter 소스를 보지 않는 이상 정확한 정보를 얻을 수 없다는 점이 문제인듯합니다.

특히 event 이름은 혼란을 줄수 있는 듯합니다.

혹 직접 사용자가 제작한 데이터를 수정해야 하는 이유가 있다면, (언제나 그렇지만) 그러한 경우와 필요성의 논리를 설득해주세요 대세가 되면 변경됩니다.^^

ps. 추후 영문,한글에 대한 맞춤법 검사 로직(플러그인 등)이 포함되어있다면, 필요성이 있을수 있겠군요...

개발본 기준

파일명 tattertools\\blog\owner\entry\add\index.php
line 34 부터

if ($id = addEntry($owner, $entry)){
    fireEvent('AddPost', $id, $entry);
    setUserSetting('LatestEditedEntry',$id);
}

이렇게 되어 있는데 이벤트를 파이어하여 할 수 잇는 것은 이메일 날려주는 것 밖에 할 수가 없네요...
플러그인에서 실제적인 데이터의 가공에는 권한이 없는 것으로 되어서 그런지 .... 궁금하네요...

if ($id = addEntry($owner, fireevent('AddingPost', $entry) )){
    fireEvent('AddPost', $id, $entry);
    setUserSetting('LatestEditedEntry',$id);
}

이렇게 추가가 되어야하지 않을 가요?

흠 플러그인이 어디까지 커버해야하고 각 바인딩(index.xml 의 기술(記述)상) 형식 별로 어떤 한계와 어떤 역할을 해야 할지 먼가 스팩을 정해야 할 듯 합니다.

이외에도 /lib/model/rss.php line 82
    if (fwrite($fileHandle, publishRSS($owner, $rss))) {
        fclose($fileHandle);
        @chmod($path, 0666);
        fireEvent('refreshRSS',$rss);
        return true;
    }
도 있네요...

ViewAttachedImage 이벤트 뿐만 아니라 첨부된 다른 파일들, 예를 들어 zip 파일이라든가 다른 멀티미디어 파일들이 링크될 때의 이벤트는 어떤게 있지요?

이경우에는 경로명이 원래의 경로명이 아닌 채로 살짝 뒤틀려보이게 하는데 말이지요. attach/숫자/파일이름.zip 형태가 아니라 attachment/파일이름.zip 의 형태가 되더라구요. 이렇게 바꿔 보여주는 것은 어떻게 처리하셨습니까?

위에서 나열된 시점에서 태터툴즈가 fireEvent라는 함수를 이용 Handler( $target , $mother) 를 호출해줍니다.
Handler는 플러그인 index.xml에
<binding>
    <listener event="이벤트명">Handler</listener>
</binding>
일케 추가 하실수 있구요..

추가로 여러 이벤트 핸들러(리스너가 맞나..)가 있는 경우 아마도 플러그인 디비에 있는 플러그인 순서 대로 호출이 됩니다 ^^

헉 그러고 보니 이벤트 핸들러 만드는 부분에서

SELECT name FROM {$database['prefix']}Plugins WHERE owner = $owner

먼가 기준 없이 플러그인을 가져오니 여러 플러그인이 겹친 경우 애매할 수도 있겠네요

네. 그렇기 때문에 모든 플러그인은 다른 플러그인에 상관없이 동작할 수 있도록 제작해 주셔야 합니다.