Product attribute type has changed after WC update

Dear Caleb,

I would also beg you to revert the latest changes and bring back the useful feature of entering any value for pre-defined product attributes in form of a text- instead of select-fields!

There are so many cases where “select”-fields DO NOT make any sense and are simly useless!

here some more cases: length, width, height, weight, mileage, build year, dates, names, cargo-load, engine-type-names (thy are crazy), a.s.o. …

Adding customised-fields is not an option as the existing fields should be used for this!

Note: not all woocommerce-users use it to sell stupid T-Shirts!!!

Beside this, editing the attributes needs to be really simplified:

=> How about displaying the attribute values without the need to slide-open all attributes one by another?! Why are the values hidden? So many additional clicks are needed to maintain all the attributes!!

… this really needs some improvement! (without removing good and broadly used freatures!)

ps: i read the thread.

Why was this topic marked as “Resolved” even it is definitively NOT solved and the provided “solutions” are no real solutions?!

I don’t know why this was resolved…I believe there will be many more people that chime in once they realize that this feature actually changed. My guess is people have not fully realized that this changed…

I proposed the solution whereby if you choose an attribute to have “free text” values, then the feature to manage values is turned off (i.e. you don’t manage “free text” values as attribute values).

Conversely, if you choose a “select” attribute, then the ability to manage attributes IS enabled as you DO want to manage them and keep them consisted on the front-end.

The main issue that is lost here is that WooCommerce now can’t begin to mimic an Amazon product page in terms of metadata…This is not a good place to be. Woo needs to be able to manage attributes natively without plugins (i.e. this is a CORE feature, not some nice to have).

How would one even begin to add attributes for:

ASIN
UPC
NSN
Mileage
and hundreds of other use-cases where the Attribute NAME must be consistent, but the values should be free-text?

Look at this Amazon listing for a simple oil filter:

Now look at the metadata that needs to be managed for this simple product (an auto part):

Brand Wix (This could be a “select” attribute)
Model 51348 (text)
Item model number 51348 (text)
Manufacturer Part Number 51348 (text)
OEM Part Number 51348 (text)
National Stock Number 2940-01-154-5127 (text)
ASIN B000C9WLA6 (text)
Date First Available November 11, 2005 (text)

This is just one product with one set of metadata. These are not tags or categories and are attributes of this product. There are so many other types of data for various types of products that could be added to this list.

I think the current development lost site of why the attribute feature was created in the first place with “select” and “text” capabilities in the first place.

I have also NOT heard any clear articulation why this was even changed accept “confusing.” What was confusing? Most likely it was the management of “text” values that were proliferating. The way to fix that is to not manage “text” attributes, only “select” attributes. But killing the whole feature is causing a ton of work for all of my clients who are in the parts business.

The issue is resolved because this change will not be reverted.

Custom attributes can be used if you need fluid editing, “add new” can be used if you are using global attributes. Any other use cases generally fall into the “mis-use” category.

We’ve now talked this through with many shop owners, and most have now seen and found the better way to go about what they were doing. If you don’t think custom attributes will work for you, or don’t understand why you shouldn’t be using global attributes for some scenarios, then you can build a custom attribute type that brings back the text editor for global attributes. Though time would better be spent building custom fields since global taxonomies is really not what you should be using for some of the things you have described.

• This reply was modified 6 years, 8 months ago by Caleb Burks.

I’m as mad as bobteree and dumboxp after reading this and after only just encountering this issue today and not understanding what I may have been doing wrong concerning my site’s taxonomy, and seeing that, just to edit some text on one of the product attributes, because of a misspelling, I’m looking at a blob, (like bobteree said,) of “tags” I’m supposed to select from.

How am I going to edit a product’s variation now?

Where do I go to learn all about properly using my site’s taxonomy? I didn’t know I was misusing anything. Now I’m pretty screwed because I have a ton of stuff to change.

I read the thread.
But please place it back, Give us the choice…as it was…

We use this for Extra EAN numbers and prices.
When you can choose between 3 choices there is no problem but we have over 15.000 EAN codes. It always is searching for a new number and this gives an server error.
And when we add a new number it takes over 45 seconds before it can find anything.

We need it to be text.

Are you kidding? These solutions are not suitable for solving the problem.
On my site from more dishes their recipes use attributs.
And their type is very important for the correct operation of the filter.

Hi,
This change also broke my API connection between my ERP and Woocommerce. I don’t understand a change as this, which is not compatible with previous versions?