Fatal Error

This is line 652 in the core.php:

require_once( self::get_core_dir() . ‘/lib/class-itsec-lib-directory.php’ );

@lparetti

Make a backup copy of the core.php file.

Then remove the leading ‘/’ from ‘/lib/class-itsec-lib-directory.php’ so it looks like this:

require_once( self::get_core_dir() . ‘lib/class-itsec-lib-directory.php’ );

Does that make any difference ?

@lparetti

If it does it will probably fail on the next similar require_once() command …

So I figured to instead make a modification in the get_core_dir() method:

return self::get_plugin_dir() . 'core/';

to:

return self::get_plugin_dir() . 'core';

Turns out the result of the get_core_dir() method is concatenated with strings starting with a slash as well as with strings NOT starting with a slash … (what a mess).

Still a better option to test this new modification since the get_core_dir() method concatenates with strings starting with a slash (far) more often. So even with this new modification it will still fail somewhere further down the stack …

Anyway perhaps we should focus on why this is failing in your env while it works fine in other envs. Could be Windows specific … Perhaps related to the PHP/Web Server version being used …

Oh I should mention that mixing the directory separator (\ and /) in a path is no problem. PHP can deal with that on a Windows platform. It’s the // I’m focusing on.

Hi Pronl,

Thanks for the replies. I have put a copy of the site on one our demo servers and activated the ithemes security plugin with the same features yesterday. The demo site has yet to crash.

We have other sites with the same plugin though maybe a bit out of date. But the same paths and files exist with the same code and those sites don’t crash. These are also on a different production server. The site that is crashing is on our newest production server and it is the only WP site on it.

One thing I noticed yesterday, I was browsing the site and it was not rendering properly. The drop down menus at the top were gone. I tried multiple browsers, but the site did not render correctly again until I recycled the app pool.

I was going to wait for the site to crash again to see if the same exact error occurs.

Another thing to note, and I don’t know if this could be the cause, we activated the security plugin on the production site before running the search and replace to change it to the correct production host name.

@lparetti

List all servers with:

• OS
• PHP version
• Web Server (version)
• PHP directive open_basedir set or not.

Particularly interested in the info from the newest production server.
The one generating the 500 internal server error.