Remove pull request message

lib/Pico.php

@@ -1,95 +1,5 @@
 <?php
 
-# First of all: Why? The sourcecode of existing forks like BaunCMS and
-# PhilleCMS isn't "stupidly simple" anymore... You can read Picos sourcecode
-# from top to down and even copy&paste programmers will understand what's going
-# on. It's all about "understanding at first glance".
-#
-# Most important second: All changes are 100% backward compatible.
-#
-# I considered writing something own, but then caught up with Pico. The only
-# thing missing was clean code - Picos concept, workflow and code really is
-# "stupidly simple", but very powerful. Actually I just did a code refactoring.
-# [I don't want to fork Pico](https://xkcd.com/927/) and I won't do it even
-# if you reject my changes (obviously I'll still use it myself :smile:).
-#
-# This should be v1.0 ready. I recommend to release it as v1.0-beta, waiting
-# some weeks to test it on a large user basis (I'll fix all appearing problems;
-# btw: being a Collaborator would make this much easier) and finally releasing
-# it as Pico 1.0 :smile:
-#
-# Please give me a hint if you'll merge this, I'll then update the homepage
-# (`gh-pages` branch) accordingly.
-#
-# What did I do?
-# - Fixes #79, Closes #93, Fixes #99, Closes #103, Closes #116, Fixes #140,
-#   Fixes #158, Closes #171, Closes #241, Closes #244, Closes #246, Fixes #249
-# - The code is now documented, code styling follows PSR. Pico superficially
-#   grows from 400 LoC to 900 LoC, when removing all comments, Pico grows from
-#   300 LoC to 450 LoC, mostly because of new public getter methods (= 50 LoC)
-#   and PSR code styling. As said, there are no big functional changes, it's
-#   more a code refactoring.
-# - The new routing system now works out-of-the-box (even without rewriting)
-#   with any webserver using the QUERY_STRING routing method. Internal links
-#   now look like `?sub/page`, rewriting to basically remove the `?` is still
-#   possible and recommended. Contrary to Pico 0.9 every webserver should work
-#   just fine. Pico 0.9 required working URL rewriting, so if you want to use
-#   old plugins/themes/contents, a working rewrite setup may still be required.
-#   If you're not using the default `.htaccess`, your must update your rewrite
-#   rules to follow the new principles. Internal links in content files are
-#   declared with `%base_url%?sub/page`. Internal links in templates should be
-#   declared using the new `link` filter (e.g. `{{ "sub/page"|link }}`), what
-#   basically calls `Pico::getPageUrl()`. You musn't change anything if you
-#   setup rewriting (what was required in Pico 0.9...), so I assume this to be
-#   fully backward compatible :smile:
-# - I've implemented a whole new plugin system while maintaining full backward
-#   compatibility. See the class docs of `IPicoPlugin` for details. The new
-#   event system supports plugin dependencies as well as some new events. It
-#   was necessary to reliably distinct between old and new events, so all
-#   events were renamed. The new `PicoDeprecated` plugin is crucial for
-#   backward compatibility, it's enabled on demand. Refer to its class docs for
-#   details.
-# - The file extension of content files is now configurable
-# - Heads up! #158 is fixed only when the `PicoParsePagesContent` plugin isn't
-#   enabled. It's disabled by default, but gets automatically enabled with
-#   `PicoDeprecated` as soon as an old plugin is loaded. This is necessary to
-#   maintain backward compatibility. You can still disable it manually by
-#   executing `$pico->getPlugin('PicoParsePagesContent')->setEnabled(false);`
-#   or adding `$config['PicoParsePagesContent.enabled'] = false;` to your
-#   `config.php`.
-# - The meta headers are now parsed by the YAML component of the Symfony
-#   project (see #116), but still requires you to register new headers during
-#   the `onMetaHeaders` event. I'm uncertain about still requiring that. What
-#   do you think?
-# - Meta header variables are now accessible in content files using `%meta.*%`,
-#   so you mustn't repeat yourself. You can now put an excerpt into the
-#   `description` meta variable and output the same content at the beginning
-#   of the article using `%meta.description%`.
-# - I decided explicitly to NOT implement pages as objects ("stupidly simple",
-#   see above). Anyway, I think plugin developers shouldn't manipulate data in
-#   "wrong" events, this could lead us to unexpected behaviour. Sure, plugin
-#   developers still can do this, we're passing variables by reference, but
-#   it's not that obvious. I even thought about dereferencing the values after
-#   the corrosponding event was called, but that would be backward incompatible.
-#   What do you think?
-# - How to fix the "composer problem" discussed in #221 and #223? There's a
-#   very simple solution: When creating a release on GitHub (after you've
-#   pushed the tag) you can upload "binaries". Simply execute composer locally,
-#   create a ZIP archive and upload the result as "binary".
-# - I didn't care much about #110, #238, #239 and #240 because I simply don't
-#   need these features. But I think they are good ideas and the core should
-#   support this. Just my 2 cents :smile:
-# - #201 and #231 should be closed - this can easily be achieved with plugins.
-#   In fact, there are already plugins adding support for these features...
-# - Imo distinct documentations for users, theme designers and plugin devs is
-#   MUCH more important than unit tests... Pico is a project with just about
-#   500 LoC (+ comments), such a manageable project doesn't necessarily require
-#   unit tests - they are nice to have, but that's it. Documentation should be
-#   the top priority!
-# - Note: I'm no english native speaker. Maybe someone should look through my
-#   code comments :smile:
-#
-
 /**
  * Pico
  *