@ kkthompson
Yep, I see the issue.
The CN_IMAGE_BASE_URL
has the http
protocol rather than the https
protocol like it should.
Inspecting the var dump of the $upload_info
shows that protocol is https
like it should:
array(6) {
[“base_path”]=> string(42) “/var/www/server/html/wp-content/uploads/”
[“base_url”]=> string(50) “https://server.gov/wp-content/uploads/”
[“base_rel_url”]=> string(20) “/wp-content/uploads/”
[“img_base_path”]=> string(61) “/var/www/server/html/wp-content/uploads/connections-images/”
[“img_base_url”]=> string(69) “https://server.gov/wp-content/uploads/connections-images/”
[“img_base_rel_url”]=> string(39) “/wp-content/uploads/connections-images/”
}
This definitely had me scratching my head since they both use the exact same code to define the URL. Then it occurred to me after looking at plugin you’re using to set https on your site … that plugin must be running after Connections is initiated so CN_IMAGE_BASE_URL
is set wrong but when the images source URL/s are created the Force SSL plugin has already initiated so the source URL/s are created correctly. Because of the protocol discrepancy, it fails a validation sanity check resulting in the error message you’re seeing.
If I’m right, there are two options to resolve this. My recommended fix is…
Since the Force SSL plugin is absolutely required by your site, you should move it to the mu-plugins
folder. These are initiated before “regular” plugins. This will fix for all plugins and not just the ones that happen to load after it. This folder is in the ../wp-content/
folder. If it does not exist, just create it before moving the plugin. You can read more about MU Plugins here:
http://codex.wordpress.org/Must_Use_Plugins
The second fix is to define the CN_IMAGE_BASE_URL
in the wp-config.php
file. Add this to it:
define( 'CN_IMAGE_BASE_URL', 'path' );
Do not use path
, instead use the path shown in the System widget for CN_IMAGE_BASE_URL
, but change the protocol from http
to https
.
The down sides to this fix is image URL/s will always be https
so if the site is visited in http
you’ll have the exact same problem, just in reverse. Also the relative URL for the images will be incorrect but I’m not currently using the relative URL/s so it is safe for now, but in future versions???
Let me know how it goes.