Product attribute hidden in archive due to .wd-hidden class

Hello, thank you for your response.

We would like to know exactly what modification has been made, as we have not changed any of the options mentioned (such as “Limit swatches on grid”), and it is now being displayed.

Kind regards.

Hello,

We are currently replicating your steps in our STAGE environment, as we are experiencing the same issue and want to understand how to properly solve it in future cases.

We have tried disabling the “Limit swatches on grid” option and enabling it again (since we actually want to limit it to 4 models), but the variation is still not displayed.

For this reason, we would like to know exactly what change you applied on your side to make it work correctly. We need to understand this both from a technical perspective and to properly explain it to our client and handle similar cases in the future.

Could you please clarify what specific action was taken?

Thank you in advance.

Hello,

Thank you for the clarification.

We understand your comments regarding the behavior of the “Limit swatches on grid” option and the “+X” indicator.

However, from our side we would like to highlight an important point: even if there were no code changes, there must have been some change in state or configuration between the time the issue was reported and the time it was reviewed.

In order to properly handle these cases with the client in the future, we need to confirm what change was made.

We are currently facing the same issue as in production: the model is not displayed, and we need to know what needs to be modified in order for it to appear correctly.

Thank you in advance.

Hello,

Thank you for the screenshot.

Indeed, the model (808) is correctly displayed in the environment you are showing. However, we would like to clarify that this corresponds to the production environment.

The case we are currently analyzing and replicating is in our STAGE environment, where the behavior remains as initially reported: the model is not displayed in the product archive.

For this reason, we need to identify the exact change (whether configuration or attribute state) that caused it to display correctly in production, so we can apply the same solution in STAGE and in future similar cases.

We look forward to your clarification.

Thank you in advance.

Hello,

We have tried regenerating the “Regenerate the product attributes lookup table” option in WooCommerce > Status > Tools, but it did not resolve the issue.

We are attaching a screenshot showing the current behavior.

We are providing you access to the STAGE environment so you can review it directly.
Please, it is IMPORTANT for us to understand exactly what action you take or what changes you apply, as we need to be able to replicate the solution if this happens again in the future.

We look forward to your response.

Thank you in advance.

Hello,
Apologies for not providing the required access details earlier.

We are now sharing the necessary information so you can properly review the case.

We look forward to your feedback.
Thank you in advance.

Hello,

Thank you for your check.

We are attaching screenshots showing how we are seeing it on our side, as in our case model 808 is not displayed.

We have included images from both the homepage and the archive, where the variation is not visible.

As you can see in our screenshots, our intention is to display 4 models (not all) in the archive, but within that limit, model 808 should be one of the visible ones.

Additionally, we are attaching an image where it can be seen that the first element has the .wd-hidden class, and it corresponds precisely to model 808, which is why it is not being rendered on the frontend.

Could you please review it again? It seems the behavior is not consistent depending on the environment or session.

We look forward to your feedback.

Thank you in advance.

Hello,

Thank you for your suggestion.

However, we would like to point out that in the production environment the issue was resolved without deactivating or modifying any third-party plugins.

For this reason, we understand that the cause should not be related to a plugin conflict, but rather to some configuration, state, or cache-related change.

Could you please check if any other changes were applied in production that might have caused it to work correctly?

We look forward to your response.

Thank you in advance.