Forum Replies Created

Viewing 15 replies - 1 through 15 (of 106 total)
  • Plugin Author MikeSoja

    (@mikesoja)

    New version uploaded. Eliminated test for PHP_MAXPATHLEN, which will affect users of PHP earlier than 5.3

    Plugin Author MikeSoja

    (@mikesoja)

    Thanks for the heads up, jrsjohn and bhagwad.

    Still don’t know why PHP_MAXPATHLEN doesn’t work.

    Plugin Author MikeSoja

    (@mikesoja)

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

    Plugin Author MikeSoja

    (@mikesoja)

    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)

    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)

    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.

    Plugin Author MikeSoja

    (@mikesoja)

    Hi, jrsjohn,

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

    Plugin Author MikeSoja

    (@mikesoja)

    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. 🙁

    Plugin Author MikeSoja

    (@mikesoja)

    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)

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

    Plugin Author MikeSoja

    (@mikesoja)

    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.

    Plugin Author MikeSoja

    (@mikesoja)

    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)

    Haven’t looked at that code for some time. 😉

    Sounds like a browser hiccup, but I do see room for improvement. Will add it to the list.

    Plugin Author MikeSoja

    (@mikesoja)

    wp.Man!

    I *may* have this figured out. I don’t know because I can’t test your problem, but it could be in the different way that PHP and mySQL deal with dates. I read up on the mySQL “date” type, and found out that it would automatically do what I was trying to do from the PHP side. In most cases it worked, but maybe in some cases it didn’t.

    I’d point you to the file changes, but I’ve got so many changes in multiple files that it all has to go at once. Several new features. I might get it out tomorrow, but there is still a lot of testing.

    Hope you’re hanging in there.

    Plugin Author MikeSoja

    (@mikesoja)

    There ya go. It works in early testing, but with a small side effect.

    If, like I do, you keep one window open to the Main Panels, and another for Sequential View, then a “Load Latest” in one page will change the value for the other, meaning it would be possible to miss some entries in the other page as you switch between them. The workaround would be to write two separate values to the WordPress Options table, and I already feel bad about writing one. However, I doubt it’s a problem that many people will be unable to cope with, so I’ll leave it at that.

    If you want to test the change, retrieve ecstatic.php and ecstatic_interface.php from the trunk in the WordPress repository and copy them over your existing files.

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