Lupin

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).

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”)

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.

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.

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.

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).

I can’t share a link or picture (page isn’t public).
I think the problem is due to an wordpress weirdness (at least from my view). I set up a page that has some static content, but also uses a shortcode to display a single post of a certain category. Apparently that makes the page no longer a “page” page but a “blog” page. Could that be the reason the “display on .. page” settings of your plugin no longer apply then? That is very annoying that WP changes the type, because that single blog entry is not always there, so it switches between “page” and “blog” depending on that.