Move config out of webroot for Horde 6

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

  • Default assumptions in the Horde registry for where apps are located were wrong
  • Javascript from library packages needed to be web visible and Horde needed to know their path and webroot
  • Custom Themes location and webroot
  • Composer2 would wipe custom configuration during software updates
  • Composer2 would wipe the static dir during software updates

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

  • Point to /web/$app/ for an app’s fileroot
  • Fix the webroot assumption, too from $webroot/horde/$app to $webroot/$app
  • Make horde search for themes in /web/themes/$app/ rather than /web/horde/$themes and /web/horde/$app/$themes/
  • Make horde load horde and library javascript files from /web/js/horde rather than /web/horde/js

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation

These items remain in the config/ dir:

  • default registry.php file
  • default prefs.php file
  • routes.php file
  • conf.xml definition file
  • other defaults files like backends.php, nls.php
  • a stub for hooks (maybe we can get away without it)

These items reside outside the webroot:

  • conf.php file
  • registry.local.php
  • routes.local.php (if any, I have never seen it used)
  • horde.local.php
  • other overrides like prefs.local.php, backends.local.php
  • registry.d/ snippets
  • conf.d/ snippets
  • all vhost-specific overrides like conf-www.example.com.php, registry-www.example.com.php, prefs-www.example.com.
  • Hooks Files. (We need to ensure correct autoloading though)

Support for existing installations

There is currently no software level support for upgrading a Horde 5 installation from pear or git-tools to a Horde 6 installation. There is no Horde 6 release by Horde Upstream yet. Installations of the maintaina horde fork are treated as existing installations of Horde 6 for the purpose of this document.

To allow a smooth transition, horde-installer-plugin will be changed in this way:
For each file in the presets dir, check if it exists in the old and new location.
Normally, the old dir should not hold a copy of the file unless it is delivered by the package itself.
If the new /var/config/ folder is writeable, put the file there. Create subdirectories as necessary.
Finally, symlink all files from /var/config to corresponding old location, even if they are not from preset.

The logic for reading configs should prefer the new location, if available, but fall back to the old location. This must be addressed in some code paths in horde/core and possibly also somewhere in the individual apps.
Writing files should always go to the new location, though in theory the symlink should take care of that.

Outlook

Moving configuration out of the web-visible and composer-owned area is a major step forward. Future developments may reduce the web-visible surface of a horde installation even further.

Implementation progress

  • https://github.com/maintaina-com/horde-deployment as of 1.0.0 includes the var/config/ dir
  • https://github.com/maintaina-com/horde-installer-plugin as of 2.2.1 contains a working implementation. Configs from /presets/ are written to /var/config/ and symlinked to their traditional locations.

Leave a Reply

Your email address will not be published.