Intro to TYPO3 v8

By Anu Bhuvanendran Nair on November 25, 2016

typo3

Hi Folks,

It’s been around a few months after the release of  TYPO3 8.3. With a constantly working team like the developers in TYPO3 development association under the leadership of Mr. Benjamin Mack, this pace is nothing… And yeah, I am happy!! Being one of the  500,000 developers working with TYPO3 CMS, I am really happy. !

It’s been around a few months after the release of TYPO3 8.3. With a constantly working team like the developers in TYPO3 development association under the leadership of Mr. Benjamin Mack, this pace is nothing… And yeah, I am happy!! Being one of the 500,000 developers working with TYPO3 CMS, I am really happy. !

First and foremost TYPO3 is a Content Management System, initially written by Mr. Dane Kasper Skårhøj (The Hero!!) in 1997. After sprinting through a long range of versions, TYPO3 currently reached its final stable version 8 series. With a whole lot of new revamped features…

All in all, more than 900 patches made it through their review process and have been merged to the master branch since the release of CMS 7 LTS in November 2015 as there newsletter reports.

It’s my pleasure to share some of these innovations with you all… Let’s see…

BACKEND USER INTERFACE

Now you can recover pages recursively to top of rootline. The Recycler supports the recursive recovery of deleted pages to the top of the rootline now. This amazing feature is available for admin users only due to internal permission restrictions.

The new wizard component is super cool. This component aims user-guided interactions. There is no need to save and reload the newly created content element anymore in order to be able to open the wizard. This is a huge usability improvement. It’ll be cool if we can set an alternative backend logo via Extension Manager, right? It’s no dream anymore. The backend logo in the upper left corner can now be configured in the extension configuration of EXT:backend in the Extension manager.

Configuration options are:

  • resource as a relative path of the TYPO3 installation

e.g. “fileadmin/images/image.jpg”

  • path to an extension

e.g. “EXT:my_theme/Resources/Public/Images/image.jpg”

  • an external resource

e.g. “//example.com/image.png”

Additionally to the usual drag and drop feature in the page module (that moved content elements), it is now possible to create copies: press the CTRL key while dropping to create a copy of the dragged element. After dropping is complete, the page module will reload to make sure the new element will be generated with all necessary information. I always thought about more handy shortcuts… Hmm… Interesting.

EMBRACE PHP7 SUPPORT!!!

After the release of PHP 7, it was a total headache managing TYPO3 platform with around many extensions. Incompatibilities, deprecations, patches, uncaught exceptions… Phew…!!

Hours of effort was needed to figure out the issues and sometimes… Yeah! Things turned messy!!

But, worries away… PHP 7.0 is the minimum requirement for version 8.They also promised that TYPO3 will support subsequent PHP 7 releases as they come out.

And you guys won’t believe the significant performance improvement achieved by the overall system with this version upgrade. Records say, load time for a full cached page call in the frontend is below 7 milliseconds now, which is approximately 40% faster compared to running the very same website with older versions of PHP.

TYPO3 also started using new features from PHP 7 such as the cryptographically secure pseudo-random generators.

Ahem… By the way, a pseudorandom number generator (PRNG) is an algorithm for generating a sequence of numbers whose properties approximate the properties of sequences of random numbers.

For instance, random_int( int $min , int $max ) in PHP 7 generates cryptographic random integers that are suitable for use where unbiased results are critical, such as when shuffling a deck of cards for a poker game.

However they gave enough time to the extension authors to rewrite or tweak their extensions for PHP 7.

Hats Off to the speed improvement…

Good bye to incompatibility…

and

EMBRACE THE CHANGE!!!

BUILT IN FORM EDITOR?? NO WAY…

Believe it or not. We’ve waited long enough for a built in form editor, as tired of using third party extensions like powermail (One of the super best of this kind) to design forms. TYPO3 8 comes with a built in form editor. It was a leap of faith they took, after the team included ‘fe_login’ extension as a system extension few versions back.

Form building is now implemented as a system extension, ‘form’ which can be manipulated as any same old content element… Much easier to use and less pain suffered. TADAAA…

Team also teased that we will see further improvements of this kind in the future.

typ

FLUID… ATLAST BROKE THE CHAIN & BECOME FREE

TYPO3’s very own templating engine Fluid – which was initially implemented as a back-port from the FLOW framework is at last free from the hands of TYPO3 and is standalone now.

Now, with version 8, they are proudly presenting a both fast and reliable templating engine for any PHP-based project without big dependencies on its own. The old Fluid extension is converted to a so-called Fluid adapter which allows TYPO3 CMS to use standalone Fluid.

Many new features & capabilities have been added in nearly all areas of Fluid.

Team stated that, ‘Fluid standalone can be easily used within other PHP frameworks like Laravel and Symfony and we’re looking forward to hearing about success stories.’ A big round of applause for that words…

TYPO3 started standalone fluid’s development during CMS 7, but didn’t make it into the LTS release.

Switching to fluid standalone brings a list of incredible new features to TYPO3 CMS that integrators will be very pleased about.

Most importantly: several of the Fluid components which were completely internal and impossible to replace in the past, are now easy to replace and have been fitted with a public API.

Fluid now supports any degree of complex conditional statements with nesting and grouping:

<f:if condition="({variableOne} && {variableTwo}) || {variableThree} || {variableFour}">
 // done if both variable one and two evaluate to true,
// or if either variable three or four do.
</f:if>

In addition, f:else has been fitted with an “elseif”-like behavior:

<f:if condition="{variableOne}">
<f:then>Do this</f:then>
<f:else if="{variableTwo}">
Do this instead if variable two evals true
</f:else>
<f:else if="{variableThree}">

Or do this if variable three evals true

</f:else>
<f:else>

Or do this if nothing above is true

</f:else>
</f:if>

A few new ViewHelpers have been added as part of standalone fluid and as such are also available in TYPO3 from now on:

f:or  -> This is a shorter way of writing (chained) conditions. It supports the following syntax, which checks each variable and outputs the first one that is not empty:

{variableOne -> f:or(alternative: variableTwo) -> f:or(alternative: variableThree)}

f:spaceless  -> This can be used in tag-mode around template code to eliminate redundant whitespace and blank lines for example caused by indenting

ViewHelper usages.

New fluid also allows default content on optional f:render.

Whenever f:render is used and flag optional = TRUE is set, rendering a missing section results in an empty output. Instead of rendering this empty output, a new attribute default (mixed) is added and can be filled with a fallback-type default value. Alternatively, the tag content can be used to define this default value like so many other content/attribute-flexible ViewHelpers.

<f:section name="MyWrap">
<div>
<!-- more HTML, using variables if desired -->
<!-- tag content of f:render output: -->
{contentVariable -> f:format.raw()}
</div>
</f:section>
<f:render section="MyWrap" contentAs="contentVariable">

This content will be wrapped. Any Fluid code can go here

</f:render>

 Doctrine DBAL

The TYPO3 Database Abstraction Layer (DBAL) was tightly bound to the DatabaseConnection class that one could reliably find in $GLOBALS[‘TYPO3_DB’]. BUT and that’s the big news the Doctrine DBAL library is also there. It is heard that TYPO3 is officially supporting it and has moved all database calls from $GLOBALS[‘TYPO3_DB’] to the doctrine syntax.

 Here is how a SELECT query looks like the doctrine way. Let’s find all backend users that don’t have the uid 1 and whose usernames don’t start with “_cli_”:

/** @var QueryBuilder $queryBuilder */
$queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)->
getQueryBuilderForTable('be_users');
$users = $queryBuilder
->select('*')
->from('be_users')
->where($queryBuilder->expr()->neq('uid', 1))
->andWhere($queryBuilder->expr()->
notLike('username', $queryBuilder->createNamedParameter('_cli_%')))
->orderBy('username')
->execute()
->fetchAll();

Since it is now possible to have multiple databases behind your TYPO3 you get the connection on a per table base with getQueryBuilderForTable($tableName).

FAREWELL DEPRECATIONS…

This time… they really mean it. Development team removed every deprecated peace of code from the core. Hmmm… Well, I remember like yesterday when I coded my first extension and was like… ‘What?! It’s deprecated? Then, why is it still here??’

Any way congratulations, lucky co-developers!!!

According to the team, Getting rid of all the junk code not only streamlines code sections and opens the view to further improvements, it also sharpens the coding interfaces and improves performance. Well said.

They are planning a relaxation period for the extension developers by giving chance to fix remaining deprecation issues within their extensions now, long before the future final v8 LTS version, which is to be released in April 2017. Doing this work now gives extension authors a rather relaxed time for the rest of the year since from now on only dedicated areas within the core might receive further breaking changes, and only if inevitable from a core point of view.

Release note talks “…So, extension authors: Start your engines, join the race! Your input and feedback in an early stage is crucial.”

The following configuration options have been removed:

$TYPO3_CONF_VARS[’SYS’][’t3lib_cs_utils’]
$TYPO3_CONF_VARS[’SYS’][’t3lib_cs_convMethod’]

(Functionality is now auto-detected and mbstring is used by default if available)

The deprecated TypoScript property page.includeJSlibs has been removed. Use the TypoScript property page.includeJSLibs (capital “L”) instead. The TypoScript option config.renderCharset, which was used as character set for internal conversion within a frontend request, has been removed.

According to their roadmap, their plan goes this way

  • v8.3 30/Aug/2016 Frontend Editing on Steroids
  • v8.4 18/Oct/2016 to be determined
  • v8.5 20/Dec/2016 Integrator Support
  • v8.7 04/Apr/2017 LTS Preparation
  • v8.6 14/Feb/2017 to be determined

v8 also provides native support to symfony console. But the real deal is they replaced the old school password hashing algorithm & introduced ‘PBKDF2’ (Password-Based Key Derivation Function 2) algorithm to system extension ‘saltedpasswords’. Geeks say that this algorithm is designed to be computationally expensive to resist brute force password cracking.

Good news is that, team removed ExtJS from TYPO3 core & introduced tree rendering based on SVGs.

ImageMagick/GraphicsMagick was always a pain. So in addition, references to specific versions of ImageMagick/GraphicsMagick have been removed from settings names and values.

So that’s it readers… We can now ‘start our engines’ and wait for more by exploring the latest, as the motto for TYPO3 v8 says..

Hail TYPO3!!!

– Anu Bhuvanendran Nair

One response to “Intro to TYPO3 v8”

Leave a Reply

SCROLL TO TOP