Posted by Gerhard Killesreiter on February 10, 2009 at 10:55am
Jump to:
| Project: | Drupal.org customizations |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | jpoesen |
| Status: | closed (won't fix) |
| Issue tags: | download & extend, drupal.org redesign |
Issue Summary
Currently, all project nodes are of the same type. However, the redesign requires theme nodes to have extra metadata such as "columns" "resolution" etc. which are not applicable to modules.
See "find a theme" at
http://infrastructure.drupal.org/drupal.org-style-guide/prototype/themes...
Also, see the "find a module" section.
http://infrastructure.drupal.org/drupal.org-style-guide/prototype/module...
Comments
#1
http://drupal.org/node/372062 is dependend on this.
#2
Themes will have their own vocabularies #371957: Add customized per project type related vocabularies. Since we can only limit vocabularies to content types, this issue still stands. We either need to hack away to limit the showing and entering of the theme vocabularies to theme projects, or we need to complete this issue to make multiple content types be projects.
#3
This is a fairly large can of worms at this point (for example, see #239485: attach an issue queue to any node type. and #75565: make a hook to get version options for a given project). Given the "we must have a working D6 version ready 6 months ago" mentality of the upgrade efforts, I've spent no time on cleanups like this in the code, beyond porting things to using views. If the goal is to have this done soon, I would suggest drupalorg_form_alter() to modify which vocabularies are present when editing different kinds of project nodes. There's already code related to this in project module itself, to conditionally hide/show the multi-select for the project categories depending on the radio for the top-level term.
Plus, I have no intention of working on anything like this before the D6 upgrade is live on d.o, and there are still known bugs and issues to work out there. However, there's a (easy) work-around for the immediate redesign efforts, so this shouldn't block anything else. Therefore, I'm marking this postponed for now.
#4
Well, this all sounds more like stuff we should do in a custom drupal.org module, right?
#5
Yes, that's what I said: "drupalorg_form_alter()". I'm just pointing out there's already code that does something similar so you can start from there instead of starting from scratch.
Meanwhile, this is still a valid request for project itself, so we can leave it here. But the way to implement #372062: Add special fields to theme content type and #371957: Add customized per project type related vocabularies is via hook_form_alter in drupalorg.module.
#6
Once #371957: Add customized per project type related vocabularies is solved, we should have the form_altering based on "project subtype" done.
#7
BTW should be done in the drupalorg.module. Should be both implemented in HEAD and DRUPAL-6--1, and we should deploy the DRUPAL-6--1 version on drupal.org if the vocabularies are live to not confuse people who are going to edit projects before the redesign is live. I can do the deployment once the changes are in.
#8
#9
Linking this from the Redesign project #661550: Meta issue for Drupal.org customizations because this issue was tagged 'drupal.org redesign'
#10
This post is directly related to this issue (or a duplicate but with a patch): http://drupal.org/node/686242
Modifications are done in drupalorg_project, so I'm not positive if that was the intention or not.
Let's determine if this is the right approach (jpoesen? dww? gabor?), and I'll push to get this finished.
#11
@csevb10: Unfortunately, #686242: Themes Category Display for Drupalorg Project Module was a waste of time, since the Project module already does that for you.
If all that's desired here is some theme-specific category terms like we have module categories, we simply need to define the terms and it'll all Just Work(tm).
However, I was under the impression that we needed something else here. Namely, we want a handful of new theme-specific vocabularies for stuff like fluid vs. fixed, supported browsers, number of regions (or something). See #371957: Add customized per project type related vocabularies linked above. So, if they're totally separate vocabularies, the existing Project functionality won't work, and we'd need some custom code to hide all these vocabularies unless the radio is selected that says it's a theme project...
Well, we only need that until we can have different node types for different kinds of projects, but that's probably going to have to wait until the 7.x-2.* series of Project* when we port to the D7 core Field API...
#12
@dww: no worries on my end. I chatted with the dev real quick and - while the project module does something similar - this breaks it into a more intuitive 3-drop-down setup.
Check out the actual code in action, I think it might make more sense. I'm still not pushing that he did it the right way, but it's close in terms of administrative functionality: http://staging9.drupal.org/node/add/project-project
#13
Possible solution & code posted here:
http://drupal.org/node/371957
#14
This is now done via #371957: Add customized per project type related vocabularies