research paper about hiv in the philippines pdf essay on article 370 for ssc son of mr green jeans essay sample teacher cover letter no experience what universities look for in a personal statement

The state of horde composer deployments

In early 2019 I first wrote a few lines on migrating horde to composer based setups.

Even though I was too occupied with other business for several months, I have something to show and it is time to review what we have and what we don’t have.

The good news is, it really runs as far as I am concerned. For the mainstream apps, the Web UI works correctly as well as caldav/carddav access, handling of db schema migrations, some critical commandline scripts. There is still a lot of scripts to check and possibly fix.

The Horde Components helper has been modified to be run as a part of a horde deployment or standalone. It can also still be run from git-tools. I added some code to git-tools to improve the way it wraps horde-components. However, most things git-tools provides are no longer that interesting to the casual developer or to deploying horde master tree installations.

I also improved the horde Controller/Routes core. It is now more successful in detecting which app handles a request. Also, a new option for unauthenticated routes and for „API style“ auth handling has been included. This enables REST interfaces.

I finally did a small proof of concept app which is completely based on the controller/routes core and does not have a single traditional „page“ file. Maybe this should be provided as an alternative skeleton.

How to run your own composer based install

Running a new horde install for development or CI purpose is as easy as:

cd your/web/root/
git clone .
composer install
cp web/horde/config/conf.php.dist web/horde/config/conf.php

For using a database, provide a config with a db backend instead.
You might also want to run web/horde/bin/horde-db-migrate.

I intend to improve the installer a little to detect if pre-made configs have been put into expected locations of the deployment and use them.

Why you should not use this in production

This deployment comes „as is“. It is still dependent on a satis server not controlled by the horde organisation, running a no-warranties fork of the unreleased git master code. If you run this in production, you need to do a lot of QA for your specific use case. Patches welcome. You may also encounter features not part of official horde releases because they are incomplete, lacking tests or else.

I am still trying to get this upstream. Dealing with a downsteam horde distribution of 150+ repos is tedious work. I’d rather invest time in actual software development. In case you really need to, contact me about commercial support options.