Tags:
create new tag
, view all tags

Feature Proposal: Plugins Per Web Or Page Needed

Motivation

Reducing work required by sysadmin to administer twikis - by allowing multiple projects to coexist in the same twiki installation.

Description and Documentation

From SysadminJohnMechalasTWikiComments

John Mechalas reports that one of the most annoying things for him as a sysadmin is that he has basically had to give each project requesting a twiki a complete twiki installation, leading to duplicated work, rather than allowing them to coexist in the same twiki install as different webs (with subwebs).

The big reason to give projects different twiki sites: plugins. Different projects want different plugins installed. Different plugins interfere with each other.

SUGGESTION: make plugins web specific. Let every web specify which plugins are active for that web (and all subwebs of that web) in WebPreferences.

This way different projects could use the same twiki installation. Each could use separate webs - probably with subwebs. Each could specify which plugins to use.

Going further: allow plugins to be specified on a per page basis. This to allow a page to be moved from one web to another, using a plugin not used in the second web.


We could have a longer discussion about why a single wiki site is easier to administer than many. But it just is. Here are some of the reasons:

  • when a security hole is found, it has to be patched once versus multiple times
    • especially relevant of some of the sites have diverged, made local changes
  • at Intel, we automatically create many groups suitable for access control - e.g. everyone in a given department, everyone on a given mailing list, etc. It is only minorly annoying that you have to have cron jobs of the like to create TWiki style Group files for these groups. It is majorly annoying that there is even more redundancy - "Oh, the foobar group exists on wiki site 1 but not wiki site 2", etc.
  • sometimes we make local changes to documentation in the TWiki web. It is annoying to have to make those changes on multiple webs.
  • users get annoyed when they have to do a user customization at each different TWiki site, rather than at a single one.


PS. you need an "admin" category for WhatDoesItAffect.

Examples

Impact and Available Solutions

Implementation

-- Contributors: AndyGlew

Discussion

-- AndyGlew - 09 Jun 2006

If a plugin is installed but disabled site-wide then can you use the INSTALLEDPLUGINS variable to reenable it on particular pages?

-- MartinCleaver - 09 Jun 2006

A single TWiki is definitely the better choice. Wikis are typically deployed in a grassroot way, hence the tendency to end up with many wikis behind corporate firewall. From the book interviews we have seen that once wikis get at the radar screen of the CTO, they get consolidated to a central wiki. Andy states reasons why you want one central TWiki. There are more: Mission critical data is in wikis, e.g. backup plan is easier with one wiki, and secirity policy is easier to enforce. Last but not least, you avoid data silos because multiple wikis do not talk to each other and people do not link to other wikis.

I think it is a good idea to have Plugins per web. This functionality was provided by Cairo, and you could control the Plugin enabling and order per web with DISABLEDPLUGINS and INSTALLEDPLUGINS settings. AFAIK, TWiki 4 does not provide this functionality, it has just a global enable in configure (and no plug & play autodetection).

So yes, re-instantiating Plugins per web is useful/essential in a big TWiki site.

-- PeterThoeny - 09 Jun 2006

Peter is right, a single codebase is the better choice. However I take a somewhat different approach. Here's how I work on several sites:

  1. Use CVS to control the installed codebase (lib, templates and bin dirs) and data/TWiki web
  2. Configure the various sites from Apache
  3. Run each "twiki" from a checkout from CVS. The only files that need to be "customised" per-install are LocalLib.cfg and LocalSite.cfg
  4. The TWiki web is common to all sites. So plugins are installed once but ony enabled in the webs that require them.
  5. Use CVS (or similar) to control the installed codebase (lib, templates and bin dirs) and data/TWiki web
  6. Configure the various sites from Apache
  7. Run each "twiki" from a checkout area. The only files that need to be "customised" per-install are LocalLib.cfg and LocalSite.cfg
  8. The TWiki web is common to all sites. So plugins are installed once but ony enabled in the webs that require them.
Of course because Main is local to each site, TWikiPreferences is local to each site as well, which allows me to configure the TWiki appropriately for that group.

Here's how CVS looks:

bin/
   *all scripts but not LocalLib.cfg or .htaccess*
lib/
   * everything except LocalSite.cfg, but including all Plugins*
templates/
   * everything*
tools/
   *everything*
data/
   TWiki/
      *everything, including Plugins topics*
pub/
   TWiki/
      *everything*
Now, if I need to install a plugin, here's what I do:
$ cd twiki_test_checkout
$ # install the plugin, check it works
$ cvs commit -m "Installed XyzPlugin"
$ cd twiki_install_1
$ cvs update
$ cd twiki_install_2
$ cvs update
$ ...
I can then enable the plugin using configure on individual sites.

This approach seems to be preferred by a lot of people, for several reasons:

  1. Each project has their own "space" without having to fight with TWiki permissions
  2. Authorisation is on a per-twiki basis
  3. Each project has their own Sandbox and Trash areas (essential when you have several companies sharing a server)
  4. It is trivial to archive, disable, or otherwise control as a unit, a single TWiki. Further, recovery from backing store also brings back all the code, ensuring data integrity.

It would be trivial to script the creation of a new twiki in this scheme. So trivial that I don't usually bother wink

-- CrawfordCurrie - 11 Jun 2006

Actually, I think in many cases (but depending on the circumstances) one central TWiki is better than 5 TWikis that share the codebase, but have distinct webs. Reasons:

  • Users need to register in more than one wiki
  • TWiki groups and ACLs need to be maintained in more than one wiki, and some need to be kept in sync
  • Multiple wikis create data silos (linking between wikis is rare, linking between webs happens often)

-- PeterThoeny - 11 Jun 2006

Sure. It depends on your environment; in some cases, having everyone in a single web is also better. I was just presenting the spectrum of choices, not trying to criticise your approach. The case I encounter most frequently, though, is where silos are actually required (because of licensee issues etc). In every case I have seen where a single TWiki can be shared between groups, then they tend to have common practices (e.g. corporate project guidelines) and therefore common plugin requirements.

If you only want users to register once, then of course you can simnply soft-link Main in the different installs. I sometimes do that for Sandbox as well. But rarely for Trash, after Colas' experiences!

-- CrawfordCurrie - 11 Jun 2006

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2006-06-11 - CrawfordCurrie
 
  • 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.