Horde 5 relied on the PEAR ecosystem ripping apart their packages and putting everything where it needs to be. But PEAR is a thing of the past. Horde 6 integrates with the composer installer using an additional piece called the horde/horde-installer-plugin. This composer plugin links together pieces from the installed composer packages into the right places and adds auto-generated configuration to make sure everything is found even though stuff is NOT mixed together the way PEAR did. This was a good starting point early in Horde 6 development when we took great pains not to break the previous distribution installs (which relied on PEAR or PEAR like behaviour) and installs based on horde-git-tools.
However, by now this is much less a priority and we are absolutely willing to move forward and make things less complicated, potentially breaking and changing code that relied on these older schemes. Much less code and assets are going to be exposed through the /web/ folder.
Proxy Mode vs Symlink Mode
Version 2.7.0 of horde/horde-installer-plugin introduces a new switch to the horde:reconfigure command:
composer horde:reconfigure --mode=proxy- In proxy mode composer will not symlink whole apps to the web dir but only create folders and files outside lib/, src/, test/ and a fairly large exclusion list. The endpoint php files will forward requests to the actual code in /vendor dir. This should reduce code duplication and makes it more obvious where related files need to be looked up
- A new constant HORDE_CONFIG_BASE is written to the autogenerated registry snippets.
- The composer autoloader is directly loaded by the proxy php files before delegating to the actual file in the vendor dir.
If you see unexpected class not found messages when testing proxy mode, please upgrade your horde/core package.
Currently proxy mode is a one-off. However, in an upcoming version the last used mode will be persisted to the composer.json file and reused on subsequent commands without an explicit mode option. Proxy mode is supposed to become the default in horde-installer-plugin 3.0.
Benefits of proxy mode
Proxy mode is the first step towards clarifying the intended architecture. Until recently much of our detection logic needed to behave differently if called through a file in the webroot or the same file but in its original vendor/horde/$app location. The new proxy files always perform the same way:
- First load the composer autoloader because the file always knows where the autoloader is relative to its own path.
- Then load the actual file in the vendor/horde/$app location
- Horde’s own internal PSR-0+ autoloader would only be loaded after composer’s autoloader. It hits action less and less often and will probably be removed from the default setup altogether.
This means the actual class files can rely on __FILE__ pointing to a predictable scheme and much less guess work and protection code is needed. On the other hand, it reveals some hidden problems and complications which developers can now fix before making this new mode the default. Unexpected lowercase class names (as found in whups and Horde Forms), complicated chicken/egg issues in the Registry, duplicate class names and parts of the error handling broken by subtle changes in newer PHP versions can now be seen and fixed.
As a consequence of spotting bugs and loading issues as I go along, starting with version 2.7.1 the composer plugin will check if a file var/config/autoload-extra.php exists. If it does, it will be included after the composer autoloader. This allows selectively hardcoding some class files until fixed versions of apps become available – or to actively undefine something for tests.