Missing input fields during installation

[webmaster@…]

Hi there,

Just downloaded the latest release (beta3) and unpacked everything on my server, set permissions to allow write and set up a new database.

Trouble is every time I run _install.php file I get no input fields for administrator user name or password. I get the database options and under the heading "Administrative Setup" I just get "Gallery Name" and "Your e-mail" input fields. So when I click install the next page just has:

Setup is now complete

Your username is and your password is ``

Completely devoid of any information... So I click proceed and it takes me to the login page which I can't login to for obvious reasons. All mysql database tables are created as they should. I've attempted this many times using different browsers to no avail.

Any ideas please?

Gaz

[Mike]

Was this actually resolved? I don't see any commits since this ticket was posted.

[sidtheduck]

We should at least have a check during _install.php and/or _upgrade.php to check that sessions are working (which I think is the original issue of this ticket).

I've noticed a growing trend (especially with shared hosting) that forces users to define their own session.save_path within the scripts (or .htaccess) so sessions are saved within access on a users own host (instead of the inaccessible shared locations above the users reachable root directory).

[kimparsell]

sidtheduck said:
I've noticed a growing trend (especially with shared hosting) that forces users to define their own session.save_path within the scripts (or .htaccess) so sessions are saved within access on a users own host (instead of the inaccessible shared locations above the users reachable root directory).

I believe that this is happening when hosts are upgrading the servers to php5. The default setting for session.save_path for php5 on most hosts is no value, while under php4 the default setting was /tmp. It seems they aren't setting the value when configuring the server initially, and don't do anything until someone complains. If they have to restore the server after a crash, the setting goes back to no value, and doesn't get fixed until another complaint is filed.

I spent 8 hours back and forth with the support techs for one of my webhosts, trying to resolve the missing session.save_path value issue, while attempting to switch my account over to php5 via .htaccess. I ended up having to tell 3rd level tech support that they needed to set the session.save_path value to /tmp on my server to resolve this - they kept saying they couldn't reproduce the issue.

I agree that we need to check whether sessions are working right or not, and give a warning to the user that they need to contact their webhost if sessions aren't configured properly. Would we want to recommend they stop the install at this point until their webhost fixes the issue? Or do we want to include code to set the session.save_path manually in the script if no path is found?

[sidtheduck]

I think we should prompt them to work with their webhost or manually set their own session.save_path in plog-globals.php [session_save_path('path/to/session/directory');] as most of the time you would preferably want this in a folder above the root directory.

If the Plogger script tries to set it automatically, the session files will be stored somewhere within the Plogger file structure itself (and always in the same spot). This worries me for possible hacking attempts if they know exactly where the session files are located.

[sidtheduck]

I think this needs to be incorporated into the install / upgrade process, so I'm bumping it up to "blocker" status for milestone 1.0.