[Resolved] Users unable to remove featured images

[Author]

Posts

[Christian Cox]

On the updated staging site, I tried to edit an Artist to remove the featured image. The script admin-ajax.php is throwing a 403 error in wp-admin every time I click the Remove Featured Image link. The next step I would like to take is to try to narrow down this problem, but I don't want to interfere with any other tests you or other supporters may be running. Is it okay for me to do this now, or should we plan a specific time?

[nadavR]

Go for it. Flyhweel have already finished this test, and concluded it's a Toolset issue. I do know that Beda is working on another thing but it might be on his own local copy of the site. So you can go ahead.

[Christian Cox]

Okay great, I've figured this one out. The short answer is that your staging environment is not configured to provide access to the Hebrew-language domain hidden link, where the missing images should exist. A detailed explanation follows:

- I disabled all plugins except Toolset and activated the parent Newspaper theme. I was able to add and remove the featured image in this post successfully when logged in as Developer:
hidden link

- Next, I activated all the WPML plugins and repeated that process with English selected in the Admin Bar. I was able to add and remove that featured image successfully again. Next I wanted to try in Hebrew, so I selected Hebrew in the Admin Bar. When I return to the Artist editor screen, I see no featured image but I see the link "Remove featured image". Now I have replicated the problem! So I checked the console, and I see this error:

Failed to load resource: net::ERR_NAME_NOT_RESOLVED - <em><u>hidden link</u></em>

Try to load that URL directly in the browser: hidden link This site can't be reached. The domain has the ".il" suffix.

Remove the ".il" suffix and try the URL in the browser:
hidden link
This image exists.

Next, I tried to investigate this in production. The same issue is not occurring in production, as far as I can tell. Here's the same Artist:
hidden link
The featured image appears as expected, and also has the .il suffix in its domain:
hidden link

So the issue is the Hebrew-translated image URLs in staging do not exist. Staging is not an accurate representation of production because the domains are not set up exactly the same way. Can Flywheel modify your staging environment so that the .il domain is also available in staging?

[nadavR]

Hi Christian,

Regarding staging, you can change the Hebrew suffix in WPML->Languages->Language URL format. This way you can place all of Hebrew in a sub-directory instead of a different domain.

However, let's leave staging alone for a minute and go back to the main issue. The issue (in its worst form, meaning, users can't even remove the images in the first place, hence the original title of the thread, before we spread out) is present on the LIVE site. Here are the steps I just took to re-create the issue:
1. Add a new artist. Just put in whichever are the required fields, add a featured image and save as draft (so not to interfere with what visitors are seeing right now on the site). I assure you that even if you hit publish, the following will still happen.
2. Now, with a saved draft, try to remove the image. For me, the image isn't removed.
3. I guess that in some cases, images can be removed as we've seen before, but then, when a new image is chosen to replace the removed one, it doesn't work.

Thanks,
Nadav

[Christian Cox]

A quick update, I have some test results from production and staging environments.

--------- Production tests -----------
First test on existing Artist, Hebrew selected in admin bar:
- I'm logged in as Toolset, and I edit this draft Artist: hidden link
- I'm able to remove, modify, and add a new featured image successfully

Second test on new Artist, Hebrew selected in admin bar:
- Created new draft here: hidden link
- I'm able to add, modify, remove, re-add a featured image successfully

Third test on existing Artist, English selected in admin bar:
hidden link
- Unable to remove existing featured image, error 403 appears: hidden link, with payload: post_id=54510&thumbnail_id=-1&_wpnonce=2d3beb9d2c&action=get-post-thumbnail-html

Fourth test on new Artist, English selected in admin bar:
- Able to upload image to Media Library, but then it does not show up in the Artist editor screen.
- Error 403 appears on admin-ajax.php, with payload:
post_id=54517&thumbnail_id=54520&_wpnonce=2d3beb9d2c&action=get-post-thumbnail-html

So I can confirm some issues with 403 errors in production. Since I can't disable plugins or activate other themes here, I continued in staging.

----------- Staging tests ------------
Existing Artist, Hebrew selected in admin bar:
- Images are 404 as we have already discussed, but the Featured image management part is working as expected. Even though the images are 404, the correct URLs are shown for the selected images

New Artist, Hebrew selected in admin bar:
- Images are 404 but featured image management is working as expected.

Existing Artist, English selected in admin bar:
- Unable to remove featured image. Error 403

New Artist, English selected in admin bar:
- Able to select existing featured image from library
- Unable to remove featured image. Error 403

Deactivate Access, New Artist, English in admin bar:
- Able to select existing featured image from library
- Unable to remove featured image, Error 403

Deactivate Access Edit the same artist I just created:
- Able to upload new featured image to library
- Unable to insert it as featured image in artist post editor

Deactivate Access, New Artist, before clicking Save Draft:
- Able to select existing image from library
- Save Draft
- Unable to remove featured image, error 403.

That last two tests show that even with Access disabled, Error 403 will be returned for the admin-ajax.php file in some cases. It also appears that the problems only occur when English is selected as the language. So the problem does not appear to be Access, or at least not only Access.

The next step is for me to try to reproduce this on my local clone, so we can eliminate server configuration differences as a source of conflict. I will use SFTP to download the additional plugins in use on staging, so I can install them locally. That will take a while. Standby, I will update you after I have run those tests locally.

[nadavR]

Ok, Thanks Christian.

[Christian Cox]

Okay I was able to replicate the same behavior on my local clone, so I think we can eliminate Flywheel's server environment as the source of the problem. In my local tests, I'm able to reproduce 403 errors with only these 4 plugins active, and a default theme:
- WPML CMS
- Types
- Give
- ACF

It only happens in the English language, so I can't rule out WPML as part of the problem, and it only occurs on custom post types, so I can't rule out Types. If I disable either Give or ACF, I don't see any 403 errors. So it seems to be a conflict between multiple plugins. I have escalated this to my 2nd tier support team for further investigation, along with some specific instructions for replicating the issue. I'll update you when I have something to share from them.

[Christian Cox]

After further investigation, we are unable to replicate the problem locally with the latest versions of Types (2.2.22) and Give (2.0.5) active. I've updated the plugins on staging, and I'm not longer able to reproduce the issue now on staging, while following the same steps I followed before. Can you confirm?

[nadavR]

Looks good here. You think this issue just spontaneously got resolved because of the new versions of both plugins?
I'll ask the AICF staff to verify it's working for them before closing the ticket.

[Christian Cox]

That's our best guess at this point, there are lots of moving parts but updating to the latest versions of Give and Types seems to stop those 403s from appearing in all my tests. My 2nd tier support team was never able to reproduce the issue at all, because they always included the latest plugins in their tests. We considered the possibility that memory issues or timeouts could be part of the difference, but could not confirm that. I realized the difference in our plugin versiosn and updated mine as well...problem seemed to be solved then. It could also account for some of the inconsistency I experienced before, because at some point I know I updated staging to use the latest plugins for testing other tickets. At that point, production and staging would have been using different versions, and that would account for different featured image behavior across those environments. Then Flywheel reset staging (old plugins were restored like production), and the problem reappeared in staging. Now staging is up-to-date and the problem seems to be resolved.