This is actually a problem with the free plugin, not with the pro plugin. I posted on the wordpress.org forum, but wanted to post here as well. <\/p>\n
I see this is somewhat of a known issue, but figure that my troubleshooting might help in a more expedient fix. <\/p>\n
In the recent releases, you’ve begun using WP_CONTENT_URL in 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. <\/p>\n
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()<\/em>, however this is easy to workaround by just hooking the filter “tribe_resource_url”. <\/p>\n However, the bigger problem is in the Tribe__Assets<\/em> class. The maybe_get_min_file()<\/em> 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()<\/em> 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()<\/em> instead of a path, which makes it fail. All of that cascades into causing a return false<\/em>. So when Tribe__Assets->register()<\/em> attempts to find use minified file, it instead sets the URL to false preventing them from loading at all. <\/p>\n Then since they don’t load, the JS errors out when events-admin.js tries to call bumpdown()<\/em>, thus rendering all JS on the Events pages of the admin broken. <\/p>\n I see no way to fix this for my setup without forking the plugin. Or perhaps you can make those functions (maybe_get_min_file()<\/em> and tribe_resource_url()<\/em>) be protocol relative? An even easier workaround would be to just simply use plugins_url()<\/em> or content_url()<\/em>. 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.
\nSee: https:\/\/codex.wordpress.org\/Determining_Plugin_and_Content_Directories#Constants<\/p>\n","protected":false},"template":"","class_list":["post-1187471","topic","type-topic","status-closed","hentry"],"yoast_head":"\n