The DMSTwigExtensionBundle

When I started using Symfony one of the aspects that really caught my eye was Twig, it really got me back into using a template engine and I don’t think i can ever go back to mixing my HTML and PHP again.

Twig’s extensibility is also something truly awesome and powerful when developing for Symfony, it allows me to easily whip up an extension that get information from the right place in the right way without having to pollute the controller with excessive interactions, or quickly provide a filter to hammer data into the format I need it to be in.

So I created the DMSTwigExtensionBundle to do two things: hold my custom extensions that I use in various projects and enable other extensions, like the non-core extensions written by Fabien Potencier.

Fabien distributes a few extensions which he deemed should not be in core, but are very useful, these are in his own repository and they do thinks like: truncate text, wordwrap, localized date formatting, amongst other things.

I usually have these enabled in my projects, but that means that every time I need to add the composer dependency and then pick one of my bundles to add the service calls with the “twig.extension” tag, which is a pain and out of place. With this bundle I can just drop it in and it will create all of those for me and even give me the option of turning them on or off via configuration, all in one single place.

As time goes i’ll be adding more useful extensions, either that I find or create myself, hopefully making it easy for you to just drop it into your project and start using them, but leaving it flexible enough that you can easily switch them on or off individually.

So check out the Repository at:
Remember to open issues at the main DMS repository:

If you want to use it, just drop it into your composer file, more instructions in the README.

    "require": {
        "dms/twig-extension-bundle": "1.*"

One thought on “The DMSTwigExtensionBundle

  1. Good bundle, however some remarks :
    – "I need to add the composer dependency" you will still need to do this with an other dep (ie our bundle),
    – "then pick one of my bundles to add the service calls" you can do this in your app config.yml,
    – "With this bundle I can just drop it in" well you should configure it somehow otherwise you'll get overhead for unused extensions (cf previous bullet),
    – To be even pickier, adding a new Bundle has a small perf impact "new Bundle()".


    • - in this case i mean you no longer need to add the extensions composer entry, just the bundle. (currently 1:1, valid. point.)
      – yes you can add to config.yml, but i dislike doing that in this file as its not expected, that's what a services.yml file is for, still it needs a bit of knowledge transfer.
      – in the README you can check that there is a on/off config setting (as opposed to service definition) which you can use. To this extent i18n and Debug which usually overlap, are off by default.
      – The perf impact of this is mostly in the compilation of the config anyway, so i do not consider it to be enough of a bother, as long as it gets me the services defined in a single place.

      The intent is to add more extensions and try to make this a single point of entry for all those small loose extensions with single place to turn them on/off.

      But this is something that bothered me, it may not be your case, but thanks for the feedback, hope i cleared those points for you.

  2. The perf effect of this is mostly in the selection of the config anyway, so i do not consider it to be enough of a hassle, provided that it gets me the solutions described in only one position.
    Removalists in Brisbane

Leave a Reply