Added a hook_form_alter and some javascript to correctly display categories for themes on the add/edit project page.
Goal was to duplicate the effect that already happens for module categories on that page.
You can view and test the results on the staging9 site
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | 686242-1.theme-categories.png | 25.12 KB | dww |
| drupalorg-project1.patch | 5.42 KB | mindbat |
Comments
Comment #1
dwwBased on the description here and skimming the patch, this was unfortunately a waste of time. The existing JS in the Project module already does this. If you add child terms to any of the top-level terms in the Project type vocabulary, you get the automagic show/hide behavior. I just added "Fluid width" and "Fixed width" as theme category terms on http://d6.project.drupal.org. I'm attaching a screenshot of the node edit page for the Zen theme:
http://d6.project.drupal.org/node/88566/edit
So, this custom code is completely unnecessary. Sorry to be the bearer of bad news...
-Derek
Comment #2
csevb10 commentedCheck the results on the staging9 site real quick to see the implementation in action. I'm not sure it's the right implementation, but it does seem to be getting the functional desire. Basically, before I make someone rewrite the code, I want to make sure we're doing it with full knowledge of his solution.
Comment #3
csevb10 commentedPopping back to needs review, so we can determine if things need to be rewritten for multiple taxonomies or the single-taxonomy multiple-drop-down approach is sufficient.
Comment #4
csevb10 commentedAnyone:
I can write the code to utilize separate vocabularies if that's the desire, but I'm trying to determine if I need to scrap the code here and start anew or if I can leverage what was done. mindbat is utilizing the project taxonomy nesting to get the desired effect: everything posts to solr as expected and everything can be retrieved based on the terms. As a result, if that's a workable solution, it'll be much faster for me to start there than to start over with creating new taxonomies, etc. I'm dodging the issue in code at the moment until this is resolved, but sooner or later, I'll need to tie it to 1 solution or another.
FWIW: Some of this code needs to be rewritten anyhow and cleaned up, so it's not the end of the world if we have to scrap it. New vocabularies make more logical sense to me, so all things being equal, if I have to make a decision, I'll probably rewrite everything utilizing separate vocabularies.
Thanks for the help.
Comment #5
damien tournoud commentedDiscussed on IRC today, we want separate vocabularies for the theme properties. Sorry, but this code was not necessary.
Comment #6
dwwRight, see also:
#372061-11: Form_alter the theme vocabularies so that they only show up for theme node editing
#371957: Add customized per project type related vocabularies