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.

[sidtheduck]

Attached is a patch for the install / upgrade rework which includes better requirement checking for session variables (or I hope it does). In addition, the installation / upgrade should now be fully translatable (in case the user fills out their config file prior to running the installation or upgrade script). There is much more error reporting and fallback measures as well as better requirement checks, file structure checks, etc. Including all of this additional enhancement has made the files a bit more of a beast than before. It can probably use some streamlining in the future, but it should get the job done for now and allow other users to test the new code which should clear up quite a bit of issues that are a common occurrence on the forums.

Also included in the patch are some miscellaneous fixes for some bugs that have come up included the translation for exifer1.7, hyphens instead of underscores for cruft-free URLs, etc. I still need to work on the commenting and CAPTCHA as it no longer works in the current code before we release for the public.

Anyway, happy testing and let me know if you find anything that needs fixing! Hopefully we can get this out the door soon!

[sidtheduck]

I've also added new input fields so the user can add their own username and password during install instead of the default 'admin' and randomly generated password. This is committed into the current codebase, but I believe kimparsell has some additional changes to the new input fields for display / layout purposes.

[kimparsell]

My changes were been committed in  rev593.

I've tested out the new code and the install process works fine.