HTML differences between WAMP and “live”

Hi @michaelh99

This looks like it’s related to the default responsive image support in WordPress.

To start, can you check if your WAMP environment is able to create the resized images on upload?

To do this, upload an image either to a post, page, or the media library, then open your Windows Explorer, browse to the /wp-content/uploads/2023/09 directory, and see if any additional resized images have been created alongside the original upload.

If it does not create any additional resized images, you might need to check if the PHP GD extension is enabled on your WAMP environment.

@psykro Thanks for the input. Couple of data points:

1. The images were originally uploaded on the live server and all the resizes are present.
2. After my original post I found a post that suggested I might need to re-upload the images when moving to a new server type. I thought that was a hail-mary but tried it anyway. The resizes were all created when uploading to my wamp server but I ended up with the same visual results.
3. I even went to the trouble of installing imagemagick since WP was complaining it wasn’t available. Same results.
4. I also tried copying and pasting the “good” html through the dev console in chrome and that didn’t work either. I wonder if some javascript isn’t being activated/loaded or if the “good” html only works during page load because of some js that’s running at the same time

@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.

@psykro One small detail, it’s failing on wamp but works fine on live.

I have made sure to copy the database and files when transferring from live to wamp, so during the initial testing, both sides were as identical as I could make them.

I’m seeing similar entries on my wamp install such as:

{s:5:”width”;i:1008;s:6:”height”;i:567;s:4:”file”;s:27:”2023/09/20230724_182059.jpg”;s:8:”filesize”;i:256824;s:5:”sizes”;a:3:{s:6:”medium”;a:5:{s:4:”file”;s:27:”20230724_182059-300×169.jpg”;s:5:”width”;i:300;s:6:”height”;i:169;s:9:”mime-type”;s:10:”image/jpeg”;s:8:”filesize”;i:13160;}s:9:”thumbnail”;a:5:{s:4:”file”;s:27:”20230724_182059-150×150.jpg”;s:5:”width”;i:150;s:6:”height”;i:150;s:9:”mime-type”;s:10:”image/jpeg”;s:8:”filesize”;i:5207;}s:12:”medium_large”;a:5:{s:4:”file”;s:27:”20230724_182059-768×432.jpg”;s:5:”width”;i:768;s:6:”height”;i:432;s:9:”mime-type”;s:10:”image/jpeg”;s:8:”filesize”;i:72301;}}s:10:”image_meta”;a:12:{s:8:”aperture”;s:1:”0″;s:6:”credit”;s:26:”Michael and Susan Harrison”;s:6:”camera”;s:0:””;s:7:”caption”;s:0:””;s:17:”created_timestamp”;s:1:”0″;s:9:”copyright”;s:26:”Michael and Susan Harrison”;s:12:”focal_length”;s:1:”0″;s:3:”iso”;s:1:”0″;s:13:”shutter_speed”;s:1:”0″;s:5:”title”;s:0:””;s:11:”orientation”;s:1:”0″;s:8:”keywords”;a:4:{i:0;s:18:”276 Valley View Rd”;i:1;s:11:”Bakersville”;i:2;s:14:”North Carolina”;i:3;s:9:”farmhouse”;}}}

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?

@psykro Interesting. I just did a search of the source and while that function exists, nothing calls it.

I know, it’s a function one can use to fetch the srcset value for an image, so it’s easier to use this to test if the underlying functionality is working.

@psykro gotcha. I’ll have to see about adding that somewhere. I haven’t done any actual development with WP so that’ll be new.

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.

@psykro Thanks. That was very helpful. I get the same results

wamp

https://pepper1.canecreek828.com/wp-content/uploads/2023/08/VetBreakfast-300×195.jpg 300w,
https://pepper1.canecreek828.com/wp-content/uploads/2023/08/VetBreakfast-768×498.jpg 768w,
https://pepper1.canecreek828.com/wp-content/uploads/2023/08/VetBreakfast.jpg 780w1

Live

https://canecreek828.com/wp-content/uploads/2023/08/VetBreakfast-300×195.jpg 300w,
https://canecreek828.com/wp-content/uploads/2023/08/VetBreakfast-768×498.jpg 768w,
https://canecreek828.com/wp-content/uploads/2023/08/VetBreakfast.jpg 780w1

IIIiiiiiinnteresting.

So my next thought would be that it has something to do with the WAMP environment/configuration.

Are you in a position to install something like LocalWP or DevKinsta, create a copy of the site using one of those local environments, and see if the problem persists?

Out of interest, what WAMP configuration are you using?

I’m installing localWP and will let you know how that goes.

What would you like to know about my wamp config?

Some info…

Apache VersionApache/2.4.37 (Win64) OpenSSL/1.1.1s PHP/7.4.33 mod_fcgid/2.3.10-devApache API Version20120211Server [email protected]:Portpepper1.canecreek828.com:0Max RequestsPer Child: 0 - Keep Alive: on - Max Per Connection: 100TimeoutsConnection: 60 - Keep-Alive: 5Virtual ServerYesServer RootC:/wamp64/bin/apache/apache2.4.37Loaded Modulescore mod_win32 mpm_winnt http_core mod_so mod_access_compat mod_actions mod_alias mod_allowmethods mod_asis mod_auth_basic mod_auth_digest mod_authn_core mod_authn_file mod_authz_core mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_cache mod_cache_disk mod_cgi mod_dir mod_env mod_file_cache mod_include mod_isapi mod_log_config mod_mime mod_negotiation mod_rewrite mod_setenvif mod_socache_shmcb mod_ssl mod_userdir mod_vhost_alias mod_php7 mod_fcgid

PHP Version 7.4.33

@psykro the localWP install behaves the same as the live site. I’ll have to compare settings and see if I can find an obvious difference. Or punt and just demo using localWP

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 ??

@psykro I’ll probably wait until after the demo (next Tues) before making any longer term decisions.

After seeing that the localWP configuration worked as expected I decided to copy the files from that config over to my wamp folder and two things happened:

1. WP decided that I was setting up a brand new config and had me go through naming the site and choosing an admin user. Everything went smoothly and at the end of that…
2. The install worked just as the live site and localWP. The on-screen layout is correct out of the box.

I’m going to move forward with that config for the next week and look at the differences as time permits.

It may simply be something that gets saved to the db/disk during setup that is just different enough when moving from a lightspeed server over to apache to cause this issue.