4-digit years for localized dates in Twig templates

You probably know the Twig Intl Extension to localize dates like this:

{{ post.published_at|localizeddate('short', 'none') }}

It uses the current locale along with the PHP IntlDateFormatter to format dates depending on the current locale.

The short format will display a date like dd/mm/yy for the french (fr_FR) locale, while it will display a date like mm/dd/yy for the en_US locale. The medium format displays a date like Jan 12, 1952.

It’s therefore impossible to display a localized date in the dd/mm/yyyy (fr_FR) or mm/dd/yyyy (en_US) formats.

Here is a solution to display localized dates with a 4-digit year, whatever the year, whatever the locale. The solution is to extend the Twig Intl extension in a new extension, so as to customize the date format generated by the PHP IntlDateFormatter class, transforming the “yy” (2-digit years) pattern to “y” (4-digit years), according to the ICU date format syntax.

namespace Acme\DemoBundle\Twig;

class AcmeIntlExtension extends \Twig_Extensions_Extension_Intl
    public function getFilters()
        return array(
            new \Twig_SimpleFilter('localizeddate', array($this, 'twigLocalizedDateFilter'), array('needs_environment' => true)),

    public function twigLocalizedDateFilter($env, $date, $dateFormat = 'medium', $timeFormat = 'medium', $locale = null, $timezone = null, $format = null)
        $date = twig_date_converter($env, $date, $timezone);

        $formatValues = array(
            'none'   => \IntlDateFormatter::NONE,
            'short'  => \IntlDateFormatter::SHORT,
            'medium' => \IntlDateFormatter::MEDIUM,
            'long'   => \IntlDateFormatter::LONG,
            'full'   => \IntlDateFormatter::FULL,

        $formatter = \IntlDateFormatter::create(

        if ($format === null) {
            // Replace yy to y (but yyy should be kept yyy, and yyyy kept as yyyy)
            // This way, years are NEVER shown as "yy" (eg. 14), but always like "yyyy" (eg. 2014)
            $pattern = preg_replace(':(^|[^y])y{2,2}([^y]|$):', '$1y$2', $formatter->getPattern());


        return $formatter->format($date->getTimestamp());

Declare the extension in the app/config.yml file:

        class: Acme\DemoBundle\Twig\AcmeIntlExtension
            - { name: twig.extension }

There was no other easy way to change the pattern of the date, so I had to use the regular expression to change “yy” to “y”, while preserving “yyy” or “yyyy”.

Leverage Symfony2 extra features to simplify controller actions

This post presents two simple yet underused Symfony2 features that make actions code shorter and simpler to understand:

  • The @Template annotation
  • Action parameters conversion (optionally used with the @ParamConverter annotation).

We will see step by step how to simplify a generated CRUD controller to leverage these features.

Doctrine filters will be introduced in an upcoming blog post to make things even easier and more reliable in some use cases.

Continue reading

Notification messages for JSON responses with jQuery and Symfony2

We’re going to setup an easy-to-use notification system using jQuery and the Symfony2 event dispatcher, plus some CSS to get things look nice.

What we want to do:

  • display a success or fail notification message after an AJAX request has been performed.
  • make it totally automatic

How we’re going to do it:

  • Backend side:
    • Define notification messages in the Symfony application using the Symfony Flash Messages system which is also used for non-AJAX requests
    • Use the Symfony Event Dispatcher to automatically add notification messages data to JSON responses.
    • Non-JSON responses will use the session to display notifications on the rendered page, as usual
  • Frontend side:
    • Make a jQuery plugin to display notification in a nice way (animated, display notifications in a stack, Growl-like)
    • The same jQuery plugin will listen to all AJAX responses and display related notifications if there are some

Continue reading

Aloha Editor plugin for symfony 1.4 – sfAlohaPlugin


It feels a bit strange to dive into symfony 1 code again but I updated today the sfAlohaPlugin plugin that I wrote some time ago to easily integrate the Aloha editor into a symfony 1.x project.

The documentation I provided for this plugin was incomplete to make the plugin work well out of the box and this should be fixed now.

The plugin helps you to turn any HTML block (e.g <div></div> blocks) into an in-content editable block. Compared to a simple use of the Aloha Editor, it provides some nice features:

  • Automatically initialize Aloha Editor parameters
  • Save the edited content to the database (its structure is created on plugin install)
  • Upload image feature : a plugin for Aloha has been made for this purpose. Images are uploaded to the server.
  • Some parameters for the symfony app:
    • Only allow connected users to edit content
    • Only allow users with specific credentials (like being an administrator) to edit content
    • Set default Aloha editor loaded plugins

I also set up a demo environment for the plugin so that you can try it!

Here is the demo address to see it in action: sfAlohaEditor demo

Download and learn more about the project: sfAlohaPlugin on Github

Important note:

  • This plugin embeds Aloha Editor 0.21 while the latest version is 0.22.x. This version introduced a lot of compatibility breaks and fixing the plugin to work with Aloha Editor 0.22.x would take too much time
  • I’ve been pretty disappointed by Aloha Editor and wouldn’t choose it as a WYSIWYG HTML editor now. The documentation is not complete at all (and I don’t see any enhancements), the library is huge for a limited set of features, compatibility is broken between versions without any upgrade guide. So for now I would highly recommend to move to CKeditor 4, which has a better documentation and now supports inline editing as well. After considering Aloha integration into Drupal, the Drupal team moved back to CKeditor as well: From Aloha to CKEditor

How to configure Markdown for WordPress

Despite the abundance of WordPress plugins for inserting source code in a post, I never found any easy solution to edit posts mixing text and code. The need to switch between the WYSIWYG editor and the HTML code editor is pretty cumbersome and indentation always gets broken at some point.

For a tech blog, one of the most suitable ways to write posts is to use the Markdown markup language, which is used for documenting projects among others on Github.

There is a plugin for that: WP-Markdown. Using it, writing posts is made really fast and easy.

However, syntax highlighting is made with Prettify.js which is not very efficient for all languages.

I installed 2 more plugins to get code look better:

To get things working, follow these steps:

  • In Settings > Writing, uncheck the Enable Prettify syntax highlighter option
  • In Settings > Highlighter, check the Load All Brushes option

And you’re done!