This is a big pile of unsorted old stuff, moved from FeatureRequests page

/!\ It is unlikely that anything of the stuff below gets done as long as there is noone caring to move it to separate FeatureRequests. Also, outdated stuff should get removed.

Old Feature Requests

Please do not add content on this page, these requests should be sorted to new pages.

Contents

  1. Old Feature Requests
    1. Spell Checking
    2. File and Directory Permissions
      1. Customization of File System Permisssions
    3. Revision History
      1. Latest version link should include version number as a GET parameter
      2. Differences between consecutive versions in RSS feed
    4. Automatic User Pages
    5. ACL controlled templates
    6. Metadata Support
    7. Twiki-like icon libraries
    8. ActionBar as IconBar
    9. Self-Documenting Extensions
    10. Include Macro header handling
    11. Watch list and rss
    12. i18n
      1. Pages with same name in different languages
      2. Templates
    13. Attach Comments to Pages
    14. Add Published Mode
    15. allow plugins to generate extra files
      1. MoinMoin's name
    16. import css files / css-market
    17. cache per page rule
    18. MoinHistory page
    19. MediaWiki like image fuctionality / image macro

Spell Checking

Check all words/combinations for possible misspeling of existing WikiName's/pages.

For example: PostgreSql => PostgreSQL or 'twisted matrix' => TwistedMatrix -- Mike Rovner

File and Directory Permissions

Customization of File System Permisssions

Example Szenario: UNIX-System. You want to have setgid bit set for directories to share access within a group that performs administrative tasks (backup, restore, cleanup etc.) on file system level.

See JohannesZiegler/SomeUnixSampleInstallationScenario for motivation and detailled description.

To adjust the permission settings to these needs you would have to patch many of the source files since most of relevant values are hardcoded.

Now, it looks like this: 

config.umask = 0775
os.mkdir(dirpath, 0777 & config.umask)
os.chmod(dirpath, 0777 & config.umask)

It could look like this (dropping umask): 

config.filemode = 00666 # octal: setuid, owner, group, other
config.dirmode  = 02777 # octal: setgid, owner, group, other
os.mkdir(dirpath, config.dirmode)
os.chmod(dirpath, config.dirmode)

or like this (keeping umask): 

config.umask    = 02777 # octal: setuid/setgid, owner, group, other
config.filemode = 00666 # octal: setuid, owner, group, other
config.dirmode  = 02777 # octal: setgid, owner, group, other
os.mkdir(dirpath, config.dirmode & config.umask)
os.chmod(dirpath, config.dirmode & config.umask)

Contact me for a detailed description of the patches (i.e. which files). If you want me to contribute (coding) just ask. -- JohannesZiegler 2003-12-22 11:49:48

Revision History

This allows one to copy a link for the current version easily if one wants to link to it as definitive.

Differences between consecutive versions in RSS feed

Currently, the differences in the RSS feed are calculated against the current version of the page. This is fine when unique=1 and the RSS document is only showing a single instance of the page, but is less than obvious when unique=0.

With unique=0 and diffs=1, the RSS feed should show the difference between the version in question and the version prior to it. This makes it possible to more easily see the differences in each version.

I guess this could be optional if someone wants the comparison to be between the version in question and the current one.

-- TomiJunnila 2005-01-14 13:33:55

Here is a quick hack that implements this behaviour. I'm not very familiar with Python and MoinMoin, so the patch is most likely far from optimal. 

--- rss_rc.py.orig-from-131       2005-01-17 08:56:05.805153102 +0200
+++ rss_rc.py   2005-01-17 09:42:48.002326950 +0200
@@ -138,10 +138,6 @@

         # general attributes
         handler.simpleNode('title', item.pagename)
-        if ddiffs:
-            handler.simpleNode('link', link+"?action=diff")
-        else:
-            handler.simpleNode('link', link)

         handler.simpleNode(('dc', 'date'), util.W3CDate(item.time))

@@ -152,18 +148,26 @@
             # searching for the matching pages doesn't really belong here
             revisions = page.getRevList()

-            rl = len(revisions)
-            for idx in range(rl):
-                rev = revisions[idx]
-                if rev <= item.rev:
-                    if idx+1 < rl:
-                        lines = wikiutil.pagediff(request, item.pagename, revisions[idx+1], item.pagename, 0, ignorews=1)
-                        if len(lines) > 20: lines = lines[:20] + ['...\n']
-                        desc_text = '%s\n<pre>\n%s\n</pre>\n' % (desc_text, '\n'.join(lines))
+            rev1 = 0
+            log = editlog.EditLog(request, rootpagename=item.pagename)
+            for line in log.reverse():
+                if item.time >= util.datetime.tmtuple(wikiutil.version2timestamp(line.ed_time_usecs)) and int(line.rev) != 99999999:
+                    rev1 = int(line.rev)
                     break
+            else:
+                rev1 = 1
+            lines = wikiutil.pagediff(request, item.pagename, rev1-1, item.pagename, rev1, ignorews=1)
+            if len(lines) > 50: lines = lines[:50] + ['...\n']
+           desc_text = '%s\n<pre>\n%s\n</pre>\n' % (desc_text, '\n'.join(lines))
+           link="%s?action=diff&rev2=%s&rev1=%s" % (link,rev1,rev1-1)
         if desc_text:
             handler.simpleNode('description', desc_text)

+        if ddiffs and not diffs:
+            handler.simpleNode('link', link+"?action=diff")
+        else:
+            handler.simpleNode('link', link)
+
         # contributor
         edattr = {}
         if cfg.show_hosts:

It doesn't work properly for the first revision of a page (where it compares revision 1 to revision 0), and it effectively forces ddiffs=1 when diffs=1 (the link includes action=diff and the revision numbers when diffs=1). There is also no checking for unique=0.

-- TomiJunnila 2005-01-17 08:41:32

Automatic User Pages

As a site option, it would be convenient to be able to automatically create a user WikiName page when creating an account via UserPreferences. It would be even more convenient if I could customize the information requested in UserPreferences and have it automatically filled in on the user's WikiName page. I recognize that this is not appropriate for every Wiki (ThomasWaldmann specifically mentioned in IRC not wanting empty useless pages) but I have a private (intranet-style) usage for which it is very appropriate and would keep users from having to take extra steps. I got used to this feature in TWiki, and while MoinMoin seems easier to use and I like the fact that it's written in Python, this is one feature I rather miss. (Well, two related features, really.)

-- Michael K Johnson 2/17/2004

I agree. We should give new users a hand and create a home page for them. This will help to build a community around a wiki. The home page can include an uploaded picture in a standard location and size, standard home page text and links (can be modified later) and category links. We can also put some links to the help pages for beginners, so a user home page will be a starting point to new users.

We should have more page building helpers for other types of pages. Using template is good for programmers, but regular people like to answer some questions and have the wiki do the work for them.

-- NirSoffer 2004-02-17 22:38:23

If forms worked, and we had a build page function that is accessable via a form post, then we could create the page creation helpers using the wiki! Something then that might be usefull would be just to have a redirect when a new user logins in.. the redirect could be specified in the config, and send them to the front page by default, but could be specified to send users to a welcome page, or a create your homepage wiki form.

-- JonathanDietrich 2004-03-23 16:31:29

At the moment all themes only add the 'home' icon if the user home page exists. My suggestion is to add this icon if the user is registered, whether the home page exists or not. This makes for an easy way to have new users discover the possiblity of having a home page, without having to provide one for those who don't care.

Like this: 

--- classic.py  Wed Jul 21 22:02:16 2004
+++ classic.py.new      Sun Aug 15 21:57:33 2004
@@ -256,31 +256,30 @@
     def iconbar(self, d):
         """
         Assemble the iconbar

         @param d: parameter dictionary
         @rtype: string
         @return: iconbar html
         """
         iconbar = []
+        if d['user_valid'] and not d['q_page_home_page']:
+            d['q_page_home_page'] = d['user_name']
         if config.page_iconbar and self.request.user.show_toolbar and d['page_name']:
             iconbar.append('<ul id="iconbar">\n')
             icons = config.page_iconbar[:]
             for icon in icons:
                 if icon == "up":
                     if d['page_parent_page']:
                         iconbar.append('<li>%s</li>\n' % self.make_iconlink(icon, d))
                 elif icon == "subscribe":
                     iconbar.append('<li>%s</li>\n' % self.make_iconlink(
                         ["subscribe", "unsubscribe"][self.request.user.isSubscribedTo([d['page_name']])], d))
-                elif icon == "home":
-                    if d['page_home_page']:
-                        iconbar.append('<li>%s</li>\n' % self.make_iconlink(icon, d))
                 else:
                     iconbar.append('<li>%s</li>\n' % self.make_iconlink(icon, d))
             iconbar.append('</ul>\n')
         return ''.join(iconbar)

As an additional feature: At the moment, if you follow a link to a page that doesn't exist, you get the usual possibility to creating that page, with a list of templates to choose from. You could have the page create action test if the page to be created is identical to the user's home page name. If it is, don't offer the list of templates to choose from, but just use CategoryHomepage if the user starts editing the page.

-- PeterKleiweg 2004-08-11 11:24:18

ACL controlled templates

Templates are nice if you only have users from the same domain, and therefore most of the templates are meaningful to them. When you have users from different application domains (e.g. in an intranet) you don't want to present them all the available templates. It just gets too messy. If ACLs would be honored when presenting the available templates, a user group (e.g. the legal department) could create their own templates and make them readable for the LegalGroup only. Even completely private templates would be possible! A drawback could be, if you forget to change the ACL back to some less restrictive permissions when saving the page. Or is it even a feature? Wouldn't it be a sensitive default to make group/private templates readable by you/the group by default?

Metadata Support

I was unsure of whether I should place this request under MarkupProposals, FeatureEnhancementProposals or InternalEnhancementProposals.

The use of WikiCategory is pretty primitive and unreliable. How about some kind of MetaData declaration at the beginning of the page, much like ProcessingInstructions? For example: 

@Category Java Programming
@Type Howto
@Keywords Java; Frameworks; Jakarta Struts; Hibernate

Which should render as:

A click a link should show a list of pages with the same metadata value.

Notice the @ character is used, so arbitrary metadata types can be defined by the users without colliding with #xxxxxx ProcessingInstructions. -GoofRider 2004.05.26

Twiki-like icon libraries

In Twiki it is possible to create wiki-pages that act as an icon library. First you have to upload graphics to the page, then you can associate that graphic to a system-wide accessible shortcut:

The following line taken from TWikiDocGraphics: 

|  <img src="%ATTACHURLPATH%/help.gif" alt="help.gif"  width="16" height="16"  />  | =help.gif= | Help |

results in the shortcut %help.gif% which you can use on any page.

In moin it would be something like: 

|| attachment:help.gif width="16" height="16" border="1" || =help.gif= || Help ||

looking like:

[ATTACH] width="16" height="16" border="1"

=help.gif=

Help

At the moment we have to put user-defined smileys in moin_cfg.py as a dict with the markup as the key and a tuple of width, height, border, image name as the value. This is cumbersome for users.

Q:BTW what is border, yes/no or 1/2 for size? What is markup, the theme?

-- SashaPoslavsky 2004-06-08 10:01:42

ActionBar as IconBar

I made a small Picture as a study for an ActionBar with the footer-Actions like the other Actions at the Top of the Page:
Here i realized only Icons for 3 Actions:

* AttachFile
* DeletePage
* LocalSiteMap


Q: Is it easy, to realize this? In my company, the users dislike to scroll to the bottom of the Page, but they like the small Action-Icons from the classic or the "leftsidebar(1)"-theme...


BTW: As you can see, i produced also a small icon as a replacement for the standard-moin-edit.png: It seems to me, that "to say" something is not so comprehensible than "to write" something...

[ATTACH]

Self-Documenting Extensions

HelpOnMacros and HelpOnActions are great, but what about adding some global docstrings to each macro, action, etc an some display macro to make them self documenting? Just a __manual__ and a __example__ string in each macro and HelpOnMacros could be created auomagically by the wiki, just listing the enabled/installed stuff. -- OliverGraf 2004-06-20 07:57:19

I've been scouring the net trying to find an easier way to do line breaks than the [[BR]] because it's a big stumbling block. Line breaks are not a rare case, but a common occurance. I want to find a way to turn on auto line breaks and keep the embedded macro out of the document. -- Georgeh

It is intended that there is no really convenient way for line breaks, because most use of line breaks is simply wrong. -- FlorianFesti 2004-07-27 21:30:45

I very much disagree. How can it be wrong to use line breaks to format text in the desired fashion? There's a reason why the "return" key is so large & accessible on a keyboard - it's because we use it all the time when we're typing! To make text more legible, and aid comprehension. --- ScorchPyro

Include Macro header handling

Currently Include Macro just puts text inline as is, optionally prepending it with a header.

That seems counterintuitive that included text doesn't take the context from the place Include was called. It shall amend included text (ex. increase heading level) according to caller environment. Include macro parameters (heading level) override this context if specified.

Watch list and rss

I would like the option to add pages to your personal watch list. Pages should have a button "watch this", that let's you put pages on your watch list, and for those already on your watch list, a button "unwatch this" to remove it from your list.

Then there should be a variant of "recent changes" that lists only changes to pages on your watch list. (Like in WikiPedia.)

Secondly, there should be an rss-feed with a username as option that returns only changes in pages on the user's watch list.

The reason for requesting this: people who have limited time and can involve themselves with only a small part of a wiki need a quick overview of changes relevant to them. And if changes to those pages are infrequent, rss is the least time consuming to keep up to date.

-- PeterKleiweg 2004-08-09 16:01:11

i18n

Pages with same name in different languages

Suppose:

I would like MoinMoin to:

I have been busy translating system pages into Dutch, and found that some pages cannot be given a natural Dutch name, because that would be the same as some name in another language. And proper names are usually identical in many languages. -- PeterKleiweg 2004-08-15 16:11:49

I 2nd that! This is exactly the feature I need for my site... Radek Podgorny

Templates

Currently, what is recognised as a template is coded in, in page_template_regex, which can only be overriden in the config file. In any case, there is one pattern for a wiki server. I would like the pattern to be processed by the i18n mechanism. For instance, in nl.po I would want to put this: 

msgid "[a-z]Template$"
msgstr "[a-z]Sjabloon$"

-- PeterKleiweg 2004-08-17 01:30:16

You can simply (and more flexibly) set page_template_regex in your config. Often one wants also to include the original english pages (and not only pages matching the translated regex), so using somewhat like ".*(Template|Vorlage)" in the config is the best way. -- ThomasWaldmann 2004-08-17 06:22:18

Attach Comments to Pages

Wiki editing is potentially frightening to non-technical users - the syntax is confusing, and they might worry about messing up the wiki page. A simple form-based comment system would allow such users to simply tack on comments to the end of a page - a model they will likely be familiar with already.

Any content worthy for inclusion could then be incorporated by someone more experienced at a later time.

Note that this is not a limiting measure - any user could decide whether to edit content directly, or just append a comment.

Rather a narrow view, in my opinion.

Add Published Mode

A very cool feature (that I have seen so far only on instiki) is to have a "published" mode where pages are rendered without any Wiki-functions (i.e., no edit/login/etc.). These pages look just like ordinary webpages.

This is great for homepages: The reader is not confused by any buttons on the page, while it is still very easy to edit. The user interface is in the links: If you call "htp://mywiki/show/mypage" mypage is shown as a wiki page (i.e., with buttons and stuff) if you call "htp://mywiki/published/mypage" you get the same page, but without any distractions.

You can create an view only theme and make it default. Additionally you should secure your wiki with ACLs. There had been a viewonly theme in MoinMoin but it was unmaintained and had been removed.

allow plugins to generate extra files

Currently, plugins like my latex2 plugin can create extra files and serve them via the AttachFile action. That, however, is fairly inefficient. It'd be nice if this could be done in a way that

  1. allows apache to serve those files directly
    • this can be unsecure (when webserver does execute such stuff)
      • not really, the plugin just has to make sure it doesn't let the user specify the file extension (or whatever apache uses to decide how to call it). I don't want attachments served by apache, but rather stuff that's generated from a plugin.
  2. has a namespace for each plugin so that the plugin can wipe all files it created
  3. does not need attachments enabled
  4. optionally (let the plugin decide!) be integrated with caching (ie. moin could decide to throw away those files and call the plugin to regenerate)
    • be aware that you can recall old revisions of any page. Throwing away cached data might break those old revisions.

-- JohannesBerg 2004-12-29 23:59:35

Not as good idea as it sounds. It will become very fragile if sometimes we'll implement database backend at last. -- MichaelDubner 2006-12-22 22:31:19

MoinMoin's name

The name of MoinMoin is different in "/usr/share/moin" and python's MoinMoin. I think we should unique the name of MoinMoin or moin.

import css files / css-market

It would be fine to have the possibility to add css files probably as macro or something else. I would like to have this probability to show ImageLink or Hits with its own style. -- ReimarBauer 2004-12-30 08:29:02

cache per page rule

At the moment cache could be used for file types. But sometimes it could be useful to switch cache off for all on one page. e.g. the Hits macro result is cached too. You have always to refresh the page yourself to see the new count. -- ReimarBauer 2004-12-30 08:29:02

MoinHistory page

Does it already give a MoinHistory page somewhere?

MediaWiki like image fuctionality / image macro

For example with MediaWiki it is possible to have an image on the right side of a page and to have text next to it or to have a text describing the picture below it and a box around the picture and the text. See: http://en.wikipedia.org/wiki/Wikipedia:Picture_tutorial

CategoryFeatureRequest

MoinMoin: FeatureRequests/UnsortedStuff (last edited 2013-06-26 14:45:48 by 134)