beenull/Pico
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Remove pull request message

Browse source
This commit is contained in:
Daniel Rudolf 2015-08-28 18:24:06 +02:00
parent 92c307d8be
commit cd145821ba
1 changed files with 0 additions and 90 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

90
lib/Pico.php
View file

@ -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
*