Support » Plugin: The Events Calendar » Use of WP_CONTENT_URL breaks plugin on admin SSL only sites

  • 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

Viewing 5 replies - 1 through 5 (of 5 total)
  • Ben Meredith

    (@benmeredithgmailcom)

    +1 for not only the clear explanation of what is going wrong, but a helpful point in the direction of a solution. Great job @earnjam.

    Also, we’ve had clients having this problem as well. So I wanted to +1 for the sake of hoping there’s a fix, soon!

    Plugin Contributor Clifford Paulick

    (@cliffpaulick)

    Hi again, William. And thanks again for these extra details.

    Again, I’ve passed this information along to our developers; thank you for it.

    This is a known bug that our developers will address.

    If you set both your Home URL and Site URL to HTTPS, you shouldn’t be affected by this bug.

    Thank you for using our plugin.

    Plugin Author ggwicz

    (@ggwicz)

    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

    shelbelliott

    (@shelbelliott)

    Hi there,

    Looks like it’s been a week or more since we’ve seen activity on this thread! I’m going to go ahead and mark this resolved, but should you still need assistance, please don’t hesitate to open a new thread!

    You may also find the following documentation helpful to search in the future:

    TEC Knowledgebase
    TEC Technical Documentation

    Cheers,

    Shelby 🙂

    This is not fixed in the most recent versions.

    You are still using WP_CONTENT_URL instead of content_url(). I’m not sure how I can be more clear in how easy it is to fix this bug for everyone.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Use of WP_CONTENT_URL breaks plugin on admin SSL only sites’ is closed to new replies.