In June 2020, I met with a group of people from the TYPO3 community to brainstorm about version 2.0 of the Frontend Editing extension. I presented my thoughts and we added items to a wish list. We also set up a working group that will help with testing, ideas, and maybe development. Feel free to join.
A major release is the time for breaking changes. Support for TYPO3 v8 will be dropped and the code cleaned up, but there was also much positivity around moving the functionality into the backend—a development time-saver, but also a way to bring the user interface closer to the TYPO3 standard.
Nobody knows the exact 2.0 change list yet, but the plan is to first make the big changes and later add new features in minor versions. Maybe we’ll see a 2.0 release around New Year.
Current State and Road Ahead
Developing the Frontend Editing extension is a journey of discovery. It is now 18 months since I published my first release as the new project lead. My focus has been bugs, speed, and user experience. My perspective: We have production-ready Frontend Editing today, but we’re only at the first milestone on a much longer journey.
Some of the things that make TYPO3 so great—the clear data/view separation and Fluid templates—is also making it hard to give frontend editing a real plug-and-play feel. You have to manually configure your templates for Frontend Editing. That is because the templates don’t know where record and field property data is coming from.
Frontend-editing-approaches like Gutenberg have been released for Wordpress and Drupal, but the Gutenberg approach takes a shortcut we will not do in TYPO3: All the editable content is placed within a single rich-text-editing field, mixing both data and view information. It removes the benefit of structured data, affecting scalability, maintainability, performance, etc. (You might remember a related problem with TemplaVoilà a number of years back.)
The solution is out there, and luckily some great people in the Structured Content Initiative are chewing on related problems. Maybe the solution is value objects, extending Fluid, or implementing non-intrusive template pre-processing? Who knows.
Primary Objectives: Move to Backend, Maintenance, and Tests
You have to break some eggs to make an omelet. Frontend Editing 2.0 will do just that. The first release has three primary objectives that will shift around on a number of things, but also prevent bugs and lower the maintenance effort:
Frontend Editing in a Backend Module
Imagine the View module with editing capabilities. Over the last few releases, the responsive TYPO3 backend has made it possible to hide almost the entire user interface. To see an entire frontend page, you can easily minimize the module list and hide the page tree.
This gives more benefits:
- No need to maintain a separate page tree implementation.
- Using existing user interface design and conventions.
- Fewer custom resources and faster page loads.
- Narrowing down development focus to making the best possible editing experience.
Leaner code is both faster to execute and easier to maintain. Removing support for TYPO3 v8 and moving into the Backend does some of the job, but splitting up class methods (some spanning 200 lines of code) will mean easier contribution and debugging too.
Improved Test Coverage and CI Workflow
Frontend Editing hooks into the TYPO3 API in places few other extensions do. There is a lot of back and forth involved in adding the frontend editor’s bit of magic. This meandering control flow easily introduces bugs.
The cleaner code will make it easier to write unit and functional tests for the extension. With a new and more comprehensive testing regime in the CI workflow, problems will be easier to detect and fix. The result: Better stability and less time spent fixing bugs of unclear origin.
More From the Wish List—Contributions Welcome
My biggest wish is to increase the number of contributors and contributions to Frontend Editing. Contribution could mean anything from writing code, to testing, to sponsorship. You should not hesitate to make contact in the #frontend_editing channel in TYPO3 Slack.
These are some of the things on the wish list:
- Reduce perceived load time by showing progress and active task information on the load screen.
- Make Frontend Editing work out of the box, without modifying templates.
- Reduce the need for mouse movement when editing.
- Evaluate the use of drag-and-drop vs. a +-button like in Gutenberg.
- Move text styling buttons closer to the text being edited.
- More closely connect fields to available style choices. For example, header text alignment is stored in a separate database field.
- Drag and drop images to add them to the page.
Do you have more ideas? Make a feature request on Github or discuss it in TYPO3 Slack.
What’s All the Fuss About Frontend Editing?
Frontend editing is an important feature for beginner editors—and decision makers. In other words: Easy onboarding makes TYPO3 easier to sell. Buyers are being told to look for it. Here’s a few examples I found when searching for CMS decision factors:
- “WYSIWYG (What You See Is What You Get) Editors and inline editing are basic requirements of any modern CMS platform”—Mike Johnston at CMSCritic.
- “You need everyone in your operation who will be working with the system to have enough of an understanding of how it works to do their jobs, particularly such often-used areas as inline editing.”—Bayshore Solutions.
You may argue that ease of use isn’t everything, and I agree, it’s not. However, “CMS vendors of course trumpet their software’s ease of use.” (Jeff Cram at CMS Myth.) We can’t expect clients to always see beyond the marketing fluff. The popularity in other CMSs shows that it's a useful editing feature, and not just a marketing checkbox. It's time to make our favorite CMS even more editor-friendly.
We don’t own the definition of “easy”—and some editors don’t need more than click-and-write—even though the project needs an enterprise CMS.
Thanks to everyone who helped review this article. Especially Paul Hansen, who also proofread it.