Images in shop not loading after page scroll

jcpst

Well-known member
I’m just curious if this an issue I’m experiencing, or if everyone is.

It happens in the shop, when I scroll past the products from the initial page load.

When I get to the next page’s worth of products, they show up, but the images do not.

IMG_1448.png
 
Hmm, I'm not seeing that on any of my devices here but we did recently switch to a new CDN / cache so it could be some sort of caching issue.
 
Yeah, it does feel like that.

It works fine on desktop for me, windows/firefox.

I'm seeing the issue on Firefox and Safari on iOS 18. I tried deleting by browser cache for pedalpcb, using a private tab, and using cellular data only instead of wifi. Tried turning my phone off and on too.

I considered resetting my router, but I'm seeing it on cellular data too.
 
Desktop win7, 500mb/second direct Ethernet cable connection, works fine

iPhone 14 same connection but wifi instead of direct, get the same problem.

edited: I turned off the wifi on the iPhone and scrolled. It was fine until it reached the next page, then the images stopped. So it has something to do with the next page loading. It's just so fast on the 500mb/s connection that I couldn't see it pause before it refreshed.

Next page function may be picking up a false timeout error.
 
I cracked open the dev tools and tried loading the page with different User Agents. Using android and ios both reproduced the issue. With Kindle user agent it worked fine:rolleyes:

All the images are coming back from the server with a 200 response. I can see in the image attributes that they are being set to hide the image.

Here's one that renders fine from page 1

angryandyplus.PNG

Here's one from page two that is being hidden

angryhidden.PNG
 
They're different images, I'd expect the path to be different if they weren't uploaded at the same time in Wordpress.
I would expect the path name for display, and continue display to be the same since images are normally stored together.

One is a very new date, one is a very old date. To me it looks like a pointer problem.

If I was doing this in unidata I'd setup a table master file entry for the display path, and load that into the constants at initialization and use the constants variable instead of a hard coded path.

But, lucky for me, I'm retired.

:sneaky: 🍻
 
I would expect the path name for display, and continue display to be the same since images are normally stored together.
I think you may be missing my original point, dates aside, these are two different images for two different boards. Of course the paths are different. The dated folder structure is built-in with Wordpress, it's fundamental to how it handles file uploads.

If I was doing this in unidata I'd setup a table master file entry for the display path, and load that into the constants at initialization and use the constants variable instead of a hard coded path.

But, lucky for me, I'm retired.
And luckily for @Robert, there's Wordpress/WooCommerce. Setting up what you're talking about (if both images were the same, and in this case, they're not) is possible but I don't know why you would. Permalink modules are likely readily available. Web has gotten far more user-friendly than it was 25 years ago. Props to the guys that did all this manually back then.
 
One is a very new date, one is a very old date. To me it looks like a pointer problem.
I think the (coincidental) fact that one image shows the Angry Charles and the other shows the Angry Andy Plus is adding to the confusion.

And luckily for @Robert, there's Wordpress/WooCommerce.
Yes, they've managed to abstract away most of the technical inner workings with a nice UI. While you can still customize/edit the PHP source, it's to the point that you could build the entire site doing nothing more than dragging and dropping elements onto pages. Images can be uploaded by simply dropping them onto a page and resizing/positioning. It's similar to one of the old WYSIWYG web editors like MS FrontPage.

The file system location and permalinks are automatically generated. You can still upload images via FTP and hard-link to them, but the preferred method is to let Wordpress handle the files since it also generates thumbnails and size variations of the images to fit desktop/mobile devices and updates the cache.

I do still do a lot of things the old fashioned way, with a text editor and FTP client though.
 
I think you may be missing my original point, dates aside, these are two different images for two different boards. Of course the paths are different. The dated folder structure is built-in with Wordpress, it's fundamental to how it handles file uploads.


And luckily for @Robert, there's Wordpress/WooCommerce. Setting up what you're talking about (if both images were the same, and in this case, they're not) is possible but I don't know why you would. Permalink modules are likely readily available. Web has gotten far :sneaky: 🍻 more user-friendly than it was 25 years ago. Props to the guys that did all this manually back then.
As a programmer I've written programs that generate HTML as well as FTP code. I am not a user, WordPress is more of a packaged user interface. I don't think you understand what I'm saying? Or perhaps I was not clear enough....

After the selection criterion and sort pattern is selected all the data is copied in that order to a sequential access file, so that initial page display, as well as followup display during scrolling is in the same file and accessible by an internal NEXT command to the sequential file.

This file name would not change because the NEXT statement would not have a starting pointer.

On server testing during upgrades, temporary files often have release or date information in the name. This is so a global variable can be flipped and you're testing using the new version of apps and data. These are flipped back after testing. When testing is complete, the switch is flipped and it stays with the new version.

This appears to be a 'upgrade artifact' where the path name is hard coded to the now empty file. So initial page display works fine since it's pointed at the data, but when it hits the statement with the old name there is no data to display.

Probably. I suspect that WordPress is generating this on the fly and somewhere in the 'real code' a hard coded path name exists instead of the indirect pathname obtained from the global switch variable.

I was involved in writing AI applications when I retired in 2010, I've written word processors, command interpreters, O/S indexing routines, used machine code, assembly code, and four different advanced 3d database models.

Started programming in 1974 when we used flint tools to carve the code into rock!!!!

:sneaky:🍻
 
Probably. I suspect that WordPress is generating this on the fly and somewhere in the 'real code' a hard coded path name exists instead of the indirect pathname obtained from the global switch variable.

Those are real paths to actual files, and they're both complete on the server.


The infinite scrolling feature on product pages loads the visible thumbnails first, then progressively loads more thumbnails as you scroll down the page. The browser is constantly firing URL requests back to the server to request more thumbnails. I suspect something is getting lost in translation here because of the CDN.
 
Last edited:
I suspect something is getting lost in translation here because of the CDN
This is a lot more likely. But I find it kind of interesting that I can switch the User Agent to reproduce the issue.

I was starting to think it’s an actual bug. One thing I didn’t mention earlier is that the the request for page 2 terminates with NS_BINDING_ABORTED. But I considered it a non-issue because I assume it’s aborting because it’s lazy loading instead.

You know that little UI trick where the image fades in right when you scroll and it goes on screen? I had a hunch… this behavior could happen if an exception is being thrown in an event handler related to toggling those DOM elements to be visible.
 
Those are real paths to actual files, and they're both complete on the server.


The infinite scrolling feature on product pages loads the visible thumbnails first, then progressively loads more thumbnails as you scroll down the page. The browser is constantly firing URL requests back to the server to request more thumbnails. I suspect something is getting lost in translation here because of the CDN.
Ok. I'm used to dealing with *extremely large* databases where description is a field, not part of the name or path.
Gives me a bit more insight into how WordPress works tho!!!

In the DB's I've worked in, those would be cross referenced or indexed by the description field, and all the images would be in one database.
 
See if it's working properly now.
Owning your own business = Fixing the internet at 11pm on a Friday.....
🤟:cool:

Working for the man, tho, I've pulled many an all nighter on Friday, Saturday, Sunday and was expected to be alert and present at 7:30am Monday morning. Boy my life sucked then.
 
Owning your own business = Fixing the internet at 11pm on a Friday.....
🤟:cool:

Working for the man, tho, I've pulled many an all nighter on Friday, Saturday, Sunday and was expected to be alert and present at 7:30am Monday morning. Boy my life sucked then.
Yup, I've been correcting code at the Christmas party with few other programmers.
 
Back
Top