#63 - Multi-categorisation
-
By Chris Graham
- Added
- 0 views
| Identifier | #63 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Multi-categorisation |
| Status | Closed (no changes needed) |
| Tags |
Risk: Large database change (custom) Risk: Major rearchitecting (custom) Type: Cross-cutting feature (custom) |
| Handling member | Chris Graham |
| Addon | core |
| Description | Allow any entry to exist in multiple categories (one primary, multiple secondary - so it can still do consistent breadcrumbs). |
| Steps to reproduce | |
| Additional information | This would be implemented for:
- 'catalogues' - 'galleries' - 'downloads' It would be implemented consistently with how it already exists for 'news'. i.e. there is a primary category, and any number of secondary categories. Unlike 'news', these are tree-based content types (well, catalogues may or may not be), so the tree input needs to support multi-selection (which fortunately it can). Breadcrumbs would favour the primary category, unless there was a URL parameter indicating an alternative navigation path. Composr would feed through this additional URL parameter if a config option was turned on for it and/or if there was already a nav-path set in the URL. The URL parameter would be added to the ones dis-considered for the canonical URL (SEO...). It's worth noting CEDI uses a URL parameter for storing alternate tree paths like the above, so this is fairly consistent with how CEDI does it. That said, CEDI is not a true tree structure, it's actually a network - there are no constraints and no primary/secondary category. But this is consistent in that CEDI is kind of wiki-like, i.e. somewhat adhoc, less formal. |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
I just realised this is no longer required, because it's been implemented via the backdoor.
In v10 the content querying is (read: will be, when released) much more powerful. Category screens actually now also deploy blocks internally to pull out data. You can also do multi-select category reference fields. So you could build in multi-categorisation via template editing, putting in a main_multi_content block that pulls out category entries that match a particular Filtercode query designed to find any entry, anywhere in the catalogue, that might be set to that category.
While this is a bit more complex to set up, it was always a bit of a corner case - the sponsorship here, but ultimately the lack of getting enough, is more of the good efforts of BobS to drum up momentum.
I prefer the backdoor method. It is more flexible in general, it keeps bloat out from the normal workflow for average users, and it removes the need to make really heavy changes across the system that would have made a lot of code far more complex.
I would humbly suggest moving over sponsorship to:
#142 - Merged sitemap API
This is something I'd love to see achieved in v10. We'd be able to simplify a lot of things down, while making things more consistent and more powerful. I may be willing to do it significantly under my own weight, if we can get some sponsorship to cover a non-trivial percentage it.