Static content doesn't work for applications that are included in a larger site

[kevin]

Since static files are configured in the config file, if they are included in an application that is joined up to form a larger site, the static files will not appear in the proper place beneath the application root.

[kevin]

John Speno mentioned that the VirtualPathFilter? may help here.

[fumanchu@…]

This is probably fixed in CherryPy? changeset  760, which allows arbitrary mount points using a  VirtualPathFilter.

[godoy]

Kevin, did r760 fix this? I saw you talking to somebody about a new approach for First Class, but is it OK for what we have in the trunk?

[jorge.vargas]

with the move for CP3 this should become obsolete.

[alberto]

Batch moved into unclassified from 1.1 to properly track progress on the later

[lszyba1]

How are you including the static content? For example if you are mounting you application via a modwsgi then all url and static request would have SCRIPT_NAME appended to them.

This tickiet #2033 makes sure that all urls are encoded with tg.url('someurl') by default in tg2 quickstart and therefore they should be properly mounted via modwsgi.

So the question for this bug would be how do you include your application in larger site? It should work with modwsgi.

[chrisz]

This problem appears with TG 1.x when you put you an app inside in a namespace package, because the default app.cfg sets

[/static]
static_filter.on = True
static_filter.dir = "%(top_level_dir)s/static"

So the static directory (the same applies to [/favicon.ico]) is set to the top level, i.e. the level of the namespace package instead of the application which is one level deeper. We should add a comment to the app.cfg file that in this case, you should use package_dir instead of top_level_dir, or maybe even generally set

[/static]
static_filter.on = True
static_filter.dir = "%(package_dir)s/static"

See also  here in the mailing list.

[chrisz]

To finally close this matter, changed the app.cfg as suggested in r6168. Also adapted the online docs accordingly and explained the difference between top_level_dir and package_dir. Since this can be considered a bug, and since it cannot break existing TG 1.0 applications, committed this to the 1.0.x bugfix branch as well.