UPFRONT BUG: Anchor links not respecting primary domain

Reported this before...reporting it again after the latest upfront 1.4 update.

Scenario in the event it wasn't clear before...for a subblog in a multisite environment:

Domain Mapping Primary domain: http://www.testcase.com

Editing customize upfront link: https://networkname.com/testcase/?editmode=true

When editing via the upfront editor creating an anchor link in the navigation bar, the link is not reflecting the domain mapping primary domain.

The link will be: https://networkname.com/testcase/#anchorlink

The link should be: http://www.testcase.com/#anchorlink

Very frustrating bug to explain and fix...can we get this in the pipeline for 1.4.1 and a hotfix so we can get things right right now...?

Thanks guys and gals

  • Nithin
    • Support Wizard

    Hi Ben,

    Hope you are doing good today. :slight_smile:

    Very frustrating bug to explain and fix...can we get this in the pipeline for 1.4.1 and a hotfix so we can get things right right now...?

    Thank you for the detailed explanation, could you also enable support access, so that we could give a closer look, and report these to the developer, if it's a bug.

    You can grant access from WPMU DEV > Support > Support Access > Grant Access, or check this manual: http://premium.wpmudev.org/manuals/wpmu-dev-dashboard-enabling-staff-login/

    Please let us know once you enable support access, have a nice day. :slight_smile:

    Kind Regards,
    Nithin

  • Ben
    • The Reaper

    Follow up, not sure if this would effect how upfront renders anchor links

    In order to get upfront to work properly with domain mapping, i modified the domain mapping plugin with the following code:

    classes/class.domainmap.php line 151

    took this:

    $admin_url = str_replace( $orig_url, $mapped_url, $admin_url );

    and replaced it with this:

    $admin_url = str_replace( $mapped_url, $orig_url, $admin_url );
    $admin_url = set_url_scheme($admin_url, self::utils()->get_admin_scheme( $admin_url ) );
  • Ben
    • The Reaper

    Kasia Swiderska

    I have no idea...maybe I included in comments of another post...that said...are you able to see the issue and have forwarded this issue to the developers...this is kinda an important issue.

    Please have the developer on this thread and lets get this fixed...if they are only testing the editor on a mapped domain when in editing mode...they wont ever see this.

    I edit on the non mapped domain so that when a user is editing...everything is in https as my mapped domains do not all have https set up (this from what i guess would be how most people would want things set things up).

    I did a quick check and found a function that would possibly be a good example for the developer to review and for him to get started on reviewing the code in his javascript for the anchor links and how they are rendered.

    In the file:
    elements/upfront-social-media/lib/upfront-social-media.php

    line 54, there is a function:

    public function likes(){
            $services = $this->_get_property('services');
            $style =  $this->_get_property('counter_options');
            $url = "http://" . $_SERVER["SERVER_NAME"] . $_SERVER["REQUEST_URI"];
    
            return Upfront_SocialMedia_Setting:: get_likes_markup($services, $style, $url);
    }

    So if somebody has mapped domain: http://www.blogmappeddomain

    But they are editing via: https://networkdomain.com/subblog/?editmode=true

    Then the $url being used would be potentially....wrong.

    So: $_SERVER["SERVER_NAME"] shouldn't be used. If domain mapping is enabled...then the primary mapped domain needs to be used from your domain mapping plugin. OR perhaps the proper way is a native word press permalink function that should be used to generate this link via your domain mapping plugin.

    What ever it is...it is a problem. And the use of $_SERVER variables in both the JS and the PHP needs to be done so cautiously and replaced with wordpress functions through out the ode (i know it can be a pain in the ass) but not doing so is screwing some things up and makes other plugins less compatible. I am using this code as an example of why the anchor links are messed, I am guessing a similar situation is occuring the javascript somewhere but its too much for me to dig through. When the developer sees this it should make sense to him/her of what to do, so please forward to the developer asap as it could fix other issues they are having.

    Kasia Swiderska I don't know why you are having trouble replicating this issue...can you give me your set up or private message me your credentials to where you are testing and I can see why you aren't seeing this?

    Again, this is a critical error, and would love this to be fixed in the next version. I love the idea of builder and upfront, would really love to get them ready for prime time ASAP. Thanks for your work.

  • Kasia Swiderska
    • Support nomad

    Hello Ben,

    I have no idea...maybe I included in comments of another post.

    In this case it could be missed if it was posted in different issue thread - without the thread and bug report there is no way if I can check progress on fixing that.

    But I did actually replicate issue with Domain Mapping and links in menu when subsite uses original, not mapped url, are showing orginal domain.

    I've send message to developer with your last responses to check that issue.

    But I also tested that I'm able to open editor from mapped domain and then all the links are correct.
    http://yourmappeddoamin.com/?editmode=true ? On front end Upfront button on admin will open editor on mapped domain not the original one. Can you try that?

    kind regards,
    Kasia

  • Ben
    • The Reaper

    But I also tested that I'm able to open editor from mapped domain and then all the links are correct.
    http://yourmappeddoamin.com/?editmode=true ? On front end Upfront button on admin will open editor on mapped domain not the original one. Can you try that?

    Kasia Swiderska

    I don't want to do that for a couples reasons.

    #1. For some reason domain mapping on my system is not properly setting the paths for various js upfront files, so I have re-written code to address those issue in the domain mapping plugin, but they only work when editing in the non-mapped domain.

    #2. I can not build a scalable system to account for https for every mapped domain...maybe you know how to but at the moment I don't. Edit mode is an administrative task, should only be done under https as you are posting data and any posting of data should be done securely.

    So for these two reasons you can understand why the way I have it set up is important as well as why editing via http://yourmappeddoamin.com/?editmode=true is not the proper way to do things or a viable option.

    Hope that clarifies things and helps get a solution asap as it is right now, if it cannot set the proper permalink structure via the mapped domain, then it is broken as any other solution is not a viable solution.

    Bug

  • Kasia Swiderska
    • Support nomad

    Hello Ben,

    I apologize for not updating thread earlier - due to family emergency I wasn't avaliable and just got back to work.
    I spoke with developer, he review thread and agreed that that has to be fixed - I already created task for devs in our system and they are working on it. So it's not forgotten - this is work in progress. I'm not able to give you ETA, but if I'll see that task is completed I'll update thread.

    kind regards,
    Kasia

  • Kasia Swiderska
    • Support nomad

    Hello Ben,

    I just spoke with developers and they are working right now on issues with Domain Mapping and Upfront - they are hoping to have a fix for next release, but it's not sure thing at the moment I'm afraid. Those Domain Mapping conflicts are not forgotten and now it's main focus for developers.

    kind regards,
    Kasia

  • Rupok
    • Support Ninja

    Hi Ben,

    I'm so sorry for the delay from our end, I do apologize for this. I found that our developers are still working on this, and I've requested them to facilitate the process. I believe, they will come up with a workaround soon, I can't give you any ETA though.

    Please keep in mind, our developers work round the clock and they have to deal with lots of critical issues and other things. So it may take a little while for them to check this and provide a fix.

    Have a nice day. Cheers!
    Rupok

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.