Use a field with meta_key starting with ‘_’ (underscore)

Hi @lupin3,

How did you store that meta-key to your products? Using a Custom Attribute?

It is created/written by a plugin and used by that in several places, so I can’t change the meta-key’s name. I just want to be able to use it in a feed (like WP All Import/Export can access it for example).

The issue is that WP All Import/Export accesses all keywords in the options table (where the Attributes are stored. I don’t want to include everything because not everything is WooCommerce related.

In this case you need to get in contact with the writer of the plugin and ask him what keyword they use to store the data in the options or post-meta table. When you have that keyword, you can open the FeedManager->Settings page and add that keyword to the “Third Party Attributes” keywords. Use a % as wildcard before and after the keyword.

I understand that showing them all would confuse some, but it is still a big limitation to not be able to use those metas at all. Changing the plugin is out of the question since all code that uses the variable and all installs around the world would have to be updated.
Changing the feed would be the much more versatile option, because it can be useful for any other plugin in the future. There are already special functions like “static value” or “combine values”. Why not add an entry like “by meta key”, so people, who know what they need, can just enter any meta-key. Or make the drop down similar to WP All Import/Export, where you can type in any value OR select from the list (I know that’s not just a simple HTML form element, but should be doable). This would also be an alternative to the “Third Party Attributes”, which I actually find quite cumbersome to use. Additionally “Third Party Attributes” don’t seem to work with meta-keys starting with ‘_’. They are not shown in the list even after adding the meta-key to the string (with or without any combination of % wildcard).

• This reply was modified 6 years, 11 months ago by Lupin.
• This reply was modified 6 years, 11 months ago by Lupin.

Our plugin does (or at least should) support metas from other plugins, so there should be no limitation. Also I don’t want you to change any plugin.

Usually using the Third Party Attributes should give you the option to access attributes from other plugins. We might disagree about how cumbersome this is to use, but up until know it always worked with plugins other users had. You just need to know a part of the meta key, add that to the list and it should give you access to the attributes from that plugin.

But the issue here is probably like you said that WooCommerce usually sees keys in the postmeta table that start with an underscore as not being custom fields. So these are thrown out now

But let me investigate the situation. What plugin are you using to add the meta value?

The plugin is “CTL Woocommerce EAN” ( https://codecanyon.net/item/ctl-woocommerce-ean/19325509 ). It stores the EAN in a field with the meta-key “_ean”. If it were just me, I’d go into the database and change one of the data source entries for a feed to ‘{“m”:[{“s”:{“source”:”_ean”}}]}’ and then never touch that feed with the backend again. But I can’t expect the actual users to do that. The EAN plugin was installed “before” me (though I am the guy, who has to make it work now), which is unfortunate, because I would most likely have solved it by just adding a custom field.

Hi @lupin3,

OK, that plugin is unfortunately only in a paid version so I can not test that out here, but could you try the following:

1) Open the Feed Manager -> Settings page.
2) Clear the Third Party Attributes input field.
3) Copy the following line into this Third Party Attributes field.
%_wpmr_%, %_cpf_%, %_unit%, %_bto_%, %_yoast_%, %_ean%
4) Open the feed list and refresh the browser (CNTRL-F5) and try again.

If you do not find the ean in the “From WooCommerce Source” selector, check if you see a blank line in that list. If there is a blank line, try selecting that and see if you get the correct EAN data in your feed.

Please let me know the result.

Already tried that (well, not exactly looking for an empty line, but for any line that was not something known else) and tried again now to make sure (also with different combinations of “%_ean%”, “%ean%”, “_ean”). There’s no empty line or any line that’s not definitely something else, for that matter.

I’ll contact the plugin writer of CTL Woocommerce EAN and see if I can find out why this items is not showing up as it should. Give me a few days to contact them and work it out.

Hi @lupin3,

Could you try the following patch file? https://sendanywhe.re/65XIODF0

Please download that file and open the ‘wp-content/plugins/wp-product-feed-manager/includes/data’ folder on your server.
In that folder make a backup of the ‘class-ajax-data.php’ file.
Then copy the patch over the original file and check if you can see the _ean attribute in your list.
Be aware that you still need the ‘%_ean%’ keyword in the Third Party Attributes list.

Let me know if this works.

Hi!

Sorry everything was slow going during the christmas holidays, so I couldn’t try it out earlier. Now the link for the patch file has timed out. I guess it was a change in myajax_get_input_fields or combine_custom_attributes_and_feeds? (although looking over it quickly I couldn’t see where the fields would get “lost”)

OK, here is a new link to the file https://sendanywhe.re/FQ8VMLBF

This did not change anything, but I found out the reason why after testing for quite a while.

The keywords are split by “, ” ([comma][space]). The description only says “comma separated” not “comma space separated”. This separation is a very weird behaviour, because whitespace around list items should not and in 99% of all compareable cases does not matter. “A, B, C” should behave the same as “A,B,C” or ” A , B , C”. This was the reason why not even an empty entry was shown for “_ean”. I just added it to the list without space. The keywords should really be split by [comma] only and then be trimmed for whitespace. That is the expected behaviour. I changed that for test purposes in class-ajax-data and class-queries, which fixes the issue. But the [comma][space] split is apparently used in several other places in the plugin, so I did not go further. But this should really be changed to the “usual” convention.

I also found a huge bug that in this case my not damage anything (but could already be confusing), but in other cases could be devastating. I see that the keywords are used in an SQL LIKE statement as is. _ [undescore] is a single character wildcard in a LIKE statement! “meta_key LIKE ‘_ean'” will match any 4 letter combination ending in “ean” and it gets even worse with ‘%’ (“LIKE ‘%_ean%’) which will match any string containing “ean” (preceded by at least one character). I hope there are no UPDATEs or DELETEs based on a LIKE statement like this.

There’s also another bug with “cleaning” the attribute names/labels. You remove the keyword part from the meta_key name (e. g. strip out “_yoast_”). This has very nasty side effects. Imagine two third party attributes (from two plugins maybe) called “A_attribute” and “B_attribute” which you select by adding “A_%,B_%” to the keyword like string. The code then removes “A_” and “B_” from the respective keys and you are left with to identical labels “attribute”. But which is which? The “$prev_dup_array” used doesn’t help either because it is not checked there and you end up with two entries with the same label in there as well. An (for the purpose of demonstration extreme) case where the replacement can break alot is, if for some reason you have a third party attribute that’s just an ‘e’ for example, the code will remove all ‘e’s from all the third party attribute in the dropdown. I tried it, it does that and you end up with entries like “viwd”, “rul”, “xpiration”, “vrsion”, “thm” aso. I don’t think removing anything from the key is a good idea. Even if you don’t end up with identical labels it makes it very hard to know which meta_key you are actually using (some plugins my use cryptic names and you only know it’s from that plugin, because of a prefix they use).

@lupin3,

Thank you for your feedback. I will make sure these items are addressed in the next update. Sorry for the time you had to spend on it.

As the issue is solved by yourself I will close this topic for now. If you have any questions or other issues, don’t hesitate to reopen it again.

Best regards,
Michel