Michael Scannell

Hi Bishal,

I don’t understand what you mean by “checking” and “replicating the issue”. This is not that sort of problem. It’s just an error in your PHP coding, and I only passed it on to you out of courtesy. Did you check in your own code?

The error occurs in this code:

function masonry_brick_dynamic_content_width() {
	global $post;
	global $content_width;

	$masonry_brick_layout_meta = get_post_meta( $post->ID, 'masonry_brick_page_layout', true );

	if ( empty( $masonry_brick_layout_meta ) ) {
		$masonry_brick_layout_meta = 'default_layout';
	}

At the time the function is called (it is hooked to ‘template_redirect’) the global $post doesn’t yet have the content your code is asking for. So at that time the ‘if’ clause would seem to be redundant.

I just thought you’d like to know!

Hi geoid. It turned out in the case of this particular Web site that it was using a version of PHP (5.2) that WordPress no longer supports. Upgrading the PHP solved the issue as far as the Site Admin was concerned.

Unfortunately, this caused the pages with WordPress posts to begin generating 500 errors. It took some time to sort this out, but the problem was eventually traced to a php.ini file which had been uploaded to the Web site to sort out a PHP problem a year or so back. Removing that fixed (and uneditable) php.ini meant that the site reverted to the server’s php.ini for later versions of PHP, so now everything is running as it should.

I have no idea if any of this will help you — but I do hope so!

I think the previous version of WordPress on this site was 4.3.

I began yesterday morning by using the automatic updater. It ran fine until it reached upgrade.php, then halted with a system error.

As I have already mentioned. this morning (24 hours after the automatic updating failure) I did a manual update, following to the letter the online instructions. This involved, among other things, deleting the existing wp-includes folder and uploading the brand-new one from the current WordPress download.

I really need help from someone who knows why the automatic update failed when it reached upgrade.php. And why upgrade.php is still causing a system error.

I tried again for you, Rajan V. I re-entered my password and it was accepted. I was directed to a blank page (in Firefox, with no system error flagged) and the URL https://www.afpocalpe.com/updates/wp-admin/upgrade.php?_wp_http_referer=%2Fupdates%2Fwp-admin%2F

Just like before. (In Chrome, the system error 500 was flagged, as I was sent to the same URL.)

Hi Rajan V. Thank you for your suggestions. There is no error log file. I searched myself, then used an FTP search. No such file found.

I have just an hour ago deleted the entire wp-admin folder and replaced it with a brand-new one from the latest version on the WordPress site. Still being directed to the same URL.

I have also tried logging in using a different browser (I use 4, for different things usually). In Chrome, which can have no cache or cookies because I had never tried to access the site admin for this site using Chrome before, I got this message:

“The https://www.afpocalpe.com page isn’t working
https://www.afpocalpe.com is currently unable to handle this request.
HTTP ERROR 500″

(The actual site is still working fine, including the WordPress posts. It’s only the site admin that fails as soon as I log in. (I’ve tried logging out and in.))

Can you help?

Thank you to marleendh. It’s useful to know that this is not because my client’s WordPress installation is private.

Have you put your own issue in this forum? Has anyone helped you solve the problem?

I myself have now carried out a complete manual update, following the WordPress instructions to the letter — only to get exactly the same problem when I try to access the site admin. Exactly the same weird URL over a bank page.

Can anyone help? My client is becoming restive.

James, thank you for that explanation.

While working on getting the installation back, I was thinking of the error messages as “historical”. I read them as saying, in effect, “it’s still not working.” But of course I was actually generating the error every time I refreshed the page, hoping that the Dashboard would appear. If I had stopped to think, I would have realised this.

It is even more obvious now how useless the cPanel “Error log” is, since none of this was recorded.

The real error messages in the server log may be of some general use, so as soon as I have the time, I will contact the people who run the servers and ask them to tell me what they can find for the AFPO Calpe site for the time in question.

Thank you again.

James, thank you for your continued interest.

The period covered in the log is the 5-hour period during which I was getting error messages. (The servers and I are in different time zones.) Every time I did something, I checked to see if I could access the dashboard, and got the error message.

The actual error would have taken place around the start of this time. I published the log because it is usually requested by people looking to help. I recognise that it is of little use..

The error occurred when the WordPress update script/program crashed. I had been looking at the dashboard when it disappeared. Trying to revive it, I got the first of the error messages (Internal System Error: 500)

There is no way that I could make the error occur again, since the update button is no longer on the dashboard (and I wouldn’t click on it if it were!)

As you will see from the end of my previous reply, I re-installed the whole WordPress setup from scratch, re-uploaded all the photos, and populated the newly installed database with the data from the previous database.

So my client’s problem is solved, as a a result of a lot of hard work on my part, but I still have no idea why the update program crashed.

As I said originally, we are using only one plugin (Akismet) and I created the theme myself. It is working perfectly well with the new installation of 4.4, and survived years of earlier upgrades—which suggests that it is compatible.

Thank you, Jeff. The server log I posted precisely covers the time during which the update script/program crashed, and I tried to access the dashboard.

Maybe you have clients who will wait 24 hours while you generate errors, and engage in a time-consuing online “chat” with for the people running your servers, but alas I don’t.

In the meantime I tried a manual update, following to the letter the official WordPress detailed instructions. To no avail. I still got system error 500s.

Eventually, I backed up thousands of photos (it’s a big site) plus the database, then destroyed everything in that area of the site and took out the database. After which I created a brand-new installation, then populated the brand-new database with the data from the old database, and re-uploaded the thousands of photos.

This worked, but I shouldn’t have had to do it. And the problem itself is not solved.