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