The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.This is my workaround for this discussion. If the audio tag settings are saved to the node on 'load' (into $node->audio_tag_settings), then any other module can set a new tag setting (in this case 'Download'), and tags that correlate with the tag setting. Those tags will then be inserted by theme_audio_display()...
What this means is that any other module can add list elements inside the audio info box... Only using the $node->audio_tag_settings at the theme level prevents these custom tags from being inserted into the variables table, and therefore from showing up on any forms...
Pretty sweet, IMO, and would have been impossible without drewish's architecture for the tag system..
| Comment | File | Size | Author |
|---|---|---|---|
| audio_tag_settings_0.patch | 1.12 KB | q0rban |
Comments
Comment #1
drewish commentedsorry, running around today and don't have much time. i'm curious though, would it make senese to implement this as a hook rather than passing the settings along with each node? it seems like a lot of the same data will end up in a lot of nodes.
Comment #2
q0rban commentedYeah, that was something I had suggested here, but I thought it would be better to avoid the overhead of adding a hook.. this method is just making use of the system already in place..
I'm not sure I know what you're referring to.. It will only be loaded into audio nodes, right? Or are you referring to the tag settings being there in insert/update and teaser views even though it's not being used? That seems pretty marginal.. But if you would prefer a hook, i won't complain.. ;)
Comment #3
drewish commentedhumm, i guess i didn't really see the hook doing the same thing there. i though you were saying you wanted audio_link() to call another hook so other modules could insert links. i didn't really make the connection between the two issues. i really like the idea of having multiple formats but it seems like it's a wierd fit in/onto the current audio module. i'd like to give it a bit of thought before commiting to anything...
Comment #4
drewish commentedi'm going to mark this as won't fix. the new hook_link format in 4.8 returns an array of links, and once #64812 is committed you'll be able to do what you want at the theme level.
Comment #5
q0rban commentedI agree that the new links api will fix the links issue, but I think we should use the forms api to output the audio info/tags so that contrib modules can modify it...
thoughts?
feel free to put back to 'won't fix' if you're not crazy about the idea...
Comment #6
drewish commentedback to won't fix...