Win 3 copies of “Extending Symfony 2″

I have 3 e-copies of Extending Symfony 2 Web Application Framework for you to win.

The rules are simple. You need to either reply here in the comments or tweet telling me why you deserve to get a free copy. I’ll pick up the best answers and randomly select 3 of you to receive a copy of the book.

If you tweet about it, be sure to tweet something on the format of “Hey, @khepin, I deserve because …”. If you don’t mention me in the tweet, I won’t be able to see it and you won’t be entered in the contest. If you reply in the comments, make sure I have a way to contact you.

How do I define the “best” answer? This is a totally subjective criteria and will depend on the answers I get. It could be the one that makes me laugh the most, the most serious one, the best use of the book, the one that gets the most retweets etc…

The contest will run until Sunday / Monday depending on your timezone, after which I’ll send a message to the winners.

Symfony book: “Extending Symfony” available

Just because this blog was not updated with much Symfony content for quite a while doesn’t mean I stopped writing about it!

In fact I’m happy to anounce the immediate availability of Extending Symfony 2 Web Application Framework (also available on Amazon).

It is a hands on approach to discovering all the ways you can extend the framework in order to benefit from advanced capabilities, have cleaner better separated code and or share your extensions in a re-usable fashion.

The 6 chapters lead you from simple creation of Symfony services all the way to creating doctrine, forms and security extensions and how to share them with the community. In details, the chapters are:

  1. Services and listeners
  2. Commands and templates
  3. Forms
  4. Security
  5. Doctrine
  6. Sharing your extensions

The first chapter is available for free if you want to have a peek inside.

Version tagging strategies for composer


Composer, the dependency manager for php is awesome. Incredibly awesome, and gaining more awesomeness by the day. There used to be many glitches, edge cases that made me grinch from time to time to time about it, but almost anything I’ve had to complain about is now working wonderful.

However not everything regarding dependency management is in control of composer, and much is left to the creators of those dependencies.

What causes me pain recently is versions. Library versions are completely in the hands of the library creators. And for this I found people have a variety of behavior regarding tagging versions that makes my use of composer quite inconsistent. Here’s the main 3 of them and why I think they are good / bad.

Update: Seems I’m not the only one thinking about this. Check @igorwesome’s opinion here: too.

Dev-master is thy master

This maintainer has no tagged versions at all. Examples include (sadly all symfony bundles):

This is a horrible idea. You should tag versions. Even if you feel like your library is still under heavy development, clearly not finished yet etc… As soon as some other people are using your code, they need to be able to afford a bit of stability.

Countless times I’ve had the issue that when running a composer update, half of my code got broken because one or two libraries made changes on their development branch and didn’t worry that it would break things down for people who were using it previously.

One more advantage of having tagged versions is that composer caches them locally when you install them. Now I know all of you have internet connections of 8TrilloBytes/PictoSecond, but there’s still some of us for whom it’s not the case.

Time / feature based versions

Versions are tagged when maintainer “feels like it”. Seems to be the most common case. The maintainer has a deadline in mind, or a certain set of features he’d like to put in before creating a new version. So sometimes, many weeks / months go by before a feature actually makes it to a tagged version. I don’t have a definitive opinion on this strategy, I think it fits some libraries, but not all of them. It fits a framework, or a library with a massive user base I think.

My rant against this strategy is that often, bug fixes are also only tagged in a new version “at a later time”.

An example of this I recently had is with DoctrineExtensions (this is just one example because it’s the most recent one in my case). After an update to the latest version, the Sluggable behavior wasn’t working for me anymore. I went on to fix what for me was a bug, wrote tests for it, submitted a pull request which got merged.

Awesome you would think. Well yes but … no. Not completely. Now that I’ve fixed my bug, how do I start using the version that has the fix?

I can start using dev-master instead of the 2.3.* or 2.* version tag I previously had. But then, I’m back on the dev-master trainwreck. It’s called “dev” for a good reason, and it means that things are gonna break. Possibly a lot.

Or I could … well I don’t know!

The version tag freak

That would be me! If you look at, it has 12 tags for about 96 commits in the repository. That’s one tag every 8 commits on average.

Whenever I update the code, or receive a pull request on it, I ensure the minimum to be confident that the code still works the way it should. Ask people to add tests when they submit new code. Run the tests before each PR. Try it on a spare project, whatever is needed.

But then as soon as I am confident that code doesn’t break things, I tag a new version immediately. X.Y+1.0 if I added some new feature or X.Y.Z+1 if it’s more of a bug fix.

I don’t think it’s a good thing to do for libraries that don’t have good testing in place as this would be like being on dev-master but with more work to be done. But for the other ones, doing something different feels like a relic of the past to me. A relic of times when it did cost money to release a new version. You had to print CD-ROMs, send them to your customers, go through an expensive upgrade process. So it made sense to only release when there was a truckload of new features / improvements.

But nowadays, what’s preventing us from having 5 versions a day if we’re confident they’re not breaking anything for existing users?

So maybe we could…

If you’re not confident, then the alpha and beta channels are here for that. I think these names are “misleading”. People have in mind that you work 5 months, then have alpha versions for one month and then beta versions for 2 weeks, and then a final version.

I’d like to propose that alpha and beta are used in a different way. Much like the “channels” on firefox and chrome.

In alpha, you can tag things as they come. Tag often. Not all the time (that would be dev-master), but often. As soon as a small feature is developed and tested => tag.

In beta, you give yourself room for a bit more feedback time.

And real versions are for when you feel comfortable that you’ve reached a new point in your library’s development.

What do you think? How do you do it?

I’m gonna say it again but you should at the very least start tagging versions of your code. This makes life easier for all the users of your code. This gives you the ability to develop new features freely without breaking everybody’s stuff.

I gave some ideas on how we could all achieve this better. I’m open to different opinions. Let me know what you think.

Partial templates with underscore.js

We’re doing some pretty advanced stuff at my company using underscore.js and to simplify some of it I wanted to use partial templates in my templates.

For example, we have different kind of tooltips all over our application. The structure is similar but the text and a few classes might change.

Underscore allows you to add your own functions using _.mixin(). And within an underscore template, all the underscore functions are still available.

So here’s the simple code:

Now you can declare a partial like this:

You declare your partials once, with a unique name. They are then globally available from within any other template.

And use it from within a template as follows:

That’s it, very easy and can save you some time by avoiding re-creating the same templates everywhere. Especially when you will need to change them!

Now …. time for the weekend!

Symfony bloggers on Twitter

A while ago, I had cleaned up all the database of symfony related blog feeds from the old symfony website, as well as added a few of my own. The whole thing is published as a single RSS feed.

Now the same is available as a Twitter account to keep you informed of all goodness in the symfony world. Just follow @sf_bloggers on Twitter.

And just like before, if you want to add your own blog feed in the mix, send a PR on khepin/symfonybloggers adding your Atom or RSS feed to the feed_list.

User dependent forms in symfony2

In a lot of cases it can happen that you want to make your forms different based on the user currently browsing your app.

The cookbook currently shows how to change a form with event subscribers depending on the data in that form. Say creating a record rather than updating something could require a different form for example.

Here we’re gonna take a look at what happens when your form should be customized based on something that is not readily available in the form’s data. Such as the user data.

In many cases though I’d tell you it’s better to not have to do that. There’s a lot of UI ways to make things so you never need the form to hold user specific data. Like letting a user browse to the thing she’s trying to update rather than have a huge select box inside of the form. But if you need something like that, here’s a clean way to do it!

Continue reading

Validate your user before “any” method call

Interception!In the app we’re developing, I want the registration process to be as painless as possible, so the registration form only asks you for a few very basic things:

  • username
  • email
  • password

However we want to have a user’s full information before he can participate in more “advanced” parts of the app. For example if you were an online air ticketing company, before allowing to proceed with a ticket checkout, you need the user’s full name, passport number and other things.

Continue reading

Custom database type with Doctrine 2 for Posgres GIS

Very quick post today, but I’m recently migrating a MySQL database to a Postgres one because the guys using it want to now take advantage of the geographical possibilities of Postgres. Some tables were very easy to migrate with very basic scripts however for some of them with lots of relations to each other, I wanted to take advantage of using an ORM to make things more simple for myself.
Continue reading

Doctrine objects schizophrenia & the ACL!

There’s a problem many people seem to encounter in Symfony2 and that appears when you start using the ACL component for security along with Doctrine. The ACL defines an object’s identity based on its class name and an id retrieved from a ‘getId’ method if one exists or from a getIdentifier method if the object implements the DomainObject interface. Continue reading

Symfony2 testing with PHP unit quick tip

I ran into a few issues running tests for a symfony2 project that seems to be common to many people once your test suite starts to be more important. One of the common issues that people encounter is that the number of PDO connections allowed was maxed out. Doctrine keeps the connections alive in case a re-use is needed, but for now doesn’t close the connections once the Kernel shuts down (see: This issue has been closed as not related to Symfony, but I can’t figure out whether it’s been updated in the Doctrine bundle. So far it doesn’t seem so.

The workaround proposed in the 2 issues referencing that problem has allowed me to do a few more tests until the same problem appeared again. The solution that works best for me was to actually close the Doctrine connection on the tearDown of the PHPUnit test like this:

Now I run all my tests without ever having this issue come up again.


Even better, my tests run WAY faster than they did before! The normal test run is between 10 to 30% faster like this. But running the tests with code coverage now takes me less than half of the time it did before this change.