Thickbox images not loaded in best way

[lmbbox]

With 2.5, you have added thickbox. In the first lines you set the image urls as relative paths. This causes an issue, if a theme includes WordPress's thickbox library, with the images. Instead of setting in /wp-includes/js/thickbox/thickbox.js on lines 8 and 9 from:

var tb_pathToImage = "../wp-includes/js/thickbox/loadingAnimation.gif";
var tb_closeImage = "../wp-includes/js/thickbox/tb-close.png";

to:

var tb_pathToImage = "/wp-includes/js/thickbox/loadingAnimation.gif";
var tb_closeImage = "/wp-includes/js/thickbox/tb-close.png";

This will allow unmodified access to the library.

[zamoose]

-1. Absolute paths are no good. You'd need to include {blog root}/wp-includes/yadda-yadda in the JS instead.

[chrishajer]

Why was this closed as wontfix? This issue still occurs on 2.8.1, and the theme is including the proper core /wp-includes/js/thickbox/thickbox.js, but in that file, the path to the images is hard-coded as ../wp-includes/js/thickbox/loadingAnimation.gif and ../wp-includes/js/thickbox/tb-close.png. That makes the path relative to the current page, which results in a 404 error depending on the page slug (sometimes it works if you go ../ from the current page permalink.) I can modify those two lines in the core file to make this work, but I think it should be fixed properly.

Thank you.

[TobiasBg]

I agree, that this not the optimal way to load those images, as more and more people use the included JS-libs in WordPress (I personally use the thickbox for a gallery, which is located on several subpages, where therefore the "../wp-includes/js/..." path is not working. And changing it manually to "/wp-includes/js/..." only works for WP installation not in a sub folder.)

Therefore I'd like to make two maybe better suggestion to load those images:

1.) This actually derived from Denis' answer: If we need the {blog root}, just let's get it: From a wp_localize_script call which will then give it to us just like a localized string.

2.) Even better would be CSS: We load the thickbox.css anyway, so why not move the paths there? They could even stay relative to the wp-includes folder, like they are now.
To then show them, we add a CSS class to the relative places in the JS file. So instead of loading them directly we just put them as background images of a <div> with a CSS class. That way nobody will ever have to touch those paths again as they work from anywhere on the site if the thickbox.js and thickbox.css are included correctly.

Do those suggestions make sense?

Maybe their implementation could be done in one step together with #10278 which deals with localizing the thickbox.js.

[azaozz]

Thickbox is an external unsupported package and many things need fixing there. Perhaps we have to decide if we want to "take over" and maintain it or replace it. There are couple of other similar scripts we could switch to.

[chrishajer]

If it's included with the WordPress installation, I think it should work. If it works when called from within WordPress, but not themes or plugins, I can understand the issue. If it can be made to work in all instances, then we should do that. If we shouldn't be calling the included WordPress thickbox.js from a plugin or theme, then just make that clear. But it's used in a fashion similar to how jquery is being used, call the version included in WordPress, don't ship a new version with your plugin or theme.

Thanks for discussing the issue.

[xavivars]

This is an annoying bug, because we can't use Thickbox in our themes...

I hope it is fixed soon ;)

[21cdb]

This bug is really annoying! Why not fix it when there is already a solution?
The best way would be to apply the images via thickbox.css. With this method it is also possibe to style the plugin whatever look you want without touching the core thickbox.js!

We also would like to see #10278 implemented in thickbox.js!

[hakre]

2.8.5 is for security issues only. Anyway I like the idea of the suggestion to have the possibility to style the thickbox easier while re-using the provided libraries.

[aaroncampbell]

I suggest that we simply replace

var tb_pathToImage = "../wp-includes/js/thickbox/loadingAnimation.gif";
var tb_closeImage = "../wp-includes/js/thickbox/tb-close.png";

with

if ( typeof tb_pathToImage != 'string' ) {
	var tb_pathToImage = "../wp-includes/js/thickbox/loadingAnimation.gif";
}
if ( typeof tb_closeImage != 'string' ) {
	var tb_closeImage = "../wp-includes/js/thickbox/tb-close.png";
}

It's almost no change to the actual file, users that expect it to work as it does will be fine, and anyone that wants to specify those variables can simply do it before they include thickbox, like this:

<script type="text/javascript">
//<![CDATA[
var tb_pathToImage = "/wp-includes/js/thickbox/loadingAnimation.gif";
var tb_closeImage = "/wp-includes/js/thickbox/tb-close.png";
//]]>
</script>

I'm attaching a patch.

[azaozz]

(In [12205]) Let plugins predefine thickbox image vars, props aaroncampbell, fixes #6453

[giuseppex]

WordPress 3.0 RC3 have old structure again:

var tb_pathToImage = "../wp-includes/js/thickbox/loadingAnimation.gif";
var tb_closeImage = "../wp-includes/js/thickbox/tb-close.png";

[ocean90]

Take a look at comment:11.

[giuseppex]

Sorry for my hurry and thanks for response. To make it work i've added some code to functions.php in theme folder founded in WP Forum.