WP 2.8 Issues

[Anonymous]

Hi,

I’ve noticed that slimbox 2 hasn’t been working since the wordpress 2.8 update. Any word on when you think it may become compatible again with wp?

Thanks,
Mark

[malcalevak]

Mark, firstly, start a new thread, or post in a thread that’s specifically related to your issue, instead of posting in an old unrelated one.

As for your issue, the plugin site and several others are using the plugin without any problems (and the few problems that have been reported are extremely minor).

Please provide a link to your site, and as much detail as possible related to the issues or I can’t fix your problem.

[Anonymous]

I too have had noticed that the plugin stopped working for me since I upgraded to 2.8+

skateandannoy.com

Here’s a sample post – http://skateandannoy.com/2009/10/22/birthday-bs/

[malcalevak]

I’m taking a look at it now. I’m not sure why, but for some reason the http://skateandannoy.com/wp-content/plu … oad.js.php keeps showing up as not found, though it does show in the directory listing.
I’ll see if I can figure out what’s causing the problem.

[malcalevak]

I think for some reason (probably because it’s a .php files) your site is treating the autoload script as a regular WP page.

Just to humor me, could you switch your permalink settings to default and test the page? You don’t need to keep it that way, I just wanted to test a theory.

I think whenever I get around to my final release I’ll likely revise my code so that the javascript is regular javascript, and makes a call to grab the settings. This will hopefully solve the issue.

In the mean time, if you want to at least have it working, a temporary fix would be to hardcode a copy of the JS. Any changes you make would have to be hardcoded each time as well.

Let me know if you want to do that.

[imported_Ryan]

I think we need to alter the way we load our settings for the javascript files. The way we are both doing it in our plugins is flawed. We are loading wp-load.php inside our javascript files (or at least I think you are), whereas what we should be doing, is sending the specs for how the file is to be displayed via some other means rather than loading WP in it’s entirety then extracting database info. and using that to decide what code to spit out.

A cleaner method which we could use, is to send those settings via the URL, so something http://bla.com/wp-content/wpslimbox2/sc … tting2=moo etc.

This would improve performance (since not loading wp-load.php) and prevent what looks like a weird clash with WP occurring.

This won’t work with some things such as CSS files as the data required to be moved is too large to be stored in a URL, but for simple javascript file changes this should work fine I think.

[imported_Ryan]

I’ve also noticed that some very poorly configured servers tend to take a [b:3c8sm408]really[/b:3c8sm408] long time to load files which include wp-load.php. They’re fine once the files are cached, but on initial page load those files take a ridiculously long time to load on those poor servers (10+s per file). This doesn’t affect many users at all since most use reasonably good shared hosting, but it seems to affect many people who are managing their own servers (and presumably are doing something wrong) or those on very poor quality hosts like GoDaddy (I’ve seen a few examples of this problem on GoDaddy hosted sites).

[malcalevak]

Kilwag, you haven’t responded back, but if you happen to see this, for the sake of testing, try this version of the plugin: http://simonwheatley.co.uk/temp/0911/wp-slimbox2.zip

It’s a modified version by Simon Wheatley, I don’t have a clue if it would actually solve the problem, but I figured it was worth a shot based on what Ryan described.

[Author]

Posts