On a fresh install of Koha, logging in I was met with: Invalid dateformat parameter () at /home/vagrant/kohaclone/Koha/DateUtils.pm line 112. It appears that if the library is not set, you get this message on mainpage.pl. Needless to say, this adds difficulty in setting up a fresh install of Koha!
Created attachment 51136 [details] [review] Bug 16430 - Mainpage.pl dies if library is not set On a fresh install of Koha, logging in I was met with: Invalid dateformat parameter () at /home/vagrant/kohaclone/Koha/DateUtils.pm line 112. It appears that if the library is not set, you get this message on mainpage.pl. Needless to say, this adds difficulty in setting up a fresh install of Koha! Test Plan: 1) Check out master, start with a fresh empty database 2) Go through the installer, log in with the db user for the first time 3) Note the error 4) Apply this patch 5) Refresh the page, the error should be gone
Created attachment 51137 [details] [review] Bug 16430 - Mainpage.pl dies if library is not set On a fresh install of Koha, logging in I was met with: Invalid dateformat parameter () at /home/vagrant/kohaclone/Koha/DateUtils.pm line 112. It appears that if the library is not set, you get this message on mainpage.pl. Needless to say, this adds difficulty in setting up a fresh install of Koha! Test Plan: 1) Check out master, start with a fresh empty database 2) Go through the installer, install all default data, log in with the db user for the first time 3) Note the error 4) Apply this patch 5) Refresh the page, the error should be gone
On further testing, I think this may be a much deeper problem than this.
The root case is a change in dt_from_string: $date_format = C4::Context->preference('dateformat') unless $date_format; This line means that if the caller does not pass a format, the native preferred format is assumed. When not logged in, $date_format will be empty and cause an error. There are also many calls to dt_from_string where no format is passed which will cause other errors.
I'd keep the die, to catch next issues of the same kind.
I do not recreate, did you fix the sysprefs.sql file before? See bug 16418
This one was invalid, it was caused by a syntax error in sysprefs.sql