Contents
MoinMoin ideas
This is a holding place for user stories describing potential new MoinMoin functionality. See SeattleMoinMoinExtensions for things already implemented. See MoinMoinPatches for other places hosting MoinMoin extensions.
Specifically, these are interesting to people living in Seattle, so maybe we're close enough to get together and pair on them.
Whatever you do, especially before you invest some time, discuss the implementation on the (developer) mailing list. The WebLog things for example will be built-in when the user-forms stuff is finished.
Update to 0.11 so that I don't ponder every time why a double-click does not open the editor.
New Wiki Features/Bugs ?
What happened to the horizontial rule at the bottom of the page right before EditText ?
Please add this to the moin_config.py file page_footer1="<hr>"
- Why is there an extra horizontial rule when you use page trails ?
- Why does it say invalid user id at the top of every page I display after entering my user profile. And won't let me edit pages?
- Why does user profile ask for my email address in two places?
- why is send mail notification the default on edit page?
Questions
- is there a way to set the default user preferences? (for the various options)
- for both new users who register, and people who haven't logged in. (should they be separate options?)
No and no. Someone else (unless it was you) wanted this already, isn't too hard to add. The negative factor is that the more config vars are there, the more obscure the config gets, and it also takes more time to process. --jh
New Stuff
Things wanted and easy to implement
These are ideas from MoinMoinIdeas that are both rather easy to implement, and need no core changes (i.e. are pure extension actions or macros):
- EMail send page - extension action, show a form for the email addr, on submit send the print view as HTML mail
- Extend the ToC macro so that a ToC for one page can be embedded in another (pass name of page as a macro arg)
GraphViz Integration
I want to be able to enter...
graph G {
"wxPython Cookbook" -- RecipesControls;
"wxPython Cookbook" -- RecipesCrossPlatform;
"wxPython Cookbook" -- RecipesEvents;
"wxPython Cookbook" -- RecipesImagesAndGraphics;
"wxPython Cookbook" -- RecipesOther
"wxPython Cookbook" -- StillToBeWritten;
RecipesControls -- BuildingControls;
RecipesControls -- CreatingCollectionOfControls;
RecipesControls -- DataAwareControlsMixin;
RecipesControls -- DatabaseCursorDecorator;
DatabaseCursorDecorator -- DataAwareControlsMixin;
}...and get out a clickable graph image map.
Not as hard as it sounds, since GraphViz actually does all the graph construction, and even outputs hyperlinks in the image map.
I'd put this on the MoinMoin wiki, but it seems to be down at the moment...
-- LionKimbro 2003-09-09 13:37:22
I ran across something called MoinDot that does this, although it looks like it needs more work. I can't try it myself because like you said the wiki is down, but see http://cgi.skizz.plus.com/blog/dev/archives/000112.html -- DougHolton 2003-09-09 16:59:05
http://skizz.plus.com/mywiki/MoinDot -- another MoinDot example
Here is a GnuPlot example, I couldn't get this to work on my Wiki
http://python.kw.ac.kr/moinmoin/komoin/moin.cgi/GnuPlot
Docs
A note on documentation: changeing help and system pages happens in the master wiki. All other changes elsewhere might be lost. Also, if one of you volunteers to always keep docs in sync while I add new features, this would help a lot.
Collect missing items you notice here, or even better, fix them.
Diffs
- Use viewcvs code for diffs
- Nice side by side view
- Python only diff code (I think...need to make sure)
Sounds good, do it. Also doesn't collide with main develeopment, since it's a local change. -- jh
Timestamping
[[UserTimes]] macro - makes a list of all users on the system and their current local time
Blogging
[[RecentBlogs]] macro which collects the 10 (or whatever) most recent Blog entries from the whole site onto one page with WikiName links to the original pages. Finished! See RecentBlogs
What the heck is a Blog, a timestamp of an entry? See WebLog for a description of Blogs. -- BrianDorsey
Survey
- For collecting things like favorite meeting date.
- It could use radio buttons (one choice) or check box (multi vote).
- checks user name, user can only vote once, but can change their vote.
- this would probably require saving a file with the user and their vote
- user name and vote wouldn't appear on the web, their vote is secret,
- but the sysadmin could view the file of course,
I suppose that you could figure it out who made the change by looking at RecentChanges.
This idea was on the MoinMoinIdeas.
- Wait with this until user-forms are finished, then it's much easier to add (just needs the save-to-file code, and a stats module that shows percentages or something). --jh
Fix password entry
The current password system saves the password in the clear along with the users name and email address. While this may not be a problem at most sites, where I work it could be an offense that ends in termination.
I tried implementing crypt, but what happened is it churned the password. That is, the UserPreferences form gets the current password from the user file that is now encrypted and re-crypts it when the user saves their profile change.
I haven't yet figured out the flow of the code to determine how and when the password comes from and goes to the user file. For now I commented out the input password line of html.
I don't care if password is implemented or not. It is just wrong to have a record of a clear password on the system. It would be nice for the saved password to support any future functionality where it would be required.
This will change with 1.1, and for now the correct thing to do is to remove it from the form if it's a problem.
JürgenHermann, you are awesome. I look forward to these changes.
True literal behavior
Literal markups should be literal. In these examples the first line uses ampersand markup to enter the characters, the second line is the actual literal except the USER and TIME markups were interpreted when I saved the page.
- Backtic literal
` @USER@ `
-- JeffSandys
- Code literal
{{{ @TIME@ }}}
[[DateTime(2002-07-18T09:12:22)]]
Send new user homepage
One behavior I would like to see in the UserPreferences is to send an email to a new user with their logon link and a link to their homepage so that they will use the site.
I configured the security on my work internal site so that you need to set your UserPreferences before you can edit a page. It would be cool to generate a homepage for the new user with an email link and CategoryHomepage on it, and to set the user subscription to their own homepage.
Misc
new processing instruction: #FORMAT Preformatted - just wraps the text in <pre></pre> tags and returns
- you could of course just use "#format plain"
add config option to suppress thankyou message after making a change to a page. (one work around, make new language definition with a blank string for that message.
which won't work, because language is determined by the user's browser, not some sytsem setting ) add config option to set a custom header. Something like the existing page_footer1 and page_footer2 config options.
- "header"?! HTTP headers?
- In this case: Arbitrary HTML above the main wiki pages. For adding detailed site info/company logo/whatever.
- current CVS: config.title1 and config.title2 are inserted into the output right before and after the system title html code (title1
is right after the <body> tag and normally undefined, title2 defaults to the "<hr>" above the page contents)
- modify wiki markup parsing to only require equal signs at the begining of header markup instead of the end as well. (will this make wiki markup parsing more difficult? It's probably the way it is for a reason) Need to research.
- it is the way it is because "= h1 heading" is very unspecific and likely to be misinterpreted.
- Makes sense. Probably not worth changing.
Picture posting
new schema (upload:) or macro upload - should automatically inline the AttachFile upload form into the middle of a wiki page so you can plop it in while writing away and add the actual file after editing.
- one trick - it should support and know the difference between multiples on the same page, allowing the user to add whichever file they like
once you've added the file, it goes into the normal AttachFile location and replaces itself with attachment:filename so the file shows up in the wiki properly
much easier to do all this by making attachment: work like a WikiName without a page, i.e. if you click on a non-existing file, the upload form will appear. --jh
Yup, that's a much better idea! -- BrianDorsey
add attachment:WikiName->attachedFileName.gif syntax to allow access to another pages attachments
attachment:WikiName/attachedFileName, done
add documentation for attachment: syntax and how it works with AttachFile to main MoinMoin wiki
- Image processing options:
- when attaching images, allow the wiki to set a max size and convert them for the user (but, this would probably add dependencies)
- add macro to show thumbnails for all attached pictures on the page. this makes an instant simple photo page (again, requires some sort of image processing.)
this should be done so that several image processing systems can be used, i.e. preferably one the user has already installed.
Site navigation
LocalSiteMap - add reverse links option. Or make new ReverseLocalSiteMap?
- or maybe it should show both?
LocalSiteMap - add Included/IncludedPages option. I view included pages as virtual links: the parent page does link to them, in a roundabout way. Being able to see which pages a given page includes would certainly make it a lot easier to see the structure of some Wikis.
Plugin
A MoinMoin plugin --
This would be a Python CGI program that serves up a web page of your choice, and allows you to include a MoinMoin page anywhere in the page. The script would serve up all the page verbatim, until it got to a MoinMoin tag: <MoinMoin>SeaPig:CoolPythonTools</MoinMoin>
The script would let you configure the actual URL for SeaPig. When the CGI program ran, it would replace the MoinMoin tag with the actual HTML for CoolPythonTools, minus all the MoinMoin headers, of course. You would have a button for editing, and a button for entering MoinMoin. If you edit, you'd actually edit in place, so that the rest of the page would give you context. If you hit the enter MoinMoin button, you'd go the real MoinMoin page. You'd probably want a way to suppress the edit/enter capability; in fact, maybe they would be suppressed by default.
The idea here is that I might post some code in a nice non-MoinMoin format, but then I could edit sections from MoinMoin.
Another option for implementing this: Since security options have been added to MoinMoin, it's probably possible to have two different moin.cgi & moin_config.py files in different directories on your web server. Setup one to allow editing and one to deny it to everyone. Setup your webserver to authenticate on the directory that allows editing, and make the read only site public. Should probably work, but we need to try it out. --BrianDorsey
Make the 2nd config import the other, and then add the SecurityPolicy class. or you make two ScriptAlias'es to the same moin.cgi and only allow editing when the URL is the editing one.
WebDAV interface
This was suggested by MikeOrr. It would allow you to edit wiki pages using a text editor that supported webdav... or with any editor, by using the WebDAV filesystem for Linux, or Windows' webfolders.
I imagine a button or link (action?) on every wiki page that would launch your favorite text editor to edit the page...
Python Davserver is some WebDAV code for python. Requires 4DOM. Hasn't been maintained in a while.
mod_dav is a WebDAV module for Apache. This requires root access to install. but should be pretty straightforward to configure for use with MoinMoin.
Btw, MoinMoin already supports WikiXmlRpc, or you can get to it through this Perl library (Python bindings for the most important functions are in CVS): WikiGateway. There is also a proxy which can bridge Atom requests and a MoinMoin: AtomGateway.
People who're interested in Pairing on these ideas
If you're interested in working on any of these ideas, please add your name below and contact some of the other people to setup a time and pick one!
LionKimbro - Don't think, just CALL ME NOW- (206) 440-0247. I will drive over to your place, after stopping to pick up some chips and dinner, and we can pair program until our project is done. Thank you.
SteveHowell (I'd like to pair on some MoinMoin when I'm in town.)
See also WikiFeatures, a wiki compiling lists of wiki feature ideas.