Add customized per project type related vocabularies

Moved to the Redesign project

Here's the way I've got the problem solved locally.
First, I want to validate the solution, then, if it works, I'll start creating/posting patches to make it happen:

1. I made changes in 2 places - project module and drupalorg module. Before anyone gets excited, the changes to project module are not specific to an implementation on drupal.org, however, they do allow any other project-utilizing site to, potentially, include other bits of data dynamically in the way that the module list is dynamically shown/hidden. The changes to project module (.inc & .js) are pretty small.
2. I added code to drupalorg_project to add selections on the vocabulary pages to associate vocabularies to top-level terms in the project taxonomy. I am currently storing them in the variable table, but I could put them in a custom table if that makes more sense.
3. I added a small class modification to the relevant vocabularies to get them to bounce into the fieldset (in a location similar to the module categories).

Let me know if, conceptually this seems in line with what you're thinking. If so, this should make it usable by any of the other sections as well (additional module facets? Install profile facets?) without writing additional code. I'll clean up what I have and post as patches to the relevant projects if the concept seems inline with expectation.

Shifting this to "needs review" in an effort to get more eyeballs.

To review such changes (especially for project module) we need to see the actual patch.

I was hoping someone might be able to validate the idea first, but here is the patch for the project module.
If you need the patches for drupalorg, too, to determine whether the project patch makes sense, I'll find time this afternoon to clean up those files as well and generate patches.

Attached are the drupalorg module (drupalorg_project.module) changes. This should provide full context of what is being changed, why it's being changed, and how we're getting relevant vocabularies into the appropriate area.

I believe that approach makes sense, but the changes in the Project module need to be documented a little bit better.

Also, we can largely live without the admin UI parts in the drupalorg module.

Attached are re-rolled patches, correcting 1 mistake and providing better inline documentation.
Not sure what you mean about the "admin UI parts" (the changes to the taxonomy page?). Is so, would you prefer I move everything into project module? or am I misunderstanding?

Also, as soon as this moves forward, we can start pushing the front end blocks for search faceting per section, so this continues to be a priority issue for that work.

+++ project.inc	12 Feb 2010 02:22:20 -0000
@@ -79,15 +79,27 @@
+          '#title' => t('!type categories', array('!type' => $top_level[$tid])),

I believe we shouldn't use the ! escape here.

Powered by Dreditor.

Switching ! to @.
Reposting both patches so that drupalorg patch doesn't get lost.

Since csevb10 pinged me via email about this, I should clarify:

A) I'm currently traveling, and not in a good space to work on this.

B) I've been juggling a ton of crap the last few weeks, and a lot of personal difficulty has been consuming a large portion of my time and attention. :(

C) I know this stuff is blocking some progress, but I'm not a bottleneck of one. There are some other Project* maintainers. You could talk to hunmonk or bdragon. Also, mikey_p has been doing great work with Project* these days. I'd also trust DamZ to do the right thing with these patches.

D) I think everyone agrees that fundamentally we're going to have these different taxonomy vocabularies on project nodes, even if the exact implementation details of the UI change a bit. So, it seems like y'all could plow ahead with the D&E implementation on many fronts, even without this patch. I don't think if anything needs to change in here as a result of careful review and testing that it's going to fundamentally impact how the rest of the D&E implementation needs to work.

Good luck sprinting on Friday, wish I could join you (but I can't).

Cheers,
-Derek

The patches look ok to me. You can certainly apply the drupalorg stuff. Not sure how to handle the project* patch. We could apply it locally to our svn...

dww and i had a chance to look at this today. here are the major issues that need to be fixed in order to move forward:

1. having an admin UI in drupalorg module for a project feature that's *supposed* to be a general purpose feature seems wrong. for now, since these associations *should* be edited rarely, let's just bag the UI and go with hard-coded settings for this in settings.php
2. the append/remove approach in project.js breaks the persistence of saved settings. for instance, if you have a term set on a related vocab for a theme, and you visit the project page, click the 'Modules' term, then the 'Themes' term, the theme setting gets wiped. we need to use a show/hide approach so the settings persist.
3. there needs to be logic added to the submit handler for the project node that examines which term from the project vocab is selected (Modules, Themes, etc), and strips out any selected terms from the 'other' vocabs. ie, if 'Modules' is selected, then any terms that were selected in the related 'Themes' vocab need to be stripped. this becomes necessary because of the change in b), and it's also the right place to perform this action.

one more thing: the drupalorg patch was rolled against the HEAD branch, and we're running the 6.x branch on d.o currently, so you may want to adjust for that...

Poking at this in the coding room.

* Do everything on the project side.
* Address #16 a, b, and c.
B was actually a previously existing problem when changing project types. Removed the line that was removing the selection and added a submit handler to remove the vocabularies we need to clear the terms from when saving. This also addressed C.

* Fix typo that was nuking the vocabularies fieldset when vocabularies not assigned to project types existed.

* Fix a couple issues in the settings form.
* Clean up variables in hook_uninstall.

Still some problems with the JS. Rewriting the code that deletes the fieldset.

* Kinder, more gentler fieldset handling that actually works correctly. I hope.

Remove debugging code.

* Fix some nits pointed out by dww.
* Remove some bogus validation code.

looks like the form is broken, probably by the adjustments to the weird hacking we do:

warning: Missing argument 2 for theme_form_element() in /Users/hunmonk/Sites/drupal/core_remote/drupal-6/includes/form.inc on line 2198

extra vocabs that are associated w/ project types are not being moved to the project type fieldset.

OK, I figured out what's up.

Lets try this one.

Fingers crossed.

* Less hacky (in theory?) vocab wrangling, add a validator for preventing turning a vocab into a freetagging vocabulary while it is associated with a project type.

* Document an icky section.

committed to 6.x-1.x-dev, finally!

thanks to all who helped with this patch.

i'm guessing that there's no hurry to deploy this on d.o now, since it's related to the redesign, so...

setting back to active for deployment, and moving to the project queue for that final step.

We should skip the 'Project type' vocabulary itself, too.

Tested on scratch, committed.

Agreed, makes sense. I had completely failed to notice that the project vocabulary doesn't actually get enabled for project_project.

http://drupal.org/cvs?commit=357928

Just wanted to say a special thanks for everyone reviewing and pushing this through, and improving the existing project logic. I appreciate all the time and energy that went into getting this done.
--Bill

FYI: moving to presave created some PHP notices: http://drupal.org/cvs?commit=358710

Attached is the related drupalorg_project patch from staging9 by csevbg10

Note: I just submitted #852342: Configure extra fields for theme projects as a webmaster issue about actually configuring the right vocabs on d.o. This issue should remain focused on the Project* plumbing to support this functionality.

Thanks,
-Derek

after further discussion with csevb10 we determined that the patch in #36 is just noise, and that all of the necessary changes for this functionality have already been committed and deployed.

i retested the functionality to ensure that it was still working as intended, and does.

so i think we can finally put this sucker to bed.