lizadaly / threepress

Automatically exported from code.google.com/p/threepress
Other
0 stars 0 forks source link

Templates not using settings.py:MEDIA_URL #154

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Deploy bookworm anywhere that isn't the webserver root
2. Load the homepage - see all those broken images and general lack of styling?

The bookworm settings file has a MEDIA_URL variable which points to static 
resources, like css 
files, images etc. If the templates used this variable, the homepage would look 
"normal" when 
delpoyed under a subdirectory. Useful for those of us who delpoy multiple apps 
under one 
CNAME / Vhost.

Patch supplied, created against today's svn trunk. My svn info:
URL: http://threepress.googlecode.com/svn/trunk
Repository Root: http://threepress.googlecode.com/svn
Repository UUID: e08d0fb5-4147-0410-a205-bba44f1f51a3
Revision: 863
Node Kind: directory
Schedule: normal
Last Changed Author: liza31337
Last Changed Rev: 863
Last Changed Date: 2009-08-20 05:48:07 +1000 (Thu, 20 Aug 2009)
Properties Last Updated: 2009-08-21 10:17:02 +1000 (Fri, 21 Aug 2009)

Original issue reported on code.google.com by steven.m...@gmail.com on 21 Aug 2009 at 1:33

Attachments:

GoogleCodeExporter commented 9 years ago
Thank you! I'll definitely apply this fix after we've tested it.

Original comment by liza31337@gmail.com on 21 Aug 2009 at 2:17

GoogleCodeExporter commented 9 years ago
oops, this is not a complete patch. There are static references in the i18n 
areas. Running 

grep --exclude "*.svn*" -rl "\/static\/" .

picks up quite a few more. Then you have to consider what you do for the uri 
references inside CSS. I know some 
people get their interpreter to serve out CSS files so they can add things url 
prefixes to these references... 

Original comment by steven.m...@gmail.com on 21 Aug 2009 at 2:18

GoogleCodeExporter commented 9 years ago
CSS files are pre-processed, so that would be a good time to make any resource 
links
relative.

Original comment by liza31337@gmail.com on 21 Aug 2009 at 2:28

GoogleCodeExporter commented 9 years ago
Oh sorry, I thought you were referring to in-book CSS, which is handled a 
different
way anyway.  Yes, the URL resources inside the CSS files are annoying, though 
I'm not
sure whether simple relative links would work.

Since this is more complicated than I originally thought I took the current 
patch and
some additional changes related to this and created:

https://threepress.googlecode.com/svn/branches/bookworm-static-resource-refactor

If you'd like to be a committer so you can work on this branch (or anything 
else)
please let me know offline at liza@threepress.org.  Your help would be 
appreciated!

Original comment by liza31337@gmail.com on 26 Aug 2009 at 10:43

GoogleCodeExporter commented 9 years ago
So I guess we can either:
 1. stop serving css statically; put it under python control using a bunch of direct_to_template urlpatterns
 2. have static css, with dynamic, python-controlled equivalents to specify the uris, maybe using cssutils

or maybe some other idea?

the first option's the simplest, but ties up more mod_python workers. the 
second is nicer to the system, but 
fragments the css, introducing unnecessary complexity.

I'l give the first option a go and see what the damage is.

Original comment by steven.m...@gmail.com on 31 Aug 2009 at 1:59

GoogleCodeExporter commented 9 years ago
Since the resources should all be within the /static/ directory, I think just 
making
them relative should work.  c.f.
http://stackoverflow.com/questions/940451/using-relative-url-in-css-file-what-lo
cation-is-it-relative-to

So instead of 'url(/static/foo.image)' just 'url(foo.image)' ought to work.

Original comment by liza31337@gmail.com on 31 Aug 2009 at 1:56

GoogleCodeExporter commented 9 years ago
ah yep, of course - just like the css @import directive.

Pretty simple change in the end; see r873: 
http://code.google.com/p/threepress/source/detail?r=873. Forgot to 
put proper googlecode syntax in the commit log - oops.

Original comment by steven.m...@gmail.com on 3 Sep 2009 at 3:57