• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Item4249: RegistrationApprovals is not a web

Item Form Data

AppliesTo: Component: Priority: CurrentState: WaitingFor: TargetRelease ReleasedIn
Engine   Urgent Closed   minor  

Edit Form Data

Reported By:
Applies To:
Current State:
Waiting For:
Target Release:
Released In:


The RegistrationApprovals are stored in .../data/RegistrationApprovals. The code in TWiki::Store::RcsFile.pm returns it as a public web when calling for a list of known webs. That's why it shows up in the sidebar navigation as a web...which we don't want.

This can be resolved in either of the following ways:

  1. filter out RegistrationApprovals in the store impl
  2. rename RegistrationApprovals to _RegistrationApprovals
  3. move the RegistrationApprovals out of the data directory

-- TWiki:Main/MichaelDaum - 15 Jun 2007

Most logical place is pub/_work_areas/_RegistrationApprovals

-- TWiki:Main.PeterThoeny - 15 Jun 2007

... or pub/_work_areas/RegistrationApprovals

-- TWiki:Main.MichaelDaum - 15 Jun 2007

This one has been bugging me for a long time. Glad you decided to fix it!

You can put it in _work_areas; just use $session->{store}->getWorkArea('RegistrationApprovals'). That's where it would be if registration was a Contrib - which it ought to be, really.

-- TWiki:Main.CrawfordCurrie - 16 Jun 2007

Right now, the directory is configured in $TWiki::cfg{RegistrationApprovals} and defaults to $TWiki::cfg{DataDir}/RegistrationApprovals. I'd opt to remove it from configure as I can't imagine a case where one would know better where to put it than the store impl.

-- TWiki:Main.MichaelDaum - 19 Jun 2007

I have just had someone else suffering as a result of the use of /tmp for temporary files. We need a safe, unbrowseable directory where we can store session files, that doesn't get eaten whenever the server is rebooted.

In fact there are several places we need:

  1. An unbrowseable work_areas dir
    • The current _work_areas is held under pub, which is bad because by default it's browseable, and therefore contrary to the documentation.
    • Must either move it, or make it unbrowseable by default
  2. A browseable place for plugins to put "stuff"
    • We have that; a plugin can attach files to any topic. I checked though all the checked in plugins, and with the single exception of HeadlinesPlugin that's how it is used.
  3. A secure place to store sessions and passthroughs
    • We currently use /tmp by default, which is bad - it is insecure and gets wiped without warning by admins
  4. A secure place to store regsitration approvals
    • Currently in data/RegistrationApprovals, which is absolutely the wrong place
    • This has to be more persistent than sessions

So here's what I'm proposing to do:

  1. add a dir in the root, called working. Add .htaccess to make it unbrowseable.
  2. move pub/_work_areas to the root, to working/work_areas.
  3. add working/tmp for sessions and passthroughs
  4. add working/registration_approvals for registration approvals
  5. remove the {RegistrationApprovals} option from configure and standardise on {WorkingDir}/registration_approvals instead.

If you can see any problem with this shout now.

-- TWiki:Main.CrawfordCurrie - 19 Jun 2007

Not sure I understand, nobody is going to shout and flame.

The current pub/_work_areas dir is unbrowseable by default, it has a .htaccess file that denies access.

Having said that, I think it is a sensible thing to add a working directory for tmp and registration_approvals. For compatibility I suggest to leave the _work_areas where it is for now, and to announce that it will be moved to below working in the release after 4.2.

-- TWiki:Main.PeterThoeny - 20 Jun 2007

Why is it incompatible to move the _work_areas out of pub? Which code does not use TWiki::Func::getWorkArea() ?

-- TWiki:Main.MichaelDaum - 20 Jun 2007

It isn't, AFAIK. I made the changes as described above. Not sure exactly what we should ship in the way of .htaccess files; I have created one at the root of WorkingDir. Note that the upgrade for working files should be seamless (all handled in configure)

-- CC


  • On upgrade, admins need to move work area data to the new location, or extensions will not be able to find it. A similar scenario happended with TagMePlugin where the tagging data was moved from pub/TWiki/TagMePlugin to pub/_work_area/TagMePlugin (some support questions have been raised on this)
    • the change is handled automatically by configure. How effective this is depends on the amount of testing/feedback between now and the release, I guess.
  • Extensions that use the work area to store browser accessible content will break (we do not know what users do in unpublished extensions.)
    • that's true; but the doc is quite clear that the area is "not browser accessible", and AFAICT all public plugins have respected that (with the possible exception of HeadlinesPlugin)
That is the reason why I suggest to leave the _work_areas where it is for now, and to announce that it will be moved to below working in the release that follows 4.2.

Let's take this to the next release meeting so that customer advocates have a voice.

-- TWiki:Main.PeterThoeny - 21 Jun 2007

The current implementation moves the _work_area when you run configure. That is a beautiful way for the upgrader to easily get going.

What we need to do is

  • Review all public plugins that they use the proper API and no hardcoded directories.
  • Evaluate is violating plugins need to be fixed.

Non-public plugins which uses non-public API will be broken anyway with all the code refactorings done from 4.1 to 4.2.

Please note that a.htaccess file in a directory often has no function at all. They only come to effect if enabled in httpd.conf. You cannot count on a .htaccess file to be effective. So the new working directory needs to be added to ApacheConfigGenerator and to the default twiki_httpd_conf.

I think moving things into working in small steps will be more painful than doing it all at once. And with the nice upgrade method in configure I do not see this as an issue. I wish other upgrade pain had been resolved as elegantly as this one. It sort of sets the standard from now on wink

-- TWiki:Main.KennethLavrsen - 21 Jun 2007

A couple of carifications above. I know a .htaccess may not be used, but I think it's better to provide one than not.

IMHO ApacheConfigGenerator doesn't get enough press. Is it linked from the installation instructions yet?

-- CrawfordCurrie - 21 Jun 2007

OK, convincing arguments to move _work_area as well.

I run configure, but it did not move the pub/_work_area/TagMePlugin directory to working/working_area. However, the tagging data was still accesible in the old location. Also when manually moved to new location.

-- TWiki:Main.PeterThoeny - 21 Jun 2007

I should have been clearer; it copies the old data to the new location, and warns you (in configure) to remove the old. Not sure what "also when manually moved to new location" is meant to mean.

-- TWiki:Main.CrawfordCurrie - 22 Jun 2007

After running configure, the pub/_work_area/TagMePlugin was still there, and there was no new working/work_area/TagMePlugin. TagMePlugin still worked. I then moved pub/_work_area/TagMePlugin to below working/work_area/ and TagMePlugin still worked.

-- TWiki:Main.PeterThoeny - 22 Jun 2007

Summary RegistrationApprovals is not a web
ReportedBy TWiki:Main.MichaelDaum

SVN Range TWiki-4.1.2, Thu, 14 Jun 2007, build 14128
AppliesTo Engine

Priority Urgent
CurrentState Closed

Checkins TWikirev:14216 TWikirev:14217 TWikirev:14232 TWikirev:14236
TargetRelease minor

Edit | Attach | Watch | Print version | History: r24 < r23 < r22 < r21 < r20 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r24 - 2008-01-22 - KennethLavrsen
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback