In the recent releases, you’ve begun using
WP_CONTENT_URLin determining resource URLs and paths. This causes a number of issues on sites that use
FORCE_SSL_ADMIN, but have non-ssl on the front-end.
First it causes about 14 different styles/scripts to fail to load on the admin because of mixed content. It tries to load them via http, while the admin uses https. The problem is in the function
tribe_resource_url(), however this is easy to workaround by just hooking the filter
However, the bigger problem is in the
maybe_get_min_file()function uses this constant as well. It uses it to try to convert the supplied URL to a file path, but ends up failing because it’s trying to do a
str_replace()on an http URL, but we’re supplying an https because of the filter we used to fix bug above, so it can’t find the substring to replace. This forces a URL to be supplied to
file_exists()instead of a path, which makes it fail. All of that cascades into causing a
return false. So when
Tribe__Assets->register()attempts to find use minified file, it instead sets the URL to
falsepreventing them from loading at all.
Then since they don’t load, the JS errors out when
events-admin.jstries to call
bumpdown(), thus rendering all JS on the Events pages of the admin broken.
I see no way to fix this for my setup without forking the plugin. Or perhaps you can make those functions (
tribe_resource_url()) be protocol relative? An even easier workaround would be to just simply use
content_url(). This is exactly the scenario those functions exist for, as they will use the proper protocol. The codex even says those constants are not to be used by plugins.
- You must be logged in to reply to this topic.