Edgewall Software

Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#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:


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 Remy Blank, 12 years ago

Yes, the plugin CSS is missing from the static resources.

comment:2 by Remy Blank, 12 years ago

Component: generalproject
Resolution: fixed
Status: newclosed

The plugin static resources were missing on the server. It should be fixed now. Thanks for reporting.

comment:3 by Christian Boos, 12 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…

comment:4 by Remy Blank, 12 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?

comment:5 by Christian Boos, 12 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.

in reply to:  4 comment:6 by Christian Boos, 12 years ago

Replying to rblank:

Didn't you generate the .../share content with trac-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).

in reply to:  5 comment:7 by Remy Blank, 12 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:8 by Dirk Stöcker, 12 years ago

Resolution: fixed
Status: closedreopened

Same issue again.

comment:9 by Dirk Stöcker, 12 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 osimons, 12 years ago

Cc: osimons 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 Dirk Stöcker, 11 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 Christian Boos, 11 years ago

Resolution: fixed
Status: reopenedclosed

Updated. I added:

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).

comment:13 by Christian Boos, 11 years ago

Milestone: not applicable

(fixing {36})

Modify Ticket

Change Properties
Set your email in Preferences
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.