Post preview : 404 error on one sub-site


On one subsite post preview doesn't work.
When I try to preview a post I get a 404 error because urls like /?p=148&preview=true are redirected to /?p=148.

I tried to reset permalinks but the problem is still here.

I don't know if it might be relevant but it was a single site I imported into my multisite network, using Snapshot.

If I publish the post it's ok, it works as expected.

Any idea?

I think this thread should actually be moved inside plugin support for Domain mapping.
This subsite is mapped and I think the problem is related to that. Thanks :slight_smile:

Best Regards

  • Patrick

    Hey there @Arom77

    I hope you're having a great day!

    I was able to reproduce that on a subsite where a Snapshot of a single site was imported.

    This occurs when the subsite's Domain Mapping setting Front end redirect is set to directed to mapped (primary) domain when first mapping that subsite.

    The solution is to unmap that subsite, then re-map it ensuring that the Front end redirect is set to disabled and entered domain should be used.

    Your previews should work fine.

    But I've notified the developer to see if some kind of check can be added to Domain Mapping for this type of situation.


    When I map a domain with 'entered domain should be used' and then try to control mapping via htaccess with a simple exception added for previews (similar to what I use with CloudFlare) I get a server error page 500 at first, now just the WP permission error.

    Without my htaccess, it works, but then there are all the issues of having multiple URLs for one's content... so... ?

    RewriteCond %{REQUEST_URI} !/wp-login\.php [NC]
    RewriteCond %{REQUEST_URI} !/wp-admin [NC]
    RewriteCond %{REQUEST_URI} !preview=true [NC]
    RewriteCond %{HTTP_HOST} ^wpmscloud-secure\.tivism\.com [NC]
    RewriteRule ^(.*)$$1 [R=301,L,S=5]

    I will make a new thread and link back here :slight_smile:

    Cheers, Max

  • Arom77

    Hello @Ashok
    OK I understand, thanks :slight_smile:

    The problem is that if you set the Front end redirect to disabled and entered domain should be used you ultimately get duplicate site (duplicate content).

    Are you saying that it's impossible to get previews running when you set Front end redirect to directed to mapped (primary) domain? Couldn't this be fixed in your Domain Mapping plugin?

    Really, that's a major issue. For Google and for real people too.


      Are you saying that it's impossible to get previews running when you set Front end redirect to directed to mapped (primary) domain?

      There are currently (to my knowledge) at least some configurations of Domain Mapping wherein the frontend mapping redirect option is essentially broken - specifically when using HTTPS for all network including mapped domains.

      Setting the mapped fronted redirect to be disabled and to use address as entered as many consequences - among them are some potentially serious 'duplicate' content issues due to the same resources being accessible/indexable via more than ONE address...

      I have my networks set up to use the original network addresses for login/admin and the mapped address (if any) for frontend only.

      I have set my mapped domains to use the frontend mapping redirect setting 'directed to mapped (primary) domain'.

      Because there are bugs with frontend domain mapping, at least in some configurations (affecting many things, including permalink addresses) I had to develop - with much awesome assistance - the htaccess rules below to deal with enforcing the redirects, including an allowance for previews. (RewriteCond %{QUERY_STRING} !preview=true [NC])

      Since I also use CloudFlare, I had to add a page rule to allow for previews as well.

      There are reasons for the way these rules are written, mostly trying to be sensitive to the 'look & feel' of the original subsite addresses on subdomain networks since that s the model I use for sites that clients/customers will see the backend addresses of... for my subdirectory networks I do not mind an original network address that looks a little funky, which makes it easy to do it all in less code...

      For the subdomain model, you would replicate the block that is in below rules that applies to .Com mapped addresses to address any other TLDs that you will be using. The trick is in making the original addresses match the expected pattern... so, if one wished to map the domain then one creates the subsite mapped-secure-1.primary.tld and so on...

      htaccess for subdomain network, placed above stock WP rules:

      <IfModule mod_rewrite.c>
      RewriteEngine On
      Options All -Indexes
      #BEGIN Remove 'www.' from all Requests
      	RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
      	RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
      #END Remove 'www.' from all Requests
      #BEGIN Frontend Address Control for Network Subsites with Mapped .Com
      	RewriteCond %{REQUEST_URI} !^/?wp-(admin|content|includes|login) [NC]
      	RewriteCond %{HTTP_HOST} ([^.]+)-secure-1\.example\.tld$ [NC]
      	RewriteCond %{QUERY_STRING} !preview=true [NC]
      	RewriteRule ^(.*)$$1 [R=301,L]
      #END Frontend Address Control for Network Subsites with Mapped .Com
      #BEGIN Author Profile Redirect
      	RewriteRule ^/?author/ https://%{HTTP_HOST}/ [R=301,L]
      #END Author Profile Redirect
      #BEGIN Catch-All SSL Address Control
      	RewriteCond %{HTTPS} !=on
      	RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
      #END Catch-All SSL Address Control

      For subdirectory networks, no further rules are needed as long as the original network addresses conform the following pattern:
      for mapping a domain mapped.tld create a subsite primary.tld/mapped-dot-tld

      htaccess for subdirectory networks, added above stock WP rules:

      <IfModule mod_rewrite.c>
      Options All -Indexes
      RewriteEngine On
      # BEGIN Remove 'www.' from all urls
      RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
      RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
      # END Remove 'www.' from all urls
      # BEGIN Custom Mapping for Subdirectory Subsites w/ Mapped Domain
      RewriteCond %{REQUEST_URI} !/?wp-(admin|content|includes|login) [NC]
      RewriteCond %{QUERY_STRING} !preview=true [NC]
      RewriteRule ^(.*)-dot-(.*)/(.*)$ https://$1.$2/$3 [R=301,L]
      # END Custom Mapping for Subdirectory Subsites w/ Mapped Domain
      #BEGIN Author profile redirect
      RewriteRule ^author/ https://%{HTTP_HOST}/ [R=301,L]
      # END Author profile redirect
      # BEGIN Catch-All SSL Address Control
      RewriteCond %{HTTPS} !=on
      RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
      # END Catch-All SSL Address Control

      CloudFlare rule pattern:

      This allows previews but does NOT really address whatever is going on with the Domain Mapping plugin; it works because it just gets these redirects done essentially before they get to WP... its not a real solution though, imho, just a temp patch to move along with while we await the next DM release :slight_smile:

      These rules can be easily adapted to work with http networks - just remove the 's' from all the instances of 'https' and delete the 'Catch-All SSL Address Control' rule block...

      Hope this can be helpful to some, happy to answer any Qs, look forward to Sam's input on this as well :slight_smile:

      Cheers, Max

  • Sam

    Hello @Arom77

    Thanks for the message.

    I can confirm the issue but it only happens when the Administration mapping is not set to mapped domain but u set the front end redirect to primary(mapped) domain, this way when you click on the post preview button, the nonce generated in the backend which is generated for won't validate for and it results in the reported bug.

    For now i've set Administration mapping to mapped domain so that u can avoid duplicate content while i'm trying to fix the issue and ship with the upcoming release.

    Hope this helps.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.