Tags:
create new tag
, view all tags

Feature: Script to create a new TWiki web

Creating a new web is currently a manual process as described in TWikiDocumentation. You need to create directories, set file permissions and copy the files WebHome.txt , WebPreferences.txt , WebNotify.txt , WebSearch.txt and WebStatistics.txt to the new data directory.

A script could automate this. ArnoVanDerKolk created a Java Servlet that does that. A Perl script would be nice so that it does not depend on installing a Java engine on the server.

JohnAltstadt had the idea of creating a template directory that contains the default files needed for new webs.

This script should be protected so that only administrators could create new webs. It would be one of the TWiki AdminToolsDev.

-- PeterThoeny - 29 Mar 2000

In addition to the new script copying the template directory, the WebPreferences.txt file needs to be edited by the script to add the new web to the WEBTOPICLIST.

-- JohnAltstadt - 07 Apr 2000

I am currently working on such a script. I have a script that does the creation of a new web, but currently does not do any post editing of preferences etc.

What I have done is created a new directory called webplates this directory has 3 directories data, pub, templates. In each of the above mentioned directories I have a directory named clean, for example webplates/data/clean. The concept is to have different types of webplates to choose from depending on the style for that web. I will upload my beta script and will post a new one once complete.

-- HaroldGottschalk - 18 Jul 2000

Thank's Harold for working on this. Your script needs be be made aware of AuthenticationBasedOnGroups once it is available. Ideally, there would be a CreateNewWeb topic that has a form to fill in, like Web name, flag if web is hidden, web color and such. The form would call the createweb script.

I recommend to have a default web available under each directory ( data/default with must have topics , template/default and pub/default ). Those directories can be copied by the createweb script. Putting the default web into the same hierarchy like other webs has the advantage that the default topics can be customised if needed.

-- PeterThoeny - 20 Jul 2000

Completed version 1.0 createweb script

Current Functionality:

  • Creates new webs and subwebs
  • Form to to ease use of script.
  • Copies files needed for a new web from a specified set of directories.
  • Currently does not edit WebPreferences or TwikiWebsTable, but does provide a link to the new webs WebPreferences page.
  • Default Webplate is set to default.
  • Checks for tainted names, but not for web existance. It will not overwrite an existing web because of the way the copy statement is written.

Current Files Needed:

  • createweb - script that does the copying.
  • create.tmpl - templated used to provide information to user.
  • CreateWeb.txt - Twiki topic that contains form for using script.

Installation:

  • Copy creatweb into twiki/bin
  • Copy create.tmpl into twiki/templates
  • Copy CreateWeb.text into the data directory of choice. Place it in data/Main to start. I have mine in data/Admin.
  • Modify wikicfg.pm add the following lines:
    # Webplates root directory : Used by createweb to build new webs and subwebs
    $twikiWebplatesDir = "/home/httpd/twiki/webplates";
  • Create a directory twiki/webplates
    • Then create webplates/data, webplates/pub and webplates/templates
    • In each of the above create a default directory and place the appropriate files in the directories.
    • Do this for the different types of web styles you want.
  • Modify CreateWeb.txt adjust the option tags to match your webplates.

Could someone try this out and let me know if it works for you. I did my own testing and it works fine for me, but other env are twiked differently.

Thanks

-- HaroldGottschalk - 27 Jul 2000

Thanks Harold for the contribution. I understand that your goal is to let the user choose from several default webs. Where is this useful? To me it seems to be sufficient to offer simply just one default web, but in return, ask the user for the name of the web, the web background color, if the web is hidden or not and so on. The createweb script would then create the new web and patch the WebPreferences topic.

If we go for just one default web I would suggest the following changes:

  • Do not use a webplates directory, rather just a name for the default web in wikicfg.pm , i.e. a new $defaultWebname = "default"; variable. This can point your script to the template directory ( $templateDir/$defaultWebname ), the data directory ( $dataDir/$defaultWebname ) and pub directory ( $pubDir/$defaultWebname ), . This way it is just another (hidden) web, where topics can be edited by a browser (also templates in the future).
  • Use the oops script for all error/message dialogs to make it more consistent with other parts of TWiki. It is already there, and it is simply a matter of creating oops*.tmpl template files. You can pass parameters along ( param1...param3 ) that can be used in the oops templates as %PARAM1%...%PARAM1% . Take the register and the oopsreg*.tmpl templates as an example.
  • Patch the WebPreferences topic. All the gluing part is there: You can do a &wiki::readTopic() , then a regex replace to set the variables, and finally a &wiki::saveTopic() . Take the register script as an example.

-- PeterThoeny - 28 Jul 2000

My reason for having multiple webplates is that category creation and the subsequent topics associated with it are long and tedious effort to configure. This way I have have a web that is oriented towards a business project, a reasearch Area,etc.

I had thought about using the oops templates, but just choose not to learn it. I will review the register script and modify it. I am willing to do the hidden web concept because of the advantage of quickly modifying the template webs. It would be better if and when the template editing feature is in place.

I also think a CategoryManagementSystem and a GenericFormBuilder component would greatly improve the usability of this system.

-- HaroldGottschalk - 31 Jul 2000

In this case (a need for multiple default webs) I suggest to:

  • Have the default web defined by a new $defaultWebname variable in wkicfg.pm (used to point to data/default , template/default and pub/default )
  • In case you need more then one default web: Create any number of webs (i.e. an additional web like data/defaultX , template/defaultX and pub/defaultX ).
  • Let the user choose the name of the web to clone from when creating a new web. This could be any existing web, including the Main web for example.
  • The createweb script

-- PeterThoeny - 31 Jul 2000

Would there be any value in updating this script?

-- MartinCleaver - 31 Oct 2001

Yes. I would like to see it updated. I wrote a simple command line shell script to create new webs, but it would be nice to be able to access web creation inside of twiki

-- JohnRouillard - 01 Dec 2001

I am currently working on this feature:

  • Names of template webs start with an underscore. Currently we have already the _default web, used as a source when creating a new web manually from the shell.

  • ManagingWebs will have a form to enter:
    • Name of web
    • Clone from web: Drop down list to select the web where topics are copied from
    • WebPreferences details like like color, description ("what" and "use to" for SiteMap), exclude search all flag.

  • Clicking on a link that points to a non existing web will show an oops dialog with an invitation to create the web (link to ManagingWebs). Same if you enter a "web dot" name (like NEWweb.) into the "Go" field.

  • An admin script will:
    • Create the web
    • Patch WebPreferences
    • Clone topics: All topics are copied over from a template web (starting with an underscore); only topics that start with Web... (like "WebHome", "WebNotify") are copied from other webs.

-- PeterThoeny - 12 Apr 2002

The first version is now in TWikiAlphaRelease.

Some technical details:

  • A new manage script does create the web. This CGI script expects a action parameter to determine the action to perform, currently it has only one action implemented, the createweb action. It can be extended for other administrative actions in the future
  • The manage script generates many messages. Hardcoding them into the Perl code is not good, and creating one oops file for each little message is a mess. The template variables come to rescue: The oopsmanage.tmpl template defines several variables, e.g. a %TMPL:DEF{"msg_missing_action"}% template variable. The manage script can display one of the messages by calling TWiki::getOopsUrl() with the first parameter set to e.g. "%TMPL:P{\"msg_missing_action\"}%".

To do:

  • Clone topics is now done inside the manage script. It currently does not support repository files located in an RCS subdir, and it does not yet clone attachments. This function should be moved into TWiki::Store.
    • JohnTalintyre: Could you do that? What is needed is a TWiki::Store::copyTopic( $fromWeb, $fromTopic, $toWeb, $toTopic ) function that clones a topic, including repository and attachments (if any).

Question:

  • Is it better to copy the revision history and owner of a topic, or is it better to create a vanilla r1.1 version with today's date and last changed by the person creating the web?

Feedback is appreciated. To test it out you need to get the latest TWikiAlphaRelease and also the form in TWiki.ManagingWebs.

-- PeterThoeny - 13 Apr 2002

Very nice! Just tried it and it works well on a local TWiki, on Windows and CygWin Perl. The chmod's are no-ops on ActivePerl, and on Cygwin they have no effect in the default security setup, but that's the same as any other TWiki code.

I would prefer to just start a new web from r1.1, but perhaps others will disagree.

On a related note: in order to get new topics (including BrowserExtensions and ManagingWebs), and for ReadWriteOfflineWiki as well, it would be useful if there was a way to grab the .txt files directly via HTTP, i.e. TextFileExport.

-- RichardDonkin - 13 Apr 2002

I'm guessing this might also work on SourceForge as the commands (in the "manage" script) are run by the "Apache user". Is this a reasonable expectation?

-- RandyKramer - 13 Apr 2002

Added access restriction, only users or groups in the ALLOWWEBCREATEWEB prefs variable are allowed to create new webs. Is in TWikiAlphaRelease. (Yes, it should work on any server)

Regarding version of topics in a new web, I prefer to keep the version because this will show and credit the original authors.

Note for upgrade (needs to be carried over into docs):

  1. Make the manage script authenticate users. Add this to .htaccess:
    <Files "manage">
        require valid-user
    </Files>
  2. Authorize users to create webs. In TWikiPreferences add this:
    • Add ALLOWWEBMANAGE to the FINALPREFERENCES list so that nobody can overwrite the setting:
      • Set FINALPREFERENCES = WIKIWEBMASTER, PREVIEWBGIMAGE, SMTPMAILHOST, SMTPSENDERHOST, ALLOWWEBMANAGE
    • Users or groups allowed to create new webs: (ex: TWikiAdminGroup)

-- PeterThoeny - 13 Apr 2002

I think ALLOWWEBCREATEWEB sounds a bit odd - it's not a web-specific permission like ALLOWWEBCHANGES, since a new web is created at the TWiki level, so why not call it ALLOWCREATEWEB?

-- RichardDonkin - 14 Apr 2002

True, ALLOWWEBCREATEWEB is kind of an odd name. It is composed of ALLOWWEB and CREATEWEB. The TWiki::Access::checkAccessPermission() expects an action of authorization like VIEW, CHANGE, RENAME and now CREATEWEB. It checks for DENY/ALLOW in the WEB first, then in the TOPIC. That way we get this (DENY|ALLOW)(WEB|TOPIC)(action) pattern. Topics and webs do not make sense for CREATEWEB, but it was the easiest to implement using the same logic. I did not want to name it ALLOWWEBCREATE because the CREATE action could be used in the future for controlling the creation of topics in webs. We could spend some more time to program extra code for a nicer name, but why the extra work.

-- PeterThoeny - 14 Apr 2002

In a word: usability... The 'create web' action is the first that really applies to the TWiki site, not a specific web - so perhaps ALLOWTWIKICREATEWEB or ALLOWSITECREATEWEB is a better name for this (and any other site-level permissions). It doesn't really make sense to implement this site-level scheme in a web/topic framework - the confusing name is just an indication of this.

I just had a quick look at the code - it doesn't seem that hard to use ALLOWSITE in the same way as ALLOWWEB.

-- RichardDonkin - 14 Apr 2002

Very nice. My users asked for it... About action name: what about ALLOWWIKIMANAGE? We have TWikiVariables like WIKIHOMEURL, WIKIPREFSTOPIC for site-wide thingies, and verb MANAGE will be associated with doing things to webs. Do we expect more fine-grained rights to managing webs will be needed later?

-- PeterMasiar - 15 Apr 2002

OK, this is a simple solution: No change in the access control code, but renamed ALLOWWEBCREATEWEB to ALLOWWEBMANAGE. In TWikiAlphaRelease.

-- PeterThoeny - 24 May 2002

One detail is left, should go into BeijingRelease: Create web does not copy file attachments. A clean way is to implement a TWiki::Store::copyTopic( $fromWeb, $fromTopic, $toWeb, $toTopic ) function that clones a topic, including repository and attachments (if any). JohnTalintyre, do you have time to work on this?

After BeijingRelease we should refactor the manage script as mentioned in SlimDownFatCgiScripts.

-- PeterThoeny - 18 Jul 2002

A simpler solution is to document that create web doesn't include attachments smile ... You could work around this limitation by attaching the files somewhere standard in a pre-existing web, and making the create-web template refer to those files. Doesn't seem too much of a problem to me, anyway.

-- RichardDonkin - 18 Jul 2002

I can't tell you how happy I was to find out about this feature. I needed this for the last TWiki I maintained, since the IT policy at the shop disallowed direct filesystem access on the server.

However being a programmer myself, I'm not keen on picking up the latest alpha just to get this one feature. So I made a patch (attached) to add this feature to the 20011201 release. The only interesting part is TWiki.pm, which needed an isWebName function added to it. I'm no Perl programmer, this is a crude hack to get the job done. Hopefully it will be of use to others.

-- SteveSexton - 20 Dec 2002

That's good. Thanks.

BeijingRelease is out on the 1 January, that's less than 2 weeks away. So, I guess the latest beta can be considered the release candidate. (I appreciate that you can't be seen to be installing alpha status software no matter how long it has been in use in production at TWiki.org)

-- MartinCleaver - 21 Dec 2002

What specifically is still needed to bring the BeijingRelease status for this feature up from 90% implementation and 50% documentation?

-- GrantBow - 06 Jan 2003

Lets spin off ScriptToCreateNewWebWithAttachments into its own topic, that way the implementation is 100% and ready for BeijingRelease.

-- PeterThoeny - 11 Jan 2003

Good idea! I've added it to the CairoRelease (please edit percentages as needed) and will accomodate this in the documentation I do.

The manage script updates several variables in the new topic's WebPreferences file but it doesn't update the WIKIWEBLIST variable of TWiki.TWikiPreferences, does it? I've added this to the documentation for now. Check it out. Documentation for this feature should be very close to complete now!

-- GrantBow - 12 Jan 2003

Topic attachments
I Attachment History Action Size Date Who Comment
Compressed Zip archivezip ManagePatch.zip r1 manage 25.5 K 2002-12-20 - 22:54 SteveSexton files to use alpha w 20011201 stable rlse
Edit | Attach | Watch | Print version | History: r34 < r33 < r32 < r31 < r30 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r34 - 2005-02-15 - SamHasler
 
  • 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.