Product attribute type has changed after WC update

This is intended. What is the reason you need the “text” option is the better question ??

You can add a new term still: https://cld.wthms.co/vEpkzQ

Or a custom attribute: https://cld.wthms.co/juaHl4

Hi Caleb,

because “text” type is useful in some cases; that’s why it was used before, for years in WC ! ??

Being serious: I use them to help the webshop’s products purchasing and I add vendor SKUs to every each product, so I would later be able to automate or make easier the purchases from vendors. I had used and I’ve been using these attributes hidden, not displayed in front end.
Obviously I can have easily 1 000+ distinct attribute values, and it shouldn’t be “Select” type…

Pls. note:
https://docs.woocommerce.com/document/managing-product-taxonomies/
according to the WC doc linked above I can define product attribute type as “Text”, and it was good as it described there, it worked!

So I hope you would reconsider it and reset “Text” type ASAP, it is a must have!

Best!
V.

• This reply was modified 6 years, 9 months ago by Vane.
• This reply was modified 6 years, 9 months ago by Vane.

If you need to add a new term to an attribute, you still can: https://cld.wthms.co/vEpkzQ

If the terms are only used on product though (SKU like), it would probably be best to use custom attributes: https://cld.wthms.co/juaHl4

I’m not sure you’re looking at both of those options correctly, as the “text” option really isn’t needed.

And just to confirm, you do see that it’s possible to still type rather than selecting from the dropdown: https://cld.wthms.co/hRN4HA ? Or does the select field not work this way for you?

Ok, I got it, just the method changed, thank you!

@vanetreg
i have the same problem. my attribute type text changed also to select.
I need the type text, so i can individually set values for every product (one product has 5 pages, an other product has 15 or 35…).

can you tell me your method?

since the last update the method to set the type doesn’t exist, you can see the type field (now only the select) in the attribut table, but you can’t set it.
thanks

Hi @icaleb,

i think, for the shopmanager/editor is it more comfortable if he selects the default properties for each product from only the preconfigured product properties (for example, A4, DIN A5, paperback, PDF) and don’t add one property to each newly created product, which was not predefined because it contains variable data (for example 4 pages or 20 pages)

What you are describing sounds like the perfect scenario to not use the old text attribute type?

Please review these two options, and let me know why/how they fall short for your needs:

> If you need to add a new term to an attribute, you still can: https://cld.wthms.co/vEpkzQ

> If the terms are only used on product though (SKU like), it would probably be best to use custom attributes: https://cld.wthms.co/juaHl4

Not trying to be rude btw :), just want to understand the different use cases out there.

@icaleb
>> https://cld.wthms.co/vEpkzQ
Oh, that’s right. I thought that it works differently and therefore did not even try it. I can use this method very well for this. So you can best add different page numbers to each product.
I was only irritated because we are under construction with woocommerce and the update led to another creation of this property.
Thanks

This “fix” is a terrible fix. What was the problem that was attempting to be fixed?! Here are the massive issues this has caused:

1) Attributes used to be a flexible way to store both public (customers can see) and private (store owners can see) way of including critical information relating to a store’s products. Use case 1: I used to have a PRIVATE attribute called “Source” I used this value to store free text that was both editable on the fly (i.e. you could update on the product page). An example would be: Source = ($15/unit without shipping from XYZ supplier. Minimum order quantity 100). This has now turned into a mandated “Select” type and is no longer a “Free Text” type. It is utterly useless now. Perhaps this is a misuse of the Attribute feature, but there is NO other native way to store private information regarding a store’s products now. You have turned the feature into a forced-select-only tag machine, whereas before it was very flexible.

2) You have concatenated ALL of my 1000’s of values! This is a mess. Use case 2: I have an attribute called: “Other Product Numbers”. I use this as these numbers are critical for SEO and to publish to various sales channels like eBay and Amazon. These values used to be free text, such as: “Bosch 1234, Napa 1234, Wix 2345” Now the whole things is a bubble select only mess (i.e. the value is the whole string “Bosch 1234, Napa 1234, Wix 2345” and it ignores commas as it is now a tag, not a free, flexible text string.

This has destroyed a key way we manage our taxonomy and create products. I manage 10 customers in the parts industry and now all of their sites and backends are broken.

@bobteree Please read the full thread above and consider what options there still are.

You can still set the attributes to not be visible on the frontend: https://cld.wthms.co/rM3OPv. And, as you can see multiple times above, you can still enter free flow text using the custom attribute: https://cld.wthms.co/juaHl4. Or you can enter a new term to a global attribute using the add new button: https://cld.wthms.co/vEpkzQ

It seems that you’ve been mis-using the global attribute type. If values aren’t shared among other products, they should be product-level custom attributes.

My question is why was this “fixed”? What was broken? Accusing a user of mis-using a feature with a solid use-case is really not productive. I am sure you will hear from others how this broke their workflow and stores. So why was this fixed? What was broken?

Have you read my entire thread?

I understand you can still have the public/private issue.

My main issue, is we must enforce attribute NAMES, but not their corresponding text. Taxonomies should generally be controlled or be controllable. To tell my customer, every single time they need to put a “Source” of their product in…both the Attribute Name and it’s value is terrible workflow. The attribute(s) a customer needs to complete their product description should always be in a drop-down so that the front-end and back-end doesn’t see a proliferation of junk like “source”, “Source”, “Surce?” Anything that appears on the front-end, must be consistent.

You are also missing the workflow aspect of creating products. Attributes are fixed taxonomies, but their values may or may not be pre-defined.

Do you realize you removed a feature, called Attribute Types and forced a data migration of all terms into a concatenated blob? They are uneditable, un cut-and-pastable.

Again, why was this feature even touched? Can you point me to the rationale for removing functionality. You added no feature (performance)?

The general item is that we need global attribute names, but may, or may not, want global attribute values/terms.

My suggestion is that if a user selects an attribute type as “text”, that attribute should have no global terms or values, just be free text.

If a user selects drop-down/select (which could be the default), then there will be global terms or values.

But having to remember to add both an attribute name and text value for every product is terrible workflow.

The fact that your forced the data migration means I have hours of work to migrate attributes and no simple way to do it.

One thing that might be quick fix on the front-end which is killing me today. Since you converted ALL Global Attributes into Select only format, it has rendered all values incapable of being able to be cut and pasted. This is killing me as we need to have all of those attribute values be able to be selected in the UI to be cut and pasted so we can forward the info to a customer, include the value in our product description, etc. There are tons of use-cases where one needs to cut and paste values….Now they are useless read-only blobs that can’t be cut and pasted or reused when creating and editing products. We upload 1000’s of products via spreadsheet and these attributes get reused in creating products…Without being selectable for cutting and pasting out of the UI, yet another UX has been destroyed.

Can you tell me how I can convert old universal attributes into custom attributes across 10,000 products? That is what I need to do unless you find a way to bring back the old way, which wasn’t broken. I need to do a wholesale conversion of global to custom for a few of my global attributes.