Make WordPress Core

Opened 16 years ago

Closed 15 years ago

#7388 closed defect (bug) (invalid)

zend.zel_compatibility_mode=on causes fatal error in taxonomy.php

Reported by: humbertocruz's profile humberto.cruz Owned by:
Milestone: Priority: normal
Severity: blocker Version: 2.7
Component: Taxonomy Keywords:
Focuses: Cc:

Description

Try to install Wordpress later than 2.2.1 on GNU/Linux server, this enabled directive on the php.ini file cause just a blank screen before the installation process. This happen on a GNU/Linux RedHat 4 server. The directive zend.zel_compatibility_mode is off by default, but it was on on this server and I don't find any reference or information to help to find it out.

Change History (12)

#1 @santosj
16 years ago

WordPress should have no issues running with zend.zel_compatibility_mode = on, since it runs on PHP4.

The directive causes more problems than it is worth and if you can convince your host to turn it back off, it might help you.

#2 @santosj
16 years ago

  • Keywords reporter-feedback added
  • Resolution set to fixed
  • Status changed from new to closed

Suggest closing as invalid or wontfix, since not enough information is provided, issue is based off server configuration, possible fix would require major work.

Turn on display_errors, if it isn't already, and report what you see.

#3 @santosj
16 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#4 @matt
15 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

#5 @jacobsantos
15 years ago

  • Keywords reporter-feedback removed
  • Milestone 2.7 deleted

#6 @Brainiac361
15 years ago

  • Cc Brainiac361 added
  • Component changed from General to Taxonomy
  • Priority changed from low to normal
  • Resolution invalid deleted
  • Severity changed from normal to blocker
  • Status changed from closed to reopened
  • Summary changed from zend.zel_compatibility_mode = on cause a blank screen on wordpress to zend.zel_compatibility_mode=on causes fatal error in taxonomy.php
  • Version set to 2.7

I had the same issue when trying to install WP 2.7 (apache2, php5).

PHP: "Implicit cloning object of class 'stdClass' because of 'zend.ze1_compatibility_mode'" (/wp-includes/taxonomy.php line 22)

The error is quite elusive though in ways that don't really make sense to me. For example disabling the line "$wp_taxonomies = array();", that should do nothing, fixes it. So does adding a var_dump for the variable after that line.

#7 follow-up: @hakre
15 years ago

I guess this is related to the bogus PHP4 references implementation on object variables. So I would guess it would help much to figure out, wether this is a problem with current PHP installations because the WP Code in this file is soooo legacy, that it is over now - or - this is just a configuration Issue on a Server.

Genereally I would say that it is a question (no flame wars here, please) which version we as Devs can Tag as PHP5 only sothat such bugs can be removed with ease.

#8 @DD32
15 years ago

which version we as Devs can Tag as PHP5 only

For reference, Matt said he will not support PHP5-only until only a small minority still run PHP4 (Something says the figure was less than 10% when consideration would be thought of). Cant quote source though.

So no version as such, just whatever release WordPress is up to at that point in time.

#9 in reply to: ↑ 7 ; follow-up: @Brainiac361
15 years ago

Replying to hakre:

I would guess it would help much to figure out, whether this is a problem with current PHP installations or this is just a configuration Issue on a Server.

Our php installation is up to date. I wouldn't know of any special configuration on our server - it's quite the usual LAMP.

If this isn't easily fixable, I would at least suggest some kind of hint to disable the compatibility mode on php5 in the installation manual. That would have saved me about five hours.

#10 follow-up: @hakre
15 years ago

Can you provide a hint since which WordPress release you encountered the problem first? Was anyone able to reproduce it?

For documentation purposes, I suggest you post it on your own blog and/or create a page in Codex. I put a lot of usefull stuff on my user page in codex. Especially for those things which can not be easily solved with patches.

What kind of PHP Error is it? Notice? Warning? Fatal?

I put this Code-Fragment into wp-config.php to be able to test bleeding AT-ALL:

/**
 * error_reporting_unstrict
 *
 * Disable Strict Errors if applicable because wordpress
 * is not php 5 strict compatible.
 */
function error_reporting_unstrict()
{
	// check if E_STRICT does already exists
	if ( defined($name = 'E_STRICT') === FALSE )
	{
		return;
	}

	/* 
	 * Change Error-Reporting by only removing
	 * the E_STRICT 
	 */

	// Read out current Error Reporting value
	$orig = error_reporting(0);
	error_reporting($orig);

	// If E_STRICT is set, unset it in the bitmask
	if ( $orig & E_STRICT )
	{
		// Unsetting E_STRICT from bitmask
		$changed = ($orig ^ E_STRICT);

		// Set the changed Bitmask
		error_reporting($changed);
	}	
}

// Disable Strict Errors //
error_reporting_unstrict();

it dynamically removes the E_STRICT errors. At list with those disabled with the recommended PHP 5.2.latest-stable it does a good job. I dunno wether or not I have that zend.setting reported here en- or disabled.

I hope this infos can help.

#11 in reply to: ↑ 10 @Brainiac361
15 years ago

Replying to hakre:

Can you provide a hint since which WordPress release you encountered the problem first?

Sorry, on that server 2.7 was the first install of wordpress. My predecessor obviously found it in 2.2.

Also sorry for the other suggestions, but we're using Wordpress for a public corporate webpage and there's people expecting it to be online, so I can't really go and experiment on it any further. Nor can I post any off-topic issues.

However, the error results in a blank page (got the message using error_get_last), so it cannot be just a notice or warning.

#12 in reply to: ↑ 9 @hakre
15 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

Sorry for being not so correct with the naming of the error classes, i only meant, that you can get a white page if there is an error. And that's it.

Anyway, since this looks like a configuration Issue to me, and it can be solved by changing the setting in the php configuration, I would strongly suggest to close this Ticket.

Anyway, it is not a Bug it is more a Feature Request to support a certain configuration. I will classify it now as such and set it to invalid.

Replying to Brainiac361:

If this isn't easily fixable, I would at least suggest some kind of hint to disable the compatibility mode on php5 in the installation manual. That would have saved me about five hours.

I created a checklist: http://codex.wordpress.org/User:Hakre/Technical_Installation

Note: See TracTickets for help on using tickets.