On Saturday, March 21, 2015 at 12:06:09 AM UTC-7, Peter Suter wrote: > > 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. >
Thank you for the explanation. Rewording the documentation according to your suggestions seems like a good idea. According to your explanation, I might include: "If a universal `/chrome` alias is used, the static resources must be extracted for all plugins. This means that the `deploy` command must be executed after installing a plugin that provides static resources." > 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. :) > > I imagine there is information in the Apache logs showing that it's handling the request and serving the file, but I haven't poked around in there yet. -- 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.
