• Resolved asreurotux

    (@asreurotux)


    Hello,

    First I’d like to thank the team for the amazing effort on putting together the v14! From a technical POV and as far as I can tell it’s a wonderfull piece of machinery.

    I’ve been testing this new version on a client that has a huge DB (over 1M+ posts in the network and a peak 500k posts in a single site) and, for security reasons, has the wp-admin served on a different domain, e.g a full backend network DNS. Each site is served to the public with a proper DNS handled by the WPMU domain alias.

    So far, so good.

    Until Yoast v13, since all the content is generated “on-the-fly”, the URL’s are generated properly on the site-face, such as: og:* tags, canonical URL’s, and so on.

    Unfortunately, with the v14 Indexables, on every update done on wp-admin, the indexed information is saved with the backend DNS and populated in the frontends with that data.

    Are there plans to make the Indexables domain-friendly or must I apply the domain translation on every available filter to avoid this issue?

    Thanks in advance and best regards,
    André.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Support Md Mazedul Islam Khan

    (@mazedulislamkhan)

    We are sorry to hear that you’re having trouble. Can you please elaborate more on what types of every update you made on wp-admin and that saved the indexed information with the backend DNS and populate with the frontends data? A relevant screenshot or relevant URLs will really help us to understand the issue better.

    Thread Starter asreurotux

    (@asreurotux)

    Hi @mazedulislamkhan, thanks for the reply!

    I meant to say any update on a post. Whenever a post is edited, the indexable in the database has its data updated with the backend DNS.

    I’m afraid I cannot provide any screenshots, but the issue is having the canonical and og:url metatags populated with the backed DNS.

    Was that more clear?

    Thanks

    Some additional info / questions:

    Starting the indexation from the modal in the backend (the notice you get when you do a fresh install or update to 14.x) will indeed use the backend URL. This is a known “bug”. See https://github.com/Yoast/wordpress-seo/issues/15141 for my earlier findings on this matter.

    However, my findings were also that saving the posts individually would use the correct URL. So I guess your setup is really only last-minute determining the URL to use? Can one physical post be served on different URLs on your site (by having all language metadata split out from one post by a plugin)? Or is every post unique for its domain?

    Resetting the indexables and only relying on the lazy-load would maybe help. Lazy-loading will use the permalink of the visited page, so that should contain the correct domain. This will not work if one post is served on different domains though.

    Plugin Support Md Mazedul Islam Khan

    (@mazedulislamkhan)

    👆

    Thread Starter asreurotux

    (@asreurotux)

    @djennez thanks so much for the pointer.

    In fact I’m not using any language plugin, but the open issue seems relatively close to what I’m experiencing.

    Also, aside from the backend (wp-admin) DNS each site in the network has a single frontend domain and no multiple aliases.

    I assume that indexing the content using wp-cli and passing the –url flag would set the proper DNS for each site, although editing a post through wp-admin would update the indexed data and replace the domain with the one from the backend.

    @asreurotux can you explain how your sites are set up, because I only just now realized you’re running a multisite network installation? We’ve tested this on multisites as well and that should just work.

    Thread Starter asreurotux

    (@asreurotux)

    @djennez Sure!

    Apart from the standard WordPress Multisite Network instance, I’m using the Mercator plugin (https://github.com/humanmade/Mercator) which enables the ability to keep the same wp-admin DNS on every site (and thus SSO across the network) while serving the front-face with a unique alias per-site.

    Using the default WordPress domain mapping is a show-stopper since it forces users to access the wp-admin interface through the same DNS.

    Since this is a high load network, the traffic is sharded through multiple wp-admin exclusive servers and some frontend exclusive ones. The requests and channeled through a redundant load balancer and split by domain, i.e. if the request has the wp-admin DNS then it’s sent to a backend server.

    I understand that, on editing/creating a post, the request is done using the wp-admin DNS and that is in fact the value of the home_url and site_url options, so its natural that the Indexable is set using this values. I simply expected that the dynamic information (meta tags, sitemaps, etc) would be lazy-generated on page load taking into account the domain through which the site was accessed (probably by replacing the site_url with the current access url)

    @asreurotux thanks for the additional details! I’ll have a look into trying to reproduce this locally.

    I am looking for “real-world” cases where our indexables permalinks are causing these kinds of troubles. So this is a good example to add to that list.

    I can’t say if / when this is something we’re going to change. But you might be able to use our filters (wpseo_canonical / wpseo_opengraph_url) to get to the desired outcome. You could use these to call the core get_permalink() again to restore some compatibility. It’s far from ideal, but it might work for the time being.

    Thread Starter asreurotux

    (@asreurotux)

    @djennez thank you so much for the sugestion.

    That was the alternative I had in mind to overcome this issue, although I wasn’t sure if the sitemap feature has such a filter to change the permalinks.

    Is there a filter to change the urls in the sitemap? And won’t it penalty the performance to make a get_permalink on every sitemap entry?

    Ah, the filters I suggested were for individual pages. The sitemap has multiple filters available, I think wpseo_sitemap_url should be able to help you further. This one is called for every entry on the sitemap, so it might be somewhat resource intensive. Then again; the sitemap is / can be cached pretty decent.

    Hi @asreurotux,

    We are going ahead and mark this topic as resolved due to inactivity. If you require any further assistance please create a new forum topic. Thank you!

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Yoast 14 Indexables and WPMU with domain alias’ is closed to new replies.