New! Our new Issues homepage has the latest issue ticket changes. Follow the latest progress of eZ Publish!


News

eZ Platform 2.3.2 released

eZ Platform 2.3.2 has been released. Check out the release notes on GitHub to see which improvements and/or bug fixes are included in this release.

Sneak Peek eZ Platform v2.4

Amit Golan-Gutin, Product Marketing Manager at eZ Systems, takes a sneak peek into the Rich Text Block.

“With v2.4, editors will be happy to discover that they will be able to easily create a rich body of text, including text, images, and videos, directly in the Page Builder. Our goal is to make editors life easier when they are thinking of creating new content on to the page that is not planned to be reused anywhere else.”

Read the full article here.

Doc Landing Page Makeover

Have you visited our documentation site recently? If not, have a look! You will notice a makeover of the landing page, providing a clear overview of available topics.

Did you know you can contribute to our documentation? The source of our documentation lives on GitHub. Both user doc, and developer doc. And we welcome you to submit pull requests. Or, simply leave a message on our dedicated doc channel on Slack, in case you spot something incorrect or incomplete. Suggestions for improvements are also welcome.

In Other News:

Resources

Webinar Bridging the Gap Between Commerce and Content

Last week, eZ Systems hosted a webinar on the topic of bridging the gap between commerce and content. The recording of this webinar is available on YouTube.

 

Looking for a bundle compatible with eZ Platform? Check out: https://ezplatform.com/Bundles.

Social Media

Follow us on Twitter, Facebook, LinkedIn, Google+, or YouTube, and join our Community for any help with eZ Platform or community-related questions.

Find eZ at These Events

For more events, make sure to check out this list.

Each week we publish a roundup of highlights from the eZ ecosystem. If you have any news or events to share, please contact me.

(Lead image credit: Eva the Weaver, CC)

11/16/2018 11:53 am   ez.no/About-eZ/Blog   Mirror   Link  

Why we created the Rich Text Block

When working in eZ Platform with the Page Builder, two main scenarios occur:

          1. An editor assembles pages from pre-existing content (i.e. article, blogs, galleries, you name it)

          2. An editor needs to create new content for the page they are working on

While the second scenario is possible up through v2.3 of eZ Platform using the Embed block and “content on the fly” feature in the Universal Discovery Widget, it’s still a bit tedious for editors.

We thought there was room for substantial improvement here and decided to reduce the amount of time and steps required for editors to achieve this goal.

That’s where the Rich Text Block comes in. The Rich Text Block lets editors create new content for pages built within the Page Builder in a quicker, easier way, without ever leaving the Page Builder.

We aim at improving the editorial experience wherever we can in eZ Platform. Following many discussions with customers and partners around this new feature, we’re pleased to finally ship the Rich Text Block in eZ Platform v2.4.

How does the Rich Text Block work?

Creating content should be a natural and simple process that does not require too many steps.

The Rich Text Block is a very simple new block for the Page Builder. It lets editors edit the content of the block freely by using the Online Editor, the same as the one used by the Rich Text field type. The user just needs to drag and drop the block onto the page and can then jump straight to using all the features available in the Online Editor.

The content editors create is only available on the page they are working on. (Please note that content created using the Rich Text Block will not be stored as a content item and therefore cannot be reused in different locations).

This means editors can produce content for pages without dealing with additional content items or choosing which content type to use and where to store them. Instead, editors can work directly on the page, without all the extra steps or questions.

As based on the already existing Online Editor, The Rich Text Block comes with all the editorial capabilities that are included with it such as styling, images, links, custom tags and tables. This allows editors to achieve much more than just simple headings or body text.

Let’s take a quick look at how the Rich Text Block works.

Creating content in the Rich Text Block

It is important to note that the Rich Text Block can be customized and extended by developers. All customization regarding the online editor (i.e. configuring custom tags and styling) are done within the editor itself, which means it will be customized for the Rich Text Block but also for any field using the Rich Text field type.

When to use the Rich Text Block

It is helpful to use the Rich Text Block when you do not want to reuse the content you’ve created in different places across your website or elsewhere using APIs. In other word, it’s good for content that is purely and only made for one specific page.

Conversely, if you do want to reuse the content you’ve produced, then we recommend using the Embed Block, which stores all content created as a content item in the content repository.

What to expect in the future

We are very excited for the upcoming release of eZ Platform v2.4. We believe that the Rich Text Block and other features will significantly improve the overall editorial experience. The Rich Text Block will be a great addition to the Page Builder, which was first introduced in v2.2.
In the upcoming weeks, we’ll release a sneak peek at the workflow that is also expected to be shipped with v2.4. Until then, if you’re interested or have any questions, please feel free to leave a comment here or on discuss.ezplatform.com and reach out to us, too, at productmanagement@ez.no.

11/15/2018 11:22 am   ez.no/About-eZ/Blog   Mirror   Link  

Ce texte est une traduction de l'excellent Less Snake Oil, More Context par Surma.

Obtenir de bonnes performances sur le web est un défi permanent. Les développeur·ses essaient et essaieront encore d'en repousser les limites et c'est une bonne chose. Je ne veux pas changer cela.

Je veux changer comment nous — en tant que communauté — approchons, analysons et comprenons les problèmes de performances. Je vois souvent des questions du type « Quel est la meilleure manière de faire X ? », « Quel bibliothèque est la plus rapide pour réaliser Y ? ». Il semble que nous aimions les superlatifs mais lorsqu'il s'agit de performance, ils peuvent être contre-productifs.

Appliquer généreusement la poudre de perlimpinpin aux zones concernées

ou autrement dit « Des règles pas des outils ». Alex Russell a utilisé « Poudre de perlimpinpin » dans un tweet (NDT: Alex Russel étant anglophone, il a utilisé Snake oil) et je pense que cette expression transmet parfaitement à la fois l'opacité et le manque de fiabilité de ce type de traitement.

Quelques exemples :

  • Une animation est saccadée. Utilisez will-change: transform sur l'élément animé.
  • N'utilisez pas forEach(), les boucles for sont plus rapides.
  • Pour une chargement plus rapide, groupez les ressources.
  • N'utilisez pas le sélecteur * car il est lent.

Tout ceci est vrai dans un contexte particulier. Il faut bien comprendre une chose : la lenteur ou une animation saccadée n'est qu'un symptôme, pas une maladie. Ce qui est donc nécessaire ici, c'est une procédure de diagnostique différentiel. La fluidité d'une animation peut être gâchée pour de nombreuses raisons mais il est probable qu'une soit réellement en cause. Par exemple, si l'effet saccadé est causé par le ramasse miette traitant de gros morceaux de données à chaque frame, will-change: transform n'aura aucun effet positif. Au contraire, cette déclaration augmentera la pression sur la mémoire et pourrait même empirer le phénomène.

Je ne me souviens pas qui a énoncé « Si vous ne l'avez pas mesuré, ce n'est pas lent » mais cette phrase résonne en moi même si se concentrer sur la mesure peut mener à la Frénésie du Microbenchmark™️.

Note : pour le reste de ce billet, je vais parler d'optimisations en terme de vitesse mais tout ceci s'applique à d'autres types d'optimisations comme la réduction de l'empreinte mémoire.

Microbenchmarks

J'ai noté que récemment une grande attention était portée vers les microbenchmarks. Dans un microbenchmark, on essaie de départager deux approches en les exécutant plusieurs milliers de fois en isolation pour déterminer quelle solution est la plus rapide.

Comprenez-moi bien, les microbenchmarks ont une utilité, j'en ai même écrit et comme beaucoup d'autres avant moi. Ce sont des outils intéressants en particulier avec des frameworks comme BenchmarkJS qui permet d'obtenir des nombres statistiquement signifiants. En revanche, les frameworks de benchmark ne sont d'aucune aide pour s'assurer que votre benchmark a réellement un sens. Si vous ne connaissez pas ce que vous êtes en train de tester, les résultats peuvent mener à une mauvaise interprétation. Par exemple, dans mon billet sur le deep-cloning, je vérifiais les performances de const copyOfX = JSON.parse(JSON.stringify(x)). Il s'avère que V8 possède un cache d'objets. Le fait de réutiliser la même valeur x fois dans les tests a faussé les résultats. En réalité, je testais le cache plus qu'autre chose. Et si Mathias n'avait pas lu mon article, je ne l'aurais jamais découvert.

Compromis

Imaginons que vous ayez écrit ou trouvé un microbenchmark avec un sens. Il montre que vous devriez plutôt utiliser l'approche A au lieu de l'approche B. Il est important de comprendre que passer de B à A ne va pas uniquement rendre le code plus rapide. Quasiment toutes les optimisations de performance sont un compromis entre la vitesse et autre chose. Dans la plupart des cas, vous abandonnez un peu de lisibilité, d'expressivité et/ou d'idiomatisme. Ces propriétés ne se verront pas dans vos mesures pour autant il ne faut pas les ignorer. Le code devrait être écrit pour les humain·es (ce qui inclut le/la futur·e vous) mais pas l'ordinateur.

C'est là où les microbenchmarks nous abusent. Être capable de réaliser une opération plus rapidement ne signifie pas que le compromis en terme d'expressivité soit valable. En se basant sur des résultats de microbenchmarks, certaines personnes prendront pour évident que A est mieux que B et donc que vous devriez toujours mettre en œuvre A. C'est ainsi que la poudre de perlimpinpin est faite. Une partie du problème vient du fait qu'il est difficile de quantifier l'expressivité. À quel point un bout de code doit-il être plus rapide pour justifier une perte de lisibilité ? 10% ? 20% ?

Un point à propos de l'analyse statique et des transpilers s'impose. Il est possible d'écrire du code lisible et idiomatique tout en délivrant une version moins lisible et plus performante en production. Des outils comme @babel/present-env permettent d'écrire du JavaScript moderne et idiomatique sans avoir à se soucier de la prise en charge par les navigateurs et des implications en terme de performance. Le compromis ici se fait sur la taille et l'impénétrabilité du code généré. Certaines fonctionnalités ne peuvent être transformées qu'avec une importante augmentation de la taille du code ce qui détériore les temps de téléchargement et de compilation. La transformation des générateurs est un exemple extrême de ce phénomène. Un exécuteur de générateur doit être ajouté tout en rendant les fonctions génératrices significativement plus lourdes. Une fois encore, ce n'est pas une raison pour ne pas utiliser les générateurs ou pour ne pas les transformer. En revanche, c'est une information importante pour prendre une décision. Il s'agit encore et toujours de faire des compromis.

Exemple de transformation d'une fonction génératrice par Babel

Budgets

Dans ce domaine, les budgets peuvent aider. Il est important de budgétiser différents aspects de votre projet. Pour les applications web, les préconisations RAIL constitue un choix populaire. Si vous souhaitez construire une application tournant à 60 images par seconde, vous avez 16ms par frame. Pour produire une interface qui paraît fluide, il faut répondre visuellement aux action des utilisateur·rices en moins de 100ms. À partir du moment où vous avez des budgets, vous pouvez profiler votre application et vérifier si vous restez dans les limites fixées. Et si ce n'est pas le cas, vous savez par où commencer les travaux d'optimisation.

Les budgets contextualisent les coûts. Imaginons que vous ayez un bouton dans votre interface qui lorsqu'il est utilisé entraîne la récupération avec fetch() et l'affichage à l'écran des dernières données liées aux stocks. Avec l'appel réseau, le traitement des données et le rendu, le délai entre le clic de l'utilsateur·rice et l'affichage est de 60ms. Nous somme parfaitement dans les préconisations RAIL abordées plus haut avec même une marge de 40ms ! Si vous considérez l'utilisation d'un worker pour le traitement des données, la communication entre les fils d'exécution impliquera un délai supplémentaire. Par expérience, ce délai est de l'ordre d'une frame (16ms) ce qui donne un total de 76ms.

Si vous aviez à prendre une décision avec un état d'esprit microbenchmark — en regardant uniquement les nombres sans contexte — la solution à base de workers vous paraîtra une mauvaise idée. Cependant, la vraie question n'est pas « Quelle est la solution la plus rapide ? » mais plutôt « Quel compromis puis-je faire ? » ou encore « Mon budget me permet-il de le faire ? » Dans l'exemple du worker, nous payons 16ms mais cette dépense rentre facilement dans les 40ms de marge par rapport à notre budget RAIL. Ce que nous obtenons en retour dépend de votre perspective; dans cet exemple je souhaite me concentrer sur la robustesse. Si le serveur envoie une énorme structure JSON liée aux stocks, le décodage prendra un temps considérable pendant lequel le main thread sera bloqué. En décodant et traitant les données dans un worker, le main thread sera épargné et l'usage de l'application restera fluide.

Capture d'écran du benchmark six-speed

Prenons un autre exemple : jusqu'à il y a un an environ, utiliser une boucle for of pour parcourir un tableau était 17 fois plus lent qu'une boucle for classique (Note : six-speed a été mis en place en avril 2017. Depuis, de nombreux changements ont été apportés à V8 et Babel). À cause de ces résultats, certaines personnes évitent toujours les boucles for of.

Penchons nous sur des chiffres concrets : en parcourant un tableau de 100 éléments dans Chrome 55 (sorti en décembre 2016, avant le lancement de six-speed) avec un boucle for of puis un boucle for classique, j'obtiens :

  • boucle for of : 134µs
  • boucle for classique : 65µs

Sans conteste, la boucle for classique est plus rapide (dans Chrome 55) mais la boucle for of donne une vérification implicite des limites et rend le corps de la boucle plus lisibe en évitant l'utilisation d'un index. Y'a t il un intérêt à gagner ~60µs ? ça dépend mais la plupart du temps la réponse est non. Si vous utilisez des boucles for of dans un chemin critique (comme du code qui construit chaque frame dans une application WebGL), c'est peut-être le cas. Cependant, si vous ne parcourez que quelques dizaines d'éléments lorsque l'utilisateur·rice clique sur un bouton, je ne m'embêterais même pas à penser aux performances. Je choisis toujours la lisibilité. Et pour information, dans Chrome 70, les deux types de boucle ont exactement les mêmes performances. Un grand merci à l'équipe travaillant sur V8 !

Capture d'écran d'un benchmark de boucles for

Ça dépend (du contexte)

Bref, il n'existe aucune optimisation de performance qui soit toujours bonne. En fait, il n'y a pratiquement aucune optimisation de performance qui soit généralement bonne. Les pré-requis techniques, les audiences, les appareils et les priorités sont trop différentes d'un contexte à un autre. Ça dépend. Si vous voulez mon conseil, voici comme j'essaie d'aborder les optimisations :

  1. Définir un budget
  2. Mesurer
  3. Optimiser les parties qui explosent le budget
  4. Prendre une décision en tenant compte du contexte
11/12/2018 01:25 am   pwet.fr/blog   Mirror   Link  

For the second year in a row, we’re very pleased to launch our scholarship program! We are super excited to open the scholarship process for this year’s SymfonyCon Lisbon 2018, December 6th and 7th. We hope to help the Symfony community members who can’t afford to attend the conference to be part of this great event.

The scholarship program is part of the Diversity Initiative which was launched last year at SymfonyCon Cluj and is led by Lukas Kahwe Smith, a long time Symfony core team member. Lukas recently posted an update about the Diversity Initiative, if you didn’t read it you can find his blog post here.

Fundraising

This year, we’d like to call the entire Symfony community to contribute to our scholarship program by donating funds to help us cover the scholarships expenses for SymfonyCon Lisbon 2018. We aim to offer 3 scholarships at SymfonyCon Lisbon 2018 and we need your help. We’re thus opening a fundraising campaign to collect enough money to offer 3 scholarships to people who cannot join us at the conference for financial reasons. You can donate via our Symfony page on Open Collective website. Anyone can donate on Open Collective, a company or an individual. You can donate the amount you want and either become a backer or a Sponsor! After your donation, you’ll automatically get a PDF invoice.

Our objective is to receive enough money to cover the 3 scholarships we’d like to offer at SymfonyCon Lisbon. In order to be able to cover these 3 scholarships, we aim to collect a minimum of 4 000€ ($4,500) to cover the conference ticket, travel (flight or train tickets from the city of departure to Lisbon) and accomodation for 3 nights per grant recipient. If we exceed this minimum amount and have enough funds to provide more scholarships, we’d be very pleased to extend our scholarship offer to more people. All the available funds and the submitted expenses will be available on our page so everyone can see them. We’ve chosen Open Collective because of its mission to operate in full transparency and because we want to involve the community in this initiative as much as possible.

If you want to help us in our Diversity Initiative, you can donate here.

Scholarship process

Application process for scholarships at SymfonyCon Lisbon 2018 is now open until November 16th. You just need to fill in a form to submit your application. SymfonyCon’s scholarship program is aimed to support Symfony community members who want to attend the conference, but cannot without the scholarship. Anyone regardless of gender, gender identity and expression, sexual orientation, ability, physical appearance, race, ethnicity, age, religion, or socioeconomic status can apply for a scholarship.

We want to include, encourage and recognize people from all backgrounds no matter where you come from. If you cannot attend the conference without financial aid, you are eligible to our scholarship program. We will consider every application. Priority will be given to underrepresented groups such as women, minorities, LGBTQIA and people with disabilities, or other underrepresented groups who will be unable to attend the event without financial support. Students are welcome!

Within the Symfony community, we support diversity and inclusion and are proud to launch our second scholarship program.

Apply here for the SymfonyCon’s scholarship program until Friday November 16th 2018.

The selection process for the scholarship will be handled by the SymfonyCon Lisbon organizers, Lukas Kahwe Smith (Diversity Initiative leader) and the CARE team. We’ll announce the grant recipients on November 20th.

We’d like to thank in advance all the people who will support the scholarship program and help us build the Diversity Initiative. If you have any questions regarding the scholarship program or the SymfonyCon Lisbon, please contact us at event[at]symfony.com. If you want to have more information about our Code of Conduct, you can find it here.

See you soon at the conference!


Be trained by Symfony experts - 2018-11-12 Clichy - 2018-11-12 Clichy - 2018-11-14 Clichy
11/08/2018 08:08 am   Symfony Blog   Mirror   Link  

Fallback for internationalized routes

Contributed by
Thomas Calvet
in #27957.

In complex internationalized apps it's common to define different contents for each regional locale (e.g. en_GB for British English and en_US for American English). However, routes (or at least some of them) could be the same for all regions, so it's cumbersome to define duplicated routes:

1
2
3
4
5
6
7
8
9
use Symfony\Component\Routing\Annotation\Route;

/**
 * @Route({ "en_GB": "/about-us", "en_US": "/about-us" }, name="about")
 */
public function about()
{
    // ...
}

In Symfony 4.2 you can define internationalized routes without the region part and Symfony will match them ignoring the region part of the locale:

1
2
3
4
5
6
7
/**
 * @Route({ "en": "/about-us" }, name="about")
 */
public function about()
{
    // ...
}

In this example, both en_GB and en_US will match the en route.

ICU parent locales as fallback locales

Contributed by
Chris Wilkinson
in #28070.

Currently, when some content is not found for some locale (e.g. es_AR for Argentinian Spanish) Symfony uses the region-less locale (es in this case) as the fallback locale.

However, the ICU project defines "parent locales" for some languages (English, French, Spanish, Portuguese, etc.) In Symfony 4.2 we now use those parents as the first fallback locale. The previous example will now work as follows:

  • Use es_AR content if it exists;
  • Otherwise, fallback to the es_419 parent locale (which is the "international Spanish for Latin America and Caribbean region");
  • Otherwise, fallback to es.

Identity translator as fallback

Contributed by
Yonel Ceruto
in #28523.

When using certain features of Symfony Forms in an application that hasn't installed the Translation component you may find errors like "The helper "translator" is not defined".

In Symfony 4.2 we've added an "identity translator" helper which acts as fallback when the Translation component is not installed. This identity translator doesn't actually translate anything and it just returns the given content.

Update XLF translations by default

Contributed by
Alexis Boyer
in #27935.

XLIFF is officially recommended by Symfony as the format to use for your translations. That's why in Symfony 4.2 the translation:update command has changed the default value of its output-format option from yml to xlf.

It's a minor change, but it will save you from typing --output-format=xlf when running this command.

Lint multiple XLIFF dirs or files

Contributed by
Yonel Ceruto
in #28522.

The lint:xliff command has also improved in Symfony 4.2 to support linting multiple directories and files at once.

Moreover, the command is now much faster to execute because the validation is done using local XSD files. This will solve the timeout problems you may have found in the past.

1
2
$ ./bin/console lint:xliff translations/messages.en.xlf translations/messages.es.xlf
$ ./bin/console lint:xliff translations/ legacy_translations/ data/translations/messages.en.xlf

Be trained by Symfony experts - 2018-11-12 Clichy - 2018-11-12 Clichy - 2018-11-14 Clichy
11/08/2018 03:58 am   Symfony Blog   Mirror   Link  

The conference is now coming in one tiny month. We are so excited to meet you at SymfonyCon Lisbon 2018! We are working hard to offer you an incredible conference experience. You are not registered yet? Don’t miss the only international event about Symfony!

If you are still wondering why you should join us in Lisbon from December 6th to 8th, read our latest blog post about the 3 top reasons to come to SymfonyCon Lisbon 2018 and in case you are still hesitating, here are 3 more top reasons to come to the conference!

  • Conference social event! Let’s not forget the super social mixer we have planned for you on the evening of December 6th after the end of the first conference day. We'll be super happy to welcome all the attendees to the conference social event. We'll share drinks and snacks, in a relaxed atmosphere. The location will be announced soon so stay tuned for more details. It's one of the coolest moment of the conference when you can meet, exchange and chill out with everyone from the conference: attendees, speakers, sponsors... We know you’ll just love it!

  • Meet the Symfony Core Team! We'll have the pleasure to welcome several Symfony Core Team members during the conference and we'll even have a Symfony Community booth where you'll be able to meet them. You always wondered who is in the Core Team and never had the chance to meet them in real life? You have a ton of questions to ask them? Come to Lisbon and you'll be able to listen to their talks and connect with them!

  • The Hackday! On the last day of the conference, on Saturday December 8th, we're organizing a Hackday. This is a dedicated moment during the conference to encourage all Symfony contributions. There are several ways to contribute to Symfony: help to write, review or translate the documentation; work on current issues and PRs to close as many of them as possible to improve Symfony’s development; mentor new contributors; learn how to be involved in the local Symfony community around you; meet other people from the community to exchange best practices, tips… There are a lot to do during the Hackday! If you never attended one before and don’t know how to contribute to Symfony, this is definitely the place to be. Usually we organize several work groups where people can gather to work on specific topics. It’s also a good way to put into practice and test what you just learned during the conference days. Plus, there will be food and coffee all day. The Hackday will start around 9:30 am and end around 4:30pm, you don’t even have to stay the entire day to contribute. But in case you stay all day, you’ll still have some time left after the Hackday to enjoy Lisbon!

And now, are you still hesitating? Oh, did I mention that on top of that you'll get your free conference t-shirt? If you collect them, don't miss this year's conference t-shirt to bring back this new one to your collection! Ready to join us?

Basic conference breakdown:

  • Pre-conference workshops: December 4th and 5th (a very few seats left for most of the workshops, you’d better secure your workshop seat asap if you want to buy a combo ticket)

  • Conference days (schedule of talks): December 6th and 7th, 3 tracks are waiting for you! Discover the schedule!

  • Hackday: December 8th (or the Contribution Day to Symfony as mentioned above)

Buy your ticket at regular price now, only available until November 12th (included), after that date the price will increase! Enjoy the regular rate while it’s still possible!

We’re counting on you to make this SymfonyCon legendary! Symfony is a vibrant community only because you make it so. Bring your team with you and share the excitement! See you soon!

PS: there are some remaining seats for the Sylius, Messenger, API Platform, Modern JS/Webpack and Symfony 4 workshops.


Be trained by Symfony experts - 2018-11-12 Clichy - 2018-11-12 Clichy - 2018-11-14 Clichy
11/07/2018 08:38 am   Symfony Blog   Mirror   Link  

Contributed by
Laurent Voullemier
in #27914.

Security voters are the key feature of Symfony's authorization mechanism. They provide the most granular way of checking permissions (e.g. "can this specific user edit the given item?").

In order to grant or deny permission, all the voters' decisions are aggregated by the Access Decision Manager. Then, depending on your application config, permission is granted if all voters said yes (unanimous), or if the majority said yes (consensus), or if at least one voter said yes (affirmative).

Sometimes, when your security logic is complex, you may need to know exactly why some permission was granted. Symfony Profiler already shows some details about voters:

However, the information is not as detailed as it should be. In Symfony 4.2, we improved this panel to display all the information available about the voters decisions and not only the aggregated results:


Be trained by Symfony experts - 2018-11-12 Clichy - 2018-11-12 Clichy - 2018-11-14 Clichy
11/07/2018 03:13 am   Symfony Blog   Mirror   Link  

After months of community work, I'm am thrilled to be able to talk about the release of Webpack Encore 0.21.0. This represents a huge step forward to stay with the latest versions of industry-standard tools and a bunch of great features along the way.

So, what changes and improvements happened? Let's find out!

WebpackEncoreBundle & encore_entry_script_tags()

Besides the Webpack 4 upgrade itself (described below) the most noticeable change is that a new bundle has been created: WebpackEncoreBundle. If you've previously installed the symfony/webpack-encore-pack, you can remove it and install the bundle instead:

1
2
composer require symfony/webpack-encore-bundle
composer remove symfony/webpack-encore-pack

Notice there is no --dev flag for symfony/webpack-encore-bundle. That's on purpose: it contains a new feature that makes it much easier to include the script and link tags for an entry:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
{# templates/.../checkout.html.twig #}

{% block javascripts %}
    {{ parent() }}

-     <script src="{{ asset('build/checkout.js') }}"></script>

+     {{ encore_entry_script_tags('checkout') }}
{% endblock %}

{% block stylesheets %}
    {{ parent() }}

-     <link rel="stylesheet" href="{{ asset('build/checkout.css') }}">

+     {{ encore_entry_link_tags('checkout') }}
{% endblock %}

Why have we added these functions? Because using these functions gives you versioning and CDN support for free, as well as enabling the new "Split Chunks" feature described below.

Webpack 4, Babel 7 and Major Upgrades

The main focus of this release was to upgrade Encore to use the latest versions of Webpack & Babel. Webpack 4 contains a long list of improvements - like faster build times and a new way to "split" your built files into more optimized pieces (more on that later). Babel 7 is also a huge release - it contains optimizations and support (via @babel/preset-env) for browserslist (more on that later).

Several other libraries were also upgraded - see the CHANGELOG for full details. If you're using Encore's features exclusively, you shouldn't have any problem with these major version upgrades. If you've added custom features - be sure to check the changes for each library.

splitChunks() & encore_entry_script_tags()

One of the biggest innovations in Webpack 4 is SplitChunksPlugin. This solves the problem of duplicated code between multiple compiled entry files. Before Webpack 4, this was solved in Encore via the createSharedEntry() method. This method will not go away soon, but Webpack now has a better option.

Encore 0.21.0 adds a new splitEntryChunks() method. When this feature is enabled, Webpack's SplitChunksPlugin will use an optimization algorithm to automatically "split" the final JavaScript and CSS files into multiple pieces. For example, an entry called "app" will normally output app.js and app.css files. But with splitEntryChunks(), it may output app.js and vendor~app.js (which would contain code shared by other entry files) as well as app.css and vendor~app.css.

But this now means you may need multiple script and link tags in your template! To solve this problem, Encore outputs a new entrypoints.json file that contains all the JavaScript and CSS files needed for each "entry". The new WebpackEncoreBundle Twig functions know how to read from this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
{# templates/.../checkout.html.twig #}

{% block javascripts %}
    {{ parent() }}

    {#
        May now render multiple script tags:
            <script src="/build/runtime.js"></script>
            <script src="/build/checkout.js"></script>
            <script src="/build/vendor~checkout.js"></script>
    #}
    {{ encore_entry_script_tags('checkout') }}
{% endblock %}

{% block stylesheets %}
    {{ parent() }}

    {#
        May now render multiple link tags:
            <script src="/build/checkout.css"></script>
            <script src="/build/vendor~checkout.css"></script>
    #}
    {{ encore_entry_link_tags('checkout') }}
{% endblock %}

That's it! Webpack will intelligently "split" your entry files and the correct script and link tags will always be rendered. The manifest.json file is still output by Encore, but is only used if you need to refer to a static asset (like an image) from your Twig template via the asset() function.

New runtime.js File

This version of Encore also introduces an optional new output file called runtime.js. You should explicitly enable or disable it by calling either enableSingleRuntimeChunk() or disableSingleRuntimeChunk(). If you enable it, a new runtime.js file will be output and needs to be included in your page (but encore_entry_script_tags() will handle this automatically)

What's the point of runtime.js? Suppose you include multiple entry JavaScript files on the same page - like an app.js in your layout and also checkout.js when you're on a checkout page. Then:

  • With enableSingleRuntimeChunk(): if the same module (e.g. jquery) is required by both entry files, they will require the same object.
  • With disableSingleRuntimeChunk(): if the same module (e.g. jquery) is required by both entry files, each will receive a different object.

Using enableSingleRuntimeChunk() will give you the same behavior as Webpack 3, but you can choose whichever setting works better for your app.

New copyFiles() Feature

One of the most-asked-for features in Encore is the ability to copy static files into your build directory. Until now, we recommended using the copy-webpack-plugin. This plugin is great, but if you used version hashes in your filenames, the manifest.json file would not contain the correct key for this copied file (the key would be the versioned/hashed filename). In practice, this made it impossible to version your copied files with filename hashes.

To fix this, Encore now has a copyFiles() method! It's simple: use it to copy files from one directory (e.g. assets/images) into your "build" directory. If versioning is enabled, all files are given version hash names and are included in manifest.json so you can fetch the correct filename via the asset() function in Twig.

Async Code Splitting out-of-the Box

Did you know that Webpack allows you to require modules asynchronously, only when you need them? The feature is called Code Splitting. It's not new, but in the latest version of Encore, you can use it without any extra configuration:

1
2
3
4
5
6
7
$('.js-open-video').on('click', function() {
    // async load the VideoPlayer module
    import('./components/VideoPlayer').then(({ default: VideoPlayer }) => {
        // once it loads, use it!
        const player = new VideoPlayer('some-element');
    });
});

browserslist Support

There are several tools in Encore that need to know what versions of browsers your site needs to support. For example, both Babel and autoprefixer (from PostCSS) will compile your code differently if you need to support older browsers versus only newer browsers.

Until now, there was no one place to configure this. But, thanks to upgrades to @babel/preset-env, you can now set your browsers via a browserslist key in package.json.

For more details, see the browserslist documentation for Encore.

Support for Uglifying ES6 Code

Before this release, Uglify (the library that minifies your JavaScript for production), was unable to process ES6 code. This meant that you were forced to transpile all your JavaScript to ES5 code, even if your site didn't need to support older browsers.

Because of this, Uglify was replaced with terser - a fork of Uglify that processes ES6 code. You shouldn't notice any difference in your app unless you use the configureUglifyJsPlugin() method (use configureTerserPlugin() now).

Ready to Upgrade?

Because this is a big release, upgrading requires a few steps:

  1. Install the bundle via composer require symfony/webpack-encore-bundle
  2. Remove the webpack-encore-pack via composer remove symfony/webpack-encore-pack
  3. Update your version constraint in package.json for @symfony/webpack-encore to ^0.21.0
  4. Run yarn upgrade
  5. Replace your manual script and link tags with the new encore_entry_script_tags() and encore_entry_link_tags() functions.

And, over time, replace createdSharedEntry() with splitEntryChunks(). If you have any issues, please report them on the symfony/webpack-encore repository.

Enjoy!


Be trained by Symfony experts - 2018-11-12 Clichy - 2018-11-12 Clichy - 2018-11-14 Clichy
11/06/2018 08:04 am   Symfony Blog   Mirror   Link  

Contributed by
Kévin Dunglas
in #28875.

The WebLink component introduced in Symfony 3.3 provides tools to manage the Link HTTP header needed for Web Linking when using HTTP/2 Server Push as well as Resource Hints. In practice, it can improve the performance of your web apps dramatically.

In order to simplify its usage, in Symfony 4.2 we've added a new addLink() shortcut to AbstractController. For example, this is how you can preload a CSS file (to send it before the browser requests it):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
// src/Controller/BlogController.php
namespace App\Controller;

use Fig\Link\GenericLinkProvider;
use Fig\Link\Link;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;

class BlogController extends AbstractController
{
    public function index(Request $request)
    {
        // BEFORE
        $linkProvider = $request->attributes->get('_links', new GenericLinkProvider());
        $request->attributes->set('_links', $linkProvider->withLink(new Link('preload', '/app.css')));

        // AFTER
        $this->addLink($request, new Link('preload', '/app.css'));

        return $this->render('...');
    }
}

Be trained by Symfony experts - 2018-11-12 Clichy - 2018-11-12 Clichy - 2018-11-14 Clichy
11/05/2018 05:54 am   Symfony Blog   Mirror   Link  

This week, Symfony 2.8.47, 3.4.18 and 4.1.7 maintenance versions were released. In addition, the first beta of Symfony 4.2 was released, including recently added new features like some debug:autowiring command improvements.

Symfony development highlights

This week, 51 pull requests were merged (35 in code and 16 in docs) and 31 issues were closed (22 in code and 9 in docs). Excluding merges, 26 authors made 17,135 additions and 5,508 deletions. See details for code and docs.

2.8 changelog:

  • 36e2983: [Console] removed duplicate condition
  • 5a2969c: fixed ini_get() for boolean values

3.4 changelog:

  • 5d11205: [DependencyInjection] fixed tags on multiple decorated service

Master changelog:

  • 3263175: [FrameworkBundle] made debug:autowiring list useful services and their description
  • 2cd1e11: [Messenger] made TraceableMiddleware decorate a StackInterface instead of each middleware to free the callstack from noisy frames
  • 225746b: [Messenger] mark the component as experimental for 4.2
  • d2b8014: [Messenger] made senders and handlers subscribing to parent interfaces receive all matching messages (wildcard included)
  • d699036: [DependencyInjection] use filter_var() instead of XmlUtils::phpize() in EnvVarProcessor
  • 79bbee2: [VarDumper] added a caster for Memcached

Newest issues and pull requests

They talked about us

Upcoming Symfony Events

Call to Action


Be trained by Symfony experts - 2018-11-12 Clichy - 2018-11-12 Clichy - 2018-11-14 Clichy
11/04/2018 03:30 am   Symfony Blog   Mirror   Link  

News

Phasing out projects.ez.no

The community contribution corner, or better known as projects.ez.no, has been around for years. As a place for contributions e.g. extensions built for eZ Publish. With the development of eZ Platform, the successor to eZ Publish, this resource is at a point that it is no longer getting any contributions.

For this reason, eZ Systems is preparing to phase out projects.ez.no. We are currently at the stage of reaching out to individual project owners, to inform them through email about these plans. Part of phasing out this resource, is moving all of the project code to GitHub.

Note: projects.ez.no will be discontinued as of December 31, 2018. A month before this date, the site will be put in read-only mode to make sure no projects will be added anymore. Stay tuned for more news.

Security Advisories

This week, two security advisories have been published. For details such as severity, affected versions and more, please check each advisory individually:

eZ Publish legacy releases

eZ Publish legacy v2017.12.4 and v2018.09.1 are released. One recent change worth noting to all is slight change to versioning. These 2017/2018 releases have until now had the internal version number v5.90.0-alpha1, as this was confusing this has now changed to make it easier to know roughly what version people are on (for exact versions always check with composer show).

Check the full details and overview of current version on our forum.

Feedback wanted: GraphQL and APIs, entry points into content?

Bertrand Dunogier from the Product team is looking for your feedback on GraphQL and APIs: “I'm working on our GraphQL API, and I'm currently researching about the entry points used to retrieve content. I'm mostly thinking of mobile or independent frontend apps (e.g. React or similar). If you have use-cases of what you would (like to) retrieve, and using which criteria (set of location ids, types...), I'd be very interested.”

If you are interested in this topic, please leave your feedback on our forum, or on Slack.

Bertrand has a demo running, which is available here. This is running on a version referred to on GitHub. For documentation, please check:

In Other News:

Resources

Product Feedback

A few weeks ago we introduced a new channel on Slack where you can provide product feedback, apart from the existing channels. We are adding another way for you to provide product feedback, through the newly launched Product Feedback Portal, available at ezplatform.com/Product-Feedback.

This new Portal provides insight to what is already on the radar for Product Management. You can leave feedback to items already on this roadmap, or you can suggest something new.

How does it work? On the Portal, you will find ‘tiles’ with a topic title and description. Click on a tile and select ‘Nice-to-have’,’Important’ or ‘Critical’. Once you select one of these options, you can also leave a comment, and finally your email. Or you can use the button on the top-right to provide feedback for something not listed on the Portal yet.

Question of the Week

Serhey Dolgushev posted on Slack, that they “are upgrading eZ Legacy 4.3 to latest eZ Platform.” His challenge, and question, is which path to follow for upgrading eZ Publish 4.3 to the latest eZ Platform. Check the thread on Slack for details.

Looking for a bundle compatible with eZ Platform? Check out: https://ezplatform.com/Bundles.

Social Media

Follow us on Twitter, Facebook, LinkedIn, Google+, or YouTube, and join our Community for any help with eZ Platform or community-related questions.

Find eZ at These Events

For more events, make sure to check out this list.

Each week we publish a roundup of highlights from the eZ ecosystem. If you have any news or events to share, please contact me.

(Lead image credit: Myxi, CC)

11/02/2018 10:53 am   ez.no/About-eZ/Blog   Mirror   Link  

News

Phasing out projects.ez.no

The community contribution corner, or better known as projects.ez.no, has been around for years. As a place for contributions e.g. extensions built for eZ Publish. With the development of eZ Platform, the successor to eZ Publish, this resource is at a point that it is no longer getting any contributions.

For this reason, eZ Systems is preparing to phase out projects.ez.no. We are currently at the stage of reaching out to individual project owners, to inform them through email about these plans. Part of phasing out this resource, is moving all of the project code to GitHub.

Note: projects.ez.no will be discontinued as of December 31, 2018. A month before this date, the site will be put in read-only mode to make sure no projects will be added anymore. Stay tuned for more news.

Security Advisories

This week, two security advisories have been published. For details such as severity, affected versions and more, please check each advisory individually:

eZ Publish legacy releases

eZ Publish legacy v2017.12.4 and v2018.09.1 are released. One recent change worth noting to all is slight change to versioning. These 2017/2018 releases have until now had the internal version number v5.90.0-alpha1, as this was confusing this has now changed to make it easier to know roughly what version people are on (for exact versions always check with composer show).

Check the full details and overview of current version on our forum.

Feedback wanted: GraphQL and APIs, entry points into content?

Bertrand Dunogier from the Product team is looking for your feedback on GraphQL and APIs: “I'm working on our GraphQL API, and I'm currently researching about the entry points used to retrieve content. I'm mostly thinking of mobile or independent frontend apps (e.g. React or similar). If you have use-cases of what you would (like to) retrieve, and using which criteria (set of location ids, types...), I'd be very interested.”

If you are interested in this topic, please leave your feedback on our forum, or on Slack.

Bertrand has a demo running, which is available here. This is running on a version referred to on GitHub. For documentation, please check:

In Other News:

Resources

Product Feedback

A few weeks ago we introduced a new channel on Slack where you can provide product feedback, apart from the existing channels. We are adding another way for you to provide product feedback, through the newly launched Product Feedback Portal, available at ezplatform.com/Product-Feedback.

This new Portal provides insight to what is already on the radar for Product Management. You can leave feedback to items already on this roadmap, or you can suggest something new.

How does it work? On the Portal, you will find ‘tiles’ with a topic title and description. Click on a tile and select ‘Nice-to-have’,’Important’ or ‘Critical’. Once you select one of these options, you can also leave a comment, and finally your email. Or you can use the button on the top-right to provide feedback for something not listed on the Portal yet.

Question of the Week

Serhey Dolgushev posted on Slack, that they “are upgrading eZ Legacy 4.3 to latest eZ Platform.” His challenge, and question, is which path to follow for upgrading eZ Publish 4.3 to the latest eZ Platform. Check the thread on Slack for details.

Looking for a bundle compatible with eZ Platform? Check out: https://ezplatform.com/Bundles.

Social Media

Follow us on Twitter, Facebook, LinkedIn, Google+, or YouTube, and join our Community for any help with eZ Platform or community-related questions.

Find eZ at These Events

For more events, make sure to check out this list.

Each week we publish a roundup of highlights from the eZ ecosystem. If you have any news or events to share, please contact me.

(Lead image credit: Myxi, CC)

11/02/2018 10:53 am   eZ Systems News   Mirror   Link  

Earlier this year we wrote about adopting Vagrant and Terraform in our steady march toward Infrastructure as Code. We recently added a new tool to this list, HashiCorp’s Packer. Packer automates building machine images, and with a single set of provisioners, creates images for multiple builders (such as VirtualBox, DigitalOcean, and Google Cloud).

11/02/2018 12:00 am   Mugo Web Blog   Mirror   Link  

Et un peu hors-sujet :

(En plus du flux RSS global, les billets veille et uniquement ceux là sont listés dans le flux RSS correspondant)

11/01/2018 07:46 am   pwet.fr/blog   Mirror   Link  

This security advisory fixes a vulnerability in eZ Publish Legacy, and we recommend that you install it as soon as possible if you are using Legacy via the LegacyBridge.

Installations where all modules are disabled may be vulnerable to XSS injection in the module name. This is a rare configuration, but we still recommend installing the update, which adds the necessary input washing.

To install, use Composer to update to one of the "Resolving versions" mentioned above, or apply this patch manually:
https://github.com/ezsystems/ezpublish-legacy/commit/4697bff700e8cf95d5847ea19dad3479a77b02d9

Have you found a security bug in eZ Publish or eZ Platform? See how to report it responsibly here: https://doc.ez.no/Security

11/01/2018 05:21 am   Security Advisories   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/xrowgpt Nov 1, 2018
1 commit to master
  • @xinyuexrow 496e49f
    added possibility to disable ivw for some siteaccess
11/01/2018 12:36 am   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/repository-forms Nov 1, 2018
2 commits to master
11/01/2018 12:31 am   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/netgensearchandfilterbundle Nov 1, 2018
2 commits to master
11/01/2018 12:24 am   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/mugocontentclassmanager Nov 1, 2018
2 commits to master
11/01/2018 12:22 am   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/LegacyBridge Nov 1, 2018
1 commit to master
  • @andrerom 7032096
    Add ticks to paths for readability
11/01/2018 12:21 am   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezstudio Nov 1, 2018
2 commits to master
11/01/2018 12:15 am   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezpublish-spi Nov 1, 2018
2 commits to master
11/01/2018 12:13 am   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezpublish-legacy Nov 1, 2018
2 commits to master
11/01/2018 12:12 am   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezpublish-kernel Nov 1, 2018
2 commits to master
11/01/2018 12:12 am   eZPublishLegacy @ GitHub   Mirror   Link  
@ezpublishlegacy
ezpublishlegacy pushed to master in ezpublishlegacy/ezpublish-api Nov 1, 2018
2 commits to master
11/01/2018 12:11 am   eZPublishLegacy @ GitHub   Mirror   Link