403 code in Colossus during image lazy-load

[Darryl Gross]

We have just completed a site update using Colossus in our dev store and are really happy with the result. Even though everything displays normally, we have found a 403 Forbidden status code returned with images loaded on 414 pages -- basically every category page with a cattree image and every product page. All images were uploaded to the same directory "graphics/00000001/". The 403 status is returning "dev.floorballplanet.com/Merchant2/" rather than the full path to the image. All of these errors are generated when the image is called under the <picture> tag.

In looking at the source code for a sampling of pages, the 403 seems to happen when the image is generated on the category or product page using the "data-lazy" call. For example <picture class="t-subcategory-navigation__picture"> <img class="t-subcategory-navigation__image" data-lazy="graphics/00000001/AERO-C_spread.jpg" src="" alt="Balls"> </picture>.

What is best way to correct this? We use URI management and all internal links seem to work just fine.

[Matt Zimmermann]

I can't say I've come across that issue before. Typically, a 403 error is tied to permissions or rights. I would recommend contacting support so they can look at your site and server configuration.

[Bruce - PhosphorMedia]

I'm not seeing any error when I visit. If you are using chrome, try another browser. Since the last update I've been having really odd cache errors (including things like caching DNS calls). This, even if I use a no-cache setting or plug in. Sad, cause otherwise I like using Chrome for dev work but switching to Opera.

[Darryl Gross]

Actually, I'm seeing these when I check the site with WebSite Auditor (part of SEO PowerSuite). I use that after I've completed most of my work because it shows issues that hadn't been obvious before. I corrected a few already but this one caught my attention.

[Darryl Gross]

I haven't seen any problem with images displayed on any device -- computer, tablet or mobile. And I only get the 403 status code for images generated by the Miva engine. All images called directly (from a page or category header) have the exact same path (graphics/00000001/) and don't generate an error code. I get the 403 error because dev.floorballplanet.com/Merchant2/ is not a valid page. It seems that the full path is not being generated in the "data-lazy" call. All other images show the path as dev.floorballplanet.com/Merchant2/graphics/00000001/test-image.jpg

[Bruce - PhosphorMedia]

Ah, that might be because those tool may not be reconciling the image call via javascript/jquery. I'm assuming that colossus uses one of those methods to defer images. The tools just look for scr="" and read the URI from there. In defer, that is often times an encoded image like

data:image/png;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=

[Darryl Gross]

That seems logical. The src="" is in each instance, e.g., <picture class="x-product-list__picture"> <img class="x-product-list__image" data-lazy="graphics/00000001/GOAL_900_main_288x259.jpg" src="" alt="Campus 900 Goal"> </picture>

[Darryl Gross]

Per Matt's suggestion, I created a ticket and tech support is looking at the issue. No answer yet.

At first I thought the issue with the incomplete image page was a curiosity -- the 403 Forbidden message didn't seem to cause a problem for the user. All images display normally when visiting the site. Cattree images and all images on product pages display normally.

HOWEVER, I'm finding the problem is definitely there and causing issues. We have been updating our store for listing in Google Shopping and using web crawl to populate the attributes so they come from what we actually have online. In Google Merchant Center, the attribute for image link (required) is pointing to "http://www.floorballplanet.com/Merchant/" which is nonexistent and causes an error. It doesn't get the full path to the image (adding "graphics/00000001/productimage.jpg").

Checking the same page in Google's Structured Data Testing Tool, the image shows up the same way. In the Google Rich Snippets section of the page, this shows up as <meta itemprop="image" content="http://www.floorballplanet.com/Merchant2/" />.

[Darryl Gross]

In talking with tech support about this issue, here is the latest about how lazy-load works in Colossus.

"The way the lazy-load function works in Colossus is that the image has no actual src until the image is scrolled into view which could be causing an issue though unsure how since a relative URL such as "graphics/00000001/productimage.jpg" is valid.

When combined, both `http://www.floorballplanet.com/Merchant/` and "graphics/00000001/productimage.jpg" make up the source."

That's all well and good. But how does we get the actual path passed to web crawlers? Since Colossus is relatively new, I'm guessing there are others out there with the same problem -- they just don't know it yet.

[Bruce - PhosphorMedia]

Modern crawlers use, or are aware of javascript and should have no trouble understanding that deferred loading is taking place and read the correct image path from the data-source. Google shopping and structured data tools, however, need to be explicitly told what the image is. I'm not sure if colossus comes with MicroData and google shopping, but simply swapping what's there for what's in data-lazy="" should solve the problem.

[Darryl Gross]

Actually, the issue seems to have morphed. Tech support says it is not a lazy load issue and I tend to agree. Once we started drilling down on the problem, it seems that somewhere near 50% of our products have an image path returned while the rest have a null value. It's the null return that is generating the 403 error. I'm still trying to figure out why it affects some products and not others. It also appears when we have cattree images on certain category pages.

At the moment, I'm focusing on the following lines of code in our product display page:

<mvt:do file="g.Module_Library_DB" name="l.success" value="ImageType_Load_Code('main', l.settings:imagetype)" />
<mvt:do name="l.success" file="g.Module_Library_DB" value="ProductImage_Load_Type(l.settings:product:i d, 1, l.settings:imagetype)" />
<mvt:do name="l.success" file="g.Module_Library_DB" value="Image_Load_ID(l.settings:imagetype:image_id , l.settings:imagedata)" />

We have 9 image types in our user interface. Every product has a "main" type. Many, but not all have a "close-up" type. Those products without an image as type "close-up" returns the null path while those that have a "close-up" image type return the path the the close-up image, not the main image. If I re-assign the image type at the product level to anything other than "close-up", the path comes back null.

A product with a null image path returns "main,Main,2," for the imagetype variable and a product with a generated path returns "" for the imagetype variable.

[Darryl Gross]

It looks like this is actually two issues and they are different:

1. The original issue I raised about the 403 error seems to be definitely related the lazy load. On a product page, I get the 403 error every time there is a Related Product. Since these images are off screen during the page load and the error message from my page audit points to it occurring with the "picture" element, it is generated during the deferred image process.

2. The second issue is products showing up when there is NOT a "close-up" image type assigned to the product. I've tested renaming both the code and the value of this image type and it doesn't change the result so it has nothing to do with that. If I delete a close-up image or change the type of that image to any other type, the image path goes away. When I examine one of these pages using Google Structured Data Testing Tool, it returns an Unspecified Type with id of "https://www.floorballplanet.com/Merchant2/" which is my baseref. In the Product schema, the image path is "http://www.floorballplanet.com/Merchant2/" (http vs https).

Would love to hear anybody's thoughts about this...

[Darryl Gross]

Regarding Leslie's post about SEOprofiler, this is exactly what I am experiencing. I don't think it has anything to do specifically with Colossus.

[Darryl Gross]

Another input on the 403 error. I was working on a category page today that has several iframes (for embedded YouTube videos). To improve page load speed by deferring Javascript loading of the YouTube video player, I changed the src="url" to data-src="url" and added src="". After doing this, the page loads significantly faster an everything works normally. However, a page audit now passes the 403 error.

I believe the data-src and src="" tags are causing the 403 problem -- whether on a category page with cattree images, a product page with deferred images, or a page with iframes.

[kayakbabe]

this is triggering a memory about a javascript issue in a Miva store and the length of product images filenames and getting 403's. That was a long time ago... but I wonder if is there a different in the filename length of images on the 403 generating pages and the ones that do not generate a 403?