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.
Related
I tried all the ways to deploy static files in production environment but still the static files are not appearing. I don't know whats wrong.
Please help me in deploying static files(like css, javascripts, images, etc.).
I've tried using many different ways from many sources.But all in vain
Is there any easy way or can you please explain the traditional ways. Can you please explain the steps that you followed?
At last i got an easy way to deploy static files in production environment. Therefore answering my own question.
For all the newbies like me who are feeling helpless in this case see this:-
https://github.com/kennethreitz/dj-static
1st Step: Install this using following command in terminal
$ sudo pip install dj-static
This is a simple Django middleware utility that allows you to properly serve static assets from production with a WSGI server like Gunicorn.
2nd Step:- Just set
#In settings.py file (to set production environment.)
Debug= False
3rd Step:- Configure your static assets in settings.py:
#add your path to STATIC_ROOT
STATIC_ROOT = 'staticfiles'
STATIC_URL = '/static/'
4th Step:-
And copy the lines written below and add them to wsgi.py
Do not remove any other lines. Just add these
from django.core.wsgi import get_wsgi_application
from dj_static import Cling
application = Cling(get_wsgi_application())
And its done. Now test it.
Note: Only using Apache(2.4) as web server. Nothing else to support apache.
Hope this helps other people too.
if you have some more ways or simplified version of the traditional way please do share it.
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
I have a Mac running OS X 10.9.3. I am trying to setup a Django application backed by a PostgreSQL database served by gunicorn, with static assets served by NGINX. I'm an old hand at Django with MySQL running with the developement server (manage.py runserver). But I'm new to setting it up with virtualenv, gunicorn and NGINX. So I'm following the instructions here.
My Django Project is being served successfully at localhost:3026. As a test of the database connectivity, I wanted to take a look at the Django Admin interface. I visited localhost:3026/admin/
I have included a screenshot below.
Why does this admin page look so ugly? It lacks the neccessary graphical interface and css that it is supposed to have? It looks like NGINX is not properly serving up those static assets. How can I troubleshoot and fix this issue?
EDIT:
After I posted this question, I did python manage.py collectstatic. That went and successfully copied all the static files to where they were supposed to (I think?) live in /opt/myenv/static. You can see the output of that command here. I then re-started gunicorn and nginx. I thought that would fix it. But unfortunately it didn't. The issue remains. In my Django settings.py file, I have configured the STATIC variables as follows:
STATIC_ROOT = "/opt/myenv/static/"
STATIC_URL = '/static/'
Try run command,
python manage.py collectstatic
If the commands executes successfuly, the static file would be generated in your project path, and then if you config the right static path, the web page will be correct.
I'm using django-compressor to concatenate and compress my CSS and JS files on this site. I'm serving static files from an S3 bucket.
On my local copy of the site, using a different S3 bucket, this all works perfectly. But on the live site, hosted on Heroku, it all works except the relative URLs for images in the CSS files do not get re-written.
eg, this line in the CSS file:
background-image: url("../img/glyphicons-halflings-grey.png");
gets rewritten to:
background-image:url('https://my-dev-bucket-name.s3.amazonaws.com/static/img/glyphicons-halflings-grey.png')
on my development site, but isn't touched on the live site. So the live site ends up looking in pepysdiary.s3.amazonaws.com/static/CACHE/img/ for the images (as it's relative to the new, compressed CSS file).
For now, I've put a directory at that location containing the images, but I can't work out why there's this difference. Both sites have this in their settings:
COMPRESS_CSS_FILTERS = [
# Creates absolute urls from relative ones.
'compressor.filters.css_default.CssAbsoluteFilter',
# CSS minimizer.
'compressor.filters.cssmin.CSSMinFilter'
]
And the CSS files are being minimised just fine... but it's like the other filter isn't being applied on the live site.
I recently ran into this issue on heroku, and running the latest version of django-compressor (1.3) does not solve the problem. I will provide the solution that I am using, as well as an explanation of the problems I ran into along the way.
The solution
I created my own 'CssAbsoluteFilter' that removes the settings.DEBUG check from the 'find' method like this:
# compress_filters.py
from compressor.filters.css_default import CssAbsoluteFilter
from compressor.utils import staticfiles
class CustomCssAbsoluteFilter(CssAbsoluteFilter):
def find(self, basename):
# The line below is the original line. I removed settings.DEBUG.
# if settings.DEBUG and basename and staticfiles.finders:
if basename and staticfiles.finders:
return staticfiles.finders.find(basename)
# settings.py
COMPRESS_CSS_FILTERS = [
# 'compressor.filters.css_default.CssAbsoluteFilter',
'app.compress_filters.CustomCssAbsoluteFilter',
'compressor.filters.cssmin.CSSMinFilter',
]
The absolute urls now always work for me whether DEBUG = True or False.
The Problem
The issue is connected to 'compressor.filters.css_default.CssAbsoluteFilter', your DEBUG setting, and the fact that heroku has a read-only file system and overwrites your app files every time you deploy.
The reason compress works correctly on your development server is because CssAbsoluteFilter will always find your static files when DEBUG = True, even if you never run 'collectstatic'. It looks for them in STATICFILES_DIRS.
When DEBUG = False on your production server, CssAbsoluteFilter assumes that static files have already been collected into your COMPRESS_ROOT and won't apply the absolute filter if it can't find the files.
Jerdez, django-compressor's author, explains it like this:
the CssAbsoluteFilter works with DEBUG = False if you've successfully provided the files to work with. During development compressors uses the staticfiles finder as a convenience so you don't have to run collectstatic all the time.
Now for heroku. Even though you are storing your static files on S3, you need to also store them on heroku (using CachedS3BotoStorage). Since heroku is a read-only file system, the only way to do this is to let heroku collect your static files automatically during deployment (see https://devcenter.heroku.com/articles/django-assets).
In my experience, running 'heroku run python manage.py collectstatic --noinput' manually or even in your Procfile will upload the files to S3, but it will NOT save the files to your STATIC_ROOT directory (which compressor uses by default as the COMPRESS_ROOT). You can confirm that your static files have been collected on heroku using 'heroku run ls path/to/collected'.
If your files have been collected on heroku successfully, you should be able to compress your files successfully as well, without the solution I provided above.
However, it seems heroku will only collect static files if you have made changes to your static files since your last deploy. If no changes have been made to your static files, you will see something like "0 of 250 static files copied". This is a problem because heroku completely replaces your app contents when you deploy, so you lose whatever static files were previously collected in COMPRESS_ROOT/STATIC_ROOT. If you try to compress your files after the collected files no longer exist on heroku and DEBUG = False, the CssAbsoluteFilter will not replace the relative urls with absolute urls.
My solution above avoids the heroku problem altogether, and replaces relative css urls with absolute urls even when DEBUG = False.
Hopefully other people will find this information helpful as well.
I've had this exact same problem for a month now, but this is fixed in the 1.3 release (3/18/13, so you were probably on 1.2), so just upgrade:
pip install -U django-compressor
The exact problem I gave up on working out, but it's related to Heroku and CssAbsoluteFilter being called but failing at _converter method. Looking at the 1.3 changelog, the only related commit is this: https://github.com/jezdez/django_compressor/commit/8254f8d707f517ab154ad0d6d77dfc1ac292bf41
I gave up there, life's too short.
Meanwhile this has been fixed in django-compressor 1.6. From the changelog:
Apply CssAbsoluteFilter to precompiled css even when compression is disabled
i.e. the absolute filter is run even with DEBUG = True.
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.