Use of WP_CONTENT_URL breaks plugin on admin SSL only sites

[UNC Web Services]

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.

I see this is somewhat of a known issue, but figure that my troubleshooting might help in a more expedient fix.

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.

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 “tribe_resource_url”.

However, the bigger problem is in the Tribe__Assets class. 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 false preventing them from loading at all.

Then since they don’t load, the JS errors out when events-admin.js tries 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 (maybe_get_min_file() and tribe_resource_url()) be protocol relative? An even easier workaround would be to just simply use plugins_url() or 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.
See: https://codex.wordpress.org/Determining_Plugin_and_Content_Directories#Constants

• This topic was modified 9 years, 5 months ago by UNC Web Services.

[George]

Hey there,

Thanks for posting a deep analysis of things. This issue is squarely on our radar and we are hoping to publish a fix for this soon — possibly our next maintenance release. (https://theeventscalendar.com/release-schedule/)

I will post an update here when the fix is available — thanks for sharing this!

(And yes, as you noted there is not really any way to fix this without modifying core plugin code directly).

Cheers,
George

[George]

Hello!

I wanted to inform you that we’ve just published a series of updates to our products that fixes a number of issues.

These updates should include fixes for the problems reported here, where our plugins’ scripts and stylesheets were being served over HTTP when they should’ve been served over HTTPS, or vice versa.

Learn more about this release—version 4.3.3—in the official release notes here → https://theeventscalendar.com/maintenance-release-events-calendar-4-3-3-event-tickets-4-3-3-premium-plugins/

Thanks for your patience in waiting for a fix!
George

[Support Droid]

Hey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.

Thanks so much!
The Events Calendar Support Team

[Author]

Posts