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 usesettings.SITE_ID, or
• Do not pass a request in toget_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 ofget_current_site andsettings.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 wheresite is available as an optional parameter and, assuming it doesn't already, the docs could be expanded to explain thatsitemust be passed in when you are not setting theSITE_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

Naturallycms.utils.get_current_site will need to be modified to take an optionalrequest 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 useget_current_site orsettings.SITE_ID that I'mfairly confident won't need any changes, but if they do I think they could be changed to useSITE_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 incms/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 acceptssite 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