63: Multi-categorisation - Composr CMS feature tracker

ID	Project	Category	View Status	Date Submitted	Last Update

63	Composr	core	public	2010-04-06 12:29	2013-03-15 09:18

Reporter	Chris Graham	Assigned To	Chris Graham
Priority	normal	Severity	feature
Status	closed	Resolution	no change required

Summary	63: Multi-categorisation
Description	Allow any entry to exist in multiple categories (one primary, multiple secondary - so it can still do consistent breadcrumbs).
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.
Tags	Risk: Large database change , Risk: Major rearchitecting , Type: Cross-cutting feature
Attach Tags	(Separate by ",")

Time estimation (hours)	17
Sponsorship open

Date Added	Member	Amount Sponsored

Chris Graham 2013-03-14 22:09 administrator ~1288	Hi all, 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.

Date Modified	Username	Field	Change
2016-06-08 00:14	Chris Graham	Tag Renamed	Major rearchitecting => Risk: Major rearchitecting
2016-06-08 00:15	Chris Graham	Tag Renamed	Large database change => Risk: Large database change