Global configuration via config entities

This isn't clear enough?

I am not sure why you want config entities? should this not be a single config-form (with a single config yml) or should it relate to multiple yml files? (lookup drupal console : $/> console generate:form:config)

So it seems to me that you're looking for:

1. enabling|disabling of group|tag plugins globally?
2. default global tags to use when we aren't looking at an entity page?

Notes:

1. the metatag module should be written to use a service to set|retrieve active tags, instead of a drupal_static() (then it could be used by anybody anywhere to set tags in new scenarios, and then it could automatically load defaults)
2. are we happy with the approach of checkout the CurrentRoute, matching to an entity canonical path, loading THE entity, and checking for fields? Does it make sense to use the field-formatter to ->set() values? (yes I know that teaser and list views would confuse things)

D8 is released. and all|most of the other D8 tasks are out of the way.

I have implemented a UI like the Drupal 7's one that manages global, entity and bundle defaults at https://github.com/Lullabot/metatag/issues/15.

Tomorrow I will start working on a patch to integrate that system with what we have at Drupal.org.

Here is the first version of the patch.

Tests pass and the module works, but there is a collision: Field meta tags can have default values for each content type:

The above logic collides with the admin interface, which lets you to do the same in the same style as the Drupal 7 version does:

Shall we keep field defaults or shall we do it exactly as the Drupal 7 version does it? Personally, I prefer the latter, but I surely miss a lot of background maintaining this module.

Damien, Dave, what do you think?

In the meantime, I will create another patch for the second option (do it as in Drupal 7).

Here is what I am going to work for the next patch: https://github.com/Lullabot/metatag/issues/15#issuecomment-159991027

Personally I prefer to keep entity things with their entity, rather than in a separate system.

Then this would be the site builder experience:

1. Install the module.
2. Open to admin/structure/metatag_defaults.
3. Adjust global and entity defaults.
4. Open http://d8.local/admin/structure/types.
5. Add the metatag field for a content type. Then set defaults. Repeat for other content types.
6. Open admin/structure/taxonomy.
7. Add the metatag field for a vocabulary. Then set defaults. Repeat for other content types.
8. When creating content, adjust metatags if needed.

I think that steps 4 to 7 will be confusing and hard to discover for site builders. This is the reason why I see value in keeping bundle defaults in the admin interface. What do you think, Damien?

Here is a new patch that fixes those warnings related with Token::replace().

I think that the failures for PHP 5.5 & PostgreSQL 9.1 3 are not related with the patch.

This patch removes the Delete operation in global and entity defaults.

Details at https://github.com/Lullabot/metatag/pull/19

Tests pass!

https://imgflip.com/gif/7uno1

This patch adds the ability to delete bundle defaults and to revert global and entity defaults.

Details at https://github.com/Lullabot/metatag/pull/19 and https://github.com/Lullabot/metatag/pull/20.

Here is another patch that fully integrates with field defaults. Details at https://github.com/Lullabot/metatag/issues/15.

This patch adds some adjustments to the README.txt and refactors the logic to render a token browser, as not it is used by the global UI and the default field UI.

Weird, I don't know the meaning of the above test failures.

I will wait. This happened before with a previous patch and got solved magically afterwards. Seems unrelated with the patch code.

This patch adds metatag defaults for the front, 403 and 404 pages. Plus testing coverage for them.

This patch removes a few tag schemas which are redundant as they use the same structure as metatag.metatag_tag.*.

Add an install script to add a new meta tag field to all content types - that'll solve the problem on initial install of it not being available for individual nodes.

I would rather indicate at the global UI that if you want to override these defaults for a content type, then you should add the field. That would optimize the use of the global defaults. What do you think?

Set it up so that the inheritance system works like this:
Global config
Entity config
Bundle conf
Field defaults
Field values

That is how it works. See metatag_get_default_tags().

In the field defaults, show what would be inherited.

The default fields are populated with global defaults. See MetatagFirehose::form(). Is this what you mean?

It also needs an update script so that any sites which had beta2 running will be able to get the functionality working.

All right! I will install beta 2 and test whether we need to do something for the upgrade.

I think the current (D7) method is a big UX win for our end users. As a developer, being able to add new config instances that didn't have any relation to entity types or bundles, and had a clear path for inheritance was a huge win as well. I was also with a couple lines of code able to make default metatags for sub-pages of nodes. The current behavior in the D8 port would make those customization much harder. Having the config system for storing all the defaults and visible in one place keeps everything consistent rather than shoe-horning our data and UX into a system that doesn't, in my mind, feel prepared or appropriate for it. And does not stick to the vision originally laid out by the original module.

The install functionality I mentioned could instead just be a message giving a quick explanation of the intended behavior.

Sounds good.

Maybe the "overview" page I was thinking of could be used to help push this idea, and provide shortcuts to adding appropriate fields to entity bundles as needed.

I don't know how we could do it. At the very least, we could say at the top of the UI: "If you want to add bundle overrides, add the field Metatag and set defaults".

By the sounds of it, there's *nothing* in juampy's patch (or my original goals for the D8 version) preventing someone from continuing to follow the D7 methodology, besides maybe some UX around the field defaults, and we're only at beta2 so we can work on improvements.

I removed bundle defaults from the admin UI because it would be confusing as they would collide with field ones. However, if we are up for fully removing field defaults, then I could get them back. See this pull request for an screenshot: https://github.com/Lullabot/metatag/pull/14.

Sounds good to me!

How about when we edit a node? Should we also show the metatag fiedls and store overrides in config?

Here is an updated version of the patch that takes into account #2613654: Parse image fields for image URLs.

Kinda going back to what I mentioned earlier - what if the UX presented as a field's default settings is just a copy of the appropriate global defaults, i.e. store the "field defaults" in the global configuration? Then it'd be two different ways of accessing the same thing, but they'd just be stored in one place - the global configuration.

For the moment and for simplicity, I will just hide the ability to edit or delete the Metatag field. Bundle defaults would be editable only at the admin UI.

Based on the latest comments, I am working in the following tasks:

• Restore bundle defaults into the metatag admin UI.
• hook_install: add field to all supported bundles
• hook_uninstall: remove fields.
• Bundle added: add field.
• Bundle removed: remove field.
• List of fields for a bundle: remove edit and delete links (so it looks like the Drupal 7 version, which uses hook_extra_fields())..
• Manage display: hide metatag field.

Does the above list look okay to both of you?

Is hook_uninstall() supposed to remove fields now? I thought the Field API system was supposed to block uninstalling modules if any of its fields are still in use?

If we install fields automatically and don't let users set default in them, then we should remove the fields ourselves as well when the module is uninstalled. This may be impossible if Drupal checks for field dependencies before calling hook_uninstall(). Does this make sense to you Damien?

Given that Drupal does not allow you to delete metatag fields on hook_uninstall() as the ModuleInstaller field validator blocks it, we should not add the fields to all the bundles on hook_install() because that would make uninstalling Metatag painful (you would have to manually remove all fields before uninstalling).

Based on the above, I will abort the task list from #58 and simply add messages on install and at the top of the administration interface as we discussed at #52.

Here is my new TODO list:

• Show a message on install on where is the admin interface and how to set bundle overrides.
• Add a message at the top of the admin interface explaining that if you want to set metatags for a specific node, you need to add the field to the content type.
• Restore the bundle defaults logic at the admin interface, and replace the "default value" fieldset by a text saying "This can be managed at {path to admin interface}".
• When editing a node that has the metatag field, show a hint on whether the field is being overridden or not.

Does the above look okay?

This patch implements everything listed at #61 except from the hint on wheter a node's metatag is using defaults or being overridden. I don't think that this is a show stopper though and I feel that this is the best we can do to integrate Config API with Field API.

Please check out the patch and test it. I will set up beta 2 and work on a database update.

This patch adds a database update for beta2. I tested it by installing beta2, adding a few fields with default values, and then replacing the code by this patch and running the database update.

I could not figure out how to remove the field defaults of the existing fields after creating config entities, but I am not too worried about it.

Damien, is there anything else that I should implement for this patch?

Those PostgreSQL failures have happened before sporadically. I would ignore them.

Nice @Damien! For follow ups, could you list here what the priorities would be? Then I could help with them but at a slower pace.