Considering the powerful features Flow 1.1 provided, it was certainly not a slow framework. However, comparing an application or a website running in Flow with an application or a website running in other less feature-full frameworks left the impression that Flow needed to be faster.
We're glad that we could dramatically improve the overall performance with Flow 2.0. Even in simple hello-world scenarios, you can measure a much smaller wall time and memory footprint. TYPO3 Flow's "Welcome" screen is a typical uncached web page based on an uncached Fluid template. While in Flow 1.1 the welcome screen had a wall time of 524 ms, Flow 2.0 only need 26 ms to be delivered.
For all real world projects, that we have heard of, which have migrated to Flow 2.0 during the beta phase, speed immediately turned into a non-issue.
One new feature in particular has made an enormous impact on improving Flow’s speed: Lazy Dependency Injection. Consider a controller which depends on 15 other services. Not all of these are used in every action. And since most of these services may in turn depend on other services which have even further dependencies, you end up loading maybe hundreds of class files which are not needed for the particular action to be executed.
In Flow 2.0 dependencies injected through Property Injection are now "lazy" by default. Developers can uses these dependencies like before, but the instance is created and thus the class file is only loaded when the service is actually used the first time. Apart from a few special cases this process is completely transparent to the developer.
After applying this new feature, one customer reported that his application loaded only a fifteenth of the class files that used to be loaded for specific requests.
Safe Request Methods
The HTTP 1.1 specification states that the GET and HEAD request methods should be considered "safe", which means that they should not do anything other than retrieve information. In Flow 2.0 we now enforce this rule by disabling the automatic persistence for "safe" request methods.
In practice this means, for example, that simple links pointing to a "delete" action will still call that action, but the delete operation will not be persisted to the database. Since we know that there won't be data modifications in "safe" requests, we also don't need to protect links to these actions with CSRF tokens. Or, in other words, links to a “delete” action will not really delete anything, so applications must use another non-safe request method, like POST, if they want the change to be persisted.
In total, this changed behaviour results in even better performance - especially on pages with a lot of links - and gives us more options to integrate even more speed improvements in future versions.
Flow 2.0 comes with a whole new package management layer based on Composer, the de-facto standard for PHP dependency management. Take a few minutes reading the Composer documentation and getting familiar with its concepts. While it takes a few days getting into the new workflow, you will love how much easier it is to use third party packages now. Just look at all the third-party libraries listed on packagist.org and you’ll begin to see some of the amazing possibilities with composer.
While creating a Single-Sign On Client / Server solution based on Flow, we wanted to be able to access and modify remote sessions in a multi-site setup. While PHP's native session implementation does support alternative storage backends, there is no official way to modify this data, except for the currently active session.
Flow 2.0 now provides a clean session mechanism written in pure PHP. Instead of creating a whole new API for the storage, we chose to just rely on Flow's caching framework: that way you can store session data in the file system, APC, Memcache, Redis, PDO compatible databases and more.
The Session Manager now provides additional functions to retrieve arbitrary sessions by identifier or by tags. This way it is possible to tag a session, for example, with a customer number and allow a support team have a closer look at possible problems or even log out a user remotely.
Various changes added even better support for creating and consuming RESTful web services. One important change introduces support for HTTP Method Tunneling: in situations where it is not possible to send a true DELETE or PUT request (or any other request type), it is now possible simulate the request method by sending a POST request either with a "__method" argument or with a special HTTP request header.
Upgrading from FLOW3 1.1
Adjusting a FLOW3 1.1 application to Flow 2.0 only involves a few simple steps. Don't be worried by the fact that virtually all class names have changed due to the new product name – we have an app for that. Flow's code migration parses your code and adjusts it where necessary. All changes are automatically put into a Git commit on its own, so you can review or revert modifications at any time.
Karsten has prepared a comprehensive step-by-step upgrading guide with all important adjustments, including the necessary Doctrine migrations. It can be found in the Upgrading.txt file in the root of your Flow project after installation through composer. For those that are not yet at that point, it is available online as well
Installation with Composer
You can install and upgrade Flow 2.0 through the simple composer commands. Even if you have never used Composer before, does it get any simpler than this?
curl -s https://getcomposer.org/installer | php
php composer.phar create-project typo3/flow-base-distribution flow-base 2.0
This will fetch the 2.0 version of the base distribution into a folder "flow-base". Then it installs all requirements (including the "dev" requirements) recursively.
Upgrading later is done by one command executed inside your project folder.
For more about composer check the composer documentation.
Version 2.0 is clearly an important release for the Flow community. We have many more ideas for future versions and half of the feature work for version 2.1 is already done. Since we follow the semantic versioning scheme (as noted earlier), 2.1 will be fully backwards compatible with Flow 2.0. So, if you have a FLOW3 1.1 application, make the switch now and then enjoy the features to come.
A big thank you to the whole TYPO3 community, with all their developers, documenters, good souls, designers, shoulder patters, event organisers, fundraisers, leaders, editors and evangelists. This release has been a true community effort and the – at times – heavy load has only been possible to carry because of the amazingly positive spirit of everybody involved.
Robert on behalf of the Flow team