#10306 closed defect (fixed)
Trac Plugin CSS not loaded
| Reported by: | Dirk Stöcker | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | not applicable |
| Component: | project | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | osimons | Branch: | |
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description
Somewhat changed for running t.e.o instance. The plugin-css files can no longer be loaded (e.g. for spamfilter admin pages).
Attachments (0)
Change History (13)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
| Component: | general → project |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
The plugin static resources were missing on the server. It should be fixed now. Thanks for reporting.
comment:3 by , 13 years ago
Well, I see that you added spamfilter et al. below ...virtualenv/.../share/htdocs/, however this shouldn't have been necessary as part of a "smooth" transition to fingerprinting support, I think. I need to investigate more…
follow-up: 6 comment:4 by , 13 years ago
Why not? All URLs below /chrome/![^/]+/ are redirected to .../share/htdocs, so the plugin resources need to be there as well. Didn't you generate the .../share content with trac-admin $ENV deploy? Isn't that how it should be done?
follow-up: 7 comment:5 by , 13 years ago
Ok, so the admin.css is added via: add_stylesheet(req, 'spamfilter/admin.css') and this adds the fingerprint. Then we have the webserver do its mapping from /chrome/!.../x to somestaticplace/x and there's not much that can be done if the file is not there…
So I guess we have to make the deploy step mandatory there.
comment:6 by , 13 years ago
Replying to rblank:
Didn't you generate the
.../sharecontent withtrac-admin $ENV deploy?
Yes… but with $ENV being a "dummy" env, and this part of the script needs to be changed (i.e. we need to define a canonical env for each Trac version).
comment:7 by , 13 years ago
Replying to cboos:
So I guess we have to make the deploy step mandatory there.
Yes, and that will also solve part of the issue in #9936 (the regexp part). If we make deploy copy the files into the hierarchy including the fingerprint (if fingerprinting is enabled), we don't need the regexp matching anymore. So the layout of the deployed data would be:
cgi-bin/htdocs/!1ab2c3d4/*: Static files for one fingerprint!8c9e8b2c/*: Static files for another fingerprint- …
Then we can point the server to the htdocs directory, and the right files will be served. We should also change deploy to accept writing to an existing directory. It should copy new files, but not overwrite existing files (it could warn about non up-to-date files, and possibly copy the new content to numbered files, e.g. trac.css.1, trac.css.2, …).
comment:9 by , 13 years ago
Any progress here? Managing the SPAM filter without a proper CSS to display the colors is no fun at all, so I currently don't train the filter for new spam.
comment:10 by , 13 years ago
| Cc: | added |
|---|
Just adding my interest in this ticket to follow progress on real-life deployment issues related to the fingerprinting feature of #9936. Please be sure to document best implementation practice.
comment:11 by , 13 years ago
Any reason why this is still not fixed? As long as this is not fixed I don't even look at the SPAM training for t.e.o.!
comment:12 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Updated. I added:
[components] tracspamfilter.* = enabled
in the dummyenvs, so that trac-admin .../dummyenv deploy .../share will also export the htdocs files for the SpamFilter plugin.
Concerning #9936 - well, that's still not 100% satisfying to my taste, so it's a bit early for the "best practices". We could however start to document the current procedure in 0.13/TracInstall (first bringing it up to date with 0.12's version and TracInstall#MappingStaticResources).
Yes, the plugin CSS is missing from the static resources.