Need to add code to the Nginx config file for Yoast

I switched back to Yoast SEO. Now that I’m on Nginx, they say I need to add the following to the Nginx config file:

‘include /var/web/site/public_html/wp-content/uploads/wpseo-redirects/.redirects’

  • Adam Czajczyk
    • Support Gorilla

    Hello Bibi

    I hope you’re well today and thank you for getting in touch with us!

    Our admins added the rules form the file so they should be applied. I can see that Yoast is still “complaining” about that but I think it’s because it simply cannot detect the file that it suggests – and that’d be expected because the file wasn’t added there, just the rules were copied to NGINX configuration.

    I’ve also checked some randomly selected redirects and they seem to work, though only partially. What I mean is that some of the rules seem to redirect correctly but some do seem to redirect to slightly “altered” target URLs.

    That seems to confirm what one of our sysadmins was saying that “may” happen: rules conflicting with other, already existing ones. It’s a managed WP hosting crafted to provide specific set of features and that also includes quite custom NGINX configuration that cannot/shouldn’t really be changed much.

    That said, if necessary I’ll ask our sys-admins to look into it again to see what more could we do to make it work this way for you but let me ask you first: is there any reason for not using PHP redirects instead?

    It’s a recommended way of doing that kind of redirects on our hosting and should work equally well while would also be much more “elastic”, in that sense that whenever you would do any changes to redirects settings (add some new, remove some or edit some) that wouldn’t require asking sysadmins to manually update NGIX rules again and would be automatically applied to the site.

    Wouldn’t that work for you?

    Best regards,

    Adam

  • Bibi
    • WPMU DEV Initiate

    Help still needed! Thanks for doing this! When all is said and done, my site isn’t looking right. I would like to request that you remove that rule. Some issues:

    Caching seems to be only working from the Cloudflare end. Hummingbird’s cache doesn’t do anything when I purge assets. I need to go to Cloudflare for this.I don’t know if this is related to adding that rule, or indicative of another problem. I made changes yesterday to my home page. They did show before you guys went in. Now, the page has gone back to its previous customization (via Elementor Pro). I switched my SEO to Yoast because the wpmu plugin wasn’t doing an important redirect on an image for me.

    I’ll keep Support access open. Thanks much!

    Bibi

  • Adam Czajczyk
    • Support Gorilla

    Hello Bibi

    Thank you for response!

    I asked our sys-admins to remove those rules back. I’ll update you here once it’s done and switching Yoast to regular PHP redirects should help you handle these redirects nicely.

    As for the other issues that you’re reporting – other than adding these rules we didn’t do any changes.

    However, I took another look at the site configuration and there’s something additional to consider. You’re using Elementor for the site, there’s Page Cache enabled, Asset Optimization working, there’s a CloudFlare implemented and there’s also Object Cache (so db queries’ results are cached) on server. All together it makes quite a complex “caching structure”, so to say.

    Currently Elementor is set to print out any CSS to external files so whenever changes are made, it might be necessary to manually re-set Asset Optimization. Some Asset Optimization data is stored in DB so change then might require flushing object cache (“flush cache” option in Hosting panel) and the CloudFlare in that all – you would have to use “Clear Cache” button on “Hummingbird -> Dashboard” rather than in e.g. “Hummingbird -> Cache -> Page Cache” and do this after aforementioned changes are made.

    A small change in Elementor settings should help, though additional “one time” steps would be required:

    1) in Elementor -> Settings -> Advanced switch “CSS Print Method” to “Internal Embed” from “External Files”

    2) make sure that other CSS optimization options in theme/plugins other than Hummingbird are disabled – if there are such options

    3) in Elementor -> Tools regenerate CSS

    4) clear all caches (including flushing cache on server)

    5) go to “Hummingbird -> Asset Optimization”, re-check files and configure it again from scratch

    6) clear all caches again

    That’s one-time procedure but should fix these other (not related to redirects) issues. After that, once changes are made and they are not visible, it should suffice to go to the “Hummingbird -> Dashboard” page and click on “Clear cache” button there.

    Getting back to redirects. The rules are already removed so nginx config is exactly as it was before adding them. You should now be able to switch Yoast to PHP redirects and add/remove/modify these redirects directly from Yoast settigns with immediate effect (if there’s no effect – flush cache in Hosting panel).

    Kind regards,

    Adam

    • Bibi
      • WPMU DEV Initiate

      I don’t know if this is related or not, but I’ve been doing everything I can to get the @font-face rule implemented. Started from scratch not knowing much about it, and now I’ve got a rudimentary understanding of it. I’ve tried a few different plugins, the font customization that allow fonts to be hosted locally, etc. – and nothing is working. Hummingbird keeps coming back with “Your page is not using font-display rule when loading the following web fonts.” I’ve uploaded fonts, deleted them, and tried adding the custom @font-face for my fonts in the extra css space that the customizer provides. It’s driving me batty! I’m only using one plugin at a time when trying this stuff out, btw. Any suggestions? Thanks.

      P.S. Where the heck does the following go?

      “To add the font-display property for Google Fonts, you can pass the desired value in the query string display parameter as shown in the example below:

      https://fonts.googleapis.com/css?family=Roboto&display=swap

  • Adam Czajczyk
    • Support Gorilla

    Hi Bibi

    I don’t know if this is related or not, but I’ve been doing everything I can to get the @font-face rule implemented. (…:wink:

    That’s sometimes a bit difficult, indeed. The recommendation about fonts is given by Google and when it comes up it means that either there’s no “font-display” for indicated fonts or PageSpeed (the very same applies to Hummingbird’s Performance Test) is not able to detect it properly.

    We got two possible “types” of fonts here: those hosted locally and those coming form “outside” where the latter can also be “only hosted” outside (so only font files are fetched from some external source) or can be “provided entirely” from outside (so also their specific CSS is fetched from external source).

    In any case, you need that “font-display” to be added to CSS but… this should actually be something that was taken care of at the theme creation level. Since it’s a relatively new thing (I mean – it wasn’t tested by PageSpeed not so long ago), it’s not as common yet as it should be.

    Recently, I found the suggestion from Elementor (in some support ticket of theirs) to simply add this to the site CSS:

    * {
    font-display:swap;
    }

    In theory it should address “all fonts on the site” but it doesn’t. It most likely will help with some only. If there are Font Awesome fonts used on site then they do, theoretically, have “font-display” already added to their core CSS but not the right one. This is something that Font Awesome said they should address soon with some upcoming update.

    As for Google Fonts. Again – the suggestion (that comes from Google) – would work if you were directly including these fonts, e.g. in a simple HTML site. In WordPress, however, that’s a bit different and also depends on the theme and how it actually loads these fonts. A plugin that “makes them local” could work in case of some simpler themes but here you’d most likely need to actually stop theme (and most likely Elementor too and probably also plugins that are using Google Fonts – if there are any that do load them on their own) from loading Google Fonts at all and then use a plugin (that supports “font-display”:wink: or your own custom code (a nice guide here) to load them.

    So what I’d do would be trying that suggestion from Elementor first (it certainly won’t harm the site at all even if it won’t fully help) and then just wait for updates of theme/Elementor/plugins to gradually solve that – while this might take time, I’m sure it will be handled because questions about dealing with this recommendation become more and more “pressing” everywhere around (on support forums of various themes and plugins etc).

    Best regards,

    Adam

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.