Fatal Error from ecSTATic

zcslee
(@zcslee)

12 years, 7 months ago

Hi, I just installed ecSTATic and this fatal error below “Fatal error: Call-time pass-by-reference has been removed in /home/olahuno/public_html/wp-content/plugins/ecstatic/ecstatic_tables.php on line 218” showed up. I can’t access my site and my hosting company tried to remove the plugin from the backend but it didn’t work. WHAT HAPPENED? WHY IS THIS PLUGIN KILLING MY SITE? Can anyone help?

http://wordpress.org/plugins/ecstatic/

Viewing 15 replies - 1 through 15 (of 22 total)

1 2 →

Plugin Author MikeSoja
(@mikesoja)

12 years, 7 months ago

I’ll have to do some research, but that line should only execute if you are running a PHP version less than 5.3. The pass-by-reference to the xml_set_object function was deprecated in PHP 5.3. It’s possible that the test for PHP 5.3 and above no longer works.

Which version of PHP is your host running?

Also, there is no reason that the plugin can’t be removed by your host, or by you via FTP.

I’ll get back to you

Plugin Author MikeSoja
(@mikesoja)

12 years, 7 months ago

The check for PHP_MAXPATHLEN, added to ecSTATic 0.91 in March 2011 in response to a change in PHP 5.3 should still work.

Either the variable PHP_MAXPATHLEN is not set by your hosts PHP with PHP > 5.3, or the ecstatic_tables.php file is corrupted.

To remove the plug-in, FTP to your /wp-content/plugins folder and delete the ecstatic folder.

Sorry, but that’s the best I can offer at this point.

Thread Starter zcslee
(@zcslee)

12 years, 7 months ago

Mike, thanks for your help. I’ll let my host know of what you wrote. They deactivated all my plugins so I ended up removing ecStatic and my site is functioning now.

Plugin Author MikeSoja
(@mikesoja)

12 years, 7 months ago

Really sorry for the trouble. I would appreciate seeing what your host writes, if they get back to you.

Thread Starter zcslee
(@zcslee)

12 years, 7 months ago

Ok, here’s the response:

What I can confirm for you is that the server that your on is running PHP 5.4.14 and not the version that developer is referring to. As far as PHP_MAXPATHLEN goes I’m not certain where this is supposed to be other than a setting within the plug-ins code. My initial thought it was supposed to be in the global php.ini file but there isn’t anything there. I’ve checked other servers here and its not a setting that is in a standard php.ini file.

As far as removing the plug-in I would agree that getting it off the server can easily be done by FTP. However, your WordPress even though the plug-in wasn’t present it was still labled as active. Which forced me to deactivate the plug-ins in order to get the site back up.

Being in a Shared environment we are limited as far as server changes go at a global level but if this developer recommends changing something we might be able to make modifications depending on what effect it has on the server.

Plugin Author MikeSoja
(@mikesoja)

12 years, 7 months ago

Thanks for the reply.

PHP_MAXPATHLEN is part of PHP’s Core Predefined Constants…

http://php.net/manual/en/reserved.constants.php

“These constants are defined by the PHP core. This includes PHP, the Zend engine, and SAPI modules.”

PHP_MAXPATHLEN (integer) The maximum length of filenames (including path) supported by this build of PHP. Available since PHP 5.3.0.

It’s not listed in the global php.ini file, because it’s defined in the core, somewhere. It’s not a setting, but a hard coded constant.

However, for some reason, it’s not being defined in your host’s environment, though I can’t speculate why.

I’m also not sure why removing the ecstatic folder from the WordPress plugins folder didn’t automatically fix the problem. If the code isn’t there, WordPress can’t load it.

As far as ecSTATic goes, if you’re still interested, you can delete the & in line 218 of ecstatic_tables.php, turning &$ecstatic_parse into $ecstatic_parse, making lines 216 and 218 identical. (Or, just delete lines 215, 217, and 218.)

I will also see about adding a secondary check to ecSTATic to work around the problem.

Thanks, again. Let me know if there’s any more info that I can work with.

Plugin Author MikeSoja
(@mikesoja)

12 years, 7 months ago

Whoops.

The problem could very well be with line 215 in ecstatic_tables.php.

if (defined(PHP_MAXPATHLEN))

should be…

if (defined(‘PHP_MAXPATHLEN’))

… with single quotes.

It worked for two and a half years. 🙁

jrsjohn
(@jrsjohn)

12 years, 7 months ago

Hello;
I am getting a error. [The website encountered an error while retrieving http://pawsraboard.com/house/wp-admin/plugins.php?activate=true&plugin_status=all&paged=1&s=. It may be down for maintenance or configured incorrectly.
Error code: 500)]

I just started get this when I installed WP 3.6. It is running still on 8 other site on the same server.

Plugin Author MikeSoja
(@mikesoja)

12 years, 7 months ago

Hi, jrsjohn,

Not sure what to make of that. What other plugins are installed?

jrsjohn
(@jrsjohn)

12 years, 7 months ago

It is a new demo site with Akismet and Hello Dolly listed in the plugins. I found two site on the server still running WP 3.52 and it loaded fine. It may be WP 3.6?

Plugin Author MikeSoja
(@mikesoja)

12 years, 7 months ago

WordPress apparently made some changes in the way their wpdb functions work in 3.6, and that may be causing problems some problems, though I haven’t seen that particular error message. I need to put a new version out, but have to do a little more testing.

frenzi
(@frenzi)

12 years, 6 months ago

mIKE LET ME KNOW If you need my help this plugin looks great by myself too facing this issue let me know i can help in testing

Plugin Author MikeSoja
(@mikesoja)

12 years, 6 months ago

Hi, frenzi,

Are you getting the same error as jrsjohn? Does it go away if you Deactivate or Delete the ecSTATic plugin? I’m not seeing it on any of the blogs I run with WordPress 3.6.

The change in the WordPress wpdb functions only throws a Warning, and comes from calling $wpdb->prepare() without one of the parameters. In ecSTATic, the warning is thrown for db queries where the $wpdb->prepare() function isn’t really necessary, and I’ve been changing statements to eliminate the call.

Plugin Author MikeSoja
(@mikesoja)

12 years, 6 months ago

ps. I guess some people started seeing the $wpdb->prepare Warning with WordPress 3.5, but I’m only seeing it with 3.6.

Plugin Author MikeSoja
(@mikesoja)

12 years, 6 months ago

Just sent new version to WordPress repository. Should be available soon.