Closed (fixed)
Project:
Project
Version:
x.y.z
Component:
Projects
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
27 Mar 2006 at 04:21 UTC
Updated:
1 May 2006 at 01:45 UTC
Jump to comment: Most recent file
Not all browsing methods will be appropriate for all project types. On drupal.org, notably, the 'Drupal project' has a single project in it--so we don't need browsing by 'category' (there are none) or date. Similarly, categories may not be relevant to translations or theme engines.
What is the best approach to this issue? We could use SQL queries to determine if there are relevant listings, and show the tabs only if there are relevant projects to display. But this isn't entirely straightforward to determine from project_menu(), since we use a complex set of queries to fetch results.
The other (easier to implement) approach would be to use configuration settings, where an admin would select which browsing options to use for each project type.
Thoughts on the merits of these approaches? Other ideas?
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | project-browsing-options_0.patch | 4.57 KB | nedjo |
| #1 | project-browsing-options.patch | 3.9 KB | nedjo |
Comments
Comment #1
nedjoHere's a patch implementing the second approach. We introduce a configuration option where admins can choose, for each project type, which browsing options are enabled. Special handling is required for the MENU_DEFAULT_LOCAL_TASK. We have an overall default option, but we need to handle the case where that overall default isn't enabled for a particular project type. The approach therefore is:
* If the overall default is available, it is the MENU_DEFAULT_LOCAL_TASK.
* If not, the MENU_DEFAULT_LOCAL_TASK is the first enabled browsing method for the given project type.
Comment #2
nedjoSlight change needed to handle the case where no browsing methods are enabled for a particular project type.
Comment #3
nedjoI've gone ahead and applied this.
Comment #4
(not verified) commented