Support for custom entities

Attached find a patch that adds support for all content entity types and their bundles (against 56026cc278cdcc11f463d5dd07179e755a44722e)

.. and tests.

Reviewing the patch again, yes this would be a great improvement, but we need some tests to confirm it all works.

Created a new version that only adds entities to the select list when they have a metatag field.

Patch attached.

Attached is a re-roll of #2 that works with beta10.

I haven't used #7 so far - but I'm unsure, if I just never tried it, or if I had problems with.. Unfortunately I'm not having time now to try => therefore the re-roll of #2 for everyone, who uses that

agoradesign: The patch you posted is giving me trouble on Drupal 8.2.1 with Metatag beta10.

On line 176 of MetatagDefaultsForm.php it's using $definition->getLabel()->render() however the result of $definition->getLabel() is already a string and doesn't have a "render" method. I'm not sure if this is in all cases or only in certain cases, but it's causing the whole settings form to error out for me.

I just double checked in the EntityTypeInterface interface and then EntityType class and it appears getLabel() always returns a string.

Actually, it seems that the ECK module returns a string, which appears to be a completely valid return value according to the method definition. While most other types return a render array for the string. Is there some way to standardize how metatag works here so that it supports either type of label return value, or should this be considered a bug in ECK?

Here's another reroll for beta10 with the addition of a getEntityTypeLabel method which handles the logic to determine how to extract a string from the entity type label. (#7 seems like a good change but I have not tested it yet, I needed something quick for a client site).

With that patch, I am able to define custom meta tags for any entity type. However, if I add a meta tags field to a custom entity type, it is not pre-populated with those defaults. It seems to default to the site default meta tags instead.

I've discovered other issues with custom entity types, such as metatag not always picking up their add/edit pages properly. For Commerce Products, for example, it was using the default entity tags rather than the ones I had specified for that product type.

I've got custom entity support working better in my local install, and I'm going to go ahead and roll patches for both beta10 and 8.x-1.x now.

Here's a new patch for beta10 (not dev yet!) which seems to fully support custom entities for me, including their add/edit pages if they're using standard route names.

I'll roll a version of this for 8.x-1.x now so that it can hopefully be merged into dev once it's fully tested.

Re-roll for beta10 again to add a missing docblock to the new getEntityTypeLabel method I created.

Here's a totally new patch, created from scratch based on the ideas from the previous patch, and applied to the latest 8.x-1.x version.

It does these things:

• Makes any bundle with content able to be used for Metatag defaults
• Makes an option for defining defaults for an entire custom entity type without selecting a bundle
• Supports all custom entity type add form routes
• Fixes issue with generating label for entity type defaults without selecting a specific a bundle
• Allows deletion of all non-stock metatag defaults.

This will not work on beta10, but my previous patch still works for beta10 (although not having all of the latest fixes from this patch).

I think this is ready for further review, and hopefully some form of it can be rolled into dev soon.

What about this? Instead of supporting *all* entity types, ignore some core ones that we'll never want to use and then require that entities have a 'links' property, otherwise they won't be supported. This way it'll show the suitable core entity types but will ignore e.g. Paragraph Types.

Should we still add a hook or some sort of API to let other modules customize the list beyond using hook_form_alter()?

I just realized that testAvailableConfigEntities() was unfinished and will fail at the end. The plan there is to check the select list for some known entity types, and confirm that some unwanted entity types aren't listed.

Here's a quick fix for the typoo I left in X-) and some assertions for the tests.

It'd be nice to add extra tests to e.g. pull in Commerce, but I don't think the drupalci testbots can handle that.

I completely forgot about the test entity. Woot.

I manually tested ECK, it seems to work fine.

Committed. Thanks everyone!

Thanks for fixing up the patch and committing!

For the record, I'm using this with the latest Commerce beta and it's working great with the previous patch to set defaults and override those defaults using a metatag field on product types. Will test with the latest commits and report back if there are any issues.

To confirm, latest dev works great for me with both ECK and Commerce with no patches needed :)

+++ b/metatag.module
@@ -189,7 +189,7 @@ function metatag_get_route_entity() {
-  preg_match('/(entity\.)?(.*)\.add/', $route_name, $route_name_matches);
+  preg_match('/(entity\.)?(.*)\.add(_form)?/', $route_name, $route_name_matches);

This url path detection is breaking the Lingotek integration with the latests dev release of metatags.
Shouldn't it have a more robust solution than a regexp against a expected path?

The attached patch fixed the issue for me, but I guess we need a more robust solution anyway.

@penyaskito: Whoops! Sorry about that.

This is a little simpler.

Works for my tests too, thanks!

Committed. Thanks!

Thanks for the (super)quick response :-)