UseModWiki소스수정/사용자추가매크로

이 페이지는...

• 매크로 작성법이나 설치법은 UseModWiki매크로를 참조하세요.
• 매크로 파일은 .pl 파일을 그대로 올리면 다운로드할 수 없으니 zip 으로 압축하던가 확장자를 txt 등으로 바꿔서 업로드해 주세요.
• 범용적으로 쓸 수 있고 호응이 좋은 것들은 ext 버전의 macros 디렉토리에 넣어서 배포할까 합니다. 근데 그런 매크로들은 처음부터 제대로(다시 수정하지 않아도 배포할 수 있도록) 작성해 주시면 고맙겠죠. :-)

1. <prevnextdiary>

2. <mostedited(시작순위,끝순위)>

3. <mysign(이름,서명시각)>

4. <small>타임스탬프</small>

5. <adminonly>내용</adminonly>

1. <prevnextdiary>

• Diary나 StarCraftReplay 등의 페이지에서 사용하기 위해 만든 것. (그러나 정작 Diary같이 최근 일기를 include 하는 경우에는 효과가 없고, Diary/2004-10-09나 Diary/2004-10과 같이 특정한 날짜 또는 달에 해당하는 페이지에서만 동작함)
• "년-월" 형식의 페이지에서 사용하면 이전 달과 다음 달에 해당하는 페이지의 링크를 표시
• "년-월-일" 형식의 페이지에서 사용하면 그 날을 전후로 가장 가까운 날짜에 존재하는 페이지를 찾아서 그 페이지의 링크를 표시
• "상위페이지/년-월(-일)"의 경우도 마찬가지
• 그 외 페이지에서는 아무 것도 출력하지 않음

• Raymundo : /단축키개선이 적용되어 있으면, "p"와 "n"으로 이전 페이지와 이후 페이지로 넘어갈 수 있게 수정했습니다. - 2005-2-6 2:04 pm
• Raymundo : Diary페이지가 블로그 형태로 바뀐 이후로 사용 불가능. 기존의 일기장 형태일 때만 의미가 있음. - 2005-3-4 5:07 pm

2. <mostedited(시작순위,끝순위)>

• Diary/2004-12-23에 적은 이유로, 갑자기 필요해서 급조한 것
• 사용법은 /MostPopular매크로와 동일
• 각 페이지의 마지막 revision 번호를 읽어서 리비전 번호가 큰 순서대로 정렬하여 출력한다.
• 딱히 ext버전 패키지에 포함할 필요가 있을까 싶긴 한데, 특별한 제한 없이 사용할 수 있는 것이므로 별 문제가 없다면 포함할 수도.

3. <mysign(이름,서명시각)>

• 기존 /MySign매크로의 동작을 대체함
• 새로 달린 서명에 표시를 붙여서 눈에 띄기 쉽게 함.
  • 로그인한 사용자의 경우, 사용자의 북마크시각보다 더 최근에 생성된 서명 뒤에 NEW라고 붙는다.
  • 로그인하지 않은 사용자의 경우, 오늘 날짜에 생성된 서명 뒤에 Today라고 붙는다.
  • 위 파일의 코드 내의 $newsign 변수를 고쳐서 그림이 표시되게 한다던가 등으로 바꿀 수 있다.
• mysign 에 들어가는 서명시각 인자가 "년-월-일 시:분"의 형태로 "초"가 빠져 있기 때문에, 서명의 시각을 계산할 때는 "0초"에 생성된 것으로 가정한다. 따라서 북마크 시각보다 최대 1분 후에 생성된 서명은 NEW표시가 안 달릴 수 있다.
  • 위 소스의 "($1, $2, $3, $4, $5, 0, $6)"의 0을 59로 바꾸면 이 문제는 해결되나, 반대로 북마크를 가장 최근으로 갱신했는데도 계속 NEW표시가 나오는 서명이 있을 수 있다. 본인이 좋을 대로 적용할 것
• Time::Local 패키지가 필요하다. /Calendar매크로가 잘 돌아가고 있다면 이 패키지도 있을 것이다.

• Raymundo : 처음 올렸을 때와 mysign.txt 가 바뀌었습니다. - 2005-1-12 3:06 pm

4. <small>타임스탬프</small>

• 한줄잡담과 같이 comments 매크로를 사용해 작성한 글에도 위의 mysign과 같이 NEW 또는 Today 가 붙게 함.
• 부작용
  • 정확히 얘기하면 <small>년-월-일 시:분 am</small> 의 형태로 적힌 문자열을 읽어서 시각을 비교한 후 뒤에 표시를 붙여주기 때문에, 이런 형태의 문자열이 무조건 치환되어 버리는 부작용이 있다. (그렇지만 comments매크로를 사용해 작성하지 않은 이상 이런 문자열이 딱히 있을 리가...)
  • 한 페이지의 모든 코멘트에 대해서 이 비교를 매번 하기 때문에 속도가 느려진다. (2003년도 분량을 분리하지 않았을 때의 한줄잡담 페이지를 처리하는 경우, 코멘트가 총740개 있었고, 이 매크로가 없을 때는 평균 2.91초, 이 매크로가 있을 때는 평균 3.19초가 걸렸다. 현재 한줄잡담페이지의 경우는 각각 1.46초와 1.63초. 뭐 0.3초 정도의 차이이므로 봐줄법 하다고 생각함.

5. <adminonly>내용</adminonly>

• adminonly 와 /adminonly 로 둘러싼 "내용" 부분은, admin 권한을 가진 사람에게만 출력된다. 권한이 없는 사람에게는 아무것도 출력되지 않는다.
• Diary/Footer에 있는 "For Admin" 단락을 주인장에게만 보이게 할 수 없을까 해서 만든 매크로.
• 단지 브라우저 화면에 출력되지 않는다는 얘기이고, 페이지 수정 또는 소스 보기를 하면 내용이 전부 보인다. 괜히 오해하여 비밀스런 내용을 적는 일이 없도록 할 것. :-)

• JuanmaMP : adminonly deserves to be treated in a way that remember PageIsHidden, with subtle differences. With help a "summary" when editing that automatically appends a mark when this happens, for instance "adminonly" in "summary" (or any other). GetDiff works in help, GetRc needs a change (next if ((!$all) && ($ts < $changetime{$pagename}))), requires other conditions, for instance if in DoEditPrefs, an user doesn't accept " Show all changes ", can happen that some changes in the same pages have adminonly an other haven't. DoRc have to change in the similar manner if page is hidden. At last, &ColorDiff gives the sequence (for instance, a change can be, erase one adminonly, other write an adminonly, but only the second option have to hide for users without admin role. I am working around this subject. It seems to goes well. - 2012-7-23 12:49 am
• Raymundo : The purpose of this macro was just to make 'final output' to be hidden from non-admin users. It doesn't hide any 'diff', 'rc', 'page source'. Of course it will be great if this macro hid all such things, but I thought it required so complex code. :-) - 2012-7-24 7:48 am
• JuanmaMP : You're right. Veeery complex because for instance, they appear some side-effects that require much imagination in order to see them all in advance ¬¬ - 2012-7-25 9:55 am
• JuanmaMP : For the moment, the most important stage is creating filters with automatic markup in summary (on dopostmain). Because one way to do it is take advantage from the format of this summary is employed that for spread of these filters in other subroutines. It seems I have three filters, now: added adminonly (to hide), changed inner content from one adminonly (then to hide too), or deleted adminonly: tags and contents (then hide, too; because it was an hidden content). The 4th scenario, deleted tags but not content, then visible; because it assumes one wants undo adminonly. It's all by the moment ... (a wonderful nightmare :)) - 2012-7-25 10:11 am