1.2.2 worked. 1.3 does not work for me…

Please explain what exactly doesn’t work and provide a link.

What version of WordPress are you on?
Have you made sure all settings (for the jQuery Lightbox plugin) remains?

I forgot to include the language files! Version 1.3.1 is available in a few minutes. Sorry. ??

IE also does not work properly 1.3.1.
v1.2.2 version of this plugin is working directly on my site. but dont work 1.3.1

1.3.1 speed opened images but dont work ?? with ie

What version of IE?

It works in IE 8 and IE 9 – both with and without compatibility mode.

ie7 and ie 9 ? try will not open files in the order maybe how to use dont make just throw the plugins folder and activate the 1.2.2 works fine this way. 1.3.1 is not working properly

I don’t understand what you’re saying. I don’t have IE7 and can’t replicate your problems.

Many JavaScript optimizers, combiners, minifiers, etc. conflict with the wp_localize_script() function which is new to this version. The reason is that the “wp-jquery-lightbox” handle is dequeued and replaced with a plugin-generated handle for the combined and/or minified .js file. So, wp_localize_script never sees the “wp-jquery-lightbox” handle that it is watching for, and, as a result, never prints the localized JQLBSettings settings. This results in a JavaScript runtime error which effectively disables the lightbox functionality. Since I use the Optimize Scripts plugin, I had to write a three line filter function to exclude jquery.lightbox.min.js from being optimized. (I could also have disabled optimization in the admin panel; but the filter method is more robust.) forumcu may be experiencing a similar issue. At any rate, this behavior is probably worth mentioning in the readme file.

? dont make because some know english

brianwhite but 1.2.2 good working

Many JavaScript optimizers, combiners, minifiers, etc. conflict with the wp_localize_script() function which is new to this version.

wp-jquery-lightbox has relied on wp_localize_script() since the very first release – nothing new about it. ??

However; your claim that combiners cause problems for many plugins mirrors my experiences, though I haven’t had time to look into why it is so. Your theory makes sense, but I thought I’d been very careful with making sure the JavaScript does not rely on the JQLBSettings-object being available. It always checks that it’s defined before using a value, and provides safe fall backs if it isn’t.

Could you specify what properties the script is trying to access that isn’t available to it?

Also; the filter solution you mentioned – is it something I could provide with the plugin to prevent these issues in the future?

Ah. The strings have been migrated to the JQLBSettings-object, and is indeed not checked before use. I’ll adjust the script and upload to trunk for you to try.

Sorry about the confusion. I should have looked more closely at the code before posting. As you discovered when I was away from my computer, the strings aren’t being defaulted if JQLBSettings is not available. The only sure ways to be optimizer/combiner tolerant are to 1) echo your configuration JS directly in a function hooked to wp_head() or 2) write the settings to separate .js file in the file system and enqueue that before the plugin’s main .js file. I use the following snippet to stop the optimize scripts plugin from concatenating wp-jquery-lightbox.js.

// Prevent optimize-scripts from optimizing/concatenating wp-jquery-lightbox.js.
function no_optimize_wp_jquery_lightbox($ok, $src, $parsedSrc = null) {
  if(!$parsedSrc)
      $parsedSrc = parse_url($src);
  return !preg_match('/jquery\.lightbox\.min\.js$/i', $parsedSrc['path']);
}
add_filter('optimizescripts_concatenable', 'no_optimize_wp_jquery_lightbox', 10, 3);

I don’t use W3 Total Cache so I’m not sure how to exclude a file from its optimizations.

BYW: jquery.lightbox.min.js is the only script in my footer and it is already minified so “concatenating” it just breaks the functionality with no benefit.

Thank you for taking the time!

This puts me in a weird position. I’m using the WordPress API as intended – letting WordPress decide where, when and in what way to configure the loaded JavaScripts. To forego this service (escaping, validation, sane output) and hardcode stuff in the header (on every pageload) just seems very pre-2.0… ??

The moment I start printing raw JavaScript in peoples page source is the moment I break validations and spawn Satan all over the place…

I’m partly of the position that “if you don’t adhere to the standard, screw you.” Meaning that this problem is on the developers of the combiner plugins. But I’m also a realist – this is causing problems for my users right now.

So what am I to do?

Couldn’t these plugins enque a bogus script with the original title, to allow wp_localize_script() to do its thing?

So what am I to do?

I think that you are doing the “right” thing in your approach/implementation/philosophy. There are fairly simple workarounds for people who use your our plugin and an ill behaved combiner; but it would be difficult or impossible to provide instructions on how to make your plugin work with all of them in the readme and keep them current. The problem affects any plugin which uses wp_localize_scripts(), you just happened to have some required data in which was not guarded for in v1.3. The ultimate solution is for JavaScript optimization plugin authors to take wp_localize_scripts() into account. Providing a filter or an administration panel whereby scripts can be excluded is not enough since users who are not developers will have a difficult time identifying the root cause and will think that a new or updated plugin is the issue. My custom filter plugin has five filters in it to make all of my plugins play well together and I do not use a lot of plugins. I can code in PHP so it wasn’t difficult; but, ultimately, developers of performance optimization plugins need to have a more user centric view.