Resolves#330
After loading the `config/config.php`, Pico proceeds with any existing `config/*.config.php` in alphabetical order. The file order is crucial: Config values which has been set already, cannot be overwritten by a succeeding file. This is also true for arrays, i.e. when specifying `$config['test'] = array('foo' => 'bar')` in `config/a.config.php` and `$config['test'] = array('baz' => 42)` in `config/b.config.php`, `$config['test']['baz']` will be undefined
This allows developers to easily add custom query data to an page URL without the need to check enabled URL rewriting on their own. Since Twigs `link` filter is just an alias for Pico::getPageUrl(), theme designers can do the same with e.g. `{{ "index"|link("foo=bar&baz=42") }}`.
Theme designers, heads up! Don't forget that the result of the `link` filter is never escaped, so the result could contain unescaped ampersands when passing custom query data. You should pass the result to Twigs `escape` filter when using custom query data.
As pointed out by @Lomanic (see https://github.com/picocms/Pico/pull/260#issuecomment-153091890; thank you btw\!) we actually have to explain users how to change the content directory. This runs contrary to our "stupidly simple" claim. So Pico now simply uses the `content` directory when it exists...
I always thought that doing this is pretty unusual... But now it simply breaks BC - please refer to @Lomanic's [comment](https://github.com/picocms/Pico/pull/260#issuecomment-152610857). Using a return statement has no advantages, but increases the probability that something goes wrong (e.g. a clueless user removes the return statement). It was introduced with 23b90e2, but we never released it ([v0.9.1](4cb2b24fae/lib/pico.php (L188-L189))). Removing the return statement shouldn't cause any problems even for users which installed Pico in the meantime. As a result we don't break BC and moreover remove a prior BC break 😃
Daniel Rudolf
theshka