Improving Developer Adoption in TYPO3

TYPO3 Core Lead, Benni Mack of b13 (a TYPO3 GmbH partner) talks about how he hooked into the PHP Framework Interoperability Group, and what it means for the project. Getting involved with FIG has put TYPO3 in a position to innovate and collaborate with other PHP projects. TYPO3 is now easier to learn because it uses shared abstractions and widely used standards. This also opens up creative potential for TYPO3 developers.

The PHP Framework Interoperability Group (PHP-FIG) is a group of individuals who work together to create PHP Standard Recommendations (PSRs). PHP-FIG includes participants from projects including frameworks and CMSs: Symfony, Laminas (formerly known as the Zend Framework), Drupal, Joomla, phpBB, ezPublish, and TYPO3.

Together, they negotiate a representation of the best practices for interoperability between PHP-based projects, written as ‘recommendations.’ FIG was founded in 2009 as the "PHP Standards Group," before being renamed to the Framework Interoperability Group in 2011. It has gone through a few different structures as it has evolved, with the current structure and workflow dating from 2016. FIG includes both member projects and an elected "Core Committee" of senior PHP architects from around the community that oversee different Working Groups that develop specifications. Larry Garfield offers a brief history of FIG up to 2016 in The Past, Present and Future of the PHP-FIG, published by SitePoint.

Over the last decade PHP-FIG has evolved by creating a way for people from a range of PHP projects to exchange and make use of shared abstractions. PHP-FIG itself is a demonstration of interoperability between projects. 

The proposals have unlocked new capabilities across the PHP landscape only possible with shared approaches and abstractions. Middleware is an example of one such functionality made more robust by these recommendations.

As a project, TYPO3 has adopted a number of PSRs that define best-practices for PHP projects, starting with the early, easy wins in coding standards (PSR 1 & 2) and autoloading (PSR 0 & 4) and kicking the TYPO3+PSR era into high gear in TYPO3 v7 with the PSR-7 HTTP Message Interface. 

TYPO3 v7 LTS, launched in 2015, was the first TYPO3 core to make use of the Interfaces defined by PHP FIG recommendations, with PSR-7. Benni admitted that when they included PSR-7, he felt even he didn’t fully understand it, “because I’m not a superhero in PHP.” But that provided a learning opportunity. “That’s what’s cool about PSRs, you gather all the knowledge that is current out there, and find the base common ground, and you can learn what crazy things they do with it.”

Benni was inspired by watching PSR-7 (HTTP Message Interfaces) evolve. “One of my personal heroes is ‘mwop’, Matthew Weier O'Phinney,” maintainer of the PHP framework Laminas. Matthew’s individual work that became common ground for PSR-7 gave Benni the idea of how he could get involved, too. 

At the time, the TYPO3 core team was still looking at how they could improve ‘hooks’ in TYPO3. “It took me 2-3 years to come up with a solution for TYPO3 and it just didn’t feel right as a replacement for hooks.” Benni wondered how other CMSs and frameworks were handling event dispatchers, but after looking, he concluded “they didn’t have a solution either.” 

In fact, a proposal for PSR-14: Event Dispatcher had already been proposed in FIG but nothing had come of it so far. Without the energy and impetus behind great ideas they might never come to fruition. Benni wanted to jump in and help get it moving again.

Larry told me that “FIG rules require a working group of at least 5, so we needed a working group together before we even could call for an entrance vote. It was an easy vote once we had the group together.”

Benni said getting a group together of people from a variety of projects was important. “The FIG core committee tries to make sure there’s a diverse group of frameworks or CMSs, and to encourage having a lot of feedback. We have people in the group who are closer to PHP core and PHP development to see what is possible in which versions.”

PHP-FIG’s recommendations should be innovative, but not ‘too innovative.’ One of the challenges for PHP-FIG is to find a way to make innovative solutions that will still be usable across many projects and frameworks. “Because everyone is doing things based on a certain way for the last five years because they needed a solution five years ago. It doesn’t mean it’s the best now. PHP can do even more nowadays.” 

During the project the participants dug into researching other programming languages, for example Benni looked at how .NET extended libraries. Together, they came up with ideas and created proofs-of-concept which evolved into the final recommendation.

Back in July 2019, TYPO3 v10.0 introduced PSR-14, with more supported events coming in over the next sprint releases. TYPO3 core now had an event dispatcher that was interoperable “with the same API” as Laminas (formerly Zend Framework) or Symfony's EventDispatcher Component. Overall it’s been a successful process and outcome. PSR-14 is already supported by major frameworks and applications including Laminas, Symfony, Yii, and TYPO3. 

Larry Garfield, the editor of the recommendation, wrote about the experience of developing PSR-14.

“Despite being the largest group I've worked with it was also overall one of the most pleasant collaborative experiences I've ever had. The process was highly collaborative and deliberative throughout, which is as it should be. I am really happy with how it turned out in the end; may all our future endeavors in collaborative architecture be as productive.”

“TYPO3 is the first CMS to go all-in with PSR-14,” said Larry in an interview by Platform.sh with TYPO3 community members. (Definitely give that a watch on YouTube!)

“PHP-FIG is not a framework itself,” Benni emphasized. “It is important to say that this is a recommendation, it’s not even a standard itself. It’s a recommendation. And implementing these recommendations doesn’t mean a project is better or worse than others.”

Benni said there are advantages in applying these recommendations in projects. “Some problems that the PSRs address are things we didn’t have solutions for before. If you have a lot of big brains working together, you can find good solutions.”

Benni sees moving to more widely adopted standards has potential to improve usability for programmers and make it easier for new developers to adopt TYPO3. “We’re narrowing the gap for people who already use PHP, Symfony, Doctrine. Otherwise, as a newcomer you’d have to learn all these unique things like TypoScript and Fluid.” 

And he’s got a point: a major aspect of usability is learnability. A system that is already familiar to a developer is going to be inherently easier to learn. A corollary in terms of TYPO3’s well-regarded interface usability is that the page-tree system is “intuitive” because people have been using hierarchical tree-based file browsing and management systems already. 

Adopting familiar approaches and methods implies that TYPO3 will have a lower cognitive load for newcomers experienced with other PHP frameworks. A lower cognitive load means there’s less mental effort required to learn something new. 

The flip side is that experienced TYPO3 developers would have to learn new methods to solve old challenges. There is a new learning curve for them, but in the end they can expand or update their toolset. 

TYPO3 developer, Xavier Perseguers @xperseguers explained what this meant for TYPO3:

I reached out and asked Xavier what could the downsides be for experienced TYPO3 developers as these changes are brought in. “I'm one of those devs who program and want my stuff to basically run for many years, not just a few months and forget about it.” Many developers don’t like deprecations. They have legacy code-bases to manage, after all. Xavier said “All those PSRs are great to streamline how devs program… but are only in some ways that couldn't be done ‘before.’” 

For developers to take the effort to learn something new, there has to be a creative advantage.

TYPO3 adopted PSR-15, HTTP Server Handlers for middleware starting in TYPO3 v9 and it was further expanded in TYPO3 v10. Benni feels this has opened up new creative possibilities. “TYPO3 has adopted other standards, like the auto-loading, composer, and coding guidelines which are nice, but not really as important for architectural possibilities.” 

“I have built TYPO3 extensions that use SlimPHP,” a framework built mostly on the recommendations from PSRs. Check out the SlimPHP bridge on GitHub to see an example. “It’s helping me build REST APIs.” It’s one way you can build a headless-like implementation on top of TYPO3 with custom REST APIs, but as the README file says “It is not meant to become a fully headless solution for TYPO3 as a CMS.” 

Behind the scenes, PSR-15 got really out-of-the-door for TYPO3 through Daniel Goerz (working at b13) by writing his blog post, PSR-15 Middleware in TYPO3. 

TYPO3 Documentation Team member, Daniel Siepmann, wrote about the new possibilities with TYPO3 v10, for example to track system events on the server side. He built an extension (viewable on GitHub) as a proof of concept, to “demonstrate technical features of TYPO3” that implements PSR-15, PSR-7, PSR-11 and ext:dashboard, demonstrating dependency injection, Middleware, and Request / Response.

Shout out and big thanks to Daniel Goerz, who, according to Benni, really got PSR-15 “out-of-the-door” for TYPO3: PSR Middlewares in TYPO3.

Before TYPO3 v10, the same capabilities were achieved through TYPO3’s unique solution of Extbase’s SignalSlot and TYPO3’s custom hook system. You can still use these in TYPO3 v10, but in v11 these will be deprecated in favour of PSR-14.

Documentation includes a list of core PSR-14 events. And there are details on what goes into the new Event Dispatcher.

• Events - a message, any PHP object.
• Listeners - sometimes called an observer or subscriber, registered via YAML. 
• ListenerProvider - collects all the listeners.
• EventDispatcher Object - executes registered listeners. 

There are also steps in TYPO3 docs for implementing an event listener in your extension. Larry’s PSR-14 series (linked at the bottom of this article) explains the recommendation further and includes six examples as proof-of-concept.

The TYPO3 community was quick to adapt with PSR-14. As soon as TYPO3 v10.2 came out the community got to work understanding the new possibilities. Kudos should go to the many extension developers and contributors who kept pace with development and had support for v10 early on. 

TYPO3 extension maintainers quickly incorporated support for PSR-14 in their v10-dev extensions. For example Chris Müller, TYPO3 developer and extension maintainer, announced support for PSR-14 events in his Schema.org extension a month before feature freeze. 

Watch this video from TYPO3 Developer Days 2019. “Don't get hooked, listen to events! PSR-14.” Benni introduces PSR-14. 

“Event dispatching is really important, not just for us in the TYPO3 world. Every PHP package, if you want people to not just use it, but to also extend it, they need some kind of event mechanism.”  - Benni Mack, TYPO3 Developer Days 2019.

The TYPO3 project was an early mover in adopting standards, which meant the community could benefit from improvements and also be in a position to innovate and contribute.


PHP-FIG has proven to be a great community of practice for people who create frameworks and CMSs. It provides an opportunity for professional development for the participants and a chance to compare and learn from leaders in other fields.