extract_idea1Add my vote for this tag create new tag
, view all tags


Creature Feep at it's finest, on the road to TWikiOO!

After receiving feedback about my local implementation of TWiki at Sun, and reading up on the various "need for corporate appeal" topics here, I decided to write a plugin implementation that would help out in that arena. I ended up some wizzy admin tools, and a somewhat decent skin. Thought I'd toss it back in the code pool to see what folks think (see attached).

I had to make a few changes to the core code (TWiki CVS, 6/19/02) to support some of these features (tweeks included in tarball, see attached)

Feature Description
Hierarchical Webs Webs inside Webs inside Webs (i know, too much structure, but corporate weenies love this stuff)... cool side-effect is that sub-web preferences are inherited from the parent web. Links to hierarchical webs look like this: Asic_Products.Fire.Chip_Integration.WebHome, or this: Asic_Products/Fire/Chip_Integration.WebHome.
Hierarchical Search Enable or disable hierarchical searches (subwebs). This is useful for bubbling information up to the top of a hierarchical web from subwebs.
Skin Themes One skin, many themes. useful for consistent look&feel, but with unique web identification
New Web creates a new web inside an existing web or at the top of the web tree
RenameWeb moves a web and renames all references to topics in that web in all other webs. You can move a web named Foo.Bar.Baz to a web named Foo.Baz.Bar, as long as Foo.Baz already exists
New Topic create a new topic (and add it to the sidebar, if using the 'mega' skin)
Rename Topic renames topic, but handles renaming of references in hierarchical webs
Delete Web Aigh! It's o.k., only the TWikiAdminGroup can do this wink
Delete Topic Again, only TWikiAdminGroup can do this
Edit Preferences Preference editing of both TWikiPreferences and WebPreferences in a gui! some folks have been asking for this... allows pick lists, text areas, ordered lists, and text entries. Has tendency to make WebPreferences a little unreadable, but that can be fixed later.
Edit Permissions Kinda clunky, but all permissions are editable (even topic permissions!). Topic permissions are hidden in the page, but an indicator on the mega skin flags what the user can/cannot do .
List of Links management Some websites, I've noticed, like to manage lists of links and their descriptions in little boxes. This function lets you edit lists of links in place, and display each list in a titled box
LDAP-based group management Register everyone who reports to my manager, TooMuchCoffeeMan. Basically a cron-job that runs periodically to create TWikiGroups based on reporting structure. Assumes LDAP field "employeenumber" is the TWiki login name. Still needs a little work to become production-worthy code, but can be easily improved.
Email alias based group management Create groups based on email aliases. this works via mconnect to the mail server where the alias is managed, and registers those users who are not already registered in the process.
Sidebar management One-Click Add/Remove topics from the sidebar
Themable Skin A nice themable skin which incorporates access to all the above features, including a nice sidebar that resembles an expandable folder tree. Topics can be added or removed from each folder's display area in the tree.

The release I've attached below is a little polluted, but should work after the usual install methods. Perl modules you may need: Net::LDAP, URI::URL, HTTP::Request.

The Code:

Some Screenshots:

  • megatwiki_admin.jpg: Screenshot of the admin screen.
  • megatwiki_frontpage.jpg: Screenshot of Main with the mega skin.
  • megatwiki_toolbox.jpg: Better screenshot of the admin toolbox. Some admin functions don't show up if the user doesn't have permission to use them. Web and topic Access restriction information shows up at the top of the toolbox.

-- PeterNixon - 24 Jun 2002

This looks very cool. All the added features look cool, but the one that interests me is the LDAP user management. Can it look at an existing LDAP database to manage users? We manage our Linux logins using LDAP, and it would be very cool for new users to automagically become new TWiki users at the same time.

How much core code do you actually change? Do you plan to keep it up with upcoming TWiki releases? Do you plan to make parts that can be plugins, plugins?

I'd like to give this a try, but not if it means I have to rely on you keeping it up to date (or me learning to code-manage all the things you added) to allow for new TWiki releases and third-party plugins.

-- MikeMaurer - 25 June '02

The LDAP user management is designed to use an existing LDAP database, and is very much a separate item (it's a script that runs independantly). I still need to make it a bit more configurable, so you can select which field to base the user's login id on (uid=* vs employeenumber=* in the search filter), and which field to use to look up the user's manager. It just requires the current LDAP plugin, and some special HTML comments to be in your TWikiGroups and TWikiUsers topics to delimit automatically editable areas.

I am currently working on another plugin which detects new users and builds topics for them from an LDAP database when they log in.

I'll have to package it up a little better and write up an installation guide.

Main.MikeMaurer: How much core code do you actually change?

As far as core code goes, I had to change TWiki.pm, Search.pm, and Prefs.pm, and RcsWrap.pm. Some of these changes (Prefs.pm and RcsWrap.pm) can be merged into the official TWiki codebase without breaking other folks, but I suspect there will be some amount of pushback on the support of hierarchical webs; it's a bit of a philosophical hot-button. We'll have to bring it up in HierarchicallyNestedTwikiWebs and HierarchicalNavigation.

Here are the basic changes:


  • Added support for hierarchical webs, and added support for more lenient wiki words. This meant I had to change the rendering rules for wiki links a little.
  • Added support for mapping old web paths to new webs. This just makes sure old bookmarks work after a massive reorganization of web directory structure.


  • Added support for hierarchical web searches, which meant just adding all the directories under each of the selected root webs. This can be turned off in a search by setting subweb to "off" (%SEARCH{"some text" subweb="off"}%


  • Re-wrote the preferences data structure into a hash for performance improvements. Looks like what was there was meant to implement a hash by using arrays. seems to have made things a little better.
  • Added routines for fetching and setting the hash of preference values.
  • Fixed getPreferencesValue routine for getting preferences from a different web.
  • Added preferences inheritance, so preferences are inherited from parent webs, all the way up to the preferences set in TWikiPreferences.


  • minor fix; RCS likes user names to start with a letter, but our TWiki login names are all numeric (badge number). The RCS commands in TWiki.cfg add a "T" in front of the user name, and RcsWrap.pm removes it when looking up the user name. At the moment, I don't like the way this is implemented, and will fix in a future release; the RcsWrap.pm implementation should detect names that RCS doesn't like and 'fix' them on the fly.

Main.MikeMaurer: Do you plan to keep it up with upcoming TWiki releases?

Yes, unless some of the changes can be integrated back in. Most of the features seem to be desirable to most folks on Codev.

Main.MikeMaurer: Do you plan to make parts that can be plugins, plugins?

That's the plan, but I'd like to minimize the number of scripts (there's a lot of functionality that used to be individual scripts). I'd like to wait to do most of this work until we see an initial version of TWikiOO to build on.

-- PeterNixon - 25 Jun 2002

Well, it certainly looks like you have done a lot of work! Well done!

Now, to maximise utility and to mitigate a risk of your version and the official version deviating we need a plan for merging your changes in.

First off, from what you have said, most of your changes to PrefsDotPm should go straight in as they are coding optimisations.

I'm personally very much in favour of HierarchicallyNestedTwikiWebs so I wouldn't object to such changes either - I'll write more in that topic.

The change to RcsWrapDotPm, as you point out, sounds like a hack. I imagine there is a better way of achieving your goal so I would object to that going into TWikiAlphaRelease.

CoreTeam - what would it take for you to accept Peter's work into the codebase?

-- MartinCleaver - 27 Jun 2002

I have uploaded a slightly slimmer version after cleaning up the pub/TWiki/MegaTWikiThemes area, and fixing a few bugs:

  • There was a problem with the rename function (both topic and folder/web), where only the root webs were displayed in the select list. I've updated the handleWebAndTopicList method in the TWiki.pm package to return all public hierarchical webs.
  • The admin screen was displayed incorrectly. Updated the megatwiki.tmpl and twiki.mega.tmpl templates to fix the rendering of the sidebar.
  • There was a bug when submitting a rename, where the admin screen would pop up, instead

of a rename occurring. Updated the mega_renamebase with the correct "request" field value.

  • A nicer fix for RcsWrapDotPm which prepends "TW__" to the beginning of user names which consist entirely of numbers to make a name which rcs likes a little better. The getRevisionInfo subroutine then removes the "TW__" if it detects a user name like "TW__12345".

-- PeterNixon - 27 Jun 2002

Very intersting enhancements! Over time we will take some parts that fit into the core code. Thanks for sharing this.

I had not yet time to look into details. A quick note on "rewriting the preferences data structure into a hash for performance improvements". I implemented this using arrays because AFAIK it is not possible to control the sequence if key words in a hash. Some variables need a certain sequencing, for example, WIKIWEBMASTER needs to be defined before a variable that uses WIKIWEBMASTER.

-- PeterThoeny - 28 Jun 2002

I have not noticed any strange side effects of order-based dependencies yet (that's not to say there aren't any), but the dependencies could be resolved by the handlePreferencesTags subroutine by introducing a while loop, e.g.:

   my $text=$_[0];
   my $prev_text="";
   while ($prev_text ne "$text") {
        foreach my $pref (keys %prefsHash) {
           $term = "\%$pref\%";
            if($text =~ /$term/) {
                  $text =~ s/$term/$prefsHash{$pref}/g;
   return $text;

The code could (and should) be further enhanced by introducing circular reference detection; There is probably existing code lounging around somewhere that we could borrow.

As each variable is substituted, if it contains references to other variables, they will be resolved until the text stops changing. In the case of circular references, we'd want to stop the substitution of a variable by "breaking it" if it is detected as a part of a circular reference chain, and flag the error with a message in the text.

Another way to deal with circular references would be to detect them right after all the preferences are read in, and mark the last variable in the chain as being suspect. That way we only have do the detective work once.

There woudn't be a depth limitation, and all possible variable substitutions would be made on the text in $text with a single call to handlePrefrencesTags. This is fairly standard code for variable substitution.

I'll try it out, including the circular reference detection, see how the performance differs, and post the changes.

Along those lines, it'd probably also be a good idea to add an audit to the preference editor to flag errors before they are saved in WebPreferences.

-- PeterNixon - 28 Jun 2002

I have installed MegaTWiki on my Windows based test machine. After adjusting the file locations, etc., I encounter the following errors when viewing some topics:

  • Can't locate object method "_init" via package "TWiki::Store::RcsWrap" (perhaps you forgot to load "TWiki::Store::RcsWrap"?) at ../lib/TWiki/Store/RcsWrap.pm line 58.
    • e.g., when viewing Know.WebSearch
  • Undefined subroutine &TWiki::Plugins::HeadlinesPlugin::getUrl called at ../lib/TWiki/Plugins/HeadlinesPlugin.pm line 115.
    • e.g., when viewing Main.NewsDesk
  • [Sun Jun 30 11:12:26 2002] [error] [client] Premature end of script haders: /c/cygwin/usr/local/lib/twiki/bin/mega in apache log
    • e.g., when setting group membership

-- ThomasWeigert - 30 Jun 2002

Sorry, I'm now going to play devils advocate!

I asked:

_ CoreTeam - what would it take for you to accept Peter's work into the codebase?_

You (Peter T) said:

Over time we will take some parts that fit into the core code. ... I had not yet time to look into details.

Am I right in thinking, therefore, that your acceptance criteria is time to review the code? Do you have any concerns about the features themselves, especially the Hierarchical stuff?

I appreciate your wanting to ensure TWiki remains stable (we all want this). I'll install MegaTWiki myself soon. Its also interesting in terms of its 'mega' script; I suspect a that a more generic solution of this may solve the problem I was referring to in PluginBinNameClashes. PeterNixon - what do you think?

-- MartinCleaver - 01 Jul 2002

I would think individual changes would need to be progress like other TWiki changes, with a topic for the proposed change and a chance to discuss ramifications and compatibility with the TWikiMission. Whilst many peole have asked for hierarchical capability (I was one of them, but find I get along fine without it) there have been concerns about the added complexity. If Peter has managed to do a fairly simple implementation that has no outstanding issues I would support inclusion in the core, simply because this is a facility so many people ask for. However, at least one issue is the need for a more general Web selection mechanism and a way of tying this into skins and dialogues that include Web selection.

-- JohnTalintyre - 01 Jul 2002

Hi CoreTeam - just for clarity (I'm not trying to be bossy!) could you please fill in your own position on each of the following.

Thanks big grin ( Table removed, see comments below)

-- MartinCleaver - 05 Jul 2002

I have removed my name from the table above as it appeared to refer to the whole to MegaTWiki. As I said above, I think we need to deal with each area in its own topic.

-- JohnTalintyre - 03 Jul 2002

Please accept my apologies for misquoting you. Accordingly, I've moved the table to HierarchicallyNestedTwikiWebs for the CoreTeam to comment.

-- MartinCleaver - 05 Jul 2002

Well, I'm back from Maine. I agree, most of the discussion about the individual features of my hairball of code should take place in separate topics, soon to be accompanied by the specific pieces of code which implement those features. Here are a few topics to start:

ThomasWeigert found some issues with the code. Try removing HeadlinesPlugin.pm and replacing it with the original; it's hacked to support using a proxy behind a firewall, and requires the following packages:

  • LWP::Debug
  • LWP::UserAgent
  • URI::URL
  • HTTP::Request

I've attached a new RcsWrap.pm. I inadvertently introduced a bug on line 164:

$userName = "TW__$user";

should be

$user = "TW__$user";

-- PeterNixon - 05 Jul 2002

JohnTalintyre has started a discussion in RcsHandleAllNosUsers about the mods needed for RcsWrap.pm to handle user names containing characters which RCS doesn't like.

-- PeterNixon - 10 Jul 2002

I have installed the new RcsWrap.pm file as well as the original HeadlinePlugin and the errors reported earlier disappeared. I suggest to update the tar archive. Thanks.

-- ThomasWeigert - 19 Jul 2002

Sorry, I've been trekking recently and so have not kept abreast of this or a bunch of the related topics. How close are we to agreeing what should and what should not go into the next official release from the code in MegaTWiki?

-- MartinCleaver - 04 Aug 2002

I don't know about what features are decided, but I do want to report a successful install on Windows 2k with Apache 1.3.23 and AS Perl. I too had to install the newer rcswrap to get full (as far as I know) functionality.

One perception about MT is that it's naviagtion aids on the screen seem less then that of TWiki. I think I might choose to do some of the layout differently too, but otherwise it looks quite nice. Definately a move towards a wiki-maintained wiki!

-- DavidLeBlanc - 04 Aug 2002

Here is something I noticed: If you take a table where TABLE WIDTH="100%" (e.g., TWikiWebsTable, but any other table will do, e.g., those generated from a search), this table will stick out over the right edge of the normal page (by the amount of screen real estate taken up by the navigation bar on the left side). On the other hand, if there is a fixed size box, such as edit frame or the raw frame, the normal page actually stretches to accomodate the size of the box. What is more, in the edit view the page stretches even wider than the edit box to the left. (What I mean by "the page stretches" is that the colored bars below the heading and that containing the footer are made wider, and that any icons that are right aligned are moved further to the right.)

Note that the same does not happen with GnuSkin...

-- ThomasWeigert - 06 Aug 2002

I really like the MegaTWiki setup, but I have noticed that it is really slow. Executing 'view' from the command line on an E250 takes 5 seconds at least, whereas the normal TWiki does it in less than a second. Peter, what do you run this on? Do you take any special actions to make it go faster?

-- WoutMertens - 09 Aug 2002

Do you oberve this in general, or just with Main. There you have all the newsfeeds being accessed, which takes time...

-- ThomasWeigert - 09 Aug 2002

I notice it in general, but I don't know how to pass the path to the command line invocation, so I could only test it with Main.WebHome :).

-- WoutMertens - 09 Aug 2002

Why don't you try with the attached variant of WebHome?

-- ThomasWeigert - 13 Aug 2002

Ok, I actually did some timings, but my browser died on me and I gave up (we need CheckPointSave!) So this is the timing for a normal WebHome:

System TWiki MegaTWiki MegaTWiki, skin=normal
Sun E250, 1x300MHz sparcv9, 512MB, Perl5.6 1.6s 3.7s 2.6s

Feel free to add your timings to this. I timed it using echo|time ./view and echo skin=normal|time ./view. I ran each test several times and took the time when it stabilized.

Both my TWiki installation and my MegaTWiki installation have about the same plugins (except for the MegaTWikiPlugin of course...)

I guess I should do timings for pluginless TWiki as well... Will do later. In the mean time, I'm curious about your results smile

-- WoutMertens - 14 Aug 2002

Here are my timings for the vanilla installation and MegaTWiki using the WebHome topic from the vanilla installation, using the same procedure (echo reports system, user, and elapsed times; below is the elapsed time):

System TWiki MegaTWiki MegaTWiki, skin=normal
Dell Latitude C800, 1x1000MHz PIII, 256MB, Perl5.6 1.07s 1.25s 1.25s
Sun E450, 1x296MHz sparc, 256MB, Perl5.6 1.50s 2.05s 2.10s

The command used was echo|time ./view > /dev/null.

-- ThomasWeigert - 15 Aug 2002

Ok, these timings are depressing. wink But I must admit that I forgot that the machine I'm running it on is also doubling as a smallish oracle server, and it's getting its Perl from a network mount. I'm going to try some local stuff, and see what it does.

-- WoutMertens - 18 Aug 2002

It was not clear to me whether you included the time to write the text on the screen in your timing. I piped this into /dev/null which does save some time...

-- ThomasWeigert - 15 Aug 2002

That's what I eventually started doing as well, but the difference is never more that 0.1s... Still need to run more tests.

-- WoutMertens - 20 Aug 2002

One thing I noticed in MegaTWiki is a large number of scripts with hardwired locations. These would benefit from some configuration utility, as most users do not have a path named /net/asics/export/www/asics/ on their machine....

-- ThomasWeigert - 15 Aug 2002

Also, I had to change the locks of all the ,v files in data/ to be owned by the user that runs TWiki. I did it something like so (run as the TWiki user):

 $ for i in `find data/ -name \*.txt`; do if [ -f $i,v ]; then rcs -l -M $i; fi; done

-- WoutMertens - 20 Aug 2002

PeterNixon, do you have any changes for the bin/statistics and bin/mailnotify scripts so that they support HierarchicallyNestedTwikiWebs as well?

-- WoutMertens - 20 Aug 2002

No, I'm not dead ;-), just learning carpentry. I don't have any changes for these as of yet, but the changes will be very simple to make. It may require a change in the TWiki.pm module to the subroutine which provides a list of all available webs, if it exists (I haven't looked at the code yet), but it should take only a few minutes. It's definitely been on my list of things todo, since I've lost track of the changes occuring on my own Sun-internal web site. I'll see if I can squeeze it in this week before my nieces arrive on Friday (geeze this summer is a busy one!!).

As far as hardwired locations for some of the scripts, I intend to make this configurable, but I just wanted to get a preview of the code out to everyone who might be interested. Keep in mind, the July release was pre-pre-pre-alpha for MegaTWiki. I wanted folks to get a feel for the interface and the code before I went further and solidified it a bit more.

A note on performance: MegaTWiki is very slow unless you are using ModPerl or the like, especially on the pages which fetch newsfeeds. There is a large amount of code to load and compile, the currently released version does nothing to mitigate that problem, and the code is only going to get bigger until I can make it more efficient/elegant. I have several solutions in mind for delaying the loading of code until it is needed (this is required for the folks who don't have access to ModPerl or SpeedyCGI), and will be investigating the problem further.

As far as most of the other discussion on this page, I'll be following up ASAIC (as soon as I can)!

Thanks for all the feedback!

-- PeterNixon - 27 Aug 2002

Hi Peter, Have all the features of MegaTWiki been accounted for now? By accounted for I mean for each feature (as much as independence is possible) one of:

  • incorporated into the TWiki Core for BeijingRelease,
  • filed as a separate hack against AthensRelease
  • turned into a plugin, or
  • filed as unsuitable?

I ask because supposing Beijing gets released MegaTWiki will become a divergent CodeFork and, as such, it will be harder to bring its features in.

-- MartinCleaver - 05 Oct 2002

At the moment, MegaTWiki is a divergent CodeFork; I don't see these features making it into the core code before CairoRelease, mainly because I'd rather wait for EnhancementsToThePluginAPI to gel a little more. I'll continue to keep this code up to date with released code; it only takes a day or so to do the merge once a stable release comes out. At the rate things are going, it'll be a long road to TWikiOO.

This code cannot be independant of the core code until the Plugin API is enhanced, and HierarchicallyNestedTwikiWebs are fully supported.

-- PeterNixon - 03 Nov 2002

Better make that DakarRelease. CairoRelease is more of a cleanup release.

-- PeterNixon - 06 Nov 2002

I am seeing a problem with MegaTWiki. Whenever I try to add a topic to any webs, the topic is getting created under one level above the web where Intended. For e.g if I try to add a new topic "GeneralTest" under Main/Test/Subfolder, the topic is getting created under Main/Test. But I guess as a work around I can create a topic directly by creating a TWiki url and add it to the side bar, still I would like to have the create new topic working fine. I have installed MegaTWiki in Windows as well as Linux running Redhat 7.2 with apache. I am seeing the same behaviour! Am I seeing a bug here or missing some config elsewhere ?

-- MuthukumarSuriyanarayanan - 16 Dec 2002

Yes, you have found a bug in MegaTWiki. I will be posting an updated MegaTWiki release in the next few weeks that fixes this behavior and many others.

-- PeterNixon - 17 Dec 2002

What is the chance or timeframe for being able to get the Hierarchical Webs feature in the core TWiki, if at all?

-- AdamTheo - 21 Dec 2002

Adam - see HierarchicallyNestedTwikiWebs for a discussion and voting table on this.

-- MartinCleaver - 21 Dec 2002

Is the newly version of MegaTWiki available ?

-- SergeStinckwich - 02 Mar 2003

Peter - are you still working on MegaTWiki?

-- MartinCleaver - 05 May 2003

I've moved into maintenance mode, but I've been keeping it semi-up-to-date. Here's an update which fixes some of the admin interface bugs, including the Create New Topic bug mentioned by MuthukumarSuriyanarayanan above.

-- PeterNixon - 24 Jul 2003

Good to see you back Peter. What's your perspective on the possibilities of splitting out the implementation parts of MegaTWiki into patches and merging them in to TWiki? It would be good to see Sun using the same codebase as everyone else.

Two questions come particularly to mind: how hard would it be (both procedurally and implementation-wise) and can you see yourself having the capacity to project lead such an initiative? I am thinking that we have some good people submitting patches (who I am keen to keep involved) and I guess they would help if given some direction by you and some acceptance criteria by our CoreTeam.

Did the enhancements you ask for make Beijing?

-- MartinCleaver - 26 Jul 2003

I'm in the first stages of merging this. The way I'm doing this is by letting CVS create the diffs for me by creating a branch based on TWiki 2002/6/13 (since that appears to be the base version), checking that in. Then checking in MegaTWiki 0.1 in, and doing diffs based on that.

In case it's of use to others, I've attached a unified diff (against TWiki20020613) to this topic. Since it's large I've gzipped it. (A mere 18,000 lines or so)

-- MS - 23 Dec 2003

Update: I've now merged the differences between TWiki20020613 and TWiki20031201 and a new smaller patch will probably appear soonish when it's been trimmed. (I still have to merge template rejections) Mixtures of tabs & spaces combined cause significant problems for patch size when large patches (like the above) have rejections. The large scale reorganisation of the Func.pm module has also been a problem. (reordering of functions, etc - AFAICT not much actual functionality was added. Doc changes changes IMO shouldn't cause such a large drift. </tuppence>)

-- MS - 10 Jan 2004

Many people want them (including me) and as both MegaTWiki and CodeAndDataSeparation are based on AthensRelease I guess it is probably simpler to bring both in at the same time. PeterNixon told me that Sun Microsystems has not "upgraded" to TWikiRelease01Feb2003 (and seemingly have no plans to - MegaTWiki is spreading internally) because TWikiRelease01Feb2003 does not have the features they need. (Our leader, PeterThoeny has not yet responded in TWikiAdvocacy01Feb2003 so I guess he has nothing to say on the matter).

  • Is the glass half empty or half full? To set things into the right perspective, I never stated that MegaTWiki should not go into the core. Many parts probably could and should. There are details that need to be worked out, e.g. I have concerns about the drop in performance that would require to switch to mod_perl. Also, if I would make extensive changes to a software package, I would also "reject" the latest release unless I would merge my changes back. -- PeterThoeny - 24 May 2003

  • I never stated that MegaTWiki should not go into the core. Many parts probably could and should. There are details that need to be worked out -- PeterThoeny - 24 May 2003

True, but you have hardly said anything at all on the matter. In fact, you made just one comment that I could find. From MegaTWiki:

  • Very intersting enhancements! Over time we will take some parts that fit into the core code. Thanks for sharing this. ... I had not yet time to look into details. -- PeterThoeny - 28 Jun 2002

Given that almost a year has now passed, will you now either commit as to when you will have finished looking at this or make a statement that you are happy for others to incorporate it on your behalf?

-- MartinCleaver - 24 May 2003

moved from TimDistroDev - 13 Sep 2004


The LDAP authentication script sounds interesting. I'd like to adapt it to MySQL. I have a team website using MySQL and it would be nice to authenticate team members against the MySQL DB. Perhaps some kind of configurable back-end for authentication would work. On Linux, perhaps one could use PAM? (Just speculating.)

-- KennethPorter - 19 Nov 2004

Kenneth - there exists an LdapPlugin for TWiki; anything that is not covered by that should be covered by the RegisterCgiScriptRewrite. Please let me know.

-- MartinCleaver - 19 Nov 2004

Hey Kids!

I'm happy to say that MegaTWiki is still not dead! Apologies for not participating for the last year, I seem to have thrown a grenade and disappear as it were. Lots happened yada yada yada.

I've been receiving quite a few requests to help other folks inside Sun Microsystems set up new TWiki servers, so I've (just this minute) started working on splitting out most of the functionality into Plugin, Patch, and Skin categories, which may be separately installed. I should have something ready/tested based on CairoRelease in a few weeks. It'll take me at least a week to catch up on what changes have been incorporated since TWikiRelease01Feb2003, and to answer some of the questions posted in this topic.

To quickly summarize what I'm up to, I'm splitting it up this way:

-- PeterNixon - 24 Jun 2005

Welcome back Peter! While you catching up, you might take a look at DakarRelease since it is not too far off and has involved some major rewriting of code (see DakarDesignPrinciples). You might even conclude that as long as you're updating your code to jump right over Cairo and target your enhancements to Dakar.

-- LynnwoodBrown - 24 Jun 2005

On the surface that sounds like it'd be fun, but I think I'd like to at least get caught up to the current production release first. After looking over the changes that are going into the next release I think it's probably wise to wait until the experts give it a chance to breathe and figure out if it still has all it's limbs.

-- PeterNixon - 25 Jun 2005

Getting "caught up with the current production release" is not necessarily a good step on the road from MegaTWiki to DakarRelease. I did a trawl of the (released) MegaTWiki code before I started work on Dakar, and it was one of the things that drove certain redesign decisions. The main MegaTWiki features missing from Dakar are hierarchical webs and the administration pages - hierarchical webs because I just don't believe in them so didn't want to put the work in, and administration tools because I hate editing templates.

As for giving Dakar a chance to breathe, that's exactly why we need people to work on the Dakar codebase - we need people to push the boundaries, and point to the missing toes.

-- CrawfordCurrie - 25 Jun 2005

Well, I don't suppose it would hurt to work on a graft for Cairo while digging around in Dakar. I'll see what I can do.

-- PeterNixon - 25 Jun 2005

See MultiLevelWikiWebs for a patch to enable MultiLevelWikiWebs in Cairo and Dakar releases.

Here's where I'm going next:

-- PeterNixon - 27 Jun 2005

Peter, welcome back... looking forward to seeing MegaTWiki influence the main line...

With respect to preference editing, in Dakar this is currently done using the PreferencesPlugin. Take a look at how this plugin supports template based editing of settings...

You can see a demo at ntwiki...

-- ThomasWeigert - 28 Jun 2005

The PreferencesPlugin is nice, but I still can't decide if I want to edit preferences in the context of the WebPreferences topic. It is useful, because you can embed informationals, but if you're going to override a preference from a parent web, it's a little tougher (you have to edit the page and manually add the preference). The goal of the MegaTWiki preference editor is to expose all the preferences in the system and should (if it doesn't already) let you know where they're being set if you're currently inheriting it. I think I'd like more of a combination of the PreferencesPlugin and what MegaTWiki currently implements, maybe one that still uses a template-driven form, but extracts information from a TWiki topic for each preference's documentation.

-- PeterNixon - 29 Jun 2005

TopicClassification FeatureRequest
TopicSummary A feature-full fork that could provide some quick wins
CurrentState UnderInvestigation
OutstandingIssues too big to easily digest; significant code drift since last release

InterestedParties MichaelDaum

TWikiContributors PeterNixon
Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatgz MEGATWIKI.01.patch.gz r1 manage 125.9 K 2003-12-23 - 00:53 UnknownUser Unified diff of MegaTWiki vs TWiki20020613
Unknown file formatgz MegaTWiki.01.tar.gz r5 r4 r3 r2 r1 manage 1253.1 K 2006-10-11 - 17:09 PeterNixon TWiki with admin tools, nice skins & bug fixes
Unknown file formatgz MegaTWiki.02.tar.gz r2 r1 manage 4492.0 K 2006-10-11 - 17:10 PeterNixon Bugfixes (not based on BeijingRelease)
Unknown file formatgz MegaThemeLogo.tar.gz r1 manage 6.2 K 2002-06-27 - 19:31 PeterNixon Non-Sun logo for MegaTheme
Perl source code filepm RcsWrap.pm r1 manage 12.8 K 2002-07-05 - 14:08 PeterNixon Fixed a syntax error on line 164
JPEGjpg megatwiki_admin.jpg r1 manage 108.1 K 2002-06-25 - 00:31 PeterNixon Screenshot of the MegaTWiki admin page
JPEGjpg megatwiki_frontpage.jpg r1 manage 125.7 K 2002-06-25 - 00:32 PeterNixon Screenshot of Main with the mega skin
JPEGjpg megatwiki_toolbox.jpg r1 manage 149.6 K 2002-06-25 - 00:35 PeterNixon Better screenshot of the admin toolbox
Edit | Attach | Watch | Print version | History: r68 < r67 < r66 < r65 < r64 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r68 - 2006-10-11 - PeterNixon
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.