If anyone knows how to make django-cms play with grappelli, please give some tips
Well I've just gone through a fairly epic adventure, the story of which might be of some use to you. The end point of said adventure was getting django-cms 2.1.3 working with django-filebrowser-no-grappelli . Whilst that may sound in fact like the opposite of what you want, I ended up there because what I really wanted was to get django-cms working with filebrowser. Without grappelli though the standard django-filebrowser does not work as expected. But with grappelli django-cms does not work as expected. So therein lay the rub, to quote shakespeare. Getting django-cms working with filebrowser was relatively straight forward except for the fact that when trying to upload files with uploadify (which is shipped with filebrowser), after selecting the files in the file dialog, nothing happened. Eventually I figured out that this was because the jquery library was being loaded twice: once by filebrowser for use with uploadify, and once by django-cms. So by commenting out the second line in this file:
your site packages dir/cms/templates/cms/toolbar/toolbar.html
which loads jquery.min.js, uploadify worked as expected. Soooo...if you just want to get django-cms working with grappelli so you can use filebrowser, the above might be helpful. Here is my settings file for reference.
My solution is to implement 2 subdomains, 'www' and 'cms', in each of which a separate instance of the Django site is running with a different STATIC_ROOT and a modified INSTALLED_APPS. grappelli runs in the 'www' subdomain. It is not running in the 'cms' subdomain, so that you can use django-cms there.
Set up a subdomain: cms.example.com
Modify your webserver to serve this subdomain. Use the same settings as your main django site but point to a different script handler. e.g. if using wsgi direct the server to run wsgi_cms.py
cp wsgi.py wsgi_cms.py. Edit wsgi_cms.py and change the line
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings")
to os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myproject.settings_cms")
settings_cms.py :
:
from settings import *
INSTALLED_APPS.remove('grappelli.dashboard')
INSTALLED_APPS.remove('grappelli')
STATIC_ROOT = os.path.join('/what/ever/static_cms/')
STATIC_URL = '/static_cms/'
ADMIN_MEDIA_PREFIX = STATIC_URL + 'admin/`
modify settings.py: change INSTALLED_APPS from a tuple to a list
restart web servers
./manage.py collectstatic --settings=myproject.settings_cms
your regular site continues as normal. To edit django-cms pages with grappelli disabled go to http://cms.example.com/admin/cms/page/
I've once made a django-cms fork on github that supports grappelli, it's a bit outdated, but maybe helps you to get started or probaly you'd like to contribute.
Related
I have a project that I've built over the last several years, and it was started in Django 1.4. The server that runs this project is due for replacement, so I'm in the process of migrating to the new server.
I'm considering taking this opportunity to upgrade the project to Django 1.7. I've been looking over the notes, and I know I will have some work to do regarding url tags, and some other things. But, it looks like the main structure of projects has changed. In my project, the settings.py, static folder, and the project wide urls.py files/folder were all within the project's root directory. However, in 1.7 (and probably a few version earlier) it seems these files/folders are moved to an app folder within the main project.
For example, my 1.4 project has a project structure of:
project folder:
- urls.py # all other app urls.py files are included in this main urls file
- static # all static files for the whole project reside here
- settings.py # project settings
./app:
- urls.py #app specific urls
But now, it seems the default project structure has changed to this:
project folder:
- # there's nothing here other than the "manage" script
./project:
- # an 'app' with the same name as the project now holds project wide files
- urls.py # project wide urls file?
- settings.py # project wide settings? within this app folder?
- static # project wide static files to be held here?
So, will I even be able to run my project in 1.7 given the new project structure?
You can have whatever project structure you desire in Django. So you will be able to run your project barring any other upgrading issues. One of the best current examples of project structure is the Django Cookiecutter by PyDanny.
Besides abstract user classes, authentication, and migrations ( and the commands like syncdb / schemamigration that go with it) nothing should really stand in your way to upgrade. Some things have been depreciated but they're well documented and easy to fix. In each release, they've ensured the upgrade path and backwards compatibility is clear and as good as possible.
I'd recommend following the best practices with 1.5, 1.6, and 1.7 that have changed the way the community writes Django applications. My favorite resource for to learn about them is Two Scoops of Django. PyDanny is one of the authors. There are two versions, for 1.5 and 1.6, and each goes over the major differences between the previous version and how the new features have changed the way you should write Django apps. By reading both you could get a clear view of how to upgrade your app from 1.4 to 1.5 to 1.6. Beyond that, the release notes of each version, and the django-cookiecutter are great places to see whats changed and what the new best practices are.
I want to be clear that this is a distilled version of the answers found at the link provided by harshil above. I am adding it here in case the URL breaks in the future as it helped me.
ADD A SECRET_KEY TO YOUR SETTINGS.PY
Changed in Django 1.5, Django now requires every project to have a SECRET_KEY.
THE CONCEPT OF APPLICATIONS AND APPLICATIONS REGISTRY IN 1.7:
This is a new concept introduced in 1.7 where Django maintains a registry of your installed applications, hence making it really easy to manage and introspect all your apps. The best part I liked about this feature is that it makes it super easy to manage subapps and also run initialization code when each app is ready.
You can learn more about this here: https://docs.djangoproject.com/en/1.7/ref/applications/
UPGRADING DJANGO TEMPLATE URL TAGS TO USE NEW SYNTAX INTRODUCED IN DJANGO 1.5:
If you were already using Django’s {% load url from future %}, you can skip this step, but in case you weren’t you must now change your url tags from {% url view_name args %} to {% url 'view_name' args %}.
There is this awesome sed command that you can use to convert all your url tags to the new format. You can either run this command from your template directory
sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g" *
or in order to run it recursively you can run the following:
find . -type f -print0 | xargs -0 sed -i -r -e "s#\{% url ([a-zA-Z0-9_.:-]+)#\{% url '\1'#g"
Credit goes to Enrico for posting this shortcut on stack here.
APP LABELS
While migrating from Django 1.4 I had issues where the new django migrations (which is the next topic) had issues recognizing which ‘app’ a given model belonged to. As a rule of thumb, I would just add app_label to all the models Meta class and set it to the package (folder) name.
MIGRATIONS
With Django 1.7 you no longer need south, since migrations are now built-in. The best way to migrate from south to django migrations is to delete all the migration files from your migrations folder (leave the __init__.py in there).
Run the following to generate all the new migrations:
python manage.py makemigrations
followed by migrate (if django sees that the table already exists then it won’t run those migrations)
python manage.py migrate
URLS.PY
You might have the following in all your urls.py
from django.conf.urls.defaults import patterns, include, url
You will want to replace that with:
from django.conf.urls import patterns, include, url
HTTPRESPONSE
If there is any code that sets the mimetype of the HttpResponse manually you will need to change it to content_type.
HttpResponse({"message": "hello world!"}, mimetype="application/json") becomes HttpResponse({"message": "hello world!"}, content_type="application/json")
GET_QUERY_SET
The get_query_set method has been deprecated in preference for get_queryset. So you will need to change that as well if you were overriding the get_query_set method previously.
CACHING
If you were using ORM caching like johnny-cache, you will need to either kill that, roll your own or upgrade to something like django-cachalot.
PLUGINS:
Remember to upgrade all your requirements and plugins. A lot of the older plugins might not be compatible with Django 1.7.
Upgrade to Celery >= 3.1.16
Here is a good list of things to keep in mind when upgrading from 1.4 http://labs.seedinvest.com/backend/upgrading-from-django-1-4-to-django-1-7/
this article suggest the best way to do it, is one version step at a time:
This section will make it clear that you should only ever upgrade one release at a time. You should not upgrade from 1.4 to 1.7 directly. Instead, make the jump from 1.4 to 1.5 first, then proceed to 1.6, and so on. This is in keeping with the idea of taking small steps.
see:
http://andrewsforge.com/article/upgrading-django-to-17/part-4-upgrade-strategies/
However, it probably depend on the time a project can be 'on hold' during refactoring it to a newer version probably mean the progress of new features and so on has to be 'on hold'.
I guess doing it all at once, is a big step, so a lot of work at once, but dividing it in small steps (version by version) means shorter tracks, but the overall track will probably be longer.
My django admin page didn't display properly. Like a pure html display. Can someone help here?
I don't have the permission to upload screenshot. But you can imagine, it doesn't look the same as tutorial shows.
thanks
You probably don't have static files serving set up. If you have DEBUG turned on, you'll get this automatically with Django's development server (./manage.py runserver). If running in production, you need to set this up manually. See the docs for more info.
Basically your static files are not set up properly, some of the reasons can be :-
If you running on a server like apache, you need to have static url in settings.py and same alias in httpd.conf file of apache.
If you are running on django in built server, please try to set Debug=True, which will force django to serve those static files.
If you have debug=False in settings.py file, https://docs.djangoproject.com/en/dev/howto/static-files/
Because u really need a static files from django, sometimes you have to set the alias of django admin static files separately, which can be set in urls.py that is pointing to django package
found the issue.
I forgot to turn on
'django.contrib.staticfiles'
in setting.py file
How do I resolve? I don't want to push a copy of Django Admin's CSS to my static files unless I have to. Is that my only option or ??
Once you move your application to production, in addition to setting DEBUG = False in your settings.py, you also have to run collectstatic and then upload these files to your webserver.
collectstatic will put all the static files that are required for all installed applications, including the django.contrib apps (like the django admin), into the folder you specified as STATIC_ROOT. You should then copy the entire contents of this folder to wherever your STATIC_URL is pointing to.
If you don't do the above, your stylesheets and other assets will not appear correctly.
As you are using S3, the excellent django-extensions package provides a sync_s3 command that will handle synchronizing your bucket for you.
Starting from django 1.6, there is an official list of things you should do before you are ready to deploy; so if you are on the current version of django make sure you visit that page. It is also pointed to in the comments in settings.py.
in Django 1.3 you could set STATIC_URL to the S3 URL and ADMIN_PREFIX to your local server, creating a webserver alias that serves the files
(in Apache for example: Alias /static/admin/ /absolute/path/to/static/admin/)
but AFAIK this is deprecated in Django 1.4 and not possible with Django >= 1.5, since they always will point to {{STATIC_URL}}admin/.
but i don't understand, why wouldn't you upload your admin static!? i strongly suggest to colletstatic all your media to S3 :)
(i don't know if i understood you question correctly, i'll update the answer if not)
I wanted to start playing around with Django again (I'm not an expert in Python/Django, but I can make nice things work tho). I used Mezzanine once just to see how it worked. The 'mezzanine-project myproject' command worked like a charm as I had a nice small app running quickly. So, today I downloaded the new Mezzanine 1.3 along with Django 1.4.3 and all its dependencies (pillow, pytz, html5lib, etc) and tried to create another project so I could now work on it in a more consistent manner for personal purposes.
For my surprise, when I ran the server, I got lots of 404 errors pointing to missing /static/ files. Also, after creating the database (with manage.py createdb command), the only thing created was the static folder containing only the pictures of the predefined gallery that come along with Mezzanine. Also, there is no Log in or signup buttons as well.
I've tried making a clean install of all Python and its site-packages with the same result. I also tried copying/pasting the folders containing missing files from the /site-packages/mezzanine folder into my project, but the result was just reducing the number of 404 messages.
I've been doing an extensive research on this issue (with no luck but maybe because of the release being recent?) and even trying to contact someone on the Mezzanine IRC channel with no success.
I hope I'm not missing something silly. Do I have to change anything (note that I'm ok with the old mezzanine default settings) in my settings.py or in a specific file before running manage.py createdb command?
For the record: before running createdb, The only thing I edited was settings.py and changed the database parameters to make it work with my MySQL Server and commenting the local_settings configuration as I do not need it.
Some parameters that could be of help:
PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(PROJECT_ROOT, STATIC_URL.strip("/"))
By default, DEBUG is set to False in settings.py, and DEBUG is set to True in local_setting.py
Given that, if you just commented out importing local_settings.py, DEBUG would be False.
Django's development server won't serve static files when DEBUG is set to False, see the staticfiles section of the Django docs for more details.
I'm trying to install the following django app from the cheeseshop:
https://bitbucket.org/codekoala/django-articles/overview
This is my first day of Django-ing and I'm unsure what to do to get the app's folder populated inside my project.
So far, I've pip installed the app into my virtualenv. This is verified by opening a python shell and getting no errors when I run "import articles"
I've edited the settings.py file and added it to the list of installed apps. I believe this to be OK as I can then run runserver without any "module not found" errors.
syncdb also ran fine.
Where do I go from here?
ie, I would like to have a section of the website called News which uses this app. I have no routes or other apps configured yet, just a clean Django with psycopg2.
EDIT: Enabling the default admin site, I can manage the Articles there, but still unsure of how these will be displayed on the site when I have no app folder created for them. When trying to startapp articles, I'm warned it's conflicting name with an existing module..
No need to create a new app called articles. As you are able to import articles via the python console you have successfully installed it. You can find it in your virtualenv folder in the folder site-packages:
/path_to_your_virtualenv/.virtualenvs/<virtualenvname>/lib/<pythonversion>/site-packages
You can use this app, installed via pip, as it is an app which lives in your project folder.
You just need to include the articles urls in your own urls.py. Since you say you want it under News, this would do fine:
urlpatterns = patterns('',
(r'^news/', include('articles.urls'),
)
Note though that the readme for the articles app implies that you'll need to create your own base template for it to inherit from. Just create a base.html file in a directory called templates under your project, give it a basic HTML structure, and put in {% block content %}{% endblock %} in the relevant place (and the same for the other blocks mentioned in the readme).
You should probably do the Django tutorial anyway, to understand exactly what's going on with the URL and the templates.