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.
The vendor directory is the installation path of the `picocms/Pico` package. If `picocms/Pico` is the composer root package (as in pre-bundled releases), it should be identical to `Pico::getRootDir()`. However, if `picocms/Pico` was installed as composer dependency (e.g. by `picocms/pico-composer`), the vendor directory usually corresponds to something like `Pico::getRootDir() . "vendor/picocms/pico"`. The vendor directory is currently only used as a last resort to load Pico's sample contents.
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`.
Daniel Rudolf