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: | 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)
#2
@
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.
#6
@
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:
↓ 9
@
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
@
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:
↓ 12
@
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:
↓ 11
@
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
@
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
@
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
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.