#142 - Merged sitemap API

By Chris Graham
Added 7th Apr 2010, 6:18 PM
5 views

Identifier	#142
Issue type	Feature request or suggestion
Title	Merged sitemap API
Status	Completed
Tags	Risk: Core rearchitecting (custom) Risk: Major rearchitecting (custom) Type: Cross-cutting feature (custom)
Handling member	Chris Graham
Addon	core
Description	We currently have a sitemap API, and a sitetree API, and the splurgh/tree-view code, and the content tree APIs. These are all structural content APIs and should be merged (we also have the content_meta_aware hooks, and also award hooks, but these are more service-orientated although they still can tie into structure). Advantages: * simpler code * if the sitemap block uses this merged system we can remove the memory problems, by using the splurgh system for display. * we could get rid of the splurgh-powered 'tree' screens for content modules, which hardly get used, and instead make it so the main_sitemap block can be called up to show subtrees of the wider sitemap, as required (more flexible). * we can do a better job of menu auto-generation * we can get around some design problems with the splurgh system: bad caching model, performance problems due to showing too much at once, requirements for JS [we can now avoid splurgh entirely - see above]
Steps to reproduce
Additional information	Also it would be nice if Comcode pages were rendered in a tree from this API, respecting their defined parenting structure (if one has been).
Related to	#140 - Category permissions for menus #16 - Fully support menu stitching
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".

Rating

Unrated

Comments

By Guest posted 5th Jun 2011, 10:54 AM

Also ID selection for the main_content block should work from the single site tree, when it's developed. So you don't select content-type+ID, you just browse to the content.

By Guest posted 11th Jun 2011, 11:01 AM

See if we can incorporate breadcrumbs into this, so they are auto-generated by the Site Tree where possible. Also tie in the logic about menu item subordination.

By Guest posted 7th May 2012, 1:24 PM

We don't need to see the term "entry point" anywhere in the UI or documentation. We can just use the term page-link.

By Guest, By Guest, posted 7th May 2012, 5:25 PM

Suggest that tracker item 415 also be addressed at the same time.
http://compo.sr/tracker/view.php?id=415

By Guest posted 10th Apr 2013, 5:12 PM

This functionality may be built on top of the new Resource-FS.

By Guest posted 10th Apr 2013, 8:28 PM

Note that we want to make sure that Comcode page hierarchy comes out of this system correctly. Currently the pages come out flat, because they are top-level under a zone.

By Guest posted 22nd Aug 2013, 7:18 AM

We can also likely merge in the do_next_menu hooks as part of the site-tree, (and give site-tree nodes support for icons in the process).

By Guest posted 22nd Aug 2013, 10:14 AM

Also consider if we need to allow different XML sitemaps, per content-type (i.e. to stop the main one getting larger than is allowed, isolating size problems in a specific sitemap).

By Guest posted 30th Aug 2013, 1:25 PM

Absorb the bookmarks menu into the site-tree also.

By Guest posted 7th Sep 2013, 9:50 AM

Also features like list_galleries, which are of very limited use, can simply become part of the new site tree.

#142 - Merged sitemap API

Rating

Comments

Statistics