Don't lower unregistered meta headers on the first level unsolicited (e.g. `SomeNotRegisteredKey: foobar` in the YAML Frontmatter should result in `['SomeNotRegisteredKey']`, not `['somenotregisteredkey']`). Furthermore, Pico no longer compares registered meta headers in a case-insensitive manner. However, you can now register multiple search strings that are used to find a registered meta header. This is achieved by flipping the meta headers array: Pico 2.0 uses the array key to search for a meta value and the array value to store the found meta value. Previously it was the other way round (what didn't make much sense...).
In the future we'll use picocms/pico-composer to create Pico's release packages (and picocms/pico-composer depends on picocms/pico-deprecated and picocms/pico-theme by default). Installing picocms/pico-deprecated and picocms/pico-theme is no longer required, but rather suggested. You simply don't need them in any case. You need picocms/pico-deprecated only if you're using old plugins, and picocms/pico-theme is obsolete when using a 3rd-party theme.
The performance vs. error-proneness trade-off doesn't justify this additional complexity. This is Pico 2.0, we always try to minimize BC-breaking changes, but we're breaking BC anyway by loading plugins from plugins/<plugin name>/<plugin name>.php only...
You can now explicitly specify both the `date_formatted` and `time` meta values to overwrite Pico's page date handling. Specifying `time` doesn't make much sense in general, however, specifying `date_formatted` allows you to use `{{ meta.date_formatted }}` on all systems, even those where `strftime()` doesn't work as wished
Due to the fact that Travis uses a shallow clone of Pico's Git repo, composer has no chance to detect on which branch it currently is. This was no big deal with Pico 1.0, however, Pico 2.0 depends on picocms/pico-deprecated and picocms/pico-theme. We use composer's `self.version` version constraint to sync the version numbers of these separate Git repos. Thus composer must know Pico's current version to resolve these dependencies. We try to guess the current version either using known branch aliases in Pico's `composer.json`, or using the `Pico::VERSION` constant (see `_build/install.sh`).
Pico doesn't require the PHP extensions itself, but erusev/parsedown-extra does. The explicit composer.json requirements are necessary until erusev/parsedown-extra#85 gets merged. Both extensions aren't part of Ubuntu's default LAMP setup anymore.
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.
Daniel Rudolf