Weighting Engine: Post meta support

[mustafauysal]

Is your enhancement related to a problem? Please describe.
Registering meta keys requires additional effort. We can manage searchable meta fields if we provide a UI on the weighting engine.

Describe the solution you'd like
Adding post meta capabilities to the weighting engine would be a good solution.

Designs

Describe alternatives you've considered

• Showing most-used meta keys with a group query and showing them for each post_type. (It's against simplicity and we might get performance issues on large-scale websites.)
• Registering post meta section for each post_type. (It didn't seem the best solution for UI. It's not easy to manage if the same key will be used across multiple post_types)

Additional context

We might consider showing (read-only) meta fields that registered via ep_search_fields.

[robpl1]

Without support for ACFs I don't think that you can claim that your plug-in gives the answers you want first time., because it doesn't, in my case, give the answers I need at all. You should also check out the ACF Custom Database plug-in and see if you can build in support for that.

[JakePT]

Putting this back into needs discussion.

I've dug back into the associated PR to see where we were at wit this feature. Currently the issue is:

1. The list of fields on the weighting screen is determined by the "weightable fields" as defined in code.
2. This list of fields is created from some manually defined fields (eg. post title) and public taxonomies, and grouped by post type and field type.
3. Developers can add fields using the ep_weighting_fields_for_post_type filter. We advise people to use this filter to add custom fields in this article.
4. The challenge of this issue is how do we allow users to add fields using the UI? Originally I was doing this by adding all possible meta fields as weightable fields using the values from get_distinct_meta_field_keys_db(), and then only showing the field in the UI if the user selects the a from a dropdown.
5. Since then, the get_distinct_meta_field_keys_db() method has been updated to only return keys that are going to be synced. I believe this was for performance reasons on sites with lots of meta, and because the values returned by this method are now being used to populate the options in the meta filter blocks.
6. To get around this, I have attempted to change the UI so that adding fields is done with a text box, rather than a dropdown of options. The idea was to then show the UI for custom fields by dynamically adding controls for fields that have a saved weighting configuration, but do not otherwise appear in the list of weightable fields.
7. The road block with this is that due to the current structure of weightable fields, I can only tell if a meta field exists in the weightable fields if it is in the ep_metadata group. If a field has been added to a different group by a developer using the filter, then from within the UI for the ep_metadata group it will appear that a given meta field does not already have a UI, and a redundant set of controls for that field will be displayed.
   • As an example, we currently display the product SKU field, meta._sku.value, in the Attributes group, but if I used the logic described above to display controls for custom fields, I would not see the SKU field in the metadata group, so I would assume that it was a custom field added by the user and I would display controls for that field even though there are already controls. This same issue would affect any custom meta. fields added by a developer.

Some of these issues would be easier to work around if the weightable fields list was 'flattened' from this:

{
	"post": {
		"label": "Posts",
		"groups": {
			"attributes": {
				"label": "Attributes",
				"children": {
					"post_title": {
						"key": "post_title",
						"label": "Title"
					},
				}
			},
			"taxonomies": {
				"label": "Taxonomies",
				"children": {
					"terms.category.name": {
						"key": "terms.category.name",
						"label": "Categories"
					},
				}
			}
		}
	}
}

To something like this:

[
	{
		"key": "post_title",
		"label": "Title",
		"group": "attributes",
		"post_type": "post",
	}
],
[
	{
		"key": "terms.category.name",
		"label": "Categories",
		"group": "taxonomies",
		"post_type": "post",
	}
]

But this would break backwards compatibility with the ep_weighting_fields_for_post_type filter, which is likely to be one of our most used filters. A workaround might be possible by creating a new filter, and then taking the data added by any callbacks on the previous filter and reformatting them for the new data structure.

There may be better options, but this is where I'm at right now.

[JakePT]

The way forward:

1. Implement a layer than flattens the weightable fields configuration as per my examples above. This can be done after any fields have been added using the filter and will involve breaking out the Groups into a separate configuration.
2. Update the UI to use the flattened configuration.
3. In the metadata panel, dynamically render controls for saved weighting values that do not have a corresponding field in the weightable fields configuration. Since the weightable fields configuration is flattened this comparison can be performed across all groups.

[JakePT]

@felipeelia Assigned to you to review failing unit tests.

[felipeelia]

Closed by #3068