Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.the project edit page is way too long and has too much info. we should split out all the "Link to ..." fields into a separate (collapsed) fieldset called something like "Project links". should be pretty easy. anyone want to roll a patch? ;) thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 64864_project_node_edit_ui.png | 92.43 KB | dww |
| #1 | project_links_collapsed.patch | 3.26 KB | dww |
Comments
Comment #1
dwwComment #2
dries commentedI don't think it is too long. Splitting this up like the way you propose, makes if feel slightly less intuitive. If you really want to split it up, I'd split it up in "logical chunks" that map onto the structure of the project overview pages: resource related settings, support related settings, development related settings. Makes for a better "brain map", IMO.
Comment #3
dwwNow that all the issue and release related settings are in their own sub tabs in 4.7.x-2.* and 5.x-*, this isn't so bad anymore. But, I now agree with Dries that just splitting it into required vs. optional isn't the best. We probably want:
- "Project identification" fieldset for all the required fields (Full project name, Full description, Short project name, Project email).
- Move "CVS tree" into the "CVS integration" fieldset. In fact, we should probably just remove it entirely and automatically generate that link for projects with a CVS directory defined, based on a per-repository setting for the link (much like we do for the setting for the diff links in the cvs log messages).
- Put "Documentation", "License" and "Changelog" into 1 fieldset ("Project information"?)
- Put "Homepage", "Demo site" and "Screenshots" into another ("Project examples"?)
Comment #4
aclight commentedJust in case others are reading this, I want to point out that this part has it's own issue at http://drupal.org/node/156118
But I'm not sure this is a great idea. I can imagine a case (probably not on d.o though) where a project may be hosted on a Drupal based site but may have its repository and web-based repository browser on another site. Furthermore, I can imagine a project that is not using version control on the Drupal based site but maintains a separate web based repository browser on a different site. As a last example, a user might be using SVN for version control and may want the cvsroot to point to a specific branch or trunk instead of just the base of the project. I'm not sure how ViewCVS/ViewVC handles this with CVS, but it doesn't seem like offering this flexibility would be necessary in CVS, but for SVN and perhaps other version control systems it might be useful.
On the other hand, always automatically setting the cvs tree would be easier from a programmer's perspective :)
Comment #5
dwwI ended up basically needing to fix this as part of #98278: project* namespace bugs in $node. node_body_field() had to live at the top-level of the $form array to work, so we couldn't turn on #tree in there. However, all the rest of the project fields wanted to be inside $form['project']['foo'] with #tree set to TRUE in $form['project']. I moved the project short name field out next to the title. All the rest of those links (with the exception of the CVS link, which should be handled by #156118: Automatically generate the value of 'Link to webcvs/viewcvs' field for a project anyway) show up under the "Resources" section of the project node, so I just put them all in a (collapsed) fieldset called "Project resources". We can trivially form_alter this to expand that fieldset on d.o if folks really want them more visible.