[Libreplanet-dev] Fwd: fsf groups extension patch

[Peter]

----------  Forwarded Message  ----------

Subject: fsf groups extension patch
Date: Friday 23 January 2009 15:52

(Already forwarded before confirmed registration:( Maybe this time it will 
work)

Hi John,

I see the upload file has been disabled, so I have included a tarball you may
want to add to FSF Groups. It unfortunately requires direct access to the
wiki and some updates to system messages and LocalSettings.php files.

The main extension is {{#subpages:}} which automatically looks for immediate
subpages to the current page and displays them in three columns, something
like Category does. It can also be directed to look for subpages in another
namespace, so {{#subpages: FSF Groups}} should find subpages in the Project
namespace. A quirk is the Main or Article namespace - it has no name - so use
the number 0 instead ({{#subpages: 0}}. If no subpages are found, the
function does not output anything.

This is already useful for the Manchester group who use meeting subpages, but
they are not shown in the Manchester group page. Rather than updating the
parent page each time a subpage is added, deleted, or moved, the subpages
function _should_ do that automatically. I anticipate all groups will follow
Manchester and believe that is the proper way to manage a group's pages.

By enabling parser functions, the DISPLAYTITLE can be used and has the side
effect of providing a link list of parent pages, so a user can select a
parent page from any subpage. Now a user can move from Manchester's meeting
page back to the main page by selecting the link.

When the DISPLAYTITLE and subpages are included in templates, it creates
automatic and dynamic navigation abilities for each page, without the editor
being aware of it. Furthermore, the DISPLAYTITLE allows editors to give an
appropriate page name without changing its actual name. Since the page name
can be anything, we can define page structures and schema without hampering
the editors or confusing visitors.

To help restructure the website, the patch includes two special pages:
MultiMove and MultiDelete. The multiple page move will move a root page and
all its subpages within its namespace - and also all other matching pages in
their namespace. This ensures that template navigation links will still work
and avoids the tedious job of moving all subpages individually. This is a
restructuring tool, so it should not create redirect links, but it does.

The MultiDelete will delete a root page and all matching subpages within a
namespace - and optionally in all namespaces, too. This can be used to delete
redirect link pages created by MultiMove (or anything else), or normal pages.
A multimove page should be followed with a multidelete to clean out the
redirects.

Clearly, the MultiPage functions are powerful administrative tools, so they
should not be available to everyone. I know Mediawiki can limit special
pages, but haven't figured it out yet.

I would like to add a new namespace called Group or Website, which will be
used to create the static part of a group's website (name, location,
description, mission statement, etc.). The Main namespace can then be used
for dynamic content (meetings, activities, tutorials, guides, etc.). Finally,
the FSF Groups (Project) namespace can be used by groups to define their
policies, campains, or any research. Using templates (i.e. menubars), we can
link up the Project to Website to Main namespaces, thus providing a complete
navigation system. Furthermore, we can provide a help structure so members
and visitors can learn what a page is for and how to edit it.

The templates themselves are structured generically, so editors can check
their namespace and subpage to know which template to use. All they need do
is add content and let the template do the links and formatting. We can then
provide a 'look and feel' to the templates, either via css, or Mediawiki's
existing mechanism.

Finally, two important categories are Groups and Regions; the Groups category
will link to all the group websites directly, while the Region category will
navigate down to local areas listing group websites in that area. This allows
visitors to find groups either by name, or area. We may even add the Groups
and Regions category to the sidebar.

Since the Regions are in the Category namespace, we can simply link to that
page and avoid tedious linking issues.

I also have ideas for using threads, such as FAQ, news, etc., which have
 their own structure distinct from all other pages. This allows editors to
 update a page without affecting any threads. Furthermore, threads can be
 completely removed (via multidelete) without affecting other pages. Each
 thread is rooted in Category, so they can be accessed independently of (but
 linked to) related pages.

While we could achieve all this without modifying the wiki, it would create
 an admin hell.

Hmm, perhaps this should be forwarded to the dev mailing list?

Peter

-------------------------------------------------------

fsfgroupsext-1.0.0.tar.bz2
Description: application/tbz