I’ve had this problem for a while now. I’m happily working away on my Windows PC, editing posts, changing code and testing and then out of the blue comes a Fatal error: Cannot redeclare message.
But when I press Enter or refresh it goes away.
I wish I knew the true cause of the problem.
Example output
Fatal error: Cannot redeclare bw_thumbnail_full() (previously declared in C:\apache\htdocs\wordpress\wp-content\plugins\oik\shortcodes\oik-attachments.php:72) in c:\apache\htdocs\wordpress\wp-content\plugins\oik\shortcodes\oik-attachments.php on line 90
Clues as to the source of the problem
- The file names look remarkably similar, except the drive letters are different
- I checked my debug log. For this WordPress install, of the 190 cases since March this year, 131 of them show that the only difference between the file names is the drive letter, where one is lower case and the other is upper case
- Sometimes the lower case file is loaded first, other times it’s the upper case one
- In all instances the file is a symlinked file
I’ve noted similar problems where my file name anonymizing routine sometimes doesn’t work, leaving the C:\apache\htdocs\wordpress or c:\apache\htdocs\wordpress at the start of the file name, when ABSPATH is C:\apache\htdocs\oikcom.
Sample trace output
Output from my trace routine indicates that
the symlinked files are referred to with a lower case drive letter ( c:/apache/htdocs/wordpress/wp-content/plugins/oik-bwtrace/includes/bwtrace.php )
but ABSPATH sees the drive letter as upper case ( C:\apache\htdocs\oikcom/wp-content/mu-plugins )
This could be the reddest of herrings.
I hope the forward slashes or backslashes aren’t part of the problem.
Aha, I’ve just seen (14th Sep 2015) this… TRAC #33265 Now I’ll have to see if the problem persists with this fix applied.
First off, I’ll just revert my wp-config update where I lower cased ABSPATH
and will try this which does the opposite – capitalizing the drive letter.
In fact, I’m going to try this
[bw_api]
if ( !defined(‘ABSPATH’) ) {
$abspath = dirname( dirname( dirname ( dirname( dirname( __FILE__ ))))) . ‘/’;
$abspath = str_replace( “\\”, “/”, $abspath );
if ( ‘:’ === substr( $path, 1, 1 ) ) {
$abspath = ucfirst( $abspath );
}
define( ‘ABSPATH’, $abspath );
}
[/bw_api]
Related problems?
I’ve also been plagued by the opposite problem.
Warning: fopen(C:\apache\htdocs\oikcom/wp-content/plugins/oik/oik.php): failed to open stream: No such file or directory in C:\apache\htdocs\oikcom\wp-includes\functions.php on line 4308
Again, this could be a symlink problem or the fact that I’m using an ABSPATH that’s got backslashes in it.
And every now and then [api wp_register_plugin_realpath()] throws a wobbler when it somehow determines that $plugin_realpath is null!
wp-includes/plugin.php(708:2) wp_register_plugin_realpath(1) 15 2015-10-19T17:10:30+00:00 0.289689 0.262612 cf! 5 0 19872768/19935912 F=160 1 C:/apache/htdocs/oikcom/wp-content/plugins/oik/oik.php
wp-includes/plugin.php(708:2) wp_register_plugin_realpath(2) 16 2015-10-19T17:10:30+00:00 0.290755 0.001066 cf! 5 0 19872768/19970112 F=160 wp_plugin_paths Array
(
[C:/apache/htdocs/oikcom/wp-content/plugins/bbboing] => C:/apache/htdocs/wordpress/wp-content/plugins/bbboing
...
[C:/apache/htdocs/oikcom/wp-content/plugins/oik] =>
)
Interim conclusion
I started writing this post in September 2015. I thought I’d be able to find an explanation of the problem by now. But I haven’t. However, I have been making code changes, and felt it’s time to log the reasons for these changes, even when they aren’t well founded.
I have therefore raised or will be raising a number of Issues
- Better setting of ABSPATH when not already defined bobbingwide/oik#6
- wp_register_plugin_realpath() setting $plugin_realpath to null
Post WordPress 4.4 update ( 14 Dec 2015)
I’ve just updated one of my development environments to WordPress 4.4
and got another Fatal error: No such file or directory, for a Genesis theme framework file.
It happened some time while processing the following requests.
- wp-admin/post.php
- wp-admin/admin-ajax.php heartbeat
- wp-admin/post.php?post=20338&action=edit&message=6
- wp-admin/admin-ajax.php?action=oembed-cache&post=20338
- oik_pluginversion/oik-read-more-v0-2-11
- wp-admin/admin-ajax.php heartbeat
- wp-admin/admin-ajax.php?action=edd_load_dashboard_widget
- wp-admin/admin-ajax.php wp-remove-post-lock
Unfortunately, I was only tracing normal requests, not AJAX requests and during the 4.4 upgrade my additional trace calls I’d added to core functionality were removed.
I’m going to have to re-introduce them earlier than I’d envisaged.
At least this time I’ll be working in a version controlled environment!