Add possibilty to add public assets to public_html

[liayn]

The current suggestion is to mount the whole /var/www/html folder. This makes it impossible to build a derived image, which already contains things within this path, as the mount would hide them.

It would be helpful to extend the entry-script to copy over stuff from /var/roundcube/assets/* to /var/www/html/*.

Example: This would allow to privde a logo within the image at /var/roundcube/assets/public_html/logo.svg, which would be updated in the mount each time the container starts.

Note: This is mostly important for php-fpm use cases.

This issue is probably related to #337 and also #396

[pabzm]

Thank you for this suggestion.

Technically nothing stops you from building a derived image and not mount /var/www/html when running it – or are there blockers?

Regarding the logo: can't you simply mount a local directory containing the image files to /var/www/html/public_html/myimages/ and specify /myimages/logo.svg in the config?

I wouldn't block to introduce something like you suggested, but as long as real work use cases work without it, I would prefer not to add the additional complexity.

If I misunderstand your use case, please try to explain it again.

[pabzm]

Also please note #381, which could help with your specific use case.

[liayn]

Thanks for your response @pabzm. We indeed solved it currently with a post-setup-script, but it would be nicer to not having to do that.

Regarding the logo: can't you simply mount a local directory containing the image files to /var/www/html/public_html/myimages/ and specify /myimages/logo.svg in the config?

The thing is that /var/www/html/ is bind-mounted (of course) and we want to supply the logo with the built image. So there is no way to have any assets in /var/www/html/public_html/* within the image as this is shaddowed and therfore hidden by the bind mount then.

It goes a bit too far for this ticket, but roundcube must/should really strive to clearly separate code/config and public stuff even more. Sticking to the php-fpm case this really means getting the source out of /var/www/html and only put the entrypoint (index.php), logos and other public stuff there.
Configuration for plugins must not require any changes to the plugin-directories, but should be stored centrally in a configuration folder. The docroot should only contain symlinks to the public folder of plugins in order to allow them to provide public assets.
A composer installer (or other kind of installer) ensures that those symlinks are in place, hence there is no need at all to copy anything to the docroot during container startup. That way any customs logos would simply be a plugin/skin, which leverages this mechanics.
How this works in practise can be seen at https://github.com/typo3/typo3/ with its package/extension handling, which does exactly that.

[liayn]

Our current solution for this is documented in #396 (comment)