David Abrahams wrote:
David Abrahams
<[EMAIL PROTECTED]> writes:
You certainly didn't configure Trac and Apache the right way,
so that your static resources are served directly by Apache.
Check:
http://projects.edgewall.com/trac/wiki/TracCgi#MappingStaticResources
http://projects.edgewall.com/trac/wiki/TracModPython#Using/tracrootURL
If you don't do that, Trac will serve the static content directly,
by using its "Chrome" component.
I certainly did try to follow those instructions.
Yes, it looks correct.
One more note: I do see the following in my Apache access_log
i.p.add.ress - - [date] "GET /trac/zkb/report/1 HTTP/1.1" 200 9341
i.p.add.ress - - [date] "GET /trac-htdocs/css/report.css HTTP/1.1" 206 167
i.p.add.ress - - [date] "GET /trac/zkb/chrome/common/trac_banner.png HTTP/1$
i.p.add.ress - - [date] "GET /trac-htdocs/xml.png HTTP/1.1" 200 452
...
Doesn't that indicate that Apache is serving the images?
First, not necessarily. It shows you that Apache receives the requests,
but that
doesn't tell you how it handles them, serving them directly or handing
them down
to mod_python -> Trac -> Chrome.
In general, to be 100% confident, you should also take a look at the
trac log,
and verify that those requests are *not* present there.
Then, in this particular case, you should note that *not all* of the
static resources
are accessed through the /trac-htdocs prefix: you can see some
/trac/zkb/chrome/...
requests as well, and those *will* be handled by the Chrome component.
From the access.log excerpt you give, it seems that this only concerns
the banner,
so it should be easy to fix. Check the following documentation:
http://projects.edgewall.com/trac/wiki/TracInterfaceCustomization#ProjectLogoandIcon
-- Christian
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac
