Is it possible to disable the Meta Tags fields from the node edit pages on specific content types? I've searched and I can't seem to find the option or any documentation explaining how.
The idea is that a specific content type will ultimately never been seen as a node view. Think of it like a utility node type. Thus there is no need for the meta tags interface. The field's presence however might encourage admins to add them even though they'll never be seen.
Any suggestions? Am I missing something obvious?
Thanks for all that you do! Its a great tool!
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 822952-8.patch | 1.23 KB | roderik |
| #6 | 822952-6.patch | 1.2 KB | roderik |
| #5 | 822952-5.patch | 1.17 KB | roderik |
| #4 | 822952.patch | 1.02 KB | roderik |
Comments
Comment #1
Anonymous (not verified) commentedIt is not possible to disable the meta tags basing on the content type. I will probably re-implement the feature, but it will be handled by an extra module.
I am moving the report to the project that will implement such feature.
Comment #2
ecksley commentedFair enough. Thanks for letting me know Kiam.
Comment #3
Anonymous (not verified) commentedThis module is not maintained anymore. This feature should be implemented in Nodewords, if it's considered worth implementing it when there is already a module with the same purpose.
Comment #4
roderikI didn't see a module with the same purpose.
(The Meta tags Node Type module provides default tags per content type, but does nothing with en/disabling the per-node edit controls for certain types.)
So here's a patch. I think the natural place for this setting is in nodewords_ui.module.
(I pretty much stole the code from upload.module. Default behavior isn't changed, i.e. things are enabled if the used variable isn't set.)
Comment #5
roderikrerolled against latest -dev
Comment #6
roderikmeh... still learning to cope with the test bot... reroll with different path prefix...
Comment #7
AlexisWilke commentedroderik,
Beautiful! 8-) Just what I needed.
3 problems though:
a) It doesn't work against the -dev version I have... and I'd think I have the newest of that UI module file.
b) You use 1 and TRUE for the same value. I think you should use 1 or TRUE in both places.
c) Maybe the name should use the $form_id variable instead of 'nodewords_' . $form['type']['#value'] ?
Thank you.
Alexis Wilke
Comment #8
roderika) indeed. -dev is moving fast.
b) I prefer using 1, not TRUE, in the nodetype edit page - because that's the variable value which will eventually get saved.
IMHO it's a matter of preference whether to use 1 or TRUE in the 'if' statement up there. I changed it to 1 now.
c) you're right; it's better to take longer variable name to prevent collisions with other types.
However, you can't just use nodewords_TYPENAME_node_form; that doesn't automatically get saved. (Note the absence of any 'submit' code here...)
I changed it to 'nodewords_ui_type_TYPENAME' now.
(Adding blocker tag from #957860: Per-content type permission to control access to Nodewords fields for each content type, which I'll set to duplicate.)
Comment #9
AlexisWilke commentedGood point about (c). The auto-save is a good idea. 8-)
My idea was that you could otherwise just use $form_id. But that's okay either way.
Thank you.
Alexis
Comment #10
dave reidWhat happens when someone requests being able to disable them per vocabulary? Can we rename this variable to nodewords_ui_node_type_[NODETYPE]?
Also, this is missing handling of renaming the variable if the node type changes via node_type_save(). Also missing uninstall of variables.
Please just make this a simple checkbox as per the Drupal UI standards is this is only an enable/disable option.
Powered by Dreditor.
Comment #11
damienmckennaIs this still ok for 6.x-1.13 or should it be promoted to v6.x-1.12?
Comment #12
dave reidLet's focus 1.13 on better node/content type support?
Comment #13
sf_wind commentedsubscribe
Comment #14
wiifmSubscribe, definitely keen on this feature
Comment #15
doublejosh commented+1
Comment #16
travelman commented+1
Comment #17
sittard commentedSubscribing +1
Comment #18
Kendall Totten commentedsubscribing +1
Comment #19
scorchio commentedsubscribing + 1
Comment #20
lekvarnik commentedsubscribing + 1
Comment #21
damienmckennaDe-tagging, will review priorities after the next stable release.
Comment #22
damienmckennaUpdating the title to be more relevant. This is definitely relevant to #945676: Allow defaults to be defined per content type.
Comment #23
damienmckennaBumping to v2.
Comment #24
damienmckennaMarking all v2 issues as postponed while v1 is finished off.
Comment #25
damienmckennaUnfortunately this module is no longer supported, so I'm closing this issue.