I've started writing FoxCMS -- another Django cms -- a few months ago after having used the Wagtail CMS on a project. Although their inspiring work, there were fews critics that drove me into this project:
- No clear separation between views and models; that has several implications such as the requirement to implement a model for each type of rendered page;
- Poorly optimized at different parts of the code, such as the page routing function that hits the database for each parent of a page in order to resolve a request;
- The CMS panel is not really practical when it comes to integrate other tools in it;
They were not the only reasons for me to start this project; I wanted also a solution that integrates most of my common needs when I develop a project that requires a CMS:
- website's content organisation totally controllable by the end-user, menus included;
- integrate everything in a single admnistration panel;
Foxcms keeps distinction between views and models, and tries to keep standard practices from Django project. It offers various tool that can be used either for page, resources, and content management/rendering. It is still not very usable for the moment since it is at its early development stage, however I still can present different feature that will be/are yet included.
Here we will cover some of the main features of Foxcms just to have a first overview. I plan to later write other articles going in depth about various developments.
Pages are organised in a tree-like structure, using django-treebeard. The
Page model is used to render any kind of page (article, etc.). They are routed using theirs slugs in a
The administration panel for pages is largely inspired by Wagtail's explorer, although it is directly integrated within a ModelAdmin. From this panel, all the page type are directly handled, and custom actions can be added using hooks.
In Foxcms, multi-site management is made by attaching a Site settings object to a given page. This allows having nested websites, based either on subdomain or specific path. We don't define Sites as a specific subclass of Page because it complicates path resolving and is conflicts prone. Later we wan't to provide per-site template system and other custom things.
We also have a specific model that allows us to integrate any wanted view as a page (
ReferableView); this is useful when we want the user to be able to create a page with a specific view that has no related model.
Resources and collections
The resource system aims to be easily extensible with new kind of resources without having to write extra-tremendous-code. In Foxcms, collections gather resources that can be of different types. The detail view of a collection allows user to edit any resources (given the correct permissions) taking in account their respective forms.
Since it is a critical part in a security system, we wan't to provide strong file type checking and cleaning up when they are uploaded by users. We also want to provide most common resources management: image, sound, video.
We provide a specific field type to resources in order to use the Foxcms' resource manager.
Regions and sections
In order to create dynamic menus that the user can change by itself, we provide a system where
Regions are a set of
Sections that are rendered at given position in templates. Theses Sections can either be an image, some list, a list of articles, search field, whatever you implement. A Region can also be configured to render only on a given class of page or on a specific page.
Later, Foxcms will provides various common section and a user interface to organise them.
We provide a per object permission system using the concept of "Clearance". A Clearance define a named set of permissions for different groups and is applied to object that targets it. It offers this way a simple permission management system for users (they practically just have to select the required clearance when editing an element) and developers (the concept is pretty straightforward, and allows quiete nice things).
It also avoid to multiplicate permissions item in a database as if we would have them attached directly to objects.
Views & Routes
More generally, we provide views that do some work for us:
- Remember which
Route has been taken and offer easy reverse;
- Generate a list of template names to look for that ease extensibility;
- Keep track of the current site;
A Route defines one or more url patterns that conduct to one (or more) views. Routes can be grouped, filtered, customized, reused for different views and models. They also can be used to automate url generation using custom criterias.