Jonathan Bossenger

Hi @lyurk

I did a quick scan through the WP Codebase for 6.3.1, and all instances of the X-WP-Total response header being set are in the same case as you’d expect in the code.

I then did a bit of searching online, and it seems that the newer HTTP/2 protocol defaults to lowercase headers (example discussions here, here, and here) so my guess would be that this is a change on your webserver. Perhaps being upgraded to the newer HTTP/2 protocol?

This raises a valid point about the documentation, and I will raise this as an issue in the REST API docs repo, to see if we can get it updated to point this out for HTTP/2

Got it.

Usually, if you’re going to do something like a Database upgrade, it’s recommended to do it on a staging site (a copy of the main site) so that you can test to make sure nothing breaks, if If it does, you can troubleshoot.

I don’t know Aruba, do they offer you the option to create a staging environment to test the Database upgrade on?

At least now we’re able to narrow it down a bit 🙂

I’ll have to compare settings and see if I can find an obvious difference

Sadly yes, it now just boils down to methodically comparing the configurations.

My suggestion would be to start with the built-in Site Health screen, specifically comparing the Site Health Info of each site (wamp vs localwp).

The other option is to compare the PHP configuration. You can do this by creating an info.php file in the root of both local WP installs, with the following PHP code.

<?php
phpinfo();

Or punt and just demo using localWP

That’s obviously entirely your call, but at least now you have that option 🙂

Sure, unfortunately it’s reached the point where I’d start digging into the code.

If it helps, you can create this file in the root of the wp install.

https://gist.github.com/jonathanbossenger/d96520acd6225ea969f091752a3bca8b

Replace the following

$sitename = get_option('blogname');

echo "Hello " . $sitename . '!';

With something like

$data = wp_get_attachment_image_srcset(ID);
print_r($data);

Replacing ID with the actual ID of the image in question.

Then browse to that file and see what it outputs.

D’oh! Sorry about that @michaelh99 I misunderstood that the problem was happening on live, not local wamp.

Do you have a way to check what the wp_get_attachment_image_srcset function returns, if you pass it the ID of one of these images on your local WAMP environment?

Hi Hugo

So you can post a job using the Post a Job form. While there are a lot of full-time positions there, it’s also open to smaller projects.

The WordPress.org Support guidelines strictly prohibit folks offering or asking for paid work here, so your best bet is to try the WP Jobs board, or another WordPress expert platform like Codeable.

@michaelh99

Okay, thanks for that feedback.

One other thing I thought of, when you copy the changes from the local WAMP environment to the live server, are you also copying any related database changes?

I just uploaded an image locally on a clean WP install, and I noticed that it adds two postmeta records against the attachment custom post type data object for the media item, one with a meta key of _wp_attached_file and one with a meta key of _wp_attachment_metadata, which is a serialized array of image metadata, and this array includes a sizes key, which includes an array of data about the different sizes.

I’m thinking if this postmeta record doesn’t exist in the live database, that might explain why it’s not generating the srcset attribute for the img tag when it’s rendering the image on the live site.

No problem.

I don’t personally have any recommendations, but you could try either posting the project on jobs.wordpress.net or codeable.io.