This is a BC breaking change!
Manipulating Pico's $plugins array is a really bad idea. We've introduced the Pico::loadPlugin() method to safely load plugins at any time, however, Pico might do unexpected things when loading plugins too late. See the class docs of Pico::loadPlugin() for more details. Nevertheless, this change breaks BC to Pico 1.0. However, I don't know a single plugin that relies on manipulating the $plugins array. If you just want to load a plugin manually, use Pico::loadPlugin() instead.
Add new onPagesDiscovered event passing the unsorted pages array, move the $currentPage, $previousPage and $nextPage arguments from the onPagesLoaded event to the new onCurrentPageDiscovered event, remove the $twig argument from the onPageRendering event and rather trigger the new onTwigRegistered event for this. Also add the new onYamlParserRegistered and onParsedownRegistered events passing the YAML parser resp. the Parsedown instance. Allow plugin's to skip a page by setting the $id argument of the onSinglePageLoading event to NULL.
Instead of using `*.config.php` files, use `*.yml` files to configure Pico. YAML is much easier to understand, more user friendly and (at least a bit) more error-tolerant, but still very powerful. Don't break BC by letting `PicoDeprecated` still read `config/config.php`.
As previously announced (see [Upgrade to Pico 1.0 page](http://picocms.org/in-depth/upgrade/)) we'll remove the default plugins `PicoParsePagesContent` and `PicoExcerpt` with the next Pico milestone. Needless to say, that you can still install both plugins without any problem - we'll add them to Pico's official [Plugins collection](http://picocms.org/plugins/) by then. Please note that the disadvantages of these plugins are still critical and we strongly advise to not use them. Please refer to the [Upgrade to Pico 1.0 page](http://picocms.org/in-depth/upgrade/) for details.
Don't use Pico::getAbsolutePath() for $config['content_dir'], just make sure the trailing slash exists. The config.php in Picos root dir should be interpreted exactly like in Pico 0.9 (the option didn't exist in Pico 0.8), thus the path isn't necessarily relative to Picos root dir
This was dropped without a replacement with Pico 0.9. I checked all changes since Pico 0.8 manually, as far as I can tell there should be no more surprises regarding BC... Thanks @Lomanic for rubbing our nose in the fact that we should check this! I also added the missing changes of Pico 0.9 to changelog.txt
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 😃
