• v3 now uses symfony3 components
  Silex 1.3 supports symfony3 so lets use it :)
  Note: as symfony3 doesnt support php5.4 anymore, we dont either!
• new ConsoleServiceProvider
  the one from knplabs that was used before seems to be unmaintained and wasnt matching the dependencies anymore.
  So i decided to take it over and renew it a bit. Check it out!
• Docker support
  I started to use Docker as dev enviroment for my projects, so i added dev & prod Docker support.
  For the sake of simplicity it uses a single container with Apache and PHP7.
  If you have Docker and docker-compose on your machine just spin it up with docker-compose up and check on localhost:8088.

As a quick outview:
we are all waiting for Silex2, but development seems to stagnate there.
Hopefully it will pace up again.
But with the rise of other MicroFrameworks like Lumen or the symfony MicroKernel, things went all a bit quiet around Silex.
As i use symfony quite a lot i personally tend to symfony MicroKernel these days.
Check out this blogpost for a benchmark of the microframeworks.

As Composer appeared, installation and autoloading is a breeze nowadays.
I presume here, that you have installed your Silex project via composer.
If so, you can install the twig extensions like this:

Just go to your project folder and run:

composer require twig/extensions:~1.0

and your done with installation and autoloading.

Now to integration and service registration, this also got more easy.

Place this after you have registered the twig service:

$app['twig'] = $app->share($app->extend('twig', function($twig, $app) {
    $twig->addExtension(new Twig_Extensions_Extension_Text($app));
    return $twig;
}));

Thats it, now you can use the text filters in your twig templates:

{{ post.content|truncate(200)|raw }}

Easy…

(If there is more extensive documentation available concerning assetic + CompassFilter, please stop reading on and let me know!)

If you take a look at the filter class itself (it is CompassFilter in the generic Assetic\Filter namespace), you should recognise several option values that you can use in your application wide config.yml file.

But first you have to install the framework plugin following these instructions.

After adding the framework plugin by ruby’s own package manager “gem” (hopefully replaced by composer in the near future ;-)) by typing something like

$ gem install zurb-foundation

the only thing remaining to do is to load the framework plugin by assetic. To do so, put the folloging lines to your config.yml assetic section (as you would do it when using the compass command line interface, refer to the output of

$ compass help compile

.)

The yaml file should look like this:

assetic:
    read_from: %kernel.root_dir%/web
    debug: %kernel.debug%
    use_controller: %kernel.debug%
    filters:
        compass:
            plugins: ['zurb-foundation'] 
            # load foundation                                     
            # framework as you would do by typing
            # $ compass compile --require 
            # zurb-foundation [...]
            # [ ... ]

Now you should be able to import the foundation library files by using the @import statement in your *.sass/*.scss files:

@import "foundation";

Have fun!

I still did not get the point regarding dependency resolution, so i simply “composed” the composer file by writing down my own requirements (“i want only the hottest, newest stuff!!”, then tracked down the error messages, removing them by explicetly writing down the missing dependencies by using the latest “dev-*” versions. After that i tried to run the project, which actually did not work, but selective downgrade of some of the bundles (framework, security-extra blahblah) finally did the job.

Feel free to use it in your own projects:

{
	"require" : {
              "symfony/symfony" : "v2.0.12",
              "doctrine/common" : "2.1.4",
              "doctrine/orm" : "2.1.6",
              "symfony/finder" : "v2.0.12",

              "symfony/assetic-bundle" : "2.0-dev",
              "twig/extensions" : "dev-master",
              "jms/security-extra-bundle" : "1.1.0",
              "sensio/framework-extra-bundle" : "2.0-dev",
              "sensio/distribution-bundle" : "2.0-dev",
              "sensio/generator-bundle" : "2.0-dev"

 	},
        "autoload" : {
            "psr-0" : {
                "Acme" : "src/",
            }
        }
}

Create a file named “composer.json” in your project’s root directory, then paste the above code into it and save it.

Now run

$ curl -s http://getcomposer.org/installer | php

After that, download all dependencies by typing

$ php composer.phar install

The easiest way to create a full project including AcmeDemoBundle, AppKernel and the whole stuff is to download the symfony 2 standard distribution without vendors and calling the script from there. The only thing to do is to modify the path to autoload.php, which should point to vendor/.composer/autoload.php.

Now you are able to upgrade your project’s dependencies to the newest versions by simply modifying the composer.json file. Have fun!.

I will show this with my Superleansilexplate and will integrate it there as an example.
Since i dont want to integrate MongoDB in Superleansilexplate it will just become an additional gist.

Given you have some smaller amount of data like a counter that needs to be stored or other loose coupled datasets, we simply speak to MongoDB “directly” and store the data via Doctrine MongoDB Abstraction Layer.
Since i presume the Data / Document Structure isnt that complex we dont use Doctrine MongoDB ODM (the Object Document Mapper).
If you want to use it instead, try this Silex Extensions.

So we use this SilexExtensions collection and install it via git:

 cd mysilexproject
 git clone git@github.com:fate/Silex-Extensions.git vendor/silex-extension

Then we install the doctrine mongodb libary manually:

 git clone --recursive https://github.com/doctrine/mongodb vendor/mongodb

The extension collection has some more poviders but you can just ignore them and just focus on the MongoDbExtension.

– i actually dont like extensions collections. i would prefer to clone each extensions individually. thou its not much code overhead, but when it comes to the vendor dependencies it can become quite messy IMHO –

Alright now the code.
Edit src/app.php and register the namespace for the extension:

 $app['autoloader']->registerNamespace('SilexExtension', __DIR__ . '/../vendor/silex-extension/src');

Then register the MongoDbExtension;

 $app->register(new SilexExtension\MongoDbExtension(), array(
 'mongodb.class_path' => __DIR__ . '/../vendor/mongodb/lib',
 'mongodb.connection' => array(
 'server' => 'mongodb://mysecretuser:mysecretpassw@localhost',
 'options' => array(),
 'eventmanager' => function($eventmanager) {
 }
 )
 ));

and finally query your MongoDB collection of choice and display the resultset as json:

$app->get('/data-from-mongodb', function() use($app) {

$coll = $app['mongodb']->selectDatabase('mydb')->selectCollection('mycoll');
 $query = array(
 'query' => 'value'
 );
 $sort = array(
 'count' => -1,
 );
 $r = $coll->find($query)->sort($sort)->toArray();
 $response = new Response();
 $response->headers->set('Content-type', 'application/json');
 $response->setContent(json_encode($r));
 return $response;
 });

Easy

To enable it you have to register it first like its shown in the docs:

 $app->register(new Silex\Provider\HttpCacheServiceProvider(), array(
 'http_cache.cache_dir' => __DIR__.'/cache/',
 ));

Also provide the writable cache dir.

Then you have to return the Response Object with HTTP cache headers.

$app->get('/about', function () use ($app) {
 $body = $app['twig']->render('about.twig');
 return new Response($body, 200, array('Cache-Control' => 's-maxage=3600, public'));
 });

And its good practice to finally call it with a dev switch.

if ($app['debug']) {
 $app->run();
 }
 else{
 $app['http_cache']->run();
 }

Now in production environment the page will be cached and if it gets requested it will be served from the cache, if the cached version is not older then the time-to-live limit given in seconds by s-maxage.
So here you avoid expensive calculation time.
You could also provide a max-age directive to tell the client to cache it on clientside, to avoid the HTTP Request.
But as always with caches its quite a rodeo to balance performance and up-to-dateness.
Expiration and Validation Headers can of course be used aswell to controll the cache even more.

To illustrate the performance increase i loaded a simple about-page, which actually does nothing more then render a template.
So while warming the cache it needed 606ms and from the cache it reduced to 190ms.
warm cache:

from cache:

I cant tell how representative this is, but it aswell feels much faster, especially if you got more logic behind the page, like webservice calls etc.

BTW my superleansilexplate got also updated to support the Cache.

Note: its about Twig-extensions not about the former “Silex Twig Extension”, this now called TwigServiceProvider.

First fetch the Twig-extensions code and put them in your vendor dir:

git submodule add git://github.com/fabpot/Twig-extensions.git vendor/Twig-extensions/fabpot
git submodule init
git submodule update

Then register the autoloader by using registerPrefixes:

$app['autoloader']->registerPrefixes(array(
    'Twig_Extensions_'  => array(__DIR__.'/../vendor/Twig-extensions/fabpot/lib')));

You will need to register the TwigServiceProvider itself:

$app->register(new Silex\Provider\TwigServiceProvider(), array(
    'twig.path' => __DIR__ . '/../views',
    'twig.class_path' => __DIR__ . '/../vendor/twig/lib',
));

And eventually enable the Extension you like to use, in my case the Text Extension to use the truncate filter:

$oldTwigConfiguration = isset($app['twig.configure']) ? $app['twig.configure']: function(){};
$app['twig.configure'] = $app->protect(function($twig) use ($oldTwigConfiguration) {
    $oldTwigConfiguration($twig);
    $twig->addExtension(new Twig_Extensions_Extension_Text());
});

That might look a bit strange but it has its reasons, read here.

Thats it! Now i can use something like this in my twig templates:

{{ post.content|truncate(200)|raw }}

I started one myself and had a close look on the others, so i thought i share this.
They all differ a bit so you must choose what fits your needs the best.

They all follow some kind of “best practise” structure, some more, some less.

So there is: https://github.com/gcalore/Silex-Stub
This has several common Providers already enabled:

• Twig
• UrlGenerator
• Monolog
• Doctrine DBAL
• Validator
• Forms

but it has no Frontend Frameworks integrated.
Another minus point is that the index is not in a web directory but in root, so that all lib files etc. are potentially accessible from the web, thou a .htaccess avoids that here.
It also doesnt provide tests.
So i wouldnt recommend that one.

The next one is: https://github.com/brtriver/silex-sample-application
This is a sample rudimentary blog application that you could use as starter.
It has Doctrine and Twig build-in, it has tests but also doesnt include some frontend magic.

The most complete is: https://github.com/lyrixx/Silex-Kitchen-Edition
This starterkit has several extension enabled:

• Doctrine
• Form
• Session
• SymfonyBrige
• Translation
• Twig (with debug extension)
• UrlGenerator

and it also has the HTML5Boilerplate and Twitter`s Bootstrap integrated.
Further Assetic and the YAMLLoader are already shipped and active and tests are provided aswell.
Here Silex is included as submodule, which means unpacked – hence not as phar-, which might be interesting for some.
In my Opinion this is some kind of a reference app, this is even more likely since the creator is sensio employee.
I stole a lot from it ;).

Last but not least mine ;) : https://github.com/ivoba/superleansilexplate
Its supposed to be very lean.
It comes just with Twig and Translation enabled.
It aims mainly at simple applications that need routing and just some additional logic. F.e. its a good container for javascript driven apps that get their data through API calls. If you need database support and more, simply register the provider yourself or use the kitchen.

Tests are included and for the frontend there is the a mix of skeleton(bootstrap seemed too verbose and too twitter branded for mi gusto) and HTML5boilerplate.
Also there is an optimized Boilerplate Build included to avoid Assetic.

Its not really finished yet, but sufficient to start with.
(feel free to provide some improvements)

So i have a structure like so:
web/
(this is the webroot, here is js/css/images, all that asset stuff and the index, here we use the recommended H5BP stuff’n’structure)
views/
(this is outside of webroot and here are all of the *.twig)

Then we need the boilerplate build stuff:

cd <silex>
cp -R <boilerplate>/build <silex>/build
mkdir intermediate
chmod 777 intermediate
mkdir publish
chmod 777 publish

Now we configure the build in the build/config/project.properties

#add your neccessary twig files that contain css and layout includes:
file.pages = views/layout.twig,views/search.twig

#exclude some already optimized libs
file.js.bypass = libs/jquery.isotope.min.js, libs/jquery.hoverIntent.minified.js

#change the source dir to web
dir.source = ./web

Since the build isnt able to handle multiple source dirs we have to copy the views manually to the intermediate and publish file.
So we need a new target:

<!--
    *************************************************
    * CUSTOM TARGETS                                  *
    *************************************************
    -->
    <target name="copyViews">
	    <echo message="copy Views for build"/>
	    <mkdir dir="${dir.intermediate}/${dir.views}"/>
            <copy todir="${dir.intermediate}/${dir.views}" includeEmptyDirs="true">
                <fileset dir="${dir.views}/" excludes="${file.default.exclude}, ${file.exclude}">
                </fileset>
            </copy>
	    <mkdir dir="${dir.publish}/${dir.views}"/>
            <copy todir="${dir.publish}/${dir.views}" includeEmptyDirs="true">
                <fileset dir="${dir.views}/" excludes="${file.default.exclude}, ${file.exclude}">
                </fileset>
            </copy>
    </target>

Gist
Copy this to build.xml or to your project.xml ( > H5BP 2).

Its nearly done! But one thing still needs to be customized if you run H5BP 2, so preplace the following with code with the code from the latest build.xml:

<replaceregexp match="&lt;!-- CSS concatenated [\d\w\s\W]*?!-- end CSS--&gt;" replace="&lt;link rel='stylesheet' href='${style.css}'&gt;" flags="m">
            <fileset dir="${dir.intermediate}" includes="${page-files}"/>
        </replaceregexp>

with this:

<replaceregexp match="&lt;link rel=['&quot;]?stylesheet['&quot;]?\s+href=['&quot;]?(.*)/${file.root.stylesheet}(?:\?.*)?['&quot;]?\s*&gt;" 
        	replace="&lt;link rel='stylesheet' href='\1/${css.sha}.css'&gt;" flags="m">
            <fileset dir="${dir.intermediate}" includes="${page-files}"/>
</replaceregexp>

and

 <replaceregexp match="&lt;!-- scripts concatenated [\d\w\s\W]*?!-- end ((scripts)|(concatenated and minified scripts))--&gt;" replace="&lt;script defer src='${scripts.js}\'&gt;&lt;/script&gt;" flags="m">
            <fileset dir="${dir.intermediate}" includes="${page-files}"/>
        </replaceregexp>

with this:

<replaceregexp match="&lt;!-- scripts concatenated [\d\w\s\W]*&lt;script.*src=['&quot;]?(.*)/${file.root.script}(?:\?.*)?['&quot;]?\s*&gt;\s*&lt;/script&gt;[\d\w\s\W]*&lt;!-- end ((scripts)|(concatenated and minified scripts))\s*--&gt;" 
        	replace="&lt;script defer src='\1/${scripts.sha}.js\'&gt;&lt;/script&gt;" flags="m">
            <fileset dir="${dir.intermediate}" includes="${page-files}"/>
</replaceregexp>

This respects js and css pathes in the replacements.

Now you can run the build local:

cd build
ant copyViews minify

So here you could be done if your with FTP or your favourite upload method, just upload the optimized files from the publish dir to their resp. location.

Next time more with integrating that in your git deployment.