befantasy
Forum Replies Created
-
Thanks for your fix
Based on the detailed breakdown I provided earlier—specifically the three different behaviors between the Product Edit “Add New” tool, Quick Edit, and the Full Term Edit page—have you been able to reproduce this bug on your end?
After further testing, I found that this is not a bug within Variation Swatches, but rather a WooCommerce Core sanitization inconsistency. I confirmed this by disabling your plugin and the issue persisted with the default WooCommerce dropdowns.
Thanks for your help. I think I fond the root cause.
Summary
There is a sanitization mismatch between the inline “Add New” attribute tool (on the Product Edit page) and the Global Attribute Manager. When an attribute slug is created with a decimal point (e.g.,
7.5ml), the web admin UI fails to match the variation, causing it to revert to “Any…”.The Root Cause (Discovery)
I have identified that WooCommerce/Variation Swatches handles slugs differently depending on where they are created:
- Method A (The Problem): Creating a term via Product Edit Page > Attributes > “Add New”. This allows the slug to be saved with a decimal point (e.g., Name:
7.5ml, Slug:7.5ml). - Method B (The Standard): Creating a term via Products > Attributes > Configure Terms. This automatically sanitizes the slug (e.g., Name:
7.5mlbecomes Slug:7-5ml).
When Method A is used, the variation selection fails to save/display in the web admin (reverting to “Any”), likely because the UI or the Swatches plugin expects a sanitized slug without dots.Steps to Reproduce
- Go to a specific Product Edit page.
- Under the Attributes tab, click “Add New” to create a value like “7.5ml”.
- Go to the Variations tab and create a variation using this “7.5ml” attribute.
- Click “Save Changes”.
- Result: The dropdown resets to “Any…”.
- Verification: Check the WooCommerce iOS App. The attribute appears as “7-5ml”.
Expected Behavior
The inline attribute creation should follow the same sanitization rules as the global attribute manager (converting
.to-), or the Web UI/Swatches plugin should be updated to support slugs containing decimal points to ensure data consistency.Workaround Found
Manually editing the attribute slug in the Global Attribute settings from
7.5mlto7-5mlresolves the issue immediately, and the variation saves correctly.Furthermore, I’ve noticed an inconsistency in WooCommerce’s internal slug standardization. On the “Edit” term page under Global Attribute settings, it’s impossible to save a slug as “7.5ml” because it’s automatically corrected to “7-5ml”. However, using the “Quick Edit” feature in the same list view allows “7.5ml” to be saved without any standardization. This bypass is likely how these problematic slugs are being introduced into the system.
Thanks a lot！
It’s really strange — the problem is that what I see in my browser is an HTTP 200 internal redirect. There’s indeed no 30x response, but it definitely does redirect.
And it’s not even all URL parameters that trigger an HTTP 200 internal redirect — only parameters like ‘srsltid’ behave this way. I don’t have access to another computer at the moment, but I’ll test it on a different machine when I get the chance.
Thanks again！
I never denied your test results — I’ve also conducted the corresponding tests myself.
But you never followed the steps I described in your own testing. I’m just trying to figure out where this redirect is coming from.
Again：Did you ever run a test in edge or chrome browser?
- This reply was modified 10 months ago by befantasy.
I’m fully aware of your test results. I got the same outcome when testing with curl, and I even bypassed Cloudflare locally. But did you see the screenshot I shared earlier? In the test using the Edge browser, which I highlighted, the browser recognized it as an HTTP 200 internal redirect. What’s more, I tested on many other WordPress-based sites using the browser and was able to reproduce the same redirect behavior. I’m puzzled as well.
So, It’s not a wordpress core built-in feature?
Did you ever run a test in edge or chrome browser?
- This reply was modified 10 months ago by befantasy.
That’s right, it’s an HTTP 200 response, but it then shows an internal redirect. Could this be a browser behavior (feature)? When I tested it locally, I bypassed the Cloudflare CDN using local DNS resolution(host file).
I uploaded a snapshot.
- This reply was modified 10 months ago by befantasy.
Thanks @sirlouen
According to your suggestion, I used the browser’s developer mode (Edge 138.0.3351.121) and disabled the cache. The URL with the
srsltidparameter still redirects, showing as an internal redirect. However, if other unrecognized parameters are used, there is no redirect.Thanks @sirlouen
I’m also puzzled, because I couldn’t find any related strings in the WordPress code. But in actual tests, a fresh installation of WordPress does strip these parameters and performs the redirect. Did you test the URL I just posted?
Auto-redirect Params: https://wp.linz.link/?srsltid=AfmB
Non-redirected Params: https://wp.linz.link/?unstripped=AfmB
Auto-redirect Params: https://demos2.exsthemewp.com/child-medic/contacts?srsltid=sdafsadf
Non-redirected Params: https://demos2.exsthemewp.com/child-medic/contacts?unstripped=sdafsadf
Based on these tests, I thought it was a WordPress core function.
Because if the redirect were implemented at the server level, then all parameters should be redirected — not just those related to source tracking.
- This reply was modified 10 months ago by befantasy.
Thanks for youre reply.
I should be able to confirm that this has nothing to do with Yoast SEO or W3 Total Cache.
As I mentioned in the post above, I disabled every plugin I could think of that might affect parameter stripping — including SEO, caching, redirection, statistics, and so on.
In addition, I created a fresh WordPress installation with no plugins or themes installed（v6.8,2）. I tested it and it can automatically redirect: https://wp.linz.link/?srsltid=AfmB
- This reply was modified 10 months ago by befantasy.
Another question：
WordPress core does not strip all URL parameters, only certain ones like
srsltidandfbclid. I’m not sure what the full list includes. I would like to know where in the source code the logic is defined to decide which parameters are stripped and which are preserved. I searched the codebase and database but couldn’t find any files that contain the stringssrsltidorfbclid.Thanks for your reply.
Since I migrated from Yoast SEO, I had already configured the page cache and CDN cache to exclude the sitemap. However, after adding this filter, it seems that the sitemap now updates correctly when publishing posts via the iOS WordPress app.
May I ask why, without the filter, publishing or editing posts via the web interface would update the sitemap, but publishing via the iOS WordPress app would not?
Thank you for the explanation. I don’t quite understand—do you mean that the link insertion feature in the desktop block editor can search for products, and this is made possible by the WooCommerce plugin? Is it also possible for WooCommerce to enable this feature in WordPress mobile app?
I don’t think this feature can be implemented within WooCommerce. Isn’t the link insertion functionality part of the UI in the WordPress mobile app?
Also, when using “Link to existing content,” I can only search for posts and pages by entering keywords — products don’t appear in the results. I believe the key to resolving this issue lies in the WordPress mobile app, not WooCommerce.
In the built-in block editor on the WordPress web version, I can search for products when inserting a link.
- Method A (The Problem): Creating a term via Product Edit Page > Attributes > “Add New”. This allows the slug to be saved with a decimal point (e.g., Name: