different sets of tags for different node types
| Project: | quicktags |
| Version: | HEAD |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
I'm aware that requests for a feature to enable quicktags for specific content types were posted earlier, but I'm asking not exactly for that.
What I'm talking about is since we can distribute different sets of buttons between (sub)modules through the hook provided by the creator of this module why can't we introduce per content type restrictions for these different (sub)modules?
For example we have a (sub)module which adds wiki-markup-buttons. We don't need these buttons anywhere except when creating or editing a node of wiki content type. But we can not disable only these buttons for other content types. We must either disable all the buttons for other content types or enable all the buttons (including wiki) for all content types.
I think its inconvenient or am I asking to much and should stay with quicktags only for wikinodes and, for example, tinymce for all other nodes?
#1
Since there are no comments, I'll add my way of implementing this feature. The way is quite "dirty" and in any way can be named appropriate.
I copied quicktags module as a whole and edited it so I created another module named quicktags2. Its the same as quicktags in every line of code (well, not exactly in every line since we need all the functions of it to be named in accordance with the module name - quicktags2) but named quicktags2. And since now we have 2 separate modules we can enable them for different content types and edit buttons in them with hook_quicktags_insert(). So now I get different sets of quicktags for different content types (for wiki pages and all the other nodes).
If it can help anybody i can upload "my" quicktags2 module.
#2
And it seems to me my "dirty" way of implementing this feature turned out to be even "dirtier", than I thought. When I enable the second quicktags module I get the following warning on a node page:
So I think I still have to look for workaround...