robscott

Hi,

I am sure there will be lots of “I have this problem too” messages, as Google Search Console has begun displaying this warning in their console.

First, a couple of points:

1. This is a warning in GSC, not an error. Warnings are meant to be pointers, but you should not suffer any ill-effects from a momentary absence of this piece of data;
2. With that being said, Google is handing you a heavy hint here that a) you should have a clear and obvious returns policy and b) assuming you do, you should mark this up with Schema.org structured data.

This isn’t particularly a WooCommerce problem – it is a merchant specific problem.

However, in WooCommerce, the system offers a great opportunity to append your own schema.org structured data, as do a number of third party plugins (mostly SEO plugins).

If you’d like to use a code snippet for adding this one piece of data to some all products, that’s possible too.

The first thing to check and resolve is that you actually have a Returns policy, because without one, you won’t be able to add this data!

NOTE this is different to Merchant Center returns policy, as this warning specifically relates to the structured data shown in “Offers” schema in your website, not the data which displays under Merchant Center / Google Shopping results.

I’ve set everything for https-only.

This wasn’t my point – my point was about how you’re proxy-ing; and this is port specific.

I don’t fully understand your use-case, nor your expectation re documentation for what looks like an edge case setup. Can you describe why you expect this setup to be documented? What’s the benefit of the split between admin and front-end?

Sorry for delay – I had a week out of office.

I wonder if you’re looping http <> https from backend to frontend.

Alternatively your issue might be how the location /wp-admin/ is handled (i.e. where wp-login.php attempts to redirect you to).

If you attempt to load /wp-admin/ after logging in – does it work?
What if you add /wp-admin/index.php ?

Is there any reason you dislike Nginx Unit for this?

I think maybe your proxy pass should be at location /wp-admin/ within your frontend directives. But I’d like to see all of nginx.conf to be sure.

Sorry — I can see that defined in your config at the top there now.

Try adding the following to your nginx.conf server directive – you’d need this in the frontend part:

server_name_in_redirect off;

This may be sufficient.

Hi Bill,

I feel like you’re not defining the admin location in wp-config.php… which sounds sort of obvious from your description of it not getting there ??

Trying to think where in the chain this might be.

I *do* use Nginx Unit to pass based on uri match (for ‘/wp-admin/’ ) and this might be all you need to define (perhaps try doing so as location in nginx.conf)

@considerthis1 – yes it is the AMP page – if you click the waterfall tab in GTmetrix, for the AMP page, you’ll see that it is calling “cdn.ampproject.org” early in the load.

In here -> https://gtmetrix.com/compare/oT4gzbtm/mhBgjo0h > Waterfall

That’s a simplified version, but its a quick and easy way to confirm you’re looking at an AMP!

Another way is to view source and you’ll see you’re looking at an AMP by the amp-html stuff at the top:

view-source:https://health-boundaries.com/vitamin-b12-and-fingernails/?amp

Why you’re not getting the lightning bolt is perhaps a different question. It is worth checking Google Search Console for any AMP specific errors (and warnings).

You can run it through Google’s online AMP test, too:

https://search.google.com/test/amp?url=https%3A%2F%2Fhealth-boundaries.com%2Fvitamin-b12-and-fingernails%2F%3Famp

This is looking valid now! It may be worth considering switching AMP to “Transitional” or “Standard” mode in your AMP settings, which make serving the AMP version the default – BUT this is something of a decision point your side, and probably only do that if you’re happy with how AMP content is looking and working.

Hi,

It looks to me like WP Supercacher is caching your AMP content. I lighthouse tested and your AMP content loads okay. It is a little slower in mobile than in desktop (this is expected – because Lighthouse simulates a slower connection – it is not actually slower). Note this is loading the exact same page – the AMP page.

Loading the non AMP page does yield faster performance in desktop.

It’s never been 14s+ on any of these tests – so it looks to me like you’ve got caching working.

The performance of AMP and non AMP are roughly equal, e.g.:

https://gtmetrix.com/compare/oT4gzbtm/mhBgjo0h

This is looking ok to me right now. To gain more speed, you’d need to get granular – and into quite advanced topics!

Hi @considerthis1 – you might be able to configure WP Supercache to make sure it caches the AMP pages. The server response time suggests it is not – but it is for desktop. This explains the difference in response time between the two.

There may be other ways around this too – including:

* Hosting migration (so the uncached load is faster – but still you’d want to fix the page caching)
* Make sure WP Supercache is caching ?amp content correctly – or look at another full page caching plugin (like WP Rocket) which may be easier to configure
* “Proxy Cache” at DNS level, via a (free) service like CloudFlare – which would also need configuring to make sure it also caches ?amp content.

Hi @considerthis1 – just stopping by as I’ve seen and resolved similar issues before.

One thing I’d like to explain is about PageSpeed Insights. When Google PSI measures mobile performance, they simulate a slower connection, using “throttling” – what this means is, under Lab (not real world performance) the mobile site on a responsive site is almost always slower than the desktop version.

Not 14x slower, but usually a little slower.

In your case, your AMP page has an “initial server response time” of 7+ seconds. This means your web server is taking over 7 seconds to begin sending the AMP page at all.

I can think of a potential reason why, too – it’s likely your hosting is caching your desktop version (because it does not have the query string – the ?amp part ) and not caching the AMP version.

So:

1) Your server is caching desktop – but not caching a page with a query string. To test, performance scan the following URL: https://health-boundaries.com/?cachebustingrandomstring and see how it performs in mobile and desktop

2) Assuming caching is hiding slow server performance, maybe migrating to a new host will help.

In my personal experience, this AMP plugin has helped my and many client sites to load extremely quickly, so it is not likely to be down to the plugin itself – although there’s clearly something amiss in your setup somewhere.

Okay – but above I’d seen you describe that you didn’t have Nginx proxy working with WordPress.

From having WordPress running via proxy, it’s less of a leap to configure accessing this in the manner described.

The script I pointed out handles all of that initial configuration – I use a similar script to this to achieve a similar thing to your initial description. But I wanted to see if you had a working Nginx proxy, as this would then be a smaller task.

Q: “does ANYBODY have a WORKING wordpress behind Nginx reverse proxy config?”
A: “yes”

Q: “Is it possible to THEN configure more complex location rules?”
A: “also yes”

I don’t fully understand the difference between “external” and “internal” in your description – but it sounded like you’d fallen at the first hurdle in any case.

@huna02 Nginx itself has a script to install a hello world WordPress behind a reverse proxy.

Spinup a server in your favourite cloud VPS and give this a spin

https://www.nginx.com/blog/automating-installation-wordpress-with-nginx-unit-on-ubuntu/

Edit the above to match your preferred setup.

Answer: yes, lots of people have WordPress running in the way you have described.

Adding here for more recent comments: this issue is in WordPress version 5.6 and will be fixed in version 5.7 which patches in the necessary place.

Please note, there’s a patch mentioned in here, but you need to be running a pre-release version of WordPress to access it. Do so at your own risk, or wait for the release.

Props to those who patched so quickly ??

1.7.1 in mine. Yeah code editor adding double lines is highly possible ??

@alexclst mine still is line 368. You may be on an older or edited version of the Mailgun plugin?

This function pops up in a few SMTP plugins too – in a couple I’ve found how they’ve fixed this warning; in my case, we have replaced with custom code because we don’t need all the features of Mailgun’s plugin.

• This reply was modified 3 years, 9 months ago by robscott.