\documentclass{article}
\usepackage{ulem}
\pagestyle{headings}
\begin{document}
\part{ Configuration files}
All applications' configuration files are inside the applications' \texttt{config/} directories. All configuration files are valid PHP files. This has the drawback that they are more difficult to edit, and that administrators might create invalid PHP code, leading to parsing errors and breaking the applications.

But there are several good reasons for making configuration files PHP code:

\begin{itemize}
\item{There is no overhead in parsing the files, they provide configuration data in a format that can be used in the applications immediately.}
\item{One can use the result of PHP expressions in configuration values, e.g. gettext strings (\texttt{\_("Some translated string")}), or references (\texttt{\$\_SERVER['SERVER\_NAME']})}
\item{Experienced administrators with PHP knowledge can create lookup functions that return dynamic configuration values, e.g. \texttt{\$servers['host'] = lookup\_host();} with \texttt{lookup\_host()} being a function looking up the \texttt{'host'} value from a database or LDAP directory depending on the user name.}
\end{itemize}
There is a set of default configuration files that are mandatory for an application, or optional but consistently used across all applications:

\begin{itemize}
\item{\texttt{conf.php}: This is the main configuration file that contains global options for every application.}
\item{\texttt{prefs.php}: This file controls the available user preferences for the application, their default values, and also controls which preferences users can alter.}
\item{\texttt{mime\_drivers.php}: This file controls local MIME drivers (aka MIME viewer) for the application, specifically what kinds of files are viewable and/or downloadable.}
\item{\texttt{servers.php}, \texttt{backends.php}, \texttt{sources.php}: If an application can connect to different servers, backends, or directories, these will be defined and configured here.}
\end{itemize}
Normally, the configuration files have distributed examples with a \texttt{.dist} suffix appended to the file names. The \texttt{prefs.php} file for example comes distributed as \texttt{prefs.php.dist}. Applications are configured by copying e.g. \texttt{prefs.php.dist} to \texttt{prefs.php} and editing the configuration files with any text editor.

The only exception is currently the \texttt{conf.php} file, which no longer comes as a \texttt{conf.php.dist} file, but as a \texttt{conf.xml} file containing the available options and their default values as XML markup (see ConfXML\footnote{http://example.com/index.php?page=ConfXML}). A graphical setup interface is created from this XML data that administrators can open and edit in their browsers. If they submit the configuration form, the PHP configuration files are created automatically, they no longer need to edited manually. This approach solves most of the drawbacks with PHP configuration files while keeping the good things:

\begin{itemize}
\item{The chances are much lower that administrators accidentally break the configuration files by creating invalid PHP code.}
\item{Configuration is much easier using a graphical interface.}
\item{The configuration files are still PHP code.}
\item{Administrators can still customize the configuration with their own PHP code.}
\end{itemize}
This approach will be extended over other configuration files in the future.

\end{document}
