• 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.

When running configure for the first time, the (first time?) user is slapped with errors and warnings. It looks bad, gives the idea the system is fragile, and it gives the user the idea s/he is failing. We surely can do better.

Can we start with a simple form where the site paths can be entered? When this is saved the user might change other settings.

This would also mean we can get rid of the error/warning message at the top of the second screen.

AC

I have wanted to raise this bug item many times but have just forgotten all the time.

I am 100% with Arthur on this one.

It does not have to be very complicated. The configure script should look for lib/LocalSite.cfg. If it is not there then only show the "General Path Setting" section and a very simplified standard error message above telling the user to check the settings, save and set a password.

Then when the user returns to configure lib/LocalSite.cfg will have been saved and the user can see everything.

KJL

Raising to Requirement. -- AC


Sorry, I'm not doing any more coding on this one for 4.1. While I totally agree it's not a good UI, don't accept it as a requirement for release. You don't give any justification for raising to release-blocking status. Regrading as enhancement, I'm sure it will be addressed when someone has the time.

CC

I am not saying you should do more coding. But the new configure needs more care than the existing code. If above arguments are not enough, we should redefine who we are creating TWiki for. In my opinion this is a release blocker, and I am intending to raise to requirement again.

AC

This issue is one of the problems people most often ask about on #twiki and has been since release of TWiki4. "You don't give any justification for raising to release-blocking status". What more reason do we need? It is user-unfriendly. It creates problems, questions, frustrations. It is the 3-4 first steps of the TWiki installations that people have the most questions about. We are now two votes to 1 that this is a requirement. Any more votes?

KJL

Any state change needs to be accompanied by a justification, and I don't regard "Raising to requirement" as sufficient, which is why I dropped it to enhancement. If you are happy for it to be a release blocker, that's fine by me.

Changed to Actioning, as the analysis is pretty clear.

CC


While what KJL says is reasonable and a good idea, I think it is also reasonable to expect that a user can read the screen. A few words on the top that say "If this is your first install, you will see problems highlighted in the general path section. Don't worry, just go there and confirm or correct the paths and save." would suffice, if implementing KJL's suggestions is too much effort at this point. -- TW

Just to clarify. It is OK that you see the errors in the general path settings section.

I just want to hide all the other configure sections AFTER General Path Settings until the file lib/LocalSite.cfg is saved. The reason is that before you have saved the general path settings there are other settings further down that show errors, and if the newbie admin tries to fix them he can really goof up everything. Once the lib/LocalSite.cfg with the general path settings correct these errors go away by themselves. We have had users that have attempted to remove the errors of other file path depending settings and goofed up everything. It is easy to help them when they arrive in #twiki IRC. We ask them to delete LocalSite.cfg and start all over. But with very simple means we could avoid this error opportunity. And that is all I propose to close this bug report.

I have been looking at the code for configure but I had trouble following the flow and find where the code is that I should bypass to skip all settings below general path settings.

KJL


Sorry to go back one step first - I can not see that the analysis is quite clear. It took me some time to examine what happens when running configure for the first time, why it happens, and what should happen instead.

  • What happens: The "user is slapped with errors and warnings" (from AC's first report) is nasty because in the CGI setup section he gets errors, but only warnings in the General Path section. Everyone who is trying to fix the "errors" before heading for the warnings is doomed.
  • Why it happens: In the CGI setup section, the checker tries to load TWiki.pm, which fails with an error if there is no LocalSite.cfg file.
    • Fix no. 1: Since the checker doesn't really need Twiki.pm at this stage, tell him to ignore the configuration files. They are taken care of by the BasicSanity checker anyway.
  • What should happen additionally: In the further sections, TWiki should not report errors for the log files if the guesses made in the "General path settings" section are ok.
    • Fix no. 2: Try with the guessed settings instead of the unexpanded $TWiki::cfg{...} values.

The new behaviour (if the changes I am preparing right now happen to work) is:

  • On a first time run of bin/configure, if the guessed paths work, there are no errors and warnings only in the "General path settings".
  • If a user confirms these settings, everything is just fine from now on.
  • Note that the LocalSite.cfg file will still contain indirections like $TWiki::cfg{LogFileName}='$TWiki::cfg{DataDir}/log%DATE%.txt';, this will be fixed if the user ever comes back to configure.

-- haj

That truely sounds very promissing. I will for sure test it when it is ready and give feedback. If it works it will eliminate one of the top 10 common installation problems.

Thanks Harald.

KJL

Just noticed that you had checked in the changes. I am not sure if you have more comming.

But what you have done is SPOT ON and much better than what I proposed.

When you delete the LocalSite.cfg to experience the impression of the first time installer you now get something which leads the installer to taking the right steps. I would say that what you have done so far is enough for me to set this to "Waiting for Release". It is what was needed 4.1. I will not do that now in case you have planned more checkins.

Thanks again Harald.

KJL

I'm not planning more checkins for this item right now. During debugging I might have found some more quirks, but these are unrelated. I'll open a new item if the findings are worth a fix, and set the current one to "Waiting for Release".

-- haj

changed headline for release notes

KJL

4.1.0 released

KJL

ItemTemplate
Summary Configure shows unnecessary errors when run first time
ReportedBy TWiki:Main.ArthurClemens
Codebase ~twiki4
SVN Range TWiki-4.1, Sun, 08 Oct 2006, build 11688
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins 12051
TargetRelease minor
Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2007-01-16 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback