The Solution
Inside the “jquery-colorbox” plugin folder, open the following file “jquery-colorbox.php”
Find the following code around line 43 – 45
if (!defined('JQUERYCOLORBOX_PLUGIN_URL')) {
// http://www.domain.com/wordpress/wp-content/plugins/jquery-colorbox
define('JQUERYCOLORBOX_PLUGIN_URL', WP_PLUGIN_URL . '/' . JQUERYCOLORBOX_PLUGIN_NAME);
and replace it with
if (!defined('JQUERYCOLORBOX_PLUGIN_URL')) {
// http://www.domain.com/wordpress/wp-content/plugins/jquery-colorbox
define('JQUERYCOLORBOX_PLUGIN_URL', '/wp-content/plugins/' . JQUERYCOLORBOX_PLUGIN_NAME);
Or simply replace WP_PLUGIN_URL with /wp-content/plugins/ on line 45. This will make sure the plugin calls the HTTPS page when your browsing secure pages.
Some Background
A client that I am working with “Native American Heritage Association” thanks to Logic By Design, had asked me to update their WordPress site as well as their out of date plugins.
I first created a backup development environment on my own dev server. Backup Buddy is a great tool to make this process a lot easier. Everything seemed to work fine, or so I thought – that said, I really do need to install a SSL cert for testing eCommerce sites.
I tested the dev environment, I didn’t see any issues so I proceeded to the live site. I deactivated all the plugins – upgraded to version 3.3.1, then started to update the plugins individually.
When I updated Colorbox, I had only tested the popup images. Stupidly, I did not test the donation Shopp ecommerce cart and checkout.

I noticed that the HTTPS was broken, when I viewed source I could see the color box stylesheet was calling for a non secure file.
<link rel='stylesheet' id='colorbox-theme10-css' href='http://www.naha-inc.org/wp-content/plugins/jquery-colorbox/themes/theme10/colorbox.css?ver=4.2' type='text/css' media='screen' />
I couldn’t figure it out, but Arbor Web Solutions could, as it turns out it was a pretty simple fix. Here is what Kevin had to say…
In the main plugin file (it’s called “jquery-colorbox.php”), there’s a line where it defines the URL to put in the script tag. It uses a WordPress constant called “WP_PLUGIN_URL”, which is always http:. I just deleted WP_PLUGIN_URL and replaced it with “/wp-content/plugins”, which should work for any site as long as plugins are available at /wp-content/plugins (so it won’t work for, say, a site that’s installed in a subdirectory).
Again a massive thanks to Kevin at arborwebsolutions.com for helping me with this fix.