Logins fail after updating to 1.6.03

[aldrichtm]

I've reviewed all the 1.6x upgrading posts and done too many searches (not just in 1.6), and after trying a number of suggestions I'm still not able to login. I was running 1.5.32 before our PHP was updated to 7.0.22. [Side note, PHP7 is required for the current Wordpress, which is probably why providers have upgraded to 7.]

This is the gallery I'm trying to login to. http://www.strategicon.net/photo_galleries/index.php

From the admin side of things...
Once I followed the steps to get things to use mysqli, the update.php was saying everything up to date, but the check versions didn't work and when I tried to login I got a blank page.
Now, when I try to run update.php I get this error "Could not authenticate you". No Apache errors. The user record exists and is an admin.

From the album website...
Everything looks and works like it did when I last saw it working (a year ago), until I try to login. Then I get the blank page. No Apache errors.

Not that I believe I'm using any, but I renamed the plugins directory, as suggested.
I don't use any bridges.
The only configuration I can think of that was done outside the admin pages is a custom header and footer referenced in lang/english.php. And nothing changes when I remove it all.
Hope you can help.

[ron4mac]

Which method did you use to update your site files?

[aldrichtm]

You might want to assume I did them all. Let's see what I can remember, I've been working on this on and off for over a week.
upgrader.php version 1 and 2, and cpg_installer_stub.php
When all those failed even after getting ZipArchive installed, I believe I found a reference to doing a standard manual update. Really wish that had been emphasized as the safest approach.
Did the manual update.
Ran update.php.
At some point, the mysqli problem got resolved, but I don't remember when.
At some point, I had to chown the files that cpg_installer_stub.php managed to copy over as www.
And, finally discovered the database user password had changed. Fixed that.
Ran the update.php at least twice. First time got a list with a few green check marks. Second time all green.

[ron4mac]

If you are able to modify the database, set debug mode:

In the _config table, find the entry for debug_mode. Change its value to 1.

[phill104]

Just as a point of order for others, the latest Wordpress will work with PHP 5.2.4 upwards. With PHP 5.6 still over a year from end of life it is frustrating many that the Wordpress team are not being quite as clear as they should be.

As for your site, did you check everything was working before the upgrade, and do you have backups?

[aldrichtm]

debug_mode set to 1. Now what?

Can't change the PHP version.

The whole reason for the upgrade was because the site hasn't worked since we upgraded our PHP. Before that as far as I know it was working.

I have backups. What did you have in mind?

[ron4mac]

I was hoping that setting debug mode would cause whatever error is occurring to be displayed.

My feeling is that there may be a corrupt file there somewhere.

You may have to agree to let us (me) have access to your cpanel (if that's what you have).

Another option is to make a change to include/debugger.inc.php.
At around line 55 in the file, make this change (comment out 1 line):

Code Select Expand

            if ($phpver < 43) {
                $this->old_handler = set_error_handler('cpg_error_handler');
            } else {
//                $this->old_handler = set_error_handler(array(&$this, 'handler'));   // <- comment out this line
            }

That may cause the error to be displayed.

[aldrichtm]

Ah-hah!

Notice: Undefined index: auth in photo_galleries/update.php on line 97
Line 97:
if (!defined('SKIP_AUTHENTICATION') && !$_SESSION['auth']) {

Notice: Undefined variable: CONFIG in photo_galleries/update.php on line 296
Could not authenticate you.
Line 296:
echo $lang_update_php['could_not_authenticate']. '. '.sprintf($lang_update_php['provide_admin_account_dbase'], $CONFIG['dbname']).'. <a href="update.php">' . $lang_update_php['try_again'] . '</a>.';

So, does my update.php need updating, or is it something else?

I'm running purely command line or via php for debugging.

[ron4mac]

I'm quite sure your update.php is okay ... it's something else.

I advise you to not run things from the command line/php ... it may cause permission or ownership issues with files. You should only be accessing the scripts using a web browser.

[aldrichtm]

I use a browser for scripts that run on a browser, like Coppermine's. But for the upgrader/cpg_installer_stub, that actually caused ownership issues. My Coppermine files are owned by the account, not www. So I had to switch all the files the upgrade added back to the account in order for Coppermine to access them.

There is no cpanel, editing and viewing files, and viewing the database is via command line.

I'm willing, within reason, to install tools in the account that might help, provided they don't require root or admin access.

[ron4mac]

If you'll install the attached file in your root or CPG directory it will allow me to browse your setup.
Don't place it there as filemanager.php ... name it something else. Then let me know its path and name so that I can access it.
If you can't PM me, email me at ...

[ron4mac]

I really believe that, since you're running ubuntu with no cpanel, all the files and folders in /home/stratcon/Domains/strategicon.net/ should belong to www-data:www-data instead of stratcon:stratcon.

Without the files owned by the web server:
1) you can't upload files
2) you won't be getting any logging
3) you have to have files (such as include/config.inc.php) world writeable .. not a good idea.
4) CPG may not run properly 

[ron4mac]

Thinking about it more ... the login failure may be coming from CPG not being able to write the log file (in logs/) because of the ownership/permission issue.

[aldrichtm]

I'm willing to consider changing the ownership on the Coppermine files. Do the permissions change?

[ron4mac]

Thinking about it more ... the login failure may be coming from CPG not being able to write the log file (in logs/) because of the ownership/permission issue.

Well ... you changed the ownership on logs/ and that didn't solve it.

Here is what has to be solved ... an error is occurring but not being displayed or logged. Your php has no log file name set, so it will not write the error to a log file. Perhaps if that could be changed we can see what the error is. Without knowing how it is failing, it's going to be near impossible to resolve.

[aldrichtm]

Trust me, I know about untraceable errors.
So, how do we set a file name for the log file?

I'm willing to change the Coppermine file ownership, but I have to wonder what changed between versions that would suddenly require www-data ownership to work. And it's only the management side of things. The site is very viewable.

[ron4mac]

So, how do we set a file name for the log file?

Since PHP is running as an Apache module, you'll have to do it in a .htaccess file.
Create the file .htaccess in your CPG root directory.
Add these lines to it:

Code Select Expand

php_flag display_errors on
php_value error_log php_error.log
php_value error_reporting -1


You'll likely have to modify include/debugger.inc.php (more) at line 48:

Code Select Expand

                $this->old_error_logging = ini_set('log_errors', 1);

And, you'll have to let the web server own the CPG directory (www-data) so that it can write the error log.

[aldrichtm]

Changes made. I'm still not seeing the error log, though I'm not entirely sure where is should be?

I don't suppose something needs to be done in Apache itself in order for the .htaccess to be read?

[ron4mac]

The .htaccess file has no effect.

And, because you changed ownership in there, I was able to add a php.ini in the CPG directory to try to coerce some more error reporting. That had no effect either. Your host has things tied up pretty tightly. You may have to request their help to get sufficient error reporting.

Also, at this point, with ownerships set, I personally would be tempted to try the cpg_installer_stub again.

[aldrichtm]

Re-ran cpg_installer_stub, still can't log in.