We should ship with default configuration, but leave it disabled by default so that users can selectively enable and override what they want.

Comments

damienmckenna’s picture

How about the reverse - automatically load it but provide a single click method of disabling it? I'd wager that more people would not know how to disable pre-defined intelligent defaults and not know how to change them, vs people who know how to change them and would be well able to disable them if they so desired. Remember, it's best to aim for the default configuration to suffice for the 80% who want average settings, then provide mechanisms, like an obvious OFF switch for those who want to do more with it, rather than annoying the 80% who think they've just installed a useless module. IMHO of course ;-)

How about automatically stating on the metatags admin pages whether the bundled defaults are loaded, and providing a simply toggle to hide this message, similar to Views always shouting about whether or not Advanced Help is installed?

kenorb’s picture

Version: » 7.x-1.x-dev
Priority: Normal » Critical

Related:
#1371968: Show/Hide Meta tags fieldset per content type
#1429100: How to disable metatag for custom entity
#1644554: Wizard shows other module fieldsets on every step

Having this by default, it's breaking the theming and forms around the site by rendering fieldset for every form, so marking this as critical.

@DamienMcKenna:
You can't force people to have it by default and render fieldset on every single form (even the simplest custom forms) on the site without knowing it's structure.
Even on ctools wizard forms, it's rendered on every single step (10 steps and you see it over and over again).
So that means that having hundreds of modules defining forms and single Metatag module, so other hundreds of modules have to hardcode every time the following line: unset($form['#metatags']);
What if more modules decide to follow this approach, so the other modules will have tons of unset's, instead of doing the main thing.

murz’s picture

This module adds metatags to each entity as default, but many entities have no separate page (url), so metatags for them are not needed and not useful.

I think that metatags must be enabled by default for node entities, and for taxonomy (with easy way to disable it per vocabulary or node type - not each node type need metatags), and must be disabled (not attached) to other entities (commerce line items, commerce orders, other custom types, etc).

And in module configuration add way to attach metatags for custom entitites (per bundle or per entity type).

For example, my site have many custom entities that used only in admin interface, but each of them have metatags fieldset (Meta tag module form elements.) that I can't delete.

murz’s picture

Title: Disable the default configurations » Disable metatags by default on all entitity types, enable it only on needed and popular types - nodes, terms
damienmckenna’s picture

Related: #1429100: How to disable metatag for custom entity

Also tagging this for the stable release.

dave reid’s picture

I'm working on this now. Basically I'm going to add logic that if an entity doesn't have any configuration for it's entity type and/or bundle, and if $entity->metatags is empty, then we should not display the form or try to 'view' any meta tags for that entity.

So to enable support for an entity type, you would have to manually add configuration for it (empty, or with some values, doesn't matter, it just has to have any possible configuration).

dave reid’s picture

Status: Active » Needs review
StatusFileSize
new3.9 KB

Patch attached which implements #6.

dave reid’s picture

Status: Needs review » Fixed
murz’s picture

Thanks, works on my sites very well!

JvE’s picture

Status: Fixed » Needs work
+++ b/metatag.module
@@ -267,6 +267,8 @@ function metatag_config_delete($instance) {
+  drpual_static_reset('metatag_entity_supports_metatags');

typo: drpual_static_reset should be drupal_static_reset

Also, this breaks the ability to disable metatags for content types through hook_entity_info_alter().
The ability of "node" entity_type to have metatags overrides anything the bundle entity_info has to say about metatags.

The new way to disable metatags for a content type:
- disable "node" config
- add config for every single content type for which you want to enable metatags

I think there has to be a better way..

damienmckenna’s picture

@JvE: Please try the latest -dev version, Dave fix that small typo.

JvE’s picture

Thanks, but the typo doesn't bother me.

Losing the ability to easily enable/disable metatags for content-types and vocabularies does.

Now I have to disable the default configs and then one by one add (and maintain) a config for each content-type and each vocabulary that I want meta-tags on.

dave reid’s picture

Status: Needs work » Fixed

This is the same pattern you would have to use for configuring your Pathauto patterns as well. you'd have to leave the default node pattern blank, and configure each content type how you want. If you have options or alternative ways how we could do this better, please file a new feature request issue.

damienmckenna’s picture

We've released alpha8 which fixes the drpual_static_reset() typo.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

JvE’s picture

damienmckenna’s picture

@JvE: I reopened that issue as it was different to this issue.

caschbre’s picture

I'm confused at how this patch is working. I'm using fieldable_panels_panes and metatags are showing up on the manage display form. How do I go about removing metatags from fieldable panels panes?

damienmckenna’s picture

Status: Closed (fixed) » Active
damienmckenna’s picture

Status: Active » Closed (fixed)

(wrong status)