Closed (won't fix)
Project:
Nodewords: D6 Meta Tags
Version:
6.x-2.x-dev
Component:
Miscellaneous
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
9 Jun 2010 at 16:46 UTC
Updated:
25 Sep 2020 at 14:57 UTC
Jump to comment: Most recent, Most recent file
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.