We should ship with default configuration, but leave it disabled by default so that users can selectively enable and override what they want.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 1281770-check-if-entity-has-metatags-or-config.patch | 3.9 KB | dave reid |
We should ship with default configuration, but leave it disabled by default so that users can selectively enable and override what they want.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 1281770-check-if-entity-has-metatags-or-config.patch | 3.9 KB | dave reid |
Comments
Comment #1
damienmckennaHow 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?
Comment #2
kenorb commentedRelated:
#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.
Comment #3
murzThis 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.
Comment #4
murzComment #5
damienmckennaRelated: #1429100: How to disable metatag for custom entity
Also tagging this for the stable release.
Comment #6
dave reidI'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).
Comment #7
dave reidPatch attached which implements #6.
Comment #8
dave reidCommitted #7 to Git.
http://drupalcode.org/project/metatag.git/commit/9adac15
Comment #9
murzThanks, works on my sites very well!
Comment #10
JvE commentedtypo: 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..
Comment #11
damienmckenna@JvE: Please try the latest -dev version, Dave fix that small typo.
Comment #12
JvE commentedThanks, 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.
Comment #13
dave reidThis 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.
Comment #14
damienmckennaWe've released alpha8 which fixes the drpual_static_reset() typo.
Comment #16
JvE commentedMarked #1371968: Show/Hide Meta tags fieldset per content type as duplicate of this one.
Comment #17
damienmckenna@JvE: I reopened that issue as it was different to this issue.
Comment #18
caschbre commentedI'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?
Comment #19
damienmckenna@caschbre: Lets continue in #1846080: Only enable Metatag on entities that request it.
Comment #20
damienmckenna(wrong status)