Tech Blog

Twig and ECT files in the AEK

JavaScript, CSS, React, these are all phrases that are recognised by web developers. The file formats that are used for the server-side structure of the AEK are a bit more obscure. This post aims to explain a little bit about them and give some best practises on what they can be used for.

What is Twig

Twig is is a templating language for PHP. We use it to surface some of the PHP functionality that developers might find useful, as well as structure things like AEK Actions. We don’t use all of Twig – do refer to the documentation at for more information on how to use it in the AEK.

What is ECT

ECT is a a templating engine for JavaScript. This is mostly used under the hood, you’re not expected to have any knowledge of it for AEK development. You’ll see a master.ect file in any AEK project; combined with the top-level project ECT file this handles the setup for you.

Everything else a developer might need in an ECT file is handled in the Server Docs, under Setting up the ECT for use. You can write Twig markup inside the ECT file and it will be processed correctly; no ECT markup is actually required.

Best Practises

The server-side in AEK is best used for handling API calls that can’t be handled on the clientside, whether it’s because of CORS or other access-related issues, or it requires confidential attributes like API keys.

It isn’t designed to handle advanced parsing of a service response – it does have legacy string manipulation functions built into it, but these aren’t recommended and are vastly improved on by what clientside JavaScript now offers. A lot of these date back from when the AEK was in its infancy and we didn’t even have an embedded JavaScript library!

A good way to manage a codebase that requires a lot of services or calls out to an API is to separate out this logic into different files. To take an example of your project’s main ECT file, after adding the init block (linked in “Setting up the ECT for use”) you could import a separate Twig file to exclusively handle AEK Actions, or even a subset of AEK actions. This lets you group your API calls sensibly and ensure that any parameters you require can be sensibly managed from within a single file, as supposed to having a list of hostnames or other service-specific data at the top of a very long ECT file.

<< block 'init': >>

  << include "includes/actions.twig" >>

  {# any other Twig code or imports you need here #}

<< end >>

All this requires is for you to add a folder (in this case called “includes”) and an actions.twig inside it with all the Twig logic you want to put in that file.

Leave a Reply