V7 Introduction

XalokNext:7 comes with a rewritten editor/SSR, using VueJS with a Vuex store.

The templates for v7 are being written using twig files, containing plain HTML annotated with wf-* attributes (called wf-html throughout the docs) - these wf-* attributes are being called wf-directives:

<div wf-role="main_image"
     wf-new
>
  <img wf-filter="thumbnail" />
</div>

If you have been using a previous version of XalokNext, the Upgrade templates from v3-6 page lists some of the differences.

In a XalokNext project, the App/Bundle/CmsBundle/Resources/views/Template directory holds the templates that are being used to build blocks of content that are editable through the UI. One or more article templates can be defined, their respective wf-html should be placed in the App/Bundle/CmsBundle/Resources/views/Template/Article directory.

Besides being able to edit article contents, XalokNext allows defining editable blocks of contents called boards - their wf-html should be placed in the App/Bundle/CmsBundle/Resources/views/Template/Board directory.

You can read the wf-html page for an introduction into wf-html, the Using wf-directives page for a more complete list of the built-in wf-directives and the Template filters page for some Javascript functions that can be used to format values in the wf-html. One can write custom wf-directives to further enhance the possibilities of XalokNext based on the particular requirements of the project. Besides modules and wf-directives, inside the templates you can embed custom Vue components to dynamically control parts of the template. The Cookbook section provides some examples of how implementing different customizations can be achieved.

Twig is being used for wf-html to leverage the twig templating language capabilities:

• extend other templates: e.g. the Article/default-amp.html.twig extends Article/default.html.twig, as it's almost identical to it, overwriting only the parts that are different)
• translate strings: 0)
• include other twig files - the most notable example being including twigs from App/Bundle/CmsBundle/Resources/views/TemplateModules.

It's important to know that the twig files themselves are not being used at runtime (when rendering an article/board), rather, they are being downloaded by either make wf_assets (in the CI environment) or by the wf-assets-watch gulp task that is included as part of make dev. Either of these tasks download the files as static html (in web/bundles/wfcmsbaseadmin/javascripts/html_template directory), from here they are picked up by webpack that bundles them together with the rest of the JS code, where they're being used. Some details can be found here.

There are two instances of webpack that XalokNext uses for the backend part: one for the client (browser), used to edit the contents, another one for the server side rendering (SSR), used when rendering the contents for the public side.

The state of the application is managed internally through Vuex, XalokNext adds some methods to ease extending base functionality, read more details in its dedicated section. Most of the actions dispatched in the application refer to a module, it's likely that extending the Vuex store implies making some changes to a module, or reacting to changes done inside a module. You can find more details about them in the Modules section.

The v7.1 version is a continuation of XalokNext v7. The most notable change is a refresh of the design of the admin interface, the dashboard and the article editor are now responsive. Besides this, the v7.1 introduces wf-components, a way to share code between multiple wf-html templates. You are encouraged to use them instead of traditional twig {% include "@AppCms/TemplateModule/your_module.html.twig" %} since this can lead to big improvements in the compilation of webpack.

Finally, this version comes with some tools that should aid developers. First, there is __PUBLIC_URL__/developer (or, since all public routes are imported in the admin with the /view prefix, __ADMIN_URL__/view/developer) that lists a collection of tools that should come in handy at various stages of the development. The most interesting addition in this area being the Cache Manager UI, a UI aimed to aid debugging ESI fragments and cache tags.

Also, the modules' toolbars show a debug button - when clicked, it logs to the console a list of variables that can be used inside that module's template. See Disabling the debug module toolbar button section for details on how to disable this in production.