My site serves pages that are almost static and there are no users with logins etc.
I want to completely disable sessions for performance reasons (so django won't access the DB to get the session on every request).
I removed django.contrib.sessions from INSTALLED_APPS, is there anything else I need to do?
You should locate articles how to set up sessions in django and remove everything from settings.py according to such article. Here is it:
Although this should already be setup and working correctly, it’s
nevertheless good practice to learn which Django modules provide which
functionality. In the case of sessions, Django provides middleware
that implements session functionality.
To check that everything is in order, open your Django project’s
settings.py file. Within the file, locate the MIDDLEWARE_CLASSES
tuple. You should find the
django.contrib.sessions.middleware.SessionMiddleware module listed as
a string in the tuple - if you don’t, add it to the tuple now. It is
the SessionMiddleware middleware which enables the creation of unique
sessionid cookies.
The SessionMiddleware is designed to work flexibly with different ways
to store session information. There are many approaches that can be
taken - you could store everything in a file, in a database, or even
in a cache. The most straightforward approach is to use the
django.contrib.sessions application to store session information in a
Django model/database (specifically, the model
django.contrib.sessions.models.Session). To use this approach, you’ll
also need to make sure that django.contrib.sessions is in the
INSTALLED_APPS tuple of your Django project’s settings.py file. If you
add the application now, you’ll need to synchronise your database
using the python manage.py syncdb command to add the new tables to
your database.
So it seems that you should remove middleware too. Maybe it's not necessary, but if you're using static application, then you it's not that bad to remove everything according to the sessions.
Related
I've been integrating Django CMS to a Django project that has been in production already for over a year. As part of my development activities, I've converted to CMS pages those pages that used to be static content before I added Django CMS. My development database now contains pages that I would like to copy to the live site rather than require that project staff recreate these pages on the live site.
I have searched the Django CMS documentation but did not find a command for this. I've also searched the issues on github, the questions on SO and the Django CMS google groups. The only thing I've found is this discussion from 3 years ago. The discussion mentions using dumpdata to dump the cms models. I've tried it. The dump contains information about the pages (for instance, who created the page and when) but it does not contain the contents of the pages.
The live site has data that must be preserved. So I cannot perform a database level dump on the development site and restore on the live site, as this would erase or overwrite data that already exists on the live site.
I'm using Django 1.7 and Django CMS 3.1.0.
The discussion you refer to predates the 3.x series. Perhaps doing a dumpdata for the models associated with the cms application was the way to go 3 years ago, but, as you discovered, it does not work now.
I actually recommend trying the following steps on a mirror of your live site first so that any surprises can be taken care of ahead of the real operation. If you run into trouble on the mirror, you can take your time figuring the problem. Once you are ready to modify your live site, before you do anything, you should backup your database. Better safe than sorry. Also, the codebase on the site should be updated to reflect your development version before you try moving data around.
You can use these steps:
Inspect your INSTALLED_APPS setting and make a list of those apps that are CMS plugins and of the applications these plugins depend on. You may need to consult the installation instructions of some of the plugins to recall what depends on what.
Once you have the list you can issue a dumpdata command on your development site with cms and the applications you identified. For my site, I have to do:
python manage.py dumpdata --natural-foreign cms filer \
cmsplugin_filer_file cmsplugin_filer_folder cmsplugin_filer_link \
cmsplugin_filer_image cmsplugin_filer_teaser cmsplugin_filer_video \
easy_thumbnails djangocms_text_ckeditor > data.json
If you also have created custom permission settings for Django CMS, you may need to edit data.json to remove some or all of the custom settings. In my case I had a cms.PageUserGroup instance that I had created on my dev site. It referred to a group that does not exist on the live site and so I had to remove this instance from the data.json dump. Otherwise, the loaddata command in the next step failed with an integrity error.
You then copy data.json to your live site and issue python manage.py loaddata data.json.
If you have any files you've added to your media directory on your development site to create your CMS pages, you also need to copy them over to your live site.
I've used the procedure above to move data from my development site to a live site, with no discernible problem.
Caveats
The procedure above is meant to be a one time deal. It won't work if you continue making changes to your development pages and then try to migrate them over to your live site.
I've mentioned issues with permissions in the steps above. You are least likely to run into permission issues if you have CMS_PERMISSIONS set to False. If set to True, then you may have to edit your dump like instructed above before loading it on the live site. If you've done heavy customization of the permission scheme and have a whole bunch of PageUserGroup instances and a bunch of pages with special permissions, etc., then you are likely to run into major difficulties. I don't know a solution short of undoing all this customization, or editing the dump by hand to make it match your live site. The problem is due to the fact that the procedure above does not dump the authentication models (of django.contrib.auth). If you are in a situation where you can safely load them on the live site, then adding them to the dump would probably do the trick. However, when you have a live site that has been in production and where the authentication data has changed over time, you cannot just load the authentication models from the development site as this would overwrite some of the records (e.g. "admin"'s password would change to the one stored in the development database).
The method above does not move any of the pages' history. It is recorded with reversion. If you wanted to move the page's history, you'd have to add reversion to the list of apps to dump but I'm pretty sure it could have undesirable side-effects: it could also affect the data that reversion records for other apps that use it in the project. (In effect it would change or erase history of other apps.)
To copy CMS pages from a development site to a live site you could use Django CMS Transfer:
https://github.com/django-cms/djangocms-transfer
Django CMS Transfer is a package that allows you to export and import plugin data from a page or a placeholder.
It works pretty well for simple tasks like exporting plugins' content from a page and then importing it to another site.
However, it does not support foreign-key relations and won't import or export related data.
The Django CMS Association endorses this project.
I have an existing Django app. Part of it is specific to a Django web app of ours, but another part does a lot of complicated computation, and it may be useful to more of our products. I am busy splitting off this more generic part into a library that does not depend on Django.
The Django app has a few settings -- for instance, it needs to know the location of certain data files. In Django I find that location as the MYAPP_DATA_DIR setting in settings.py, and I use django-appconf to set defaults for such settings.
What's the most common way to handle settings for generic Python libraries? Should I have a configure() function that can be called to set up the library, look in environment variables, something else?
We are building a multi tenant website, and some tenants want different URLs and such. No big deal, and this is something we already have fixed by making multiple urls.py which can serve as ROOT_URLCONF. When it comes to a request, we simply use our middleware which sets request.urlconf. So far, so good.
But we are also running Celery for a bunch of nightly tasks, and one of those is sending out emails. Here we don't have a request (obviously), so we can't use that to switch the ROOT_URLCONF that way. But changing django.conf.settings.ROOT_URLCONF doesn't work either (which is kinda logical). Is there any way to switch the URLConf that's being used "mid-process"?
It isn't really an option to run multiple Celery instances, each with their own settings because not all objects can be efficiently linked to the tenant they belong to (the views are different, we start with a User which knows it's tenant).
You can use django.core.urlresolvers.set_urlconf:
from django.core.urlresolvers import set_urlconf
set_urlconf('module.path.urls')
That's what django.core.handlers.base.BaseHandler.get_response uses to set up the resolver for the current request.
I'd like to know if I can just ditch the Sites default app (comment it out from INSTALLED_APPS and so on) without breaking anything?
It's written in the doc that some other parts of django use it (redirects framework, comments, flatpages, syndic, auth, shortcut and view on site), but it's not explicitly said if it's going to break them. Is it?
Django 1.5
If you are sure that there are not any dependencies from some other files in your project or in your apps you can safely remove them.
First comment out one by one and every time check the project in your browser if it is running correctly. Also check the logs for warnings and errors.
I'm building a website that doesn't require a database because a REST API "is the database". (Except you don't want to be putting site-specific things in there, since the API is used by mostly mobile clients)
However there's a few things that normally would be put in a database, for example the "jobs" page. You have master list view, and the detail views for each job, and it should be easy to add new job entries. (not necessarily via a CMS, but that would be awesome)
e.g. example.com/careers/ and example.com/careers/77/
I could just hardcode this stuff in templates, but that's no DRY- you have to update the master template and the detail template every time.
What do you guys think? Maybe a YAML file? Or any better ideas?
Thx
Why not still keep it in a database? Your remote REST store is all well and funky, but if you've got local data, there's nothing (unless there's spec saying so) to stop you storing some stuff in a local db. Doesn't have to be anything v glamorous - could be sqlite, or you could have some fun with redis, etc.
You could use the Memcachedb via the Django cache interface.
For example:
Set the cache backend as memcached in your django settings, but install/use memcachedb instead.
Django can't tell the difference between the two because the provide the same interface (at least last time I checked).
Memcachedb is persistent, safe for multithreaded django servers, and won't lose data during server restarts, but it's just a key value store. not a complete database.
Some alternatives built into the Python library are listed in the Data Persistence chapter of the documentation. Still another is JSON.