https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33115 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- What files are you editing in those directories? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33115 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to David Liddle from comment #2)

Logos and custom fonts were added to the root htdocs directory for both sites, and there is a modified XSLT stylesheet in use for the intranet site. All of these are referenced by system preferences that would be included in a restore.

If there is a better location for such files, such that they would be dumped and restored by the existing processes, then I would happily alter our practice.

You could create a /var/lib/koha/<instancename>/web folder and then use an Alias in Apache in /etc/koha/apache-shared-opac.conf like the following: Alias /web "/var/lib/koha/${instance}/web" You may also need a directive like the following depending on your security: <Directory "/var/lib/koha/${instance}/web"> Require all granted </Directory> The /var/lib/koha/<instancename> directory gets automatically backed up by koha-dump. -- It does require customization of the Apache config, so maybe we should consider providing this out of the box for people to drop files into... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33115 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- (In reply to David Liddle from comment #4)

Thank you! That is a fantastic suggestion. Your idea of making such a function available out of the box is excellent. As soon as I could, I logged into what you might call our development server, created the directory and alias, and then also added the directory to the <access_dir> section in koha-conf.xml.

I haven't used the access_dir feature but I think that might be defeating the purpose of the access_dir feature. Not a big deal if you do it intentionally I suppose but something to keep in mind, especially if anyone takes over your system, as they might think they're putting files in a private directory and not realizing they're being exposed publicly via Apache.

- I did have to figure out that, when you wrote ${instance}, it wasn't something of a wildcard entry that Apache would apply to any given instance. - I'm not quick enough with regular expressions to know if one could enter a single alias in such a way that only the web folder of the applicable instance has its files served by the instance's base URL.

I'm not sure what you mean by this. The ${instance} is a variable used in the Apache configuration. You can see examples of it throughout the Koha Apache configuration like for the sitemap on /etc/koha/apache-shared-opac.conf It's defined with this directive (where "kohadev" would be the name of your instance): Define instance "kohadev"

- The pickle of this method is that /etc/koha/apache-shared-opac.conf is also not included by koha-dump. So if one uses koha-restore, one still has to document and implement the changes to that file. Unless, I suppose, a web folder is supplied from the start and a clever alias added to the apache-shared conf.

It is a bit of a pickle.

- IF such a thing was built in, I wonder if it would be good or bad to add the web folder to the Upload tool or have a separate page of its own.

If you're happy for the files to be managed via the Web UI, then you can already use the "Upload" tool. You just need to tick "Allow public downloads".

I know that much of the above would really belong in a new feature bug describing the addition and function of a web folder. Who should take on the creation of that? As for this bug, I think your suggestion renders it pretty squashed.

You've read my mind ;). I'll mark this one as closed, and you can open a new one describing the behaviour that you're envisioning. Although I think what you're describing is really already possible using the existing "Upload" tool. Personally, I probably wouldn't work on a web tool for this. I already use something like "/var/lib/koha/${instance}/web" although I maintain that configuration using a customized Koha Debian package. I'd be interested in upstreaming that change. I think I'll open a report for that now... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33115 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|NEW |RESOLVED -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33115 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- (In reply to David Liddle from comment #7)

Indeed, it does work; the error was mine. I realized today that, with Plack enabled, I needed to add a few lines to /etc/koha/apache-shared-opac-plack.conf. All is well.

You shouldn't need to add a few lines to /etc/koha/apache-shared-opac-plack.conf if you've already added them to /etc/koha/apache-shared-opac.conf -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.