I like both terms,Collection andChapter. Maybe chapter is a good analogy to page. Anyway, we must provide a way to allow nestest chapters/collections. This is to further subdivide the page tree if it gets bigger and bigger. At the University of Innsbruck, we are heading towards ~100k pages. Since books never (rarely?) have nested chapters, the term collection may be a better name.

Just as a side-remark:Collection is used by djangocms-moderation. A site could have severalsections containing pages. (But then again,<section> is also a HTML tag used on a page.)

@fsbraun would this lend itself to the djangocms-categories idea you proposed a while back when the issue was brought up of tying blog entries to categories for "subscribing"... would/could that abstraction possibly fit this scenario as well?

The term "section" is also commonly used for CMS plugins. So this could be confusing.

@sparrowme Interesting thought! the djangocms-categories was an idea to be used to categorize any content element( like pages, blogs, etc...) It would have a generic foreign key and would be available to models through a manager (just likePlaceholderRelationField makes placeholder available).

Sincerely, I have no idea how to implement this feature request as a third party package. The modelPage is a fundamental part of Django-CMS andSite is built into Django itself. Therefore I would be interested in proposals on how to make this relationship pluggable.

Sincerely, I have no idea how to implement this feature request as a third party package. The modelPage is a fundamental part of Django-CMS andSite is built into Django itself. Therefore I would be interested in proposals on how to make this relationship pluggable.

I think this is the real point here. We've got this new version that's more powerful than any of us know because we've lost the knowledge of those who built it.

But what we do know is that through the new CMSConfig concept we can do powerful things that weren't possible before that allow apps to change functionality if they're installed.

I had some thoughts on categories before, on how to define a general categorizing model.

But the first thing needing to be clarified would be if page permissions would not allow for filtering out the subtree(s) that should be displayed in the page tree.

If not, I'd go for a nullable one2one model to thePage model. Then, the third-party package needs to have aCMSAppConfig subclass incms_config.py which implements aconfigure_app method. In this method, the third-party package can inject something like thedivision method from theprevious comment intoPage using Django'sadd_to_class method. The admin'sget_queryset might have to be adjusted, and the page tree template would have to be overwritten to include a widget for selecting the "division".