I like the way that MoinMoin now separates those pages specific to the particular wiki from the standard files that provide support and instruction for the wiki user, plus, the easy way that help files are now just a click away. JonathanSmith 2005-01-29

통상 1단어 검색은 자유로운데 2단어 이상 검색할때 google등에서 사용하는 것과 같이 여러단어를 나열하면 and 검색을 하여 보여주는 매크로등이 있었으면 합니다. 좋은방법이 없을까요. --04년 3월 25일 김기상

data/user 밑에 있는 파일도 data/text 밑에 있는 파일처럼 UTF-8 코드로 변환시켰으면 좋겠습니다. 백업 등을 할 때에 충돌이 일어날 염려가 있는 것 같아서요.. --PuzzletChung

MoniWikiBlog에 BloggerAPI지원을 추가해보았습니다. 아직 문제가 많이 있고 구현안된것도 많지만, 일단 현재까지 된것은 http://hellocity.net/~iolo/files/xmlrpc_blog.php.txt 에 있습니다. GnomeBlog나 ChronicleLite라는 BloggerAPI클라이언트에서 테스트했는데 대충 굴러가는군요. editPost와 인증부분은 잘 몰라서 비워두었습니다.

와~~ 감사합니다~ 테스트해보고 넣어두겠습니다~ --WkPark

GnomeBlog라는 그놈 애플릿이 있습니다. Blogger 클라이언트인데, 포스팅만 할수 있는 간단한 프로그램이죠. 이 녀석이 글꼴 속성이나 링크를 WYSIWYG으로 편집할수 있게 되어 있는데, 이 태그들을 MoniWiki에 맞게 바꾸고 간단한 XmlRpc›1를 붙여서 플러그인을 만들었습니다. http://hellocity.net/~iolo/files/GnomeBlog.php.txt 이건 블로그와 무관합니다. GnomeBlog를 그냥 모니위키 페이지 만들기 및 내용 추가에 사용하는 거죠 --iolo

한 사용자가 여러번 고칠 경우, session을 체크하는 방식으로 하여 사용자가 원하면 고친 것을 merge할 수 있게 한다 ? (마지막으로 co한 revision을 지우고 다시 co 한다든지 하는 방식으로..)

config.custom.php 같은 걸 두고 config.php에서 include() 하면 어떨까요? (중요도: -1)

config.php가 너무 일반적인 이름이라면 다른 이름으로 바꾸던지 local/ 밑에 넣도록 하는 PmWiki의 방법도 괜찮을 듯합니다 --WkPark

위키에서 일기를 쓰고 싶은데, 블로그 형식으로는 지나간 날짜의 일기를 쓸 수 없네요. 일기를 블로그 형식으로 남겨 comment나 TrackBack을 사용할 수 있다면 참 좋겠습니다만.. -- hey

rss파일을 제공할때 description에 해당파일의 diff을 넣어주면(text겠죠?) 좋겠습니다. 요즘 rss viewer들이 많이 있는데... diff만 보여주어도 관리하기가 참 편해질것 같습니다. --iolo

일단, 위키에서 description은 그다지 큰 의미가 없습니다. diff를 넣으면 위키답겠지만, diff정보를 제대로 표현해 주려면 컬러링을 해줘야 할까요 ? 그리고, 현재 MoniWiki에서 사용하는 방법은 매번 ?action=rss_rc에 의해서 로그파일을 적절히 파싱해서 실시간으로 뿌려주기 때문에, 각 페이지를 diff하면 로드가 커지겠고요.

description이 나오게 하려면, 현재의 실시간 갱신 방법을 쓰지 않고, 새로 고친 파일이 있을 경우(editlog가 갱신되었을 경우)에 한해서 rss를 만들어 캐쉬에 저장하고, 저장된 캐쉬를 뿌려주는 식으로 하면, 로드도 줄고 description를 집어 넣을 때 생기는 오버해드도 거의 없을 것입니다. (일단 캐쉬를 쓰는 방식으로 고쳐야겠군요 =3=3=3) --WkPark

임의의 페이지로 이동하는 단축키가 하나 있으면 좋을 것 같습니다. 심심할때 랜덤페이지를 돌아다니는 경우가 많아서요. ^^; --안용열

TableOfContents 마크로를 사용할때 heading 번호에만 링크되지 않고 heading 전체를 링크로 만드는 것이 좋지 않을까요? 노스모크모인모인에서처럼요. 숫자를 누르는 것보단 문장을 클릭하는 것이 더 쉽지 않을까요? 1.1.1이후에는 [[TableOfContents(simple)]]이라는 옵션을 제공합니다.

RecentChanges에 지금 현재는 오늘자(7월 27일) 변동사항만 나오고 있는데 그나마도 0시 부근의 내용은 보이지 않네요. 전체 변동사항이나 특정일자의 변동사항을 볼 수 있는 방법은 없는지요? -- 권순선

http://no-smok.net/nsmk/ChronologicalTitleIndex 가 있긴 한데, 전체 페이지를 대상으로 하기 때문에 RecentChanges 대용으로 쓰기는 뭣합니다. phpwiki던가에서처럼 RecentChanges에 기간 범위를 정해주는 게 어떨까요? --kz

버전 1.1.1 이후에는 보다 영리하게 처리해서, 지나간 날짜의 RecentChanges도 볼 수 있도록 할 예정입니다.

지금 문득 보니 KLDP위키토론의 목차가 이상하게 생성되는군요. TODO와 논의가 같은 레벨인데(= 두개로 둘러쌈) 목차에서는 논의가 TODO보다 한단계 높은 절로 구분되네요. -- 권순선

see also http://kz.mpecc.com/moniwiki/wiki.php?MultiSearch, http://kz.mpecc.com/moniwiki/wiki.php?�ڵ���ũ === MoniWikiBlog == blog액션을 막아버리니 anonymous사용자는 코멘트까지 달 수 없네요. 어떻게 해결하는게 좋을까요?

blog액션은 플로그인이며, 코멘트액션과 코드를 공유합니다. 두 액션을 구분지으려면, 두 액션을 떼어서 따로 플러그인으로 만드는 방법이 있겠지요.
일반 페이지에 대해서도 코멘트를 다는 기능이 필요한 경우가 있으므로 고려해 봐야 겠군요.

security 플러그인 액션 부분을 수정하면 가능합니다.

  function may_blog($action,&$options) { # blog 액션일 때
	if ($options['value']) { # 만약 코멘트라면 허용
	    return 1;
	}
    if (!$options['page']) return 0;
    if ($options['id']!=='hyacinth') { # hyacinth 아이디가 아니면 action=blog 불가
      $options['err']=sprintf(_(" "),$action);
      return 0;
    }
    return 1;
  }

- hyacinth

방금 있었던 일을 말씀드리겠습니다.

오늘 제 모니위키에 "관심사"라는 제목으로 페이지를 만들었다가, 별로 좋은 이름이 아니라고 생각되서 바로 지웠습니다. 지우고 나서 블로그로 기록하려고, Calendar 매크로의 링크를 누르고 AddBlog를 하려고 했습니다. 아니, 그런데 이 어찌된 일입니까? 페이지가 지워졌다는 메시지가 나오는 페이지에서 Calendar 매크로의 링크를 클릭하니 "관심사/2003-08"이라는 이름의 페이지가 바로 생성되더군요. 위 페이지는 원래 제 위키에 없었던 페이지인데 Blog 액션으로 바로 생성되더란 말입니다. 정말 이상한 일 아닙니까?

그런데 한편으로 생각해보니 이 방식이 전 아주 마음에 듭니다. 예를 들어 MyBlog라는 이름의 페이지에서 달력 매크로의 링크(또는 다른 AddBlog 링크)를 클릭했을 때, 자동으로 "MyBlog/YYYY-MM" 형식의 블로그 페이지를 만들어주면 편할 것 같다는 생각이 듭니다.

블로그를 크게 Subject에 따른 블로그와 Chronology에 따른 블로그로 구분할 수 있다면, 대부분의 블로그들이 대개 월을 기준으로 아카이브를 생성하므로 "MyBlog/YYYY-MM" 형식의 PageName은 그 두가지를 모두 충족시킬 수 있지 않나 하는 생각이 듭니다. "/"은 URL 인코딩에 영향을 미치므로 "~"도 괜찮구요. 이렇게 해두고 MyBlog라는 페이지에는 PageList 매크로와 BlogChanges 플러그인을 써서이것들 역시 지금보다 좀더 업그레이드되면 좋겠네요 아카이브페이지로의 링크와 변경내용들을 보여주면 아주 멋질 것 같습니다. PageName 끝이 "/YYYY-MM", 정규식 버전으로는 "@/1-90-9{3}-010-9$@" 정도를 블로그 페이지로 기본 인식하게 하고, MyBlog 페이지에서 AddBlog를 하면 MyBlog/YYYY-MM 형식의 페이지가 없을 경우에는 새로 만들면서 블로그를 추가할 수 있는 편집 폼이 나오도록 하면 어떨까요? MoinMoin의 AttachFile 매크로가 아마 해당 페이지명으로 디렉토리를 만들면서 거기에 파일을 올릴 수 있도록 하는 걸로 아는데, 이와 비슷하다고 보면 됩니다. 아, 이건 MoniWiki의 UploadFile매크로 역시 비슷한 방식인 것 같군요. MoinMoin은 AttachFile 매크로를 추가하면 모든 페이지의 하단에 링크가 생겨서 좀더 직관적으로 기억이 됩니다.

장혜식님의 홈을 보면 pyblosxom과 MoinMoin이 멋지게 결합되어 있는데, MoniWiki도 블로그 기능이 좀더 강화되는 쪽으로 파워업되었으면 하는 바램입니다. --nohmad

accesskey를 더 많이 지원하면 좋겠습니다. 타이틀에 걸리는 FullSearch나 페이지가 없을 경우 페이지 만들기, 그 외에도 accesskey를 적용하면 편리할 기능이 많다고 생각합니다. --kz

See also AccesskeyStandards

카테고리 선택하는부분을 ^Category[A-Z] 에서 Category$로 바꿔서 사용하고 있습니다(한글사용을위해서). 그렇게 하다보니 자동적으로 링크가 걸리지 않더라구요, Category를 글 밑에 쓸때 [ ]도 같이 써지게 하고, 한글이 들어가있어도 카테고리메뉴에 나오게 수정이 되면 좋겠습니다(이미 저는 그렇게 바꿔서 사용하고 있습니다;;).--ErMaker

action=print시 [http://어쩌고/ 어쩌고]에 대해서 "어쩌고(http://어쩌고)"로 바꾸었으면 합니다. 그리고 모든 하이퍼링크를 끄면 좋겠습니다. 복사후 붙이기를 다른 편집기에 하면 하이퍼링크가 생겨서 영보기가 그렇네요. 도표도 이왕이면 줄있는 것으로 나왔으면 합니다. --hermian

Sunnmary of Change를 출력해 주는 Macro가 있으면 좋겠습니다. [[SummaryHistory]]정도의 매크로가 있으면 문서의 변경사항을 매번 적어줄 필요가 없지 않을까요? http://docbook.or.kr/wiki/index.php/WikiToDocBook 에서처럼 고친목록을 안 적어도 말이죠.. -- behumble

[[Info]]가 비슷한 기능을 할 수 있습니다.

http://moinmoin.wikiwikiweb.de/HelpOnMacros/Include

위에서 보는 것과 같은 include 매크로가 있으면 좋겠습니다. 제 실력으로 짤 형편은 못되고... 나름대로 쓰임새가 많을 것 같은데 말입니다. -- lordmiss

Include매크로는 이미 포함되어 있습니다.

redirect했을 때 메시지가 따로 없는 것이 아쉽습니다. --PuzzletChung

scrap 기능이 들어갔습니다. Please see ScrapPlugin

See TwinPages:MoniWikiIdeas