On 21.03.2015 02:34, RjOllos wrote:
> * I suppose that if a plugin creates its own resource directory, it
> should be mapped too. A plugin like wikiextras creates 7 of these
> directories which makes a lot of aliases
Ideally, yes.
I would also like to try and understand this better.
All of the static assets of WikiExtrasPlugin are extracted below
/path/to/trac/htdocs/wikiextras, so would the following be sufficient,
even though there are subdirectories in wikiextras?:
Alias /trac/chrome/wikiextras /path/to/trac/htdocs/wikiextras
$ find /path/to/trac/htdocs/wikiextras/ -type d
/path/to/trac/htdocs/wikiextras/
/path/to/trac/htdocs/wikiextras/icons
/path/to/trac/htdocs/wikiextras/icons/fugue
/path/to/trac/htdocs/wikiextras/icons/fugue/icons-shadowless
/path/to/trac/htdocs/wikiextras/icons/fugue/bonus
/path/to/trac/htdocs/wikiextras/icons/fugue/bonus/icons-shadowless-32
/path/to/trac/htdocs/wikiextras/icons/fugue/bonus/icons-shadowless-24
/path/to/trac/htdocs/wikiextras/icons/fugue/bonus/icons-24
/path/to/trac/htdocs/wikiextras/icons/fugue/bonus/icons-32
/path/to/trac/htdocs/wikiextras/icons/fugue/icons
/path/to/trac/htdocs/wikiextras/css
Maybe I misunderstood the initial question or at least missed the part
about wikiextras creating 7 directories. I just meant to say that, yes,
resource directories of plugins should be mapped too. But you are right,
one Alias directive is sufficient for all subdirectories.
>
> * I don't understand why "its important to override only known
paths and
> not try to make universal |/chrome| alias for everything", unless
you
> suspect a rogue user could create more directories in `htdocs`
I think it just means that not necessarily all paths can be mapped the
same way, e.g. because plugins will be installed later (but not mapped
in htdocs),
I think I'm missing some critical point here. Provided that all of the
static resources are extracted below /path/to/trac/htdocs, for example:
$ ls /path/to/trac/htdocs
common newsflash tracfullblog
footnote site wikiextas
... one still should not use the following alias?:
Alias /trac/chrome /path/to/trac/htdocs
If you're sure all the static resources are there, I think it's fine.
The only potential problem I can think of is when more static resources
are (later added) elsewhere.
For example when you allow uploading plugins, but the uploader forgets
or is not allowed to extract the uploaded plugin's resources. In that
case the Alias would apply to the static resources of the new plugin,
but the files would not be found.
(While it would "work" if each known chrome subfolder had its own Alias
directive. The new plugin would not yet have one, so Trac would serve
the resources.)
If that's all the documentation means, it's maybe a bit overstated.
Instead of:
> Plugins can add their own resources, usually accessible by
`/chrome/<plugin>` path, so its important to override only known paths
and not try to make universal `/chrome` alias for everything.
The documentation could say:
> Plugins can add their own resources, usually accessible by
`/chrome/<plugin>` path. A universal `/chrome` alias for everything
might miss these. Either override only known paths, or extract all
(future) plugin resources to the same location.
But maybe I'm missing the point.
or maybe some plugins are installed globally and mapped to
some shared path etc.
There's also /chrome/shared defined by the htdocs_dir option in the
inherit section of the TracIni.
http://trac.edgewall.org/wiki/TracDev/TracURLs
<http://trac.edgewall.org/wiki/TracDev/TracURLs>
If I want to be sure that a file is being served by Apache, that would
be indicated by the absence of GET requests in the log? The following
message that is seen before I setup a mapping for footnote, but not after.
2015-03-21 02:06:21,372 Trac[main] DEBUG: Dispatching
<RequestWithSession "GET '/chrome/footnote/footnote.css'">
Or is there another way I can check that Apache is serving the file?
Maybe delete the file? If it still works Trac is serving it. Your way
sounds better. :)
--
You received this message because you are subscribed to the Google Groups "Trac
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.
