Hi @patrickhaond. The screenshot is useful: it shows ‘Échec de l’ajout du nouvel attribut’ with a loading overlay. That looks like an attribute-add operation failing, rather than simply having no global attributes to choose from. A slow host alone does not tell us why it failed.
First, can you open Products > Attributes normally, and does this happen with every global attribute or only ‘Genre’?
For one controlled test, use a draft product on a staging copy if available. Open your browser’s developer tools > Network, then try adding the same existing global attribute once. If a request fails, note its HTTP status and the first error shown in the Console. Please share just that error/status, not a full request export with cookies or authentication headers. This helps distinguish a failed server request from a JavaScript problem before changing hosting or installing more plugins.
Which exact WordPress, WooCommerce and PHP versions are you using?
Adam
Thread Starter
Pat
(@patrickhaond)
Thank you for your help.
Unfortunately I can not reproduce the problem for now…
Yes I can open Products > Attributes normally.
I am using WP 7.1.3 , WooCommer 11.2.1, and php 8.4.27 .
I will try to reproduce the error…
Thread Starter
Pat
(@patrickhaond)
back to the same error.
404 POST https://mywebsite.com/wp-admin/admin-ajax.php load-scripts.php:8
Thanks, that gives us something concrete to investigate. The important part is POST /wp-admin/admin-ajax.php returning 404. ‘load-scripts.php:8’ identifies the browser script reporting the failure; it does not establish what caused it.
In Network, select that failed POST and check:
- Does Request URL use the correct domain and WordPress installation path?
- In Response/Preview, is it a normal WordPress 404 page, a hosting/CDN error page, or a short error message?
- What is the ‘action’ value under Payload/Form Data? Share only that value and the short error text, not cookies, nonces or a full request export.
Reload the product editor before repeating the same test on your draft/staging product. If it happens again, note the exact time and ask your host to compare the failing POST with a successful one in their access/error logs. That should help identify which layer returns the 404 before changing hosting, permalinks or plugins on guesswork.
Does the failure happen when adding an existing global attribute to the product, or when creating a new attribute value?
[signature removed by moderators]
Thread Starter
Pat
(@patrickhaond)
Thanks a lot for your help.
- Domaine and path seem correct.
- File not found (nothing else…)
- action “wpml_action”
Is that possible to have any link with Wordfence… ?
-
This reply was modified 6 days, 10 hours ago by
Pat.
-
This reply was modified 6 days, 10 hours ago by Pat.
That is a useful detail. The action name “wpml_action” points us towards a WPML-related request, but it does not yet show that this is the request responsible for adding the attribute. A background request can fail at the same time.
Are WPML and WooCommerce Multilingual active, and which versions are installed?
For the next test, clear the Network list, click Add for one existing global attribute once, then check all requests created by that click. Does only “wpml_action” fail, or is there another failed request with a different action value? Also check whether the same “wpml_action” 404 appears on a fresh product-editor page before you touch the attributes.
If it fails even without an attribute action, that helps separate the two problems. “File not found” alone is not enough to say whether WordPress, the web server or a proxy generated the 404. Please keep the translation plugins and live settings unchanged while we establish that.
[signature removed by moderators]
Thread Starter
Pat
(@patrickhaond)
Thanks a lot.
Actually all attributes have been set for a long time, I never add any new one, moreover from new product page…
Wordfence or WPML problem ?
Understood — you are selecting attributes that already exist, not creating new ones. Thanks for clarifying.
We cannot yet choose between Wordfence and WPML from that 404. The “wpml_action” name tells us which request failed, not why it failed or whether it caused the attribute problem.
You can check Wordfence without disabling it: immediately after reproducing the problem, open Wordfence > Tools > Live Traffic and look for a blocked request to /wp-admin/admin-ajax.php at the matching time. If there is one, share just the blocking reason, not the full record or your IP address. No matching entry would not rule Wordfence out, because logging settings can exclude traffic.
Please also confirm the installed WPML/WooCommerce Multilingual versions and whether the failed request appears before you interact with the attributes, as in the previous test. That will give us evidence to work from rather than turning off protection on the live shop.
[signature removed by moderators]
Hi Pat,
Thanks for the details, and thanks to Adam for the Network checks so far.
One thing that narrows it down: when you pick an attribute from “Add existing”, WooCommerce sends a request to admin-ajax.php with the action woocommerce_add_attribute. If that request fails, it shows “Adding new attribute failed.” (the “Échec de l’ajout du nouvel attribut” in your screenshot). So your attributes are fine. It’s that request that doesn’t get through.
On Wordfence vs WPML, I don’t think we can blame either yet. When WordPress can’t handle an admin-ajax request, it answers with a 400 and a “0”. A bare 404 “File not found” makes me think the server or a firewall in front of WordPress is cutting the request off. That would also explain why it only happens some of the time.
Next time it happens, check whether the woocommerce_add_attribute request also returns that 404. If it does, send your host the exact time and ask them to check their logs and firewall rules for blocked POSTs to /wp-admin/admin-ajax.php.
Cheers
Thread Starter
Pat
(@patrickhaond)
Thanks for your help.
there is no woocommerce_add_attribute that shows.
And there is also nothing in Wordfence > Tools > Live Traffic.
Hi Pat,
Thanks for checking both. Those two answers actually tell us a lot.
The “File not found” response is the key part. WordPress doesn’t answer admin-ajax.php that way: when it can’t handle a request it returns a 400 with a “0”. A bare 404 with “File not found” comes from the web server or something in front of WordPress (a proxy, CDN or firewall at your host). In other words, those requests never reach WordPress at all.
That also explains the rest:
- Nothing in Wordfence Live Traffic: Wordfence runs inside WordPress, so it can’t log a request that never got there. When Wordfence blocks something you’d normally get a 403 and its own block page, not a 404.
- The failed request was wpml_action: if something drops admin-ajax.php requests now and then, whichever request is sent at that moment fails. Sometimes it’s a WPML one, sometimes it’s a WooCommerce one.
About woocommerce_add_attribute not showing up: Network only records while it’s open, and that request goes out the moment you pick an attribute. “Add existing” actually uses two requests: woocommerce_json_search_product_attributes fills the dropdown when you open or type in it, and woocommerce_add_attribute adds the one you pick. If the first one fails, the list stays empty and the second one never happens.
For the next try:
- Open the product editor, then open Network, tick “Preserve log” and type admin-ajax in the filter box.
- Use “Add existing” as usual until it fails.
- Tell us the action value of every request that failed (not just the first one), and what each one returned.
Then send your host the exact time and the “File not found” response, and ask them which layer returned that 404 (web server, PHP, or a proxy/firewall in front) and why only some of the time. That’s the question that should get you to the cause.
If you have a staging copy, reproducing it there with WPML and Wordfence turned off would also tell us quickly whether either one plays a part, without touching protection on the live shop.
In the meantime, if the alert pops up, reloading the page and trying again should work, since nothing is wrong with your attributes.
Let us know what you find.
