Astra tries loading file that doesn’t exist

Kindly give the URL of your page where this problem is occurring, so we can take a look and help you.

Hi George,

Thanks for the reply. I can give u the URL, but the problem is that it’s not displaying the root issue. Because of TranslatePress it throws a HTTP 302 response, instead of the 404 response. The website also has minify enabled, which also alters the HTTP response. In order for you to see the real problem, I would have to disable both TranslatePress and WP Optimize’s minify, and because it’s a production website, I’m not so keen on that.

What I would rather do is disable both plugins and then copy all of the Google Chrome Inspect information. Is that a valid alternative, and if so, what would you like me to capture?

Also, it doesn’t only occur on a single page, it occurs on all the frontend pages and not on the admin pages.

Thanks, again.
Frank

Hi @fibronic,

I am a bit confused here. What is actually the issue? Is it related to Astra or TranslatePress and WP Optimize?

Would you please elaborate a bit more with us so we can share our thoughts?

Looking forward to hearing from you.

Kind regards,
Herman ??

Hi Herman,

Our website is trying to load an image that isn’t there anymore. This increases the load time of all of the frontend webpages significantly. This is the Google Inspect reponse header:

General
Request URL: https://roodbolevenementen.nl/wp-content/uploads/2018/11/bg-10-free-img.jpg
Request Method: GET
Status Code: 404
Remote Address: 20.105.216.1:443
Referrer Policy: strict-origin-when-cross-origin
Response Headers
cache-control: must-revalidate, no-cache, max-age=0
content-encoding: gzip
content-type: text/html; charset=UTF-8
date: Tue, 15 Mar 2022 10:45:53 GMT
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://roodbolevenementen.nl/wp-json/&gt;; rel=”https://api.w.org/&#8221;
server: nginx/1.14.2
x-powered-by: PHP/8.0.11
Request Headers
:authority: roodbolevenementen.nl
:method: GET
:path: /wp-content/uploads/2018/11/bg-10-free-img.jpg
:scheme: https
accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,nl-NL;q=0.8,nl;q=0.7
cookie: wordpress_test_cookie=WP%20Cookie%20check; ARRAffinity=7bb81a2218562f014bc0f51eb0d63115484ded253a94ea773a560d355a3735c0; ARRAffinitySameSite=7bb81a2218562f014bc0f51eb0d63115484ded253a94ea773a560d355a3735c0; wp_lang=en_US
referer: https://roodbolevenementen.nl/
sec-ch-ua: ” Not A;Brand”;v=”99″, “Chromium”;v=”99″, “Google Chrome”;v=”99″
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: “Windows”
sec-fetch-dest: image
sec-fetch-mode: no-cors
sec-fetch-site: same-origin
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36

Is this useful information?

Kind regards,
Frank

• This reply was modified 2 years, 8 months ago by fibronic.
• This reply was modified 2 years, 8 months ago by fibronic.

Hi @fibronic,

Did you previouly import a Starter Template to your site? If you did, please share with us what the template was.

Looking forward to hearing from you.

Kind regards,
Herman ??

Thanks for the reply. I can give u the URL, but the problem is that it’s not displaying the root issue. Because of TranslatePress it throws a HTTP 302 response, instead of the 404 response. The website also has minify enabled, which also alters the HTTP response. In order for you to see the real problem, I would have to disable both TranslatePress and WP Optimize’s minify, and because it’s a production website, I’m not so keen on that.

I can see the problematic image is being called from this WP Optimize CSS cache file:

/wp-content/cache/wpo-minify/1647774016/assets/wpo-minify-header-8587ad63.min.css

Kindly re-generate your WPO cache (or ALL your caches elsewhere, just to be sure), and let’s see if the problem goes away.

If the newly-generated cache file still contains the invalid image reference, then there’s definitely something on your site that’s still calling this image… and you’ll (unfortunately) need to temporarily disable WPO before you can troubleshoot further.

UPDATE: The full block of CSS causing this problem is:

.site-primary-footer-wrap[data-section="section-primary-footer-builder"] {
    background-image: linear-gradient(to right, var(--ast-global-color-2),
var(--ast-global-color-2)), 
url(https://roodbolevenementen.nl/wp-content/uploads/2018/11/bg-10-free-img.jpg);;
    background-repeat: repeat;
    background-position: center center;
    background-size: cover;
    background-attachment: fixed;
    border-style: solid;
    border-width: 0;
    border-top-width: 1px;
    border-top-color: #e6e6e6
}

• This reply was modified 2 years, 8 months ago by George Appiah. Reason: Added CSS block referencing non-existing image

Hi @bsfherman
Yes, that is corrected. We used the Starter Templates — Elementor, WordPress & Beaver Builder Templates. The plugin is no longer installed so I can’t see exactly which template it was. It was called something like “Sierra National Park” and it had a big picture of an elephant on the home page.

Hi @gappiah
Thanks! That’s a great step forward. If you don’t mind me asking: how did you get to this conclusion? Did you just inspect the page and searched for the image name?
Do you know what would be the best way to resolve this? Do we need to make a change to a database entry?

Thanks to both of you!

Kind regards,

Frank

If you don’t mind me asking: how did you get to this conclusion? Did you just inspect the page and searched for the image name?

I simply checked the browser’s console, which shows the problematic image and the CSS file that it’s referenced from, as seen in the screenshot below (click to see larger image). I then opened the CSS file, searched for the image, and pulled out the block of code I quoted.

Note that the long delay is actually caused by the redirect loop, not the mere fact that the image is non-existing.

Do you know what would be the best way to resolve this? Do we need to make a change to a database entry?

The file wpo-minify-header-8587ad63.min.css is a cache of a portion of your site’s CSS, generated by the WP Optimize plugin.

But the image reference is in there because, at the time that WPO generated the cache file, your site’s CSS (either from your theme, or some plugin, or even your site’s content) had that image reference.

Hence my earlier recommendation to…

1) Regereneate the WPO caches… to see if the newly-generated CSS cache file will not contain the image reference any longer (this would be the case if the problem does not exist any longer, and the WPO cache is simply containing outdated info.).

2) If the newly-generated CSS cache file still contains the image reference, it means the problem still exists in the source (from where WPO generated the cache). And the only way to troubleshoot further would be to disable WPO so you can get to the source of the problem.

On a closer look…

In my earlier response, the WPO cache file containing the problematic image was wpo-minify-header-8587ad63.min.css.

In my last response above, the WPO cache file is now wpo-minify-header-8707ad65.min.css and still contains a reference to the problematic image.

This just means the WPO caches have refreshed already.

And as the problem still persists in the new cache file, this indicates the problem still exists elsewhere on the site (WPO is simply picking what it’s finding on your site)… and you need to temporarily disable WPO to get to the bottom of this.

Hi George,

Thanks for all the effort you’ve put in! I fixed it by playing around with the Astra Footer builder Design section. I picked a background image for both of the sections of the Primary footer section and then deleted them again. That seems to have done the trick.
The weird thing is that when I edited the settings there were no images set. Maybe whenever the background image was removed, it didn’t process the change somewhere on the backend of the site.

Kind regards,

Frank

Hi @fibronic,

Most probably the missing image was the background image of one of the Footers and due to a little glitch, while it should be removed during the template importing process, it didn’t happen. That’s why when you did the thing you explained above it fixed the issue.

Well, very pleased to know that this has been fixed. Let us know if you need more help, otherwise please mark the topic as Resolved.

Kind regards,
Herman ??