Related Posts Not Displaying After Server Move

You’re going to have a problem with your URLs ?? and I suspect that’s why Jetpack’s being weird.

https://www.thezenofmaking.com/2014/12/tutorial-resin-thread-spool-bracelet.html

Notice how they end in .html? We’ve been working through some issues where Varnish decides those are legit HTML pages and caches them as static content, versus the dynamic that WP should be.

We strongly recommend not using .html in your URLs, and just change your permalinks to /%year%/%month%/%postname%/

Then you can use this to redirect all the posts without loosing SEO:

RedirectMatch 301 ^/([0-9]{4})/([0-9]{2})/([^/]+).html$ https://www.thezenofmaking.com/$1/$2/$3/

It would go at the top of your .htaccess. If you open a ticket, we can help you with that.

Holy cats, you just fixed an issue that I’ve been working on for 3 days with only 30 seconds of work. Thank you so much, Ipstenu-DH!

In addition to fixing the Jetpack Related Posts module issue, changing the permalinks structure and updating my .htaccess also fixed the issue I was having with my admin toolbar not displaying on single post pages.

In case anyone else is having this problem, the permalinks structure should actually read as follows: /%year%/%monthnum%/%postname%/ (There was a typo in the post above.)

Thanks again!

Been having the same exact issue with the admin toolbar and other dynamic admin only content not appearing on single post pages after migrating to Dreampress and have been pulling my hair out trying to diagnose the issue.

@thezenofmaking – thanks so much for taking the time to post this and explain your issue in such detail.

@ipstenu-dh – Any idea when this will be fixed? I’d prefer not to do a wholesale URL structural change and I’m surprised there isn’t a fix for this on the Varnish end.

The issue is that it’s (kinda properly) treating .html files as… well … .html. Those are MEANT to be static files and so they’re caught by the static file check. We do have a couple possible changes to fix it, but with only two people impacted, it’s not really a huge priority.

We don’t want to use the extant check for is WP logged in around ALL static caches, because js and css are included there and you should have those cached :/ So we would have to move out the .html check, which we don’t want to do since you really do want .html pages cached.

I know the wholesale URL change is annoying, but at the same time it’s 2015 and .html URLs have been rather unpopular for a few years. I’ll bring it up again at our meeting tomorrow morning, but since there’s no SEO benefit to using it AND it’s a very simple .htaccess rule to change it without losing your SEO ranking or links (people would redirect properly), the safest fix is removing .html :/

So I bit the bullet and made the change. For those who have to manage large site URL updates like this here are a few tips.

Steps:

1. Update your Permalink under Settings. I chose to go with the %POSTNAME% approach. As always Yoast has great advice on this and I suggest reading that first: https://yoast.com/change-wordpress-permalink-structure/

2. Add the HTACCESS rule. In our case we moved from /%postname%-%year%-%monthnum%-%day%/ to %postname% so you’ll see a different HTACCESS rule for our site versus what was used above:

RedirectMatch 301 ^/([^/]+)-([0-9]{4})-([0-9]{2})-([0-9]{2}).htm$ https://www.pinkcakebox.com/$1/

3. Google recommends updating both internal links and external links (https://support.google.com/webmasters/answer/6033049?hl=en) For most people I would imagine updating external links is not feasible, but internal links are another story.

In general it’s good practice to update your internal links especially if you have a large number of internal links and a heavy trafficked site as these type of sites shouldn’t have to be burdened with the overhead of executing 301 redirects for every request.

In our case we had thousands of internal links so I resorted to a regular expression replace to modify all the internal links. Ideally I would have done this in MYSQL, but REGEXP does not support replace.

So my hack was to export the wp_posts table and run a regexp replace in Notepad++ and re-import the table. Certainly risky as I had to ensure my regular expression did not inadvertently update the wrong thing.

In case it helps anyone here is the regex:

Find What: \"\/([^\/]+)-([0-9]{4})-([0-9]{2})-([0-9]{2}).htm
Replace: "/$1/

That’s it! The plus side is we have nice clean URL structure as a result of the work.