Background

We would like to use the multi-site features of Django CMS but it is not viable for us to spin up a separate instance for each site, or maintain a separate settings file for each site.

It seems that the Django sites framework was designed to support this use-case but many parts of the Django CMS codebase are either:

• Hard coded to use settings.SITE_ID, or
• Do not pass a request in to get_current_site or similar functions

I have raised this discussion to see if there is interest in supporting our use-case, or to see if there are any hard blockers that would mean this could not be supported.

Notes

I have spent some time looking at all of the usages of get_current_site and settings.SITE_ID to see how easy each of them is to convert to a "request-aware" method. Most of them seem straightforward but there are some more challenging ones that I could do with some input/feedback on.

Documentation changes

I have found some scenarios where site is available as an optional parameter and, assuming it doesn't already, the docs could be expanded to explain that site must be passed in when you are not setting the SITE_ID setting.

• cms.api.create_page
• cms.utils.page_permissions.user_can_add_page
• cms.utils.page_permissions.user_can_view_page
• cms.utils.page_permissions.has_generic_permission

Straightforward changes

Naturally cms.utils.get_current_site will need to be modified to take an optional request parameter. There are also a lot of cases where a request is available and can be passed in to this method:

• cms.toolbar_base.CMSToolbar
• cms.views.details
• cms.admin.pageadmin.get_site
• cms.admin.placeholderadmin.PlaceholderAdmin
• cms.templatetags.cms_tags.StaticPlaceholderNode
• cms.utils.decorators.cms_perms
• cms.utils.i18n.get_site_language_from_request
• cms.utils.page.get_page_from_request
• cms.wizards.views.WizardCreateView
• menus.menu_pool.MenuRenderer
• menus.utils.DefaultLanguageChanger
• menus.templatetags.menu_tags.LanguageChooser
• cms.cache.page._page_cache_key

There are a few test files that use get_current_site or settings.SITE_ID that I'm fairly confident won't need any changes, but if they do I think they could be changed to use SITE_ID = 1:

• cms.tests.test_forms.FormsTestCase
• cms.tests.test_log_entries.LogPageOperationsTests - request is actually available, not sure how useful it is though
• cms.tests.test_menu
• cms.tests.test_page
• cms.tests.test_permod
• cms.tests.test_wizards
• cms.tests.test_navextender

Harder changes

And last, but certainly not least, I came across a few scenarios that I do not think have a clear or straightforward solution:

cms.appresolver.get_app_patterns is called in cms/urls.py where a request not available and, as far as I'm aware, is only called during the application boot. I think this is the most challenging issue.

cms.models.query.PageQuerySet accepts site as a parameter so existing calls to this function could be checked to ensure they pull the site from the request, but I get the impression it's not as simple as that. Also this is a public API so that could add some exta challenges.

cms.utils.conf has a few functions that rely on the site, but I'm not sure how that could be varied by the request.
- cms.utils.conf.get_templates
- cms.utils.conf.get_languages

And as a bit of a grab-bag there are a few places where a request is currently not available:

• cms.admin.forms.PageTreeForm
• cms.admin.forms.PagePermissionInlineAdminForm
• cms.forms.widgets.PageSelectWidget
• cms.models.managers.PageManager
• cms.utils.mail.send_mail