Domain Mapping Bug 4.0.3.3 breaks https permalinks, causes mixed content

Hi WPMUdev,

I hope your day is going awesome!

This is a bug report for Domain Mapping 4.0.3.3

This concerns using Domain Mapping with HTTPS

This is using a totally fresh WPMS w/ only WPMUdev dashboard & Domain Mapping plugins, Twenty Fifteen theme

I have set network primary SITEURL and HOME to use https

I have also set the subsite SITEURL and HOME to use https

Admin/Login are at original network addresses

Network primary is using CF Pro (currently bypassed straight to server), mapped domains using CF Free

Network primary has validated Wildcard SSL at server, mapped domains' SSL from CF only.

Prior to mapping a domain to the subsite:
images are uploaded to https address w/ no mixed content issues as UPLOAD URL PATH inherts from SITEURL unless otherwise defines

permalinks are shown as using https as set by the HOME value

After mapping a domain using the HTTPS setting option (and any option for frontend redirect, though I'll focus on using 'Mapped' for frontend):
images are uploaded https address w/ no mixed content issues as UPLOAD URL PATH inherts from SITEURL unless otherwise defines

permalinks are shown as using http contrary to every setting value that I can think of setting

This causes mixed content issues only on the frontend as images are shown in page source as using http addresses.

I have also forced https via the following in my .htaccess file:

RewriteCond %{HTTPS} !=on
RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]

Which means that if you actually click on an image at or try to load any resource using http it will be rewritten to https with no issues

here is a live example:
primary: https://wpms.network
test: https://test.wpms.network

Screenshots for the details re. settings...

Support access is active if you'd like to look around

Please advise as it'd be nice to not just have to put a series of symptomatic fixes into place if the core issue can be dealt with to produce nice code...

Basically, when https is being used for subsite HOME and https is used for domain mapping then permalinks should be https as expected and images/uploads should use https addresses!

Apologies for the lack of code reference/general nomenclature... I am not a coder per se and mostly treat WPMS as a series of black-boxes

Kind Regards, Max

ps. just to be clear, setting the https controls at network > settings > domain mapping to 'on' did nothing for this issue, I did test both ways

  • wp.network

    Just a 'lil update for clarity and completeness:
    from above

    (and any option for frontend redirect, though I'll focus on using 'Mapped' for frontend)

    was more than a bit unclear... basically, the above was assuming
    Frontend redirect should be: 'directed to mapped (primary) domain'

    If instead, the setting used in mapping the domain is
    Frontend redirect should be: 'disabled and entered domain domain should be used'
    so that I can take over the frontend mapping via .htaccess, then the permalinks show as expected yet the mixed content on the frontend remains with the mapped address... see screenshots below for details

    Cheers, Max

  • wp.network

    @Ashok @Sam

    Installed fresh network, installed DM 4.3.0.4 (just noticed I got the v# wrong in my title

    Issue remains unchanged

    Why does network admin > settings > domain mapping > mapped domains tab properly show original network address for test.wpms.network as using HTTPS (as defined by SITEURL) while subsite admin > tools > domain mapping improperly shows original network address as using HTTP (contrary to SITEURL value)?

    Kind Regards, Max

  • wp.network

    Also, there is an issue with using Automattic's SuperCache plugin which is somewhat related to my older thread re. CDN Linker Master - SuperCache's CDN functions are powered by CDN Linker adpatation...

    Basically, SuperCache (and I imagine the stand alone CDN Linker as well though I am only focusing on using SuperCache as it has a very large userbase) does not recognize the mapped domain and so does not rewrite the static resource addresses on the frontend as expected/desired.

    I can easily open a new ticket to address that SuperCache CDN issue, mention it here in case the solutions are intertwined

    Cheers, Max

    ps. I only installed SuperCache on this WPMS after running above DM test

    pps. Support access is again active if you'd like to poke around

  • wp.network

    update @Ashok @Sam

    I have modified my network setup and retested for above issues.

    I have verified the same behavior, noticed a few additional quirks and developed a few potential ways to address current behavior...

    The network setup is now as follows:
    Apache 2.4 w/ PHP 5.6
    Using SNI at server, validated Wildcard SSL certs installed for primary (wpms.network) and one mapped domain (tivism.com)
    Primary and all mapped domains (EXCEPT for tivism.com) are using CloudFlare.com (in part to provide free SNI-based SSL certs)
    Primary is currently 'paused' CF only resolving DNS, mapped domains are marked in 'development mode' at CF during testing

    1) I have removed all custom .htaccess rules, now relying only on core WP and DM behaviors to control URLs
    2) I have modified primary site's SITEURL and HOME values to use https
    3) I have created an series of subsites
    wpmsnetwork-secure-1.wpms.network - uses default SITEURL and HOME values of http - uses CF
    wpmsnetworks-secure-1.wpms.network - uses modified SITEURL and HOME values of https - uses CF
    wpmshost-secure-1.wpms.network - uses default SITEURL and HOME values of http - uses CF
    wpmshosting-secure-1.wpms.network - uses modified SITEURL and HOME values of https - uses CF
    tivism-secure-1.wpms.network - uses modified SITEURL and HOME values of https - does NOT use CF
    sub1-tivism-secure-1.wpms.network - uses default SITEURL and HOME values of http - does NOT use CF
    sub2-tivism-secure-1.wpms.network - uses modified SITEURL and HOME values of https - does NOT use CF
    sub3-tivism-secure-1.wpms.network - uses default SITEURL and HOME values of http - does NOT use CF
    sub4-tivism-secure-1.wpms.network - uses modified SITEURL and HOME values of https - does NOT use CF
    4) I have mapped domains to the above subsites, in each case using 'https' and 'directed to mapped (primary) domain' as the domain mapping options
    wpmsnetwork-secure-1.wpms.network > wpmsnetwork.com
    wpmsnetworks-secure-1.wpms.network > wpmsnetworks.com
    wpmshost-secure-1.wpms.network > wpmshost.com
    wpmshosting-secure-1.wpms.network > wpmshosting.com
    tivism-secure-1.wpms.network > tivism.com
    sub1-tivism-secure-1.wpms.network - sub1.tivism.com
    sub2-tivism-secure-1.wpms.network - sub2.tivism.com
    5) In every case, I see behavior consistent with above reported bugs, namely:
    5a1) subsites using default http for SITEURL and HOME have mixed content issues on both front end and backend
    5a2) subsites using modified https for SITEURL and HOME have mixed content issues only on frontend
    5b1) subsite admin > tools > domain mapping shows original subsite address as using http even for subsites using https for SITEURL and HOME
    5b2) subsite admin > settings > permalinks show mapped address yet using http despite selection of https during domain mapping - this effects everything in WP tht uses the permalinks value!

    6) I have looked through the DM code and found:
    at line 98 in domain mapping.php
    if ( !defined( 'DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN' ) ) {
    define( 'DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', false );

    7) I have added the following to my wp-config, just below the sunrise define
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);

    8) This does mostly *fix* the issues with the permalinks (5b1 and 5b2 above)

    9) it does not address above issues 5a1 and 5a2

    for example, see:
    https://wpmshost.com/2015/pic-post-test-post-map-wo-define/ - posted without define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true); in wp-config
    https://wpmshost.com/2015/pic-post-test-post-map-w-define/ - posted with define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true); in wp-config
    https://sub2.tivism.com/2015/pic-post-test-post-map-wo-define/
    https://wpmshosting.com/2015/pic-post-test-post-map-w-define/
    https://sub1.tivism.com/2015/pic-post-test-post-map-wo-define/
    https://sub1.tivism.com/2015/pic-post-test-post-map-w-define/
    https://sub2.tivism.com/2015/pic-post-test-post-map-wo-define/
    https://sub2.tivism.com/2015/pic-post-test-post-map-w-define/

    10) using define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true); in wp-config causes the following strange issue:
    10a) for all subites with mapped domains, the default WP meta widget links for login/admin are adversely affected
    10b) for all subsites with mapped domains, ONLY from frontend, most links in admin bar menu as adversely affected (except for network admin links and each subsite's visit site link)
    10c) the link urls are being malformed as follows:
    https://htts://remainder of url as expected]

    You can see this be visiting any of the above listed mapped domains and hovering over the 'login' link

    Support access is granted, so you should be able to log in and look at the admin menu bar links from the frontend of a mapped domain.

    I can add more screenshots if that would be at all helpful

    Will continue to poke around on this issue, welcome any feedback

    Kind Regards, Max

    ps. for the mixed content issue, one of the coolest approaches so far is to add the following to wp-config
    define( 'WP_CONTENT_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/wp-content' );
    currently this is NOT in use, figured we'd deal with the above first

    before adding DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN define to wp-config

    after adding DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN define to wp-config

    • wp.network

      update @Ashok @Sam

      even weirder url issues, only on frontend of mapped domains... in addition to the above documented issue, after looking at this with a friend for a few hours this evening we finally noticed this:
      when the DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN constant is defined true in wp-config in order to address the significant issues with incorrect permalinks, as documented above - (which it seems to successfully accomplish - see above screenshots of tivism.com example - while currently also introducing these weird side-effects on mapped subsite frontend links...)

      effects:
      from the frontend of any subsite w/ mapped address (primary and subsites w/o mapped domain do not exhibit this behavior, only occurs on frontend of subsite with mapped domains - see above for domain mapping settings used)

      the meta-widget login link for all visitors
      most links in admin bar for logged in users

      as documented above, if you inspect the element (for instance, the login link in the meta-widget for https://tivism.com), the code is shown as:
      https://htts://tivism-secure-1.wpms.network/wp-login.php

      the new thing we noticed:
      if you hover over the malformed link in the element inspector, it reveals an even weirder url that made us think of possible query string issues:

      https://tivism.com/https:/htts:/tivism-secure-1.wpms.network/wp-login.php

      this behavior is consistent for admin bar urls when logged in, (see second screenshot below) and occurs at only frontend of subsites with mapped addresses... could this be related some how to an issue with query strings??

      We also thought that it could possibly be a server config issue, and can pursue/test against that if needed... also, possibly a conflict caused by Multi-Domains (there are issues with M-D and https, we'll save that for another thread though)... if needed we can easily wipe this instance and set up a fresh model with only DM installed (+CF and debugging plugins) if needed.

      We're hosting this project with wpmu-hosting in part because we assume that their baseline server config is set to work with WPMS and Domain Mapping... perhaps the https use is throwing a wrench in things, yet given their somewhat-recent implementation of SNI I believe they'e put some thought into use of SSL with WPMS and we've had no other issues that are server related, in any case I'll open a ticket and ask Joe to look at this too...

      I'd also reiterate that we are currently using stock htaccess and wpms.network is 'paused' - only using CloudFlare to resolve DNS - while tivism.com is not using CF at all (other mapped domains are using minimal CF settings and 'Full SSL' - we can purchase and install additional validated SSL certs at server as needed to avoid CF, though that shouldn't be needed)...

      We're feeling fairly confident that the issue is somewhere within DM... we're also feeling generally positive about resolving this (its gonna be so sweeet!) and we'll work on generating some more qualified Qs/ideas in the morning... hoping for some feedback/insight...

      Support access is currently granted...
      If needed I can provide server access or clarifications/step-by-steps for replication...
      Please let me know of any updates on the situation, especially please let me know which behaviors you have been able to replicate and which you have not

      Kind Regards, Max

    • wp.network

      @Sam

      Thanks for the update

      Just as a note, the codex (and many WP docs & pros) refer to updating SITEURL and HOME to use https as a very essential method to essentially 'let WP know what you're doing' (eg. effecting content upload URL to avoid mixed content issues)

      I like to err on the side of letting WP be WP (meaning working with core behaviors), yet since we're working on Domain Mapping here, I'm happy to follow your direction so as to establish a baseline

      Clarification Q:
      assuming SITEURL and HOME are set to use http as is default, will setting
      define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);
      in wp-config be expected to produce
      1) correction of mixed content issues described above?
      2) correction of permalinks as described above?

      of are these corrections expected without setting this define at all?

      the plan:
      I will comment out the define, delete all current mappings, reset all appropriate SITEURL and HOME values and use Interconnect/IT's s/r script to alter URLs in post content...

      I will then remap the domains... I will then test for the above issues, then uncomment the define and test for above issues...

      I will update this thread with results when above is complete

      If needed we can then look at doing a fresh install...

      To be proactive, I will also go ahead and provide you with cPanel/WHM access (you can set up for SFTP as needed). Will email shortly

      Kind Regards, Max

    • wp.network

      clarification: re

      Please try to set http in db for siteurl and home, they should not be modified by you when you're using DM to force scheme.

      Usually, I set SITEURL and HOME to use https and my code uses https (or at least relative addresses) and then I take care of the rest via .htaccess - I usually set the https options at network > settings > domain mapping to 'no' and though I also usually employ .htaccess to control mapped frontend redirects for mapped domains, I do use 'https' and 'directed to mapped (primary) domain' options when mapping domain in attempt to correctly set the permalinks....

      ...for this testing I backed out almost all my custom controls/configurations (namely except for the SITEURL and HOME modifications) and chose only to use DM options

    • wp.network

      btw: from above

      trying to advocate for increased dev resources

      I mean for the DM project (and kinda by extension, Multi-Domains too)

      #################################################################
      note: at this point in the thread flow Sam has gotten re-involved and I have begun reconfiguration/retesting as per @Sam's spec to NOT modify SITEURL and HOME values for primary or any subsite to control against DM https options conflict... and, as noted above, though I usually set SITEURL and HOME to use https in a (mostly very successful) bid to work with WP core behaviors, in this test I chose to follow DM/wpmudev spec to the 'T' ...see below for results, play-by-play style!

  • wp.network

    update @Sam

    I will comment out the define, delete all current mappings, reset all appropriate SITEURL and HOME values and use Interconnect/IT's s/r script to alter URLs in post content...

    I have complete this portion, also visited each site's permalinks page to flush any rules and re-saved... also flushed all CF caches and reset dev mode to prepare domains for mapping in subsequent stage...

    For now, primary and all subsites are using http for SITEURL and HOME as you specify and the
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);
    is commented out in wp-config...

    Here are results at this point:
    1) Mixed content due to http in uploads / permalinks
    1a) this now affects network primary frontend and backend as well as all subsites fronend and backend
    1b) despite network > settings > domain mapping set to force https for login/admin and frontend

    2) permalinks are shown as using http at site admin > settings > permalinks for primary and all subsites
    2a) this impacts everything in WP core that draws on the permalink value
    2b) such as links in feeds or shortlinks for posts, etc.

    screenshots continue below...

  • wp.network

    ok, I am now going to back everything up

    then I will uncomment the define
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);

    and see if, as I expect given that I have not yet mapped any domains, it fixes the permalinks issue w/o causing any weird URLs and w/o fixing the mixed content/uploads issue...

    I will report w/o as many screenshots now that we have a baseline

    Then I will remove the define from wp-config and proceed to map and retest for above behaviors and will report with some screenshots...

    Then we can look at re-adding the define to wp-config
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);

    and seeing if it fixes the permalinks but causes the weirdness with frontend links on subsites w/ mapped domains as described above...

    Sound good?

    @Sam
    http://isup.me/wpms.network
    https://www.whatsmydns.net/#A/wpms.network
    http://tools.pingdom.com/fpt/#!/egSE0H/wpms.network

    http://isup.me/tivism.com
    https://www.whatsmydns.net/#A/tivism.com
    http://tools.pingdom.com/fpt/#!/bWW2ov/tivism.com

    I really appreciate knowing that you're working on this/following along!

    Let me know re the connectivity... sending the creds email now

    Just to be sure, you're clear that at this point all domain mappings are deleted, correct?

    I am now proceeding as outlined above...

    Cheers, Max

  • wp.network

    update:

    with the following define active in wp-config
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);

    and domain mapping set to force https for original frontend addresses
    and NO domains mapped

    1) as expected, the mixed content issues remain
    2) as expected, site > settings > permalinks shows http in original url
    3) as expected, site > tools > domain mapping shows HTTPS in original url

    I will now comment out the define in wp-config and proceed with mapping domains as described above

    wpmsnetwork-secure-1.wpms.network > wpmsnetwork.com (uses CF for SSL)
    wpmsnetworks-secure-1.wpms.network > wpmsnetworks.com (uses CF for SSL)
    wpmshost-secure-1.wpms.network > wpmshost.com (uses CF for SSL)
    wpmshosting-secure-1.wpms.network > wpmshosting.com (uses CF for SSL)
    tivism-secure-1.wpms.network > tivism.com (has Validated Wildcard SSL, does NOT use CF at all)
    sub1-tivism-secure-1.wpms.network > sub1.tivism.com (has Validated SSL, does NOT use CF at all)
    sub2-tivism-secure-1.wpms.network > sub2.tivism.com (has Validated SSL, does NOT use CF at all)

    Will let you know when complete

    Cheers, Max

  • wp.network

    update: domain mapping complete

    with the following define NOT active in wp-config
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);

    and domain mapping set to force https for original frontend addresses
    and domains mapped using 'https://' and 'directed to mapped (primary) domain'

    1) as expected, the mixed content issues remain for all sites, including primary
    2) as reported previously, urls in post content (eg. images) are not only using http but are also using the original network address rather than the mapped domain when visiting frontend (this is addressed by the WP_CONENT_URL define in wp-config or by setting UPLOAD_URL_PATH in options - both approaches also solve for https re content/uploads)
    3) as expected, site > settings > permalinks shows http in original url
    4) as expected, site > tools > domain mapping shows http in original url
    4a) as mentioned, imho this is a big deal and need to be solved so that permailnks are correct/canonical (eg. in feed, shortlinks, etc.)

    I will now heat up my coffee and then will uncomment the define in wp-config
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);
    so that it is active, ...and will report the differences observed.

    So far the only difference I see in NOT modifying SITEURL and HOME is that now all sites have mixed content issues on both frontend and backend, whereas when I modify SITEURL and HOME to use https then at least the backend of those sites are secure with out further meddling (eg. setting content or upload urls or using *fancy* plugins or protocol relative urls to deal with this... https should be https in the code/output/whatever-you-properly-call-it and everywhere else too... for security and for seo - my 2 cents

    Ok, on with the coffee and testing!

    Aloha, Max

    ps. the posts and images shown below are newly created/uploaded just now after the domain mapping steps

  • wp.network

    update @Sam

    testing complete w/
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);
    active in wp-config

    results:
    1) Primary
    1a) permailnks remain HTTP
    1b) frontend links are as ok

    2) subsite WITHOUT mapped domain
    2a) permalinks remain HTTP
    2b) tools > domain mapping shows original address using HTTPS
    2c) frontend links are ok

    3) subsite WITH mapped domain
    2a) permalinks show HTTPS
    2b) tools > domain mapping shows original address using HTTPS
    2c) frontend links are all kine messed up and kaput - same behavior as reported above

    Summary to follow

  • wp.network

    more screens:

    in the two screens below, please observe as reported above:

    for the 'login' link in the meta-widget on frontend of (for instance) tivism.com, inspect element, observe in code:
    https://htts://tivism-secure-1.wpms.network/wp-login.php

    if you hover over the malformed link in the element inspector, it reveals an even weirder url that made us think of possible query string issues, please confirm you also see this produce:
    https://tivism.com/https:/htts:/tivism-secure-1.wpms.network/wp-login.php

    this behavior persists across all subsites w/ mapped addresses (inlcuding admin bar links as before) yet only from frontend... other than this issue, adding the define to wp-config to correct the permalinks seems to work well

  • wp.network

    update @Sam

    Summary:
    Differences when NOT defining SITEURL and HOME to use https are:

    A) WITH
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', false);
    1) for primary with SITEURL and HOME using http
    1a) mixed content issues on both frontend and backend
    1b) permalinks use http

    2) for primary with SITEURL and HOME using https
    2a) NO mixed content issues on frontend OR backend
    2b) permalinks use https

    3) for subsites WITHOUT mapped domain with SITEURL and HOME using http
    3a) mixed content issues on both frontend and backend
    3b) permalinks use http
    3c) tools > domain mapping shows original address using http

    4) for subsites WITHOUT mapped domain with SITEURL and HOME using https
    4a) mixed content issues on only frontend
    4b) permalinks use https
    4c) tools > domain mapping shows original address using http

    5) for subsites WITH mapped domain with SITEURL and HOME using http
    5a) mixed content issues on both frontend and backend
    5b) permalinks use http
    5c) tools > domain mapping shows original address using http

    6) for subsites WITH mapped domain with SITEURL and HOME using https
    6a) mixed content issues on only frontend
    6b) permalinks use http
    6c) tools > domain mapping shows original address using http

    B) WITH
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);
    7) for primary with SITEURL and HOME using http
    7a) mixed content issues on both frontend and backend
    7b) permalinks use http

    8) for primary with SITEURL and HOME using https
    8a) NO mixed content issues on frontend OR backend
    8b) permalinks use https

    9) for subsites WITHOUT mapped domain with SITEURL and HOME using http
    9a) mixed content issues on both frontend and backend
    9b) permalinks use http
    9c) tools > domain mapping shows original address using https

    10) for subsites WITHOUT mapped domain with SITEURL and HOME using https
    10a) mixed content issues on only frontend
    10b) permalinks use https
    10c) tools > domain mapping shows original address using https

    11) for subsites WITH mapped domain with SITEURL and HOME using http
    11a) mixed content issues on both frontend and backend
    11b) permalinks use https
    11c) tools > domain mapping shows original address using https
    11d) meta-widget and admin bar links are (doubly and strangely) malformed ONLY from frontend

    12) for subsites WITH mapped domain with SITEURL and HOME using https
    12a) mixed content issues on only frontend
    12b) permalinks use https
    12c) tools > domain mapping shows original address using https
    12d) meta-widget and admin bar links are (doubly and strangely) malformed ONLY from frontend

    I'll give this another read though in a bit to make sure its all accurate to my experience... I do hope that this detail has been helpful and moves us quickly closer to an effective solution

    Frankly, looking at above list, I see defining SITEURL and HOME as producing way more benefit/impediment than leaving the values using http and using DM to control everything.

    Looking forward to an update; any guidance/ideas on what to try/look for today when I sit down with my *coder* friend to play with this will be appreciated (even a few ideas for rough hacks to fix the symptom of the malformed link urls on mapped frontends until a real solution is pushed out would be very welcome)...

    Kind Regards, Max

  • Ash

    Hello @WPMS.Network

    I hope you are well today.

    Is it possible for you to try in a different server, maybe in a much cleaner server? Currently you have a complex setup, so we want to test it without loads of hassle and old configs.

    To be honest, we didn't get any report like this issue so I think it's not a Domain mapping issue but could be a server issue. So, if you please set it up in clean server would be easier for us to troubleshoot.

    Cheers
    Ash

    • wp.network

      @ashok I am well, thank you! I hope the same goes for you too

      As I stated at this threads opening post, this is based on a fresh install.

      The server itself is with wpmu-hosting.org (run by @aecnu) and is fairly recently set up... as mentioned above, I will ask Joe & team to look into any possible server misconfiguration.

      Currently, installed plugins are:
      CloudFlare - active per site as appropriate
      Developer - deactivated
      Log Viewer - deactivated
      Debug Bar - network activated
      Debug Bar Console - network activated
      Debug Bar Extender - network activated
      Rewrite Rules Inspector - network activated
      Simply Show IDs - network activated
      Domain Mapping - network activated
      WPMUdev Dashboard - network activated

      Themes:
      Twenty Fifteen - active at all subsites and (as of now) primary
      Genesis Framework - not active (was active at primary, behavior the same)

      It is no real problem to replicate, however I am not eager to do so as I am very confident that we will get the same results.

      Can you point out any thing in particular that requires or suggests need for a total reinstallation?

      If you will require that I set up fresh and document every step it is possible, again, I'm just not eager to spend hours taking screenshots of steps that we both know inside-and-out.

      If you simply want a fresh slate and don't need step-by-steps on everything then that is easier, obviously... however, I am not sure how to make the configuration any simpler re. plugins/theme...

      Please advise - I don't mind detailed QA/bug testing when needed yet I have no desire to spend my time or anyone else's in needless work

      Kind Regards, Max

      • wp.network

        update from host re. server config:
        "Server misconfiguration regarding SNI is virtually impossible as it is a core OS function and nothing to configure - it simply relates domain names with SSL rather then by IP - Server Name Indication the keyword being "name" and not IP. ...and concerning php 5.6 - it has not gone mainstream and therefore the reason why native is php 5.4 - your option of course and at your own risk, however I do not think it has anything to do with the issue at hand i.e. permalinks etc."

        Basically, the server seems fine from their end. I've also checked in w/ CF Support recently and they have not reported any issues w/ services on their part. I agree that being thorough about the situation is crucial... if you have any further specific concerns, please let me know and I will liaise as needed

        Cheers, Max

  • Sybre Waaijer

    Hi @WPMS.Network

    You asked me to drop by here, however, I'm afraid I'm not going to read through ~6800 words.

    So I'm here, with a clean slate in a massive topic. Please tell me within a few sentences what you still need help with and I'll do my best to guide you

    Hope you have a great day! (Also good night, will reply ASAP tomorrow

    EDIT: Also, add the .php file within this .zip file to your mu-plugins:
    https://hostmijnpagina.nl/share/ssl-mixed-fixer.zip
    It's forked from https://wordpress.org/plugins/ssl-insecure-content-fixer/ and hasn't caused any problems to my site so far.

    • wp.network

      Cheers @Sybre

      There are other issues mentioned/documented in this bug report, yet this mostly is all focused around getting the permalink values to behave as expected (show https for all domains) with out needing to do a bunch of further custom patching...

      For this test, I removed all custom .htaccess - only using DM settings as per Sam's spec in attempt to isolate the bugs a bit (scroll up for screens of settings pages through out test runs)... this was done on an initially fresh WPMS - we may end up wiping it and replicating w/ only absolutely essential components just to be 110% sure

      My one remaining custom addition to the brew is from domain-mapping.php around line 98, using in wp-config below sunrise:
      define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);

      fixes permalinks issues generally, causes one gnarly side effect:
      ONLY at frontend of mapped domains when above is defined in wp-config

      you can see this live at wpmsnetwork.com (using CLoudFlare) and tivism.com (NOT using CF)

      when logged out, for the 'login' link in the meta-widget on frontend of (for instance) tivism.com, inspect element, observe in code:
      https://htts://tivism-secure-1.wpms.network/wp-login.php

      if you hover over the malformed link in the element inspector, it reveals an even weirder url that made us think of possible query string issues, please confirm you also see this produce:
      https://tivism.com/https:/htts:/tivism-secure-1.wpms.network/wp-login.php

      this behavior persists across all subsites w/ mapped addresses (inlcuding admin bar links when logged in) yet ONLY from frontend of subsites with mapped domain using 'directed to mapped (primary) domain'... other than this issue, adding the define to wp-config to correct the https use in permalink URLs seems to work well

      Run across anything like this before/any bright ideas?
      Does this seem like it could be related to issues with query strings not being passed correctly?
      Have you ever used DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN without such effect?
      Read any really great books lately?

      Thanks for taking some moments to look at this

      Kind Regards, Max

  • Axel

    Hello all,

    I have more or less the same issue at my multisite. I chose not to report it yet, because I did not dig into it yet, since I'm still working on my theme and I gave priority to a different (?) HTTPS issue https://premium.wpmudev.org/forums/topic/multi-domains-domain-mapping-cloudflare-https.

    However, since the issue is very similar, perhaps it is helpful to confirm here. Moreover, I notice that it is not theme related (see print screens attached).

    My setup:
    - Ubuntu 14.04 LTS;
    - Apache with Nginx as proxy (via Vesta CP) https://vestacp.com/;
    - CloudFlare on all related sites;
    - I had CF Flexible SSL on all sites;
    - Now a self signed certificate & CF full SSL on the main site makes no difference.

    Problem:
    - Image URLs change to http, or "http(s):" gets removed.
    - Occurs only on sub sites where domain mapping is active.
    - "define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);" does not seem to impact the image URL here, but it does change the URL in the domain mapping options screen and it does also change the URL to edit a post, f.ex. to https://htts//tv.eco13.me/wp-admin/post.php?post=83&action=edit.

    I hope that helps. If there is anything else you would like to know, surely feel free to ask.

  • wp.network

    Awesome stuff @Sybre and @Axel

    Thank you both for adding your experience/thoughts

    @Sybre your points and suggestions are all right on and will work, as per usual

    ...however, the main intention of this bug report thread is to help push the DM project (and by extension, the M-D project if possible) along toward working well with 100% HTTPS use cases...

    For image content issues, additional temporary 'bridge' solutions are setting UPLOAD_URL_PATH per site to use standard (or custom) location, essentially only explicitly defining use of https

    Another, though I am not positive how this will interact w/ DM (or M-D) is in wp-config:
    define( 'WP_CONTENT_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/wp-content' );

    For this current testing, I intentionally did not take any measure to correct these elements

    The main point I'm trying to focus on is permalinks using https

    This lead me to find in DM code and try working with
    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);

    Which brings us back to the summary post I did for you above...

    If you are not using this approach, then if I may ask, have you worked out a different way to have permalinks for mapped domains properly use https w/ the mapped domain?

    (eg. the value shown as permalink base at site admin > settings > permalinks | the value generated and saved in db upon new post/page creation becomes the value shown at post edit page and the value supplied by the 'get shortlink' button | the permalink url is also used by defaul in all feeds | etc... what I'm getting at is that successfully touching permalink value makes a huge effect in WP/MS and has significant security/seo/UX impacts

    Cheers, Max

    • Sybre Waaijer

      Hi @WPMS.Network,

      If you are not using this approach, then if I may ask, have you worked out a different way to have permalinks for mapped domains properly use https w/ the mapped domain?

      Nope, not using that approach. And well, kinda have worked out a different way.

      My setup is quite complex at this moment but gets the job done.
      First off, I have installed this mu-plugin (same as my previous reply):
      https://hostmijnpagina.nl/share/ssl-mixed-fixer.zip

      Secondly, I'm using .htaccess magic:

      <IfModule mod_rewrite.c>
            RewriteEngine On
            RewriteCond %{HTTPS} !=on
            RewriteRule .* - [E=CANONICAL:http://hostmijnpagina.nl%{REQUEST_URI},NE]
            RewriteCond %{HTTPS} =on
            RewriteRule .* - [E=CANONICAL:https://hostmijnpagina.nl%{REQUEST_URI},NE]
         </IfModule>
         <IfModule mod_headers.c>
            Header set Link "<%{CANONICAL}e>; rel=\"canonical\""
         </IfModule>
      
      #BEGIN Adminbar registration fix
      		RewriteCond %{REQUEST_URI} !/wp-signup\.php [NC]
      		RewriteRule ^/?wp-signup(.*)$ https://hostmijnpagina.nl/registreren/ [L,R=302]
      #END Adminbar registration fix
      
      #BEGIN all subdomains force SSL
      		RewriteCond %{HTTPS} off
      		RewriteCond %{HTTP_HOST} ^(.*)\.hostmijnpagina\.nl [NC]
      		RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
      #END all subdomains force SSL
      
      #BEGIN main blog SSL
      		RewriteCond %{HTTPS} off
      		RewriteCond %{HTTP_HOST} ^hostmijnpagina\.nl [NC]
      		RewriteRule ^(.*)$ https://hostmijnpagina.nl/$1 [R=301,L]
      #END main blog SSL

      Third, I'm using MaxCDN in combination with W3 Total Cache, this will solve all file issues automatically for me by exchanging the file url's for the CDN url's and while doing so also considering HTTPS.

      Last but not least, I have this on top of my .htaccess file to prevent cross-domain file issues:

      #BEGIN ENABLE CORS on images
      <IfModule mod_setenvif.c>
        <IfModule mod_headers.c>
          <FilesMatch "\.(gif|png|jpe?g|svg|svgz|ico|webp)$">
            SetEnvIf Origin ":" IS_CORS
            Header set Access-Control-Allow-Origin "*" env=IS_CORS
          </FilesMatch>
        </IfModule>
      </IfModule>
      #END ENABLE CORS on images

      There we go I hope this helps.

      • wp.network

        Very helpful @Sybre

        Many thanks for your input, also as per usual!

        I will do some work with your approaches asap, they're very interesting and useful!

        For the moment, I will press on with this for a bit so as to (hopefully) provide a testbed for Sam to try working with for a moment as WPMUdev doesn't seem to have testing capicity to replicate for SNI and CF and such, though I'm confident that the above documented issues are replicable using very standard systems...

        Again @Sybre, you've always got great inputs, appreciate your consideration

        Kind Regards, Max

        ps. for general context, my current setup is costing $60/m for server & CF ...overhead in domain names & opportunity costs are relatively enormous... I figure others have somewhat similar situations, and am happy to provide sever and testing if it helps produce results all around

  • wp.network

    @Ashok @Sam

    any update on this?

    Sam are you still experiencing connectivity issues? You mentioned above that you were unable to visit my sites or gain access via WPMUdev Dashboard Support Access and I show no Staff logins during current 'access granted' period...I have reextended the Support Access in any case. I did get a confirmation on the creds submission you asked for... have you been able to gain access to the server using the supplied creds? Please let me know if you face any further connectivity/access issues and I will do my best to address

    I'd like to know if you have been able to replicate these issues or not, most specifically re. permalinks issue and DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN - I am happy to provide any clarifications on replication steps, please advise

    Also if you'd like to try anything out on my setup for some testing (btw, it is possible to take CF totally out of the picture with relative ease if that would make things easier for y'all, though imho it should not make a diff. here when properly configured)...

    If I don't hear back soon then I will likely follow Ashok's suggestion and wipe the instance and set up a totally fresh WPMS with only absolutely needed components:
    Theme:
    Twenty Fifteen
    Plugins:
    Domain Mapping
    (WPMUdev Updates Dashboard)

    I will set up to avoid CF completely for the time being for certainty's sake.

    I will then bring the network back to its current state (as documented above).

    Let me know if y'all have another idea in mind or any other updates on the situation

    Cheers, Max

  • wp.network

    update @Ashok @Sam

    I have completed the re-configuration & re-installation of the network.

    All involved domains are using our own nameservers and have validated SSL - CF is no longer involved.

    The public_html directory and database/user were deleted.

    WP was then reinstalled, network was setup & DM installed. Domains were then mapped and original permalinks bug shown. Then we define DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN in wp-config to be true which fixes permalinks bug yet causes additional buggy behavior as a seeming side-effect (as described in detail above).

    A few odds-and-ends differences in the setup:

    I have returned to setting SITEURL and HOME to use https for primary and all subsites (except one subsite which I left default as a 'control').

    To address Sam's concern re. potential conflict when setting SITEURL and HOME while also using the https options at network > settings > domain mapping and also as my preference is also to set these options to 'No' and control this behavior elsewhere (eg. in .htaccess or other server level config/through CDN like CF or MaxCDN) I have set these options to 'NO'. (Also, please see this results summary post above)

    Currently I have taken no steps to enforce https for primary other than making the standard wp-config define for FORCE_WP_ADMIN and setting SITEURL and HOME to use https

    The network has ONLY TwentyFifteen Theme 1.0 and Domain Mapping plugin 4.3.0.4 - if you would like me to add the WPMUdev Updates Dashboard for Staff Access please let me know, the WPMS login and server creds remain the same as submitted to Sam

    Primary: https://wpms.network
    Subsites & Mapped Domains:
    https://tivism-secure-1.wpms.network > https://tivism.com
    https://sub1-tivism-secure-1.wpms.network > https://sub1.tivism.com
    https://sub2-tivism-secure-1.wpms.network > https://sub2.tivism.com
    https://sub3-tivism-secure-1.wpms.network - (no mapped domain)
    https://cannabizwebsite-secure-6.wpms.network > https://cannabiz.website

    ------------------------------------------------------------------------------------------------------------------------

    Again, fixing the permalinks is a huge step forward and DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN seems to work well besides the above documented gnarly side-effect w/ the malformed frontend link URLs...

    using a simple defing in wp-config like

    define('DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true);
    seems easy enough for most to handle if they're at all ready to be working with 100% HTTPS networks

    What can we look at to get this approach fixed up and working?

    I have some friends w/ deeper php skillz than mine who are willing to lend me a hand, esp. if we know where to start looking... please advise

    ####################################################################
    Here is a screencast documenting almost the entire WPMS setup process (I didn't show my sensitive system files, you can check the server if needed):
    http://www.screencast.com/t/HWwtiok8iD
    http://youtu.be/oWGVzsIuUcA
    ####################################################################

    BUGS PERSIST - Replication was Successful

    While we'd appreciate as much info on this as you can supply, as a beginning,
    please, can you confirm/deny your replication?

    Kind Regards, Max

  • wp.network

    @Ashok @Vaughan @Sam (I mention Vaughan as we spoke of this setup the other day)

    Hey y'all... I'm feeling a little 'left out in the cold' here...

    To be very straight-forward: I see that @Ashok is active on other DM threads this morning as well as other Staff on deck, basically why is this bug report being ignored?

    At this point, I am only seeking confirmation that you have been able to replicate the issue (or at least that the testing is being currently attended to, when it will be completed).

    Even if you were to provision a new server to do the replication on, we're talking a few hours work at most (I completed the replication screencast below in about 30min)... my time is valuable and I am beginning to feel like I am wasting it in trying to work on this issue w/ WPMUdev.

    I wish to do other things with my network than hold it steady in a buggy state, especially if WPMUdev staff does not need me to or is not interested in using the current WPMS in testing potential solutions.

    Please advise:
    1) have you attempted to replicate & verify the issues w/ permalinks?
    2) have you been successful in replication?
    3) what is next?

    Kind Regards, Max

  • wp.network

    update: we have decided to move on with setting up a fresh instance to test WP-Multi-Network

    https://github.com/johnjamesjacoby/wp-multi-network

    I have made backups of current state and can restore if needed, hopefully the documentation and screencast provided above prove sufficient.

    It does bother me a bit that we were unable to get confirmation of replication in a reasonable span of time, yet do understand being busy... please do update w/ your results when available as we remain very interested in resolving this issue

    Kind Regards, Max

  • wp.network

    network-of-networks on SNI/CF = awesomeness
    https://github.com/wpmsnetwork/wp-multi-network/tree/onlyhttps
    (assumes SITEURL and HOME are manually - for now! - set to actually use https though it should be fine if not done)

    in .htaccess (above WP rules):

    RewriteCond %{HTTPS} !=on
    RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

    in wp-config:

    define('FORCE_SSL_ADMIN', true);
    
    /** Multisite */
    define('WP_ALLOW_MULTISITE', true);
    define('MULTISITE', true);
    define('SUBDOMAIN_INSTALL', true);
    //define('DOMAIN_CURRENT_SITE', 'original.primary');//not needed with wp-multi-network
    define('PATH_CURRENT_SITE', '/');
    //define('SITE_ID_CURRENT_SITE', 1);//not needed with wp-multi-network
    //define('BLOG_ID_CURRENT_SITE', 1);//not needed with wp-multi-network
    define('DOMAIN_CURRENT_SITE', $_SERVER['HTTP_HOST']);
    define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST']);
    define('WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST']);
    define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content');
    define('WP_CONTENT_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/wp-content');
    define('WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/plugins');
    define('WP_PLUGIN_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/wp-content/plugins');
    define('PLUGINDIR', dirname(__FILE__) . '/wp-content/plugins');
    define('UPLOADS', 'uploads');
    define('WPMU_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/mu-plugins');
    define('WPMU_PLUGIN_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/wp-content/mu-plugins');
    define('MUPLUGINDIR', dirname(__FILE__) . '/wp-content/mu-plugins');

    There are doubtless many cleverer way to do this, yet this get the job done nicely for now... namely doing what we can to force WPMS to 'natively' use https prior to actually changing values in db following new subsite creation - essentially re-setting default values works, so does actually moving things around while we're at it

    for now we intend to continue exploring the network-of-networks model

    ##################################################################

    remain interested in digging deeper into DM https permalinks issue when y'all are ready

    aloha, max

  • wp.network

    Update @Sam @Ashok

    We have finished playing around with WP-Multi-Network (we also messed around with humanmade/mercator) and though we had were pleased at how little weirdness was generated and intrigued by possibilities (so many possibilities...!) of network-of-networks, we have returned to our established single-network model...

    Which brings us back up against this issue with malformed links in admin bar (and default meta-widget) for frontend of mapped domains...

    We have two tools which need to be accessed from the frontend as a logged-in user:
    Dynamik Website Builder (the Frontend CSS tool)
    WPBeaverBuilder Pro

    I will be testing these tools tonight and will update with results.

    If this bug with malformed links from frontend of mapped domains affects the above tools we will also reach out to the respective support teams for assistance in resolving this situation.

    Also, I am mystified why there has been no staff response on this thread since @Ashok asked me to re-replicate on March 4 (17 days ago) despite my reaching out via twitter and posting a (contributing & supportive) comment at https://premium.wpmudev.org/blog/domain-mapping-update/#comment-155027

    I am happy enough to let that all be if we can see some kind of engagement from WPMUdev on this; we're solution/action oriented folks over here and understand that s happens =)

    Please advise re. the issue with malformed links from frontend of mapped domains for logged-in users - once we clean this up then DM will be able to accomplish canonical permalinks with https mapped addresses... a significant achievment!

    Kind Regards, Max

  • Jack Kitterhing

    Hi there Max,

    Hope you're well today! Appreciate your patience on this, I've been taking a look at this thread and have done a lot of testing myself on this issue today and have replicated too with various different setups.

    Would you mind sending through the following information please?

    - In the subject field add "Attn: Jack Kitterhing"
    - Link back to this thread
    - Include admin/network access
    - Include FTP
    - Include cPanel access
    - Include any relevant URLS for your site

    On the contact form, select "I have a different question", this ensures it comes through and gets assigned to me.

    https://premium.wpmudev.org/contact/

    As we're hoping we may be able to apply a patch to your site this week, before the official plugin updates gets released, so it'll save some time for yourself.

    It'll also help one of our developers looking into this for you.

    Thank you!

    Kind Regards
    Jack.

  • wp.network

    @Jack Kitterhing

    Thank you =)

    I will reinstall the network, install WPMUDEV DM and Dashboard, replicate the situation with at least a few subsites and then send the creds email shortly.

    I did already provide Sam with creds for server & WPMS and I will be sending you the same creds, fyi.

    Again Jack, thanks so much for engaging here... I was starting to kinda freak out a bit on this one as I was really up against my current skill limits... Its our last major issue to clear away and, well, it means more than alot to have your help in making it happen!

    Kind Regards, Max

    ps. FYI when looking at my server:
    In this fresh setup I will be returning to my preferred configuration wherein I move most of the contents from wp-config to a custom file above public_html and include the contents by reference... don't be alarmed, just follow the file path... =)

    pps. this looks awesome: https://wpperformanceprofiler.interconnectit.com/

  • wp.network

    Update @Jack Kitterhing

    Fresh network setup complete. Creds sent. Support Access enabled.

    Please document any changes made at server!

    I have also enabled DOMAINMAPPING_ALLOWMULTI figuring that we may as well make sure that that doesn't throw any curve balls...

    From my config file:

    /** Domain Mapping */
    define( 'SUNRISE', 'on' );
    define( 'DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true );
    define( 'DOMAINMAPPING_ALLOWMULTI', true );
    /** WPMS */
    define( 'WP_ALLOW_MULTISITE', true );
    define( 'MULTISITE', true );
    define( 'SUBDOMAIN_INSTALL', true );
    define( 'DOMAIN_CURRENT_SITE', 'wpms.network');
    define( 'PATH_CURRENT_SITE', '/' );
    define( 'SITE_ID_CURRENT_SITE', 1 );
    define( 'BLOG_ID_CURRENT_SITE', 1 );
    define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] );//working?
    define( 'WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] );//working?
    define( 'WP_CONTENT_DIR', '/home/XXXX/public_html' . '/ext' );
    define( 'WP_CONTENT_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/ext' );
    define( 'WP_PLUGIN_DIR', '/home/XXXX/public_html' . '/ext/plugins' );
    define( 'WP_PLUGIN_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/ext/plugins' );
    define( 'PLUGINDIR', '/home/XXXX/public_html' . '/ext/plugins' );
    define( 'UPLOADS', 'uploads' );
    define( 'WPMU_PLUGIN_DIR', '/home/XXXX/public_html' . '/ext/netcom' );
    define( 'WPMU_PLUGIN_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/ext/netcom' );
    define( 'MUPLUGINDIR', '/home/XXXX/public_html' . '/ext/netcom' ); // Relative to ABSPATH.  For back compat. dirname(__FILE__)

    Current .htaccess file:

    # BEGIN Secure Files
    <FilesMatch "^.*(error_log|wp-config\.php|php.ini|\.[hH][tT][aApP].*)$">
    Order deny,allow
    Deny from all
    </FilesMatch>
    # END Secure Files
    
    # BEGIN Custom HTTPS Control
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{HTTPS} !=on
    RewriteRule ^.*$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    </IfModule>
    # END Custom HTTPS Control
    
    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    # add a trailing slash to /wp-admin
    RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
    RewriteRule ^(.*\.php)$ $1 [L]
    RewriteRule . index.php [L]
    </IfModule>
    # END WordPress
    
    # BEGIN CORS Controls
    # Images
    <IfModule mod_setenvif.c>
    <IfModule mod_headers.c>
    <FilesMatch "\.(gif|png|jpe?g|svg|svgz|ico|webp)$">
    SetEnvIf Origin ":" IS_CORS
    Header set Access-Control-Allow-Origin "*" env=IS_CORS
    </FilesMatch>
    </IfModule>
    </IfModule>
    # Webfonts
    <IfModule mod_headers.c>
    <FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css|css)$">
    Header set Access-Control-Allow-Origin "*"
    </FilesMatch>
    </IfModule>
    # END CORS Controls

    https://test.wpms.network
    https://wpmscloud-secure-1.wpms.network > https://wpmscloud.com
    https://wpmsclub-secure-1.wpms.network > https://wpmsclub.com
    https://wpmshost-secure-1.wpms.network > https://wpmshost.com (primary), https://wpmshosting.com (secondary)

    Excited to move forward =)

    Kind Regards, Max

  • wp.network

    Support Access has been Extended

    fyi, all domains in current test setup are running through CF, yet I have carefully turned off CF cache & security features as far as possible while still using CF for SSL... each domain has page rules as follows:

    *domain.tld/
    *domain.tld/*

    set to bypass all caches and turn of all performance/security other than SSL (primary has additional rules). Again, please let me know any Qs w/ CF =)

    I will also setup some mapped domains that do NOT use CF for SSL, instead using validated SSL certificates via SNI at server so that we can be thorough as possible in testing.

    Cheers, Max

    • wp.network

      word @Jack Kitterhing =)

      Thanks for the update, it seriously helps me maintain a peaceful state of being ;~p

      ...as mentioned above, I will setup a few additional mapped domains to test with:
      premium.support.wpms.network - will use CF for DNS only (no 'orange cloud' in DNS) - single SSL

      tivism.com - will use CF for DNS resolution only (no 'orange cloud' in DNS and CF generally 'paused') - has a Wildcard SSL certificate setup, could theoretically work with Multi-Domains (works with network-of-networks)

      cannabiz.website - will NOT use CF at all, will use our own nameservers - single SSL

      In particular, if you'd like to take a shot at trying out Multi-Domains in this context in order to experience the behavior/etc then I fully encourage you to do so now using *tivism.com to test with =)

      Cheers, Max

      ps. please allow a few hours for propagation of course...

      Update: finished configuration of additional sites, DNS was already appropriately setup =)
      ( I also added https://subtest.tivism.com as a mapped domain )

      The observed behaviors remain consistent in all examples, including https://premium.support.wpms.network

  • Jose

    Hello there Max,

    Hope you are doing great today, and thanks for all your detailed feedback and cooperation here.

    if you hover over the malformed link in the element inspector, it reveals an even weirder url that made us think of possible query string issues

    The problem is more simple than that. There is a bug in the parsing logic for the original url. Therefore, it returns this broken url:
    httpshttstivism-secure-1.wpms.network/wp-login.php
    When the browser is not able to find a valid protocol/schema it will treat the url as a relative one, prepending the base url https://tivism.com/.

    I fixed the parsing issue. I would appreciate if you can take the time to test the beta version attached here and give me your feedback.

    Thanks in advance,
    Jose

  • wp.network

    @Jose for sure DM 4.3.0.5b seems to fully resolve issue w/ frontend links when using
    define( 'DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', true );
    to address http (non-cononical) permalinks for https mapped domains... =)

    However, if
    define( 'DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', false );
    then issue with http (non-cononical) permalinks for https mapped domains remains, fyi...

    Also, what do you think are the chances of addressing Multi-Domains with https issues as mentioned briefly above and by myself and @Axel (@Axel had their own thread too)?

    I mention this especially as I know you have been involved at https://premium.wpmudev.org/forums/topic/domain-mapping-plugin-breaks-multi-domain-sites#post-841503 which seems like it may somewhat connect with issue generally, though the coding involved is yet beyond me to really understand well enough to make intelligent commentary...

    While I'd love to see everything work asap of course, even getting a rough sense of the odds of M-D https support in the near term would be very useful... any thoughts?
    (should I just open a fresh thread for such a Q?)

    Kind Regards, Max

    ps. still think you're a rockstar; re. further Qs, its only that once an issue is solved we must advance to the next, amirite?!

  • Jose

    Hey Max,

    However, if
    define( 'DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN', false );
    then issue with http (non-cononical) permalinks for https mapped domains remains, fyi...

    Isn't that expected? I mean, If you want https permalinks you need to define the constant to true. Am I missing something?

    Also, what do you think are the chances of addressing Multi-Domains with https issues

    Could you please replicate the issue in your site so that I can try a fix? (too many threads and posts, so I'm a bit lost at this point).

    its only that once an issue is solved we must advance to the next, amirite?!

    You are right for sure

    Cheers,
    Jose

  • wp.network

    Cheers Jose!

    Isn't that expected? I mean, If you want https permalinks you need to define the constant to true. Am I missing something?

    I guess you are saying that in current DM it is expected behavior to have http permalinks for https mapped domains unless constant is defined true - correct? (this is to allow for other features/configurations?)

    edit: from my perspective it seems that if a domain is mapped with https selected as protocol then the permalinks should be https ... I assume though that y'all are more familiar with the range of use cases that DM is being put to and are in good position to know if such behavior would negatively impact other use cases... having an optional constant to define is acceptable for our use as long as it works =)

    Could you please replicate the issue in your site so that I can try a fix? (too many threads and posts, so I'm a bit lost at this point).

    I apologize for the confusion and am happy to replicate so that you can have a look...

    from above when I tested current M-D w/ DM 4.3.0.4

    mostly the evident issue with M-D is while original admin address works, the frontend of subsites using a multi-domain as base have redirect loop between http and https - the extra wrinkle is that since backend is available at original address, one is able to perform a domain mapping with https that, unlike the original subsite address, resolves and is forced to https as expected... I think that this has to do with how M-D works with the DOMAIN values

    I will test now w/ DM 4.3.0.5b and will update shortly when ready =)

    Kind Regards, Max

    • Jose

      Max,
      Regarding the first point, while I'm not an assiduous user of DM nor the lead developer, I'm just saying that the constant is there for some reason, and setting it to false or true should make some difference.
      If this is not the expected behaviour, what do you think should be the expected? Is there some scenario that you can't cover with the current behaviour?

      I'll wait for your update on the second point.

      Thanks,
      Jose

      • wp.network

        update @Jose: replication complete w/ Multi-Domains 1.3.4.3

        tivism.com used for multi-domain base - has validated WIldcard certificate at server (is currently using CF only for DNS resolution).

        The behavior matches the description given above.

        I made three test sites:
        sub1.tivism.com
        sub2.tivism.com - (SITEURL and HOME use https)
        sub3.tivism.com

        All produce a redirect loop on frontend; backend admin is fine with DM set to use 'original' for login/admin (also, I began tests w/o the DM_FORCE constant defined, then defined - behavior steady).

        I then mapped domains as follows:
        sub1.tivism.com > sub1map.tivism.com
        sub2.tivism.com > sub2map.tivism.com

        the frontends of the mapped domains (in this case also being subdomains of multi-domain base domain) resolve just fine...

        sub3.tivism.com has been left in the redirect loop so you can easily see it yourself =)

        I have also made another screencast to document/explain if more clarity is needed... I will post link when its ready... otherwise, Support Access is active and you are very welcome to try a fix for this! I can send you server creds as needed, or you can obtain from either Sam or Jack =)

        (PLEASE do document any changes made at server!)

        Kind Regards, Max

  • wp.network

    update @Jose @Sam

    I am going to now proceed in some additional testing with WP Rocket cache & CF...

    The current configuration with Multi-Domains at tivism.com will be left in place for your inspection and testing...

    If needed I can replicate again with a clean instance for more careful testing.

    We are so stoked with the awesome leaps & bounds that WPMUDEV is making in relatively rapidly adapting to an https web... really, its a major shift in use patterns and y'all have done a great job in (pivot, sprint) keeping up... thank you very much =)

    Kind Regards, Max

  • Jose

    Also, I fixed a glitch on the routine to check "Wildcard DNS Availability", but it is still showing "unavailable" for tivism.com.

    The explanation is simple. In order to check the wildcard, MD will request a random subdomain and expect for a HTTP status 200.

    For instance, this subdomain:
    http://3a7ca7.tivism.com/

    As you can check in your browser, it is not resolving as expected.

    Cheers!
    Jose

    • wp.network

      Hey Jose,

      Thank you very much! This is stupendous progress!!

      1) Thanks for being careful to note changes!

      2) As far as I can tell, it is now working as expected!

      2a) the frontend of https://sub3.tivism.com now resolves

      2b) I created (and set SITEURL & HOME to use https) https://sub4.tivism.com and it also resolves

      2c) My one remaining concern is around the M-D Single Sign-On feature...
      'out-of-the-box' behavior - dm_sso_setup is second request made:
      http://tools.pingdom.com/fpt/#!/BHWrQ/https://sub4.tivism.com/2015/awesomeness-test/
      https://webpagetest.org/result/150401_MZ_2CT/

      With WP Rocket cache (CF 'Paused') - dm_sso_setup request is pushed to middle of the pack:
      http://tools.pingdom.com/fpt/#!/dQ0D1i/https://sub4.tivism.com/2015/awesomeness-test/
      https://webpagetest.org/result/150401_QD_2NP/

      With WP Rocket Cache & CF 'Active' - dm_sso_setup request is pushed to middle of the pack:
      http://tools.pingdom.com/fpt/#!/43ZTa/https://sub4.tivism.com/2015/awesomeness-test/
      https://webpagetest.org/result/150401_YX_JS/

      I have DM Cross Domain Auto-login active and set to load async in footer in addition to the M-D SSO feature... I am frankly not sure what is expected with this combo at thispoint, especially as I am running the DMbeta and I know that Sam has been putting a bunch of work into this recently on DM side...

      3) Re. the fix to "WIldcard DNS Availability" and your note...
      3a) awesome that you were able to make an improvement
      3b) the outstanding issue you point out with
      http://3a7ca7.tivism.com/
      is associated with CF and https use... You happened to test when I had reactivated CF for my own testing =)

      Basically, you can use a wildcard DNS record at CF yet it will not run through their proxy or cache... and if you are requesting an https resource it will not resolve at all...

      The issue you had was also related to my current .htaccess which would have returned a 301 and an https address, which CF then has an error with... the solution is having a CNAME for every subsite (and a CF API integration is awesome for that!).

      I have now disabled ('Paused') CF for tivism.com and the URL
      http://3a7ca7.tivism.com/
      now behaves as expected =)

      Cheers, Max

      • wp.network

        update/edit to fix links & make update description:

        2c) My one remaining concern is around the M-D Single Sign-On feature...
        'out-of-the-box' behavior - dm_sso_setup request is shown earlier in waterfall:
        pingdom result
        webpagetest result

        With WP Rocket cache (CF 'Paused') - dm_sso_setup request is shown later in waterfall:
        pingdom result
        webpagetest result

        With WP Rocket Cache & CF 'Active' - dm_sso_setup request is shown later in waterfall:
        pingdom result
        webpagetest result

        I have DM Cross Domain Auto-login active and set to load async in footer in addition to the M-D SSO feature.

        I am frankly not sure what is expected with this combo at this point, especially as I am running the DMbeta and I know that Sam has been putting a bunch of work into DM Cross Domain auto-login... perhaps we will need to await his opinion on the matter when he gets time...

        ##############################################################

        Mostly I just want to say that Jose, you've really come though on these issues!

        Thanks again - you totally earned that rock'n'roll kitten t-shirt =)

        Look forward to an update re. if above SSO behavior is in line with expectation and then seeing these awesome fixes pushed into new project releases!

        Kind Regards, Max

  • wp.network

    @Sam @Jose

    update: latest DM beta has changed status on Multi-Domains functionality, it no longer works with https - we updated @Sam's thread
    https://premium.wpmudev.org/forums/topic/domain-mapping-beta-huge-update-sso-async-rewritten#post-867417
    with a brief test result, will do further updates here as needed...

    Support access is active if you want to look at settings, creds for WPMS and server remain the same, can resubmit if needed.

    Please Advise =)

    Kind Regards, Max

  • Sybre Waaijer

    Hello everyone

    I've been briefly skipping a lot of text and only watched the pictures. What I get from this is that HTTPS posts don't automatically change when desired.

    For this, I'll leave you the following pieces of code I use. Please advice if they work:
    https://cyberwire.nl/share/HTTPSfixes.zip

    This zip file contains everything I use to get HTTPS going well plus it contains some extra's which I've never released (because of insignificance)

    I also use W3 Total Cache to replace Super Cache and any other caching system since it can handle multiple Memcached servers for page caching while also doing a great job of adding CDN's (I use MaxCDN).

    Hope this helps

    NOTE: Although the "permalinks" might not be shown correctly, the front-end is what matters. For that, everything just works and no one, not even google or any site scanner is complaining.

    PS. my domainmapping settings, once more:
    Allow multiple mappings: YES
    Administration mapping: DOMAIN BY USER (there's a bug with caching/permalinks if different)
    Login mapping: ORIGINAL DOMAIN (so they get SSL)
    Cross-domain autologin: YES + Async
    Check: NO
    Force admin: YES
    Force front-end: NO
    Excluded: mymaindomain.com + Disallow sub-domains of excluded
    Enable excluded: I have no idea what they do lol, so unchecked for both

    @Sam feel free to implement these fixes into your code as extra's. Note that ssl-mixed-fixer.php is a fork but I'm not sure if you can use it in a paid product.

  • Sam

    hi @WPMS.CLUB

    Trying to find my way through the comments here but no way no chance to fully understand what the different problems are.
    Please note that i'm trying to figure out the problems and release a fix for them and will be thankful if you helped me by writing a real brief summary in bullets. I want to know how many issues you're facing and what they are, no need to add lots of details, because i usually get lost in too much details. Please keep it as concise as possible.

    Thanks for your patience and help.
    Sam

    • wp.network

      Cheers @Sam

      1) to be VERY clear, I think that @Jose should be consulted around his work in this thread.
      1a) @Jose's patch has resolved all our issues with the DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN
      1b) the current DM beta seems to have kept this fix. Again, this issue is resolved! =)

      2) @Jose then went on to address the DM codebase issue with Multi-Domains use w/ https
      2a) @Jose then addressed a small issue with MD codebase

      3) The patched DM that @Jose produced had made Multi-Domains work with https and SSO worked across all subsites

      4) with most recent DM beta, Multi-Domains and SSO are no longer working with https usage

      I have summarized current behavior at
      https://premium.wpmudev.org/forums/topic/domain-mapping-beta-huge-update-sso-async-rewritten#post-868325

      "A) We installed a fresh network for this test:
      - only essential plugins and Twenty Fifteen (no .htaccess tricks, all values for SITEURL and HOME use https)
      - we also cut CloudFlare out of the picture, we are currently using our own nameservers
      - both domains in test have valid WIldcard SSL certs at server.
      - Network primary is https://wpms.network
      B) Domain Mapping set up w/
      - Login/Admin at original addresses
      - DM set to use Cross-Domain Auto-Login, and to load async

      C) Multi-Domains set up, SSO was 'Enabled'
      - tivism.com was then set up as a MD domain

      D) a new subsite was created: https://sub1.tivism.com
      - Logged in as superadmin to primary, we are NOT able to visit admin for sub1.tivism.com nor does the SSO work on frontend.

      - Logging into the frontend of https://sub1.tivism.com with superadmin brought us to network primary, however, we were then able to successfully visit the subsite admin and the admin bar was visible on frontend.

      E) We the made a second subsite: https://sub2tivism.wpms.network
      - used DM to map the following domain to this subsite (selecting 'https' as the protocol):
      https://sub2.tivism.com
      - We are able to visit this admin for this subsite, and the frontend resolves and is forced to the mapped domain (however, https is NOT enforced! eg. currently, http://sub2.tivism.com also resolves)
      - SSO is NOT working for https://sub2.tivism.com frontend
      - Even when we logged in directly from frontend of https://sub2.tivism.com with superadmin the admin bar is NOT displayed on frontend (however, the meta-widget and other links are good!)

      I apologize for any confusion, I am doing my best and appreciate guidance on what works for you

      update: have now tested without MD installed and SSO issue described above as 'E)' remains unchanged
      (note: will now re-install MD and replicate the issues described above as 'D)' for your inspection)

      update: we also tested with all SITEURL and HOME values using http and this seems to have no impact on behavior in any test configuration

      Cheers, Max

  • wp.network

    ...so it seems like DM 4.4 has been released and the changelog notes that DM_FORCE_PROTOCOL_ON_MAPPED_DOMAIN has been removed.

    I am interested to know, does DM 4.4 allow canonical permalinks for https mapped domains?

    Have the fixes for SSO w/ Multi-Domains when using https been included in this release?

    Will test, discover and then open a clean thread as needed =)

    Kind Regards, Max

  • Sybre Waaijer

    Hi Max!

    I found a piece of code online and I wonder if it would fix your problem. I haven't tested it myself but I think it could work :3

    What it does:
    Uses: https://codex.wordpress.org/Function_Reference/wp_make_link_relative
    To convert the list of code below to relative URL's, therefor removing the http:// protocol and calling the one relative to the current page.

    <?php
    /*
     * Plugin Name: Relative URL
     * Plugin URI: http://sparanoid.com/work/relative-url/
     * Description: Relative URL applies wp_make_link_relative function to links (posts, categories, pages and etc.) to convert them to relative URLs. Useful for developers when debugging local WordPress instance on a mobile device (iPad. iPhone, etc.). Edited by Sybre to only do attachments and pages.
     * Version: 10.0.10sw
     * Author: Tunghsiao Liu & Sybre Waaijer
     * Author URI: http://sparanoid.com/
     * License: GPLv2 or later
     */
    
    	add_action( 'template_redirect', 'relative_url' );
    
    	function relative_url() {
    	// Don't do anything if:
    	// - In feed
    	// - In sitemap by WordPress SEO plugin
    	if ( is_feed() || get_query_var( 'sitemap' ) )
    		return;
    	$filters = array(
    		'post_link',       // Normal post link
    		'page_link',       // Page link
    		'attachment_link', // Attachment link
    		'get_shortlink',   // Shortlink
    
    		// site location
    		'includes_url',
    		'site_url',
    		'site_option_siteurl',
    		'network_home_url',
    		'network_site_url',
    
    	// attachments
    		'wp_get_attachment_image_src',
    		'wp_get_attachment_thumb_url',
    		'wp_get_attachment_url',
    	);
    
    	foreach ( $filters as $filter ) {
    			add_filter( $filter, 'wp_make_link_relative' );
    	}
    
    }
    ?>
  • wp.network

    Thanks @Sybre that does look interesting...

    My issue with canonical permalinks is a best practices thing... canonical means canonical, GUID means GUID and these awkward artifacts/concepts exist for very good reason (and for instance, I see this perspective represented in your code above: exceptions made for feeds and sitemap & this open the Q: will values in feeds and sitemap use desired scheme?).

    Imho, if one wants to use relative URLs thats fine yet this should be a totally distinct decision - canonical should be canonical, then altered as desired... =)

    I do understand that this is a bit theoretical and for most practical purposes we have *workable* solutions in the here-and-now, just trying to advocate for what I see as best practice generally.

    The outstanding issue of note remaining is SSO w/ Multi-Domains when using 100% https - @Jose had it working, then it seemed broken again just before release... will test this aspect and open new thread w/ update...

    Sybre, as always your insights and consideration are vastly appreciated and enjoyed!

    Cheers, Max

    • Sybre Waaijer

      Hi @WPMS.CLUB

      From what I know, search engines try to find the sitemap, if it exists it will try to crawl the pages even if not found through your navigation menu's.

      That's why they recommend a sitemap! So search engines know what's out there!

      When it crawls a page, it will take the canonical URL from the meta tag if presented and/or it will create his own for the search index.

      From there everything is fine A sitemap is actually merely a guideline.

      Anyway, the reason it's left out in the plugin is from what I understand as a conflict with SEO tools like Yoast's.

      Anyway, if you wish to get canonical URL's, taking away the work from Google and other search engines, maybe this edit will help you It will make them canonical and uses is_ssl().

      <?php
      /* Plugin Name: Rebuild URL
       * Plugin URI: https://cyberwire.nl/projects/
       * Description: Fixes canonical link issues presented in some pages. Loops through relative and canonical to make it the correct scheme.
       * Version: 1.0.0alpha
       * Author: Sybre Waaijer
       * Author URI: https://cyberwire.nl
       * License: CopyLeft
       */
      
      add_action( 'template_redirect', 'relative_url' );
      
      function relative_url() {
      	// Don't do anything if:
      	// - In feed
      	// - In sitemap by WordPress SEO plugin
      	if ( is_feed() || get_query_var( 'sitemap' ) )
      		return;
      	$filters = array(
      		'post_link',       // Normal post link
      		'page_link',       // Page link
      		'attachment_link', // Attachment link
      		'get_shortlink',   // Shortlink
      
      	// site location
      		'includes_url',
      		'site_url',
      		'site_option_siteurl',
      		'network_home_url',
      		'network_site_url',
      
      	// attachments
      		'wp_get_attachment_image_src',
      		'wp_get_attachment_thumb_url',
      		'wp_get_attachment_url',
      	);
      
      	foreach ( $filters as $filter ) {
      			$canonical = esc_url(home_url(wp_make_link_relative( $filter )));
      			add_filter( 'the_content', $canonical );
      	}
      
      }
  • Sybre Waaijer

    Hi @WPMS.CLUB

    I know this topic is old but I just thought about it while releasing another update for the "AutoDescription" plugin.

    I've made a function which adds a canonical URL in the header which will point to the mapped domain if it exists. This way Google knows where to look after the domain has been mapped

    I've edited a little bit so it probably won't crash your site if you use it (since it's pulled out from the plugin).

    function hmpl_ad_canonical_standalone_function($url = '') {
        global $wp;
    
        if ( empty($url) ) {                
    
            //* Get url from options
            if ( function_exists( 'hmpl_ad_get_custom_field' ) )
                $url = hmpl_ad_get_custom_field( '_genesis_canonical_uri' ) ? hmpl_ad_get_custom_field( '_genesis_canonical_uri' ) : '';
    
            //* Genesis fallback
            if ( empty($url) ) {
                $theme_info = wp_get_theme()->get('Template');
                if ( $theme_info == 'genesis' ) {
                    $url = genesis_get_custom_field( '_genesis_canonical_uri' ) ? genesis_get_custom_field( '_genesis_canonical_uri' ) : '';
                }
            }
    
            //* Generate URL
            if ( empty ($url) ) {
    
                //* Domain Mapping canonical url
                if ( is_plugin_active( 'domain-mapping/domain-mapping.php' ) ) {
                    global $wpdb,$blog_id;
    
                    //* Get the URL path
                    $path = $wp->request;
    
                    //* Check if the domain is mapped
                    $mapped_domain = wp_cache_get('wap_mapped_domain_' . $blog_id, 'domain_mapping' );
                    if ( false === $mapped_domain ) {
                        $mapped_domain = $wpdb->get_var( $wpdb->prepare( "SELECT domain FROM {$wpdb->base_prefix}domain_mapping WHERE blog_id = %d", $blog_id ) ); //string
                        wp_cache_set('wap_mapped_domain_' . $blog_id, $mapped_domain, 'domain_mapping', 3600 ); // 1 hour
                    }
    
                    if ( !empty($mapped_domain) ) {
    
                        //* Fetch scheme
                        $mappedscheme = wp_cache_get('wap_mapped_scheme_' . $blog_id, 'domain_mapping' );
                        if ( false === $mappedscheme ) {
                            $mappedscheme = $wpdb->get_var( $wpdb->prepare( "SELECT scheme FROM {$wpdb->base_prefix}domain_mapping WHERE blog_id = %d", $blog_id ) ); //bool
                            wp_cache_set('wap_mapped_scheme_' . $blog_id, $mappedscheme, 'domain_mapping', 3600 ); // 1 hour
                        }
    
                        if ($mappedscheme === '1') {
                            $scheme_full = 'https://';
                            $scheme = 'https';
                        } else if ($mappedscheme === '0') {
                            $scheme_full = 'http://';
                            $scheme = 'http';
                        }
    
                        // Put it all together
                        $url = trailingslashit( $scheme_full . $mapped_domain ) . $path;
                    }
                }
    
                //* Non-domainmap URL
                if ( empty($url) ) {
                    $url = home_url(add_query_arg(array(), $path));
                    $scheme = is_ssl() ? 'https' : 'http';
                }
            }
        }
    
        $scheme = !empty($scheme) ? $scheme : '';
    
        $output = '<link rel="canonical" href="' . trailingslashit( esc_url( $url, $scheme ) ) . '" />' . "\r\n";
    
        echo $output;
    }
    
    add_action( 'wp_head', 'hmpl_ad_canonical_standalone_function' );

    Don't feel like coding? Get it here (with all the other SEO functions): https://wordpress.org/plugins/autodescription/

    I also believe you don't have issues anymore with the permalinks. If that's the case, time to mark this topic as resolved <3

    • Sybre Waaijer

      Nope! I've browsed through a lot of comparison charts and what not but I stuck with Apache for one main reason:
      Somewhere this year HTTP/2 is coming out and it's being developed by the Apache group.

      HTTP/2 is going to blow you away in regards of speed and safety, together with Litespeed and Nginx

      I've noticed Nginx is faster than Apache at this point, especially with SPDY. But SPDY is HTTPS only.
      HTTP/2 will be faster than Nginx + SPDY, but when HTTP/2 comes out, SPDY will most likely be deprecated... SPDY is also owned by Apache at this point AFAIK.
      HTTP/2 will also work without HTTPS

      I thought Nginx and Litespeed were on par with speed and reliability.

      Anyway, I'm sticking with Apache ^^. Saves me time transfering my server to HTTP/2, HTTP/2 FTW

      P.S. So many ABBR in this reply OMG WTF BBQ

  • wp.network

    https://www.litespeedtech.com/http2-ready
    https://www.litespeedtech.com/support/wiki/doku.php/litespeed:wiki:enable_http2
    http://blog.litespeedtech.com/2015/06/12/lsapi-officially-released-to-support-php7/

    Generally I agree... considering potentials of http/2 and php7 I think staying with my old friend Apache is a pretty good plan... still... I may yet try LSWS for the experience of it... we'll see... Thanks for your thoughts =)

  • wp.network

    Going to provision and move forward with:
    Dual X5650
    24GB DDR3 ECC
    1TB Primary Disk
    500GB Database Disk

    Will use WHM/cPanel, Centos6.6, MariaDB 10 w/ InnoDB, Memcached... most of the RAM will go to InnoDB's buffer_pool and to memcached... will also be setting up for later testing w/ CF Railgun (partly thus, Memcached rather than Redis)... and then, (after testing and backups) move on to LSWS Enterprise x2 CPUs... assuming that goes well, will move on to HTTP/2 and then likely LScache... this will take some time to do it thoroughly... by then I figure (again, assuming success) to move on w/ PHP7 via LSAPI... any thoughts, or generally good advice on tuning MariaDB/InnoDB configs very welcome =)

    If interesting results emerge I'll be sure to open a new thread and let you know...

    Cheers, Max

  • Jose

    Hey guys!

    Hope you are doing fantastic.

    Me and the developer are kind of lost on this thread. It is now 114 posts long and I'm pretty sure that it is an official world record

    If I recall correctly, the original issue here is resolved, right?

    It would be really helpful if we can close this thread and discuss further issues on dedicated threads. That way we can cooperate better between the support team and the lead dev.

    Makes sense for you?

    Cheers,
    José