On Monday, March 23, 2015 at 1:02:21 PM UTC-7, RjOllos wrote: > > > > 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." >
Documentation revised in: https://trac.edgewall.org/wiki/TracInstall?action=diff&version=426 I might have mentioned elsewhere, I'd really like to simplify TracInstall with the aim of making it less intimidating for new users. I think TracInstall should target a TracStandalone installation, since those steps are all (or mostly) common to running with a web server. Everything about configuring a web server could be pulled out and put in other pages, particularly this section: https://trac.edgewall.org/wiki/TracInstall#RunningTraconaWebServer Also, TracInstall could document RedHat and Debian -like platforms, and leave all other platform-specific instructions and caveats for the platform-specific pages. It appears the page has been revised in a very piecemeal way and could benefit from a major revision. > > 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 https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
