> 1. Use of HTML() macro. I used this in only a few places. It says
> to be careful about it due to security. How bad is it?
It depends on WHO writes the HTML (== has write access to a wiki
offering the old, unsafe 3rd party HTML stuff).
If it is an attacker, he could put some evil javascript in there,
stealing your cookies or doing other bad stuff. In the worst case, he
maybe could steal your session and install moin extensions (python code)
or pull a complete backup of your wiki (in case you are superuser) or
read acl protected pages...
Note: the new html parser in 1.6 is a "safe html" parser, that doesn't
permit problematic stuff. So if you want to put some harmless html into
your wiki, use the builtin html parser of 1.6.
> 2. use of my own custom noprint processor block
> I customized moin 1.0 so that it supported non-printable blocks.
> That is, in normal web view, the block would be displayed as normal,
> but in "print" view, the block would be hidden. This was used for
> online comments in a specification that could be edited online, but
> then ultimately printed without the comments. Online, the comments
> appeared in a different color (green).
Not sure if it helps, but moin now has /* comments */ and their
visibility can be toggled. Not sure how printing behaves, but if it is
not behaving correctly, it maybe could get fixed easily.
> I modified parser/wiki.py for this, adding expressions for the
> opening and closing of a 'noprint' block:
> (?P<noprint>(\{\{\{#noprint))
> (?P<noprint_close>(#noprint\}\}\}))
> And also adding block parsing code, and functions to handle the block
> depending on the mode:
> def _noprint_repl(self, word):
> return '<FONT COLOR="green">'
>
> def _noprint_close_repl(self, word):
> return '</FONT>'
>
> Is there any feature like this already (that suppresses text depending
> on the display mode), that I could transition to?
You can either use /* comments */ or put the comments on a
supplementation page (comment subpage).
Or, write a plugin parser that does whatever you like and put it into
data/plugin/parser as e.g. noprint.py). Much cleaner now as you don't
have to hack the wiki parser directly.
> If not, would this be interesting enough to other people that I should work
> up a patch against 1.6.3 and send it in? I'm hesitant to continue using
> a custom feature, because it makes upgrades a pain.
If you can't get it working with the builtin stuff the way you want,
yes.
> 3. use of my own TableOfContents and Include macros.
> I modified moin-1.0 to suppress my custom TableOfContents expansion in
> Included
> documents, and to have my custom TableOfContents macro include the headings
> of Included documents (adjusted for nesting level). Does MoinMoin do this
> now?
I rarely use the (builtin) toc and include stuff and I avoid looking at
the code of it to not get blind. |-)
The good news is that we'll have a summer of code project soon that will
implement a new formatter that is able to do such stuff in a much
cleaner and more powerful way.
Don't hold your breath for it though, the SOC stuff will be in 1.8 or
later (not expected before end of this year, maybe even later).
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Moin-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/moin-user
