Support for Domain Mapping???

  • Resolved althe3rd

    (@althe3rd)


    8 years, 8 months ago

    I noticed that on a number of sites that I manage on a WordPress multisite that the Venue input fields don’t load when adding/editing an event.

    I did quite a bit of debugging and found that the plugin appears to load its additional javascript for UI elements (jquery UI, etc.) secondarily using its own methods and fails whenever domain mapping is enabled for a given site. This may sound familiar as there was a previously patched bug in a couple versions prior for those encountering issues with https.

    In short, it appears to be a direct conflict with The Events Calendar and the use of domain mapping. The moment domain mapping is deactivated for a site, the venue editing fields reappear and all javascript errors on that page disappear.

    Will the events calendar be adding support for the use of domain mapping? Or perhaps changing their code so that those additional scripts are loaded via more conventional stable means? If I load them myself separately everything works fine, but I don’t want to have to patch a third party plugin for something so basic to the function of the UI.

Viewing 7 replies - 1 through 7 (of 7 total)
  • Will Earnhardt

    (@earnjam)

    8 years, 8 months ago

    Bumping this, as it’s a major regression.

    I’m still troubleshooting to determine the specific issue, but I think it’s because of the use of the WP_PLUGIN_URL and WP_CONTENT_URL constants. The Codex explicitly say not to use these:

    WordPress makes use of the following constants when determining the path to the content and plugin directories. These should not be used directly by plugins or themes, but are listed here for completeness.

    WP_CONTENT_DIR  // no trailing slash, full paths only
WP_CONTENT_URL  // full url 
WP_PLUGIN_DIR  // full path, no trailing slash
WP_PLUGIN_URL  // full url, no trailing slash

    Source: https://codex.ww.wp.xz.cn/Determining_Plugin_and_Content_Directories

    I’ve brought this up in the past related to setups that use mixed http/https environments. There are perfectly good functions that prevent these types of issues. Use those instead of trying to recreate parts of them every time you need one of the constants.

    Will Earnhardt

    (@earnjam)

    8 years, 8 months ago

    BTW, I just forked the plugin to fix this. Essentially exact same thing I did ~9 months ago and warned about then.

    In common/src/Tribe/Assets.php

    Replace line 219-220:

    $wp_plugin_url = set_url_scheme( WP_PLUGIN_URL );
$wp_content_url = set_url_scheme( WP_CONTENT_URL );

    with:

    $wp_plugin_url = set_url_scheme( plugins_url() );
$wp_content_url = set_url_scheme( content_url() );
    Thread Starter althe3rd

    (@althe3rd)

    8 years, 8 months ago

    Thanks William for that analysis. It’s a bit troubling to see that tribe is still using the apparently long past deprecated methods for determining those URLs.

    I made the adjustments you suggested and sure enough that did the trick. And searching around the rest of the code I haven’t spotted any other instances of the older method.

    You mentioned it as a major regression, I assume this was fixed at one point and has since found its way back into the code by commit solving a different issue? Or has this always been present but never was visible until the version of WP core that dropped the deprecated methods? Just curious if you know off hand, otherwise I am happy to do some investigating through GitHub further to try and find when it was added.

    Thanks for your help!
    -Al

    Barry

    (@barryhughes-1)

    8 years, 8 months ago

    @earnjam – if you haven’t already done so, have you considered submitting your change via a pull request?

    github.com/moderntribe/tribe-common

    Will Earnhardt

    (@earnjam)

    8 years, 8 months ago

    Thanks @barryhughes-1! I didn’t know about that repo. I’ll definitely make a pull request there!

    @althe3rd, I reported a slightly different issue before related to https, but still resolving around using these constants. Actually looking at the repo Barry linked above, I now see it was just never actually fixed correctly and I had just kept my instance patched against it. But I updated to the latest version this time and overwrote my patch again, causing it to break.

    FWIW, it looks like they fixed it in EC 4.4, but then broke it again in EC 4.5.10.

    I first reported it almost 11 months ago and advised against the constants then:
    https://ww.wp.xz.cn/support/topic/use-of-wp_content_url-breaks-plugin-on-admin-ssl-only-sites/

    Here is a commit from last December where they temporarily fixed a regression on HTTPS due to use of the constant:
    https://github.com/moderntribe/tribe-common/commit/e7a69fb6d5966e9b9e0069c0f03303d4948f7e6a#diff-55769dfdd1ff4f3ddbdb7aa3cf37088c

    Then they broke it when adding support for mu-plugins by re-adding the constants here:
    https://github.com/moderntribe/tribe-common/commit/3083c47dec8241e65041c3891d5c7fb3aa559a6f#diff-55769dfdd1ff4f3ddbdb7aa3cf37088c

    And then they updated it to fix the https admin/http front-end issue by wrapping it in set_url_scheme() calls about a month ago, but still used the constants.
    https://github.com/moderntribe/tribe-common/commit/3d7aedf8c198b5e623225a996e9078954c11ffd2#diff-55769dfdd1ff4f3ddbdb7aa3cf37088c

    Anyway…pull request incoming!

    Barry

    (@barryhughes-1)

    8 years, 8 months ago

    I didn’t know about that repo. I’ll definitely make a pull request there!

    Thanks! One of the team will review in due course 🙂

    Courtney Robertson

    (@courane01)

    8 years, 6 months ago

    Hey there! This thread has been inactive for a while so we’re going to go ahead and mark it Resolved. Please feel free to open a new thread if any other questions come up and we’d be happy to help. 🙂

Viewing 7 replies - 1 through 7 (of 7 total)

The topic ‘Support for Domain Mapping???’ is closed to new replies.