When using django, compressor, and clevercss, I set my css url to an absolute path. Clevercss is then passed the path of the .ccss file without the COMPRESS_ROOT prefixed (the absolute path). When I set my css url to a relative path, clevercss processes the ccss files, but the browser then correctly looks for relatively placed css files (e.g. mywebsite.com/profile/user/1/css/stylesheet.css)
Compressor, however, does use the MEDIA_ROOT when the css link is a relative url, but not when an absolute url is used. This has the unfortunate effect of my css either being rendered by clevercss and not accessible by the browser (unless on the home page), or clevercss not having access to the files (due to an absolute url being used). Ironically, the examples offered on http://github.com/mintchaos/django_compressor use absolute urls for the css paths.
I think I'm doing something wrong here, but I'm not sure where it could be and have spent quite a few hours looking. I'm also currently running this locally through ./manage.py runserver and serving some static files (images) through django. (this is fine for my local development).
I can't speak to django-compressor specifically; but I have been dealing with finding a good automatic compression solution for the CSS and JS files of my Django-powered web applications. I'm currently using django-static. It's been really easy to set up and use, IMO. I was running into some issues running django-compress (different from django-compressor) when I decided to give django-static a try. So far it's been great. Might be worth checking out. It can be found here: http://github.com/peterbe/django-static.
Related
I have set up a basic Django system and am testing out the admin app. The admin screen displays with raw styles and not the pretty ones shown in the tutorials and specified in the style-sheets.
Following several other questions, I found this is a common problem caused because Django doesn't normally serve static files. However, it does if DEBUG is switched on and I do have debug switched on. I followed all of the suggestions in the answers anyway to collect static files, etc.
If I enter the static file URLs directly they get downloaded and I can see the files in the developer mode of the browser (both Chrome and Edge). So I think the static files are being served.
Furthermore, if I save the page using the browser, it saves all of the static files and then if I open the main page it is shown with the correct styles. So the styles are working.
So it would seem to me that the files are being served and the browser is getting them and it can render them (from a saved file) but it somehow isn't working when served from Django.
Can anyone tell me what is going on?
EDIT:
Here is a strange thing: if, using the Chrome developer tool, I select the base.css file, click somewhere in the text of the CSS (say at the end of a line) and then add a space, suddenly the page appears correctly.
If I then do refresh the page it goes back to unstyled again.
EDIT 2:
I saw a recommendation to install the Whitenoise app to serve static file so I went ahead and did it. I turned off debug and presto! the styles appear. Turning on debug (so I presume django serves the files) and the styles go away. I saved both sites to the file system and compared the directories using a compare tool. There was no difference.
I'm not calling this an answer as the question is:
Why?
Also, I can't have debug on and get styles.
I do a simple web application written in Python using cherrypy and Mako. So, my question is also simple.
I have one page with URL http://1.2.3.4/a/page_first. Also there is an image that available on URL http://1.2.3.4/a/page_first/my_image.png. And I want to locate my_image.png on the page_first.
I added a tag <img src="my_image.png"/>, but it is not shown. I looked at web developer tools->Network and saw that request URL for image was http://1.2.3.4/a/my_image.png, instead of http://1.2.3.4/a/page_first/my_image.png.
Why does it happen?
Thanks.
The page address needs to be http://1.2.3.4/a/page_first/ (with trailing slash).
ADDED:
You don't seem to understand relative URLs, so let me explain. When you reference an image like this <img src="my_image.png"/>, the image URL in the tag doesn't have any host/path info, so path is taken from the address of the HTML page that refers to the image. Since path is everything up to the last slash, in your case it is http://1.2.3.4/a/. So the full image URL that the browser will request becomes http://1.2.3.4/a/my_image.png.
You want it to be http://1.2.3.4/a/page_first/my_image.png, so the path part of the HTML page must be /a/page_first/.
Note that the browser will not assume page_first is "a directory" just because it doesn't have an "extension", and will not add the trailing slash automatically. When you access a server publishing static dirs and files and specify a directory name for the path and omit the trailing slash (e. g. http://www.example.com/some/path/here), the server is able to determine that you actually request a directory, and it adds the slash (and usually also a default/index file name) for you. It's not generally the case with dynamic web sites where URLs are programmed.
So basically you need to explicitly include the trailing slash in your page path: dispatcher.connect('page','/a/:number_of_page/', controller=self, action='page_method') and always refer to it with the trailing slash (http://1.2.3.4/a/page_first/), otherwise the route will not be matched.
As a side note, usually you put the images and other static files into a dedicated dir and serve them either with CherryPy's static dir tool, or, if it's a high load site, with a dedicated server.
Try <img src="/page_first/my_image.png"/>
In the ATOM feeds (RSS) for my site created with Pelican, the URLs and images with a relative path point to http://feeds.feedburner.com/blogname/whatever instead of my site's path.
I have the SITEURL and Relative_URLS = False settings in Pelican. What else can I do to get the feeds to use absolute instead of relative paths?
I know there is an xml:base setting, but I don't know how to get Pelican to use it?
OK, googling around, it seems like there's no way to do this. I'm going to have to resort to rewriting all the feed content by hacking the feed writer with absolute image paths and link URLs.
I was going through serving media in django and the I encountered a project with this line of code
href="{{STATIC_URL}}/custom/js/list.js"
in settings, STATIC_URL= /xexo/static/. That means the url will become
127.0.0.1:8000/xexo/static//custom/js/list.js
notice the //. Surprisingly even if I do this
127.0.0.1:8000/xexo/static///////custom/js/list.js
or
127.0.0.1:8000/xexo/static/////custom/////js/list.js
in my browser, the list.js will still load.
My qn is, how is this possible?
EDIT
Here is another link I have found
Link 1
Link 2
This questions url is:
http://stackoverflow.com/questions/15260904/serving-media-in-django
I can add a few slashes in and it works fine...
http://stackoverflow.com/questions/15260904///////serving-media-in-django
My point being this isn't a thing associated with serving media in django, this seems to be typical browser behaviour.
Although it doesn't seem to cause any problems in the browser to have multiple slashes it might be best to avoid it and change that line to:
href="{{STATIC_URL}}custom/js/list.js"
so the double slash is avoided.
I tried profiling my web application and one of the bottlenecks reported was the lack of gzip compression. I proceeded to install the gzip middleware in Django and got a bit of a boost but a new report shows that it is only gzipping the HTML files i.e. any content processed by Django. Is there a way I could kludge/hack/force/make the middleware gzip my CSS and my JS as well?
Could someone please answer my questions below. I've gotten a little lost with this.
I might have gotten it wrong but
people do gzip the CSS and the JS,
don't they?
Does Django not compress
JS and CSS for some browser
compatibility issues?
Is compressing
and minifying the same thing?
Thanks.
Your CSS and JS should not be going through Django on your production system. You need to configure Apache (or Nginx, or whatever) to serve these, and when you do so you'll be able to set up gzip compression there, rather than in Django.
And no, compressing and minifying are not the same thing. GZip compression is done dynamically by the server when it serves your request, and the browser transparently unzips the file when it receives it. Minification is the process of removing comments and white-space from the files, and sometimes concatenating multiple files into one (ie one css and one javascript, instead of lots of each). This is done when you deploy your files to the server - by django-compress, as Ashok suggests, or by something external like the YUI compressor, and the browser doesn't attempt to reconstruct the original file - that would be impossible, and unnecessary.
You should think about placing your django application behind an HTTP reverse proxy.
You can configure apache to act as a reverse proxy to your django application, although a number of people seem to prefer using nginx or lighttpd for this scenario.
An HTTP reverse proxy basically is a proxy set up directly in front of your web application. Browsers make requests from the reverse proxy, and the reverse proxy forwards the requests to the web application. The reverse proxy can also do a number of interesting things like handle ssl, handle gzip-compressing all responses, and handle serving static files.
Thanks everyone.
It seems that the GzipMiddleware in Django DOES compress CSS and JS.
I was using Google's Page Speed plugin for Firebug to profile my page and it seems that it was generating reports based on old copies (non-gzipped versions) of the CSSs and JSs in my local cache. These copies were there from the time before I enabled the Gzip middleware. I flushed the cache and it seems that the reports showed different results altogether.
Follow Daniel Roseman's suggestion, "Your CSS and JS should not be going through Django on your production system"
If you want to serve through Django then
you can compress css, js files using django-compressor, django-compress