A blog by the Brick Factory The Brick Factory
Selecting the right tool for the job

Using the Right Tool for the Job

The Brick Factory’s development team has been writing custom PHP applications for ourselves and clients since 1999, and PHP development has changed quite considerably since then. At that time, and for years after, there were few available frameworks with which we could build our applications on, so all of our applications were developed from the ground up, with later applications taking advantage of some reusable code libraries (most of which came from our ImpactWatch application, and others from our online training service).

In 2005, we started using WordPress for blog sites, and later, in 2007, we started to use Drupal for more complicated sites. Both can, to varying degrees, be called application frameworks (Drupal considerably more so than WordPress), and using these tools allowed us to create many websites covering a wide range of needs for our clients must faster than we could have if we had to write everything from scratch.

Actually, at one point before we adopted Drupal, we started to write our own CMS tool, and stopped when we realized that the amount of time we’d have to spend building it to meet our needs would be considerably larger than just using an existing open-source platform. And even if we succeeded in building something that met our standards, ultimately, we’d just be re-inventing the wheel that Drupal, WordPress, Joomla, and 40+ other CMS systems (according to Wikipedia) have spent years refining. And where’s the fun in that?

So, we’ve spent the last several years refining our skills with Drupal, even contributing back a few bug fixes and a Drupal module (Splashify) to the community, and we think we’ve gotten pretty good at Drupal site and module design and implementation.

In December, we started planning for Sway, our next internal project. We have some ambitious goals with Sway, and we wanted to get something to market relatively quickly, so it was obvious early on that we had to use a framework of some sort. This meant we couldn’t use the internal workings of ImpactWatch or Training, as aside from a few reusable components, they were never designed and developed to the point of being significantly useful in other applications.

It also put Drupal out of consideration, as what we had in mind would require so much custom work that the strengths Drupal brought to the table would be outweighed by the time we’d spend working against it. Also, we wanted a chance to use the latest and greatest technologies. PHP 5.4 has been available for just over a year, and we wanted to be able to use it. Drupal 7, by comparison, doesn’t take advantage of many of the new features in PHP 5.3, let alone PHP 5.4.

Ultimately, we settled on Symfony, and in January, started developing Sway using Symfony 2.1 (and quickly upgraded to Symfony 2.2 in March after it was released).

As an added bonus, working on Sway will give us a head-start in learning to use Drupal 8, which is expected to be released later this year. Core components from Symfony are being used in Drupal 8, so we’ll be able to put some of our experience working on Sway to use on any Drupal 8 sites we start working with. Both Symfony 2 and Drupal 8 use the Twig template engine, so our designers will have time to become familiar with Twig before we have to start using it on Drupal sites.

We’re looking forward to what we’ll be able to accomplish with Sway, and with future versions of Symfony and Drupal. This should be an exciting year!

HTML5 Vs. Flash

Five Awesome HTML5 Interactive Pieces

The technology people use to browse websites has changed dramatically the last few years.  Smartphones and tablets have become ubiquitous.  Desktop monitors are getting bigger.  Connectivity is getting better.  Browsers are getting more sophisticated and powerful.

The approach to building website has evolved along with the technology people use to brose the Internet.  In the last few years Flash has gone from ubiquitous to scarce.  And HTM5 has gone from an experimental technology to a fairly common way to build websites.

The rise of HTM5 and the fall of Flash have had a particularly dramatic impact on Interactive pieces.

I remember seeing this Arcade Fire HTML5 interactive film back in 2010, and being blown away by the possibilities it presented. While it is still pretty great, pieces like this have become more and more common over the last few years.  Following are five HTML5 interactive pieces I’ve come across in the last few months that push the boundaries of what is possible in browser. (more…)

Injection attacks are still the number one security vulnerability

How to Protect Your Code Against Injection Attacks

When I started working with PHP years ago, the first thing I did was go online and try to find tutorials. I worked with someone who also did PHP (and was the primary driver for wanting to learn the language), but finding out how to do things on my own fit better into my schedule. Eventually I got to working with databases, and the tutorials I found looked like this:

This is perfectly valid code. In fact, if you look at a lot of examples today you will see the same thing. There’s a huge flaw in these examples, and one that has given PHP a bad name when it comes to security. It isn’t the fault of the language but of the way that many developers learned how to do things. PHP makes it easy to shoot yourself in the foot and it doesn’t help that developers keep showing new developers how to do it. Get gun, point at foot, pull trigger. That’s essentially what the above example is showing you.

So, what is so wrong with the example code? The problem is that we aren’t validating anything. Do we know what $_GET['id'] actually is? What happens if $_GET['id'] is set to something that isn’t an integer?

When mysql_query() runs it will return false. Depending on how well your code handles a false return, someone screwing around with the query variables will learn that we didn’t properly make sure that the id query variable is being checked. At the very least they learned that changing query string parameters does cause the code to change. Depending on the setup of our code, it might even expose what database we’re using. If it’s MySQL, they can get crafty and do something like this:

That little OR 1=1 bit will cause the SQL server to return all of the data in the user’s database. Let’s take this a step further, and say that we are authenticating a user. Most of the examples would look like this:

We’re doing one thing correctly (forcing this data to come through the POST array), but we’re still not really validating that $username or $password are actually good valid values. We can still do the following:

We’re in, and as a user where we didn’t even know the password. Why? The -- will comment anything after it, so we dropped the AND password= portion of the SQL and do the select based on just the username. It will return a single value just like the code will expect, so your code never knows that it was altered.

Both of these attacks are called “SQL Injection Attacks”, and is part of the OWASP Top 10’s #1 attack vector. The sad thing is that these are really easy to combat against. I see all the time on Reddit and Stack Overflow people asking for help and seeing this same sort of code. In 2013 we should have been able to stop this, but with years of old tutorials out there it is an uphill battle.

The reason that it sad to see this as still the #1 attack on OWASP is that it is easy to combat. The first and foremost is to stop using the mysql_* functions in your code. The module that handles those is old, and it doesn’t support the best way to handle SQL injections. Yes, it has mysql_real_escape_string(), but that relies on the developer remembering to use it. Better security comes from the developer having to not remember to do it and it just being built in.

Since PHP 5.0, PHP has shipped with something called PDO. PDO is a database abstraction layer that makes it easier to write cross-database code. If you write your app for MySQL, you can more easily port it to something like Postgres or MSSQL by doing nothing more than changing the connection parameter (assuming you haven’t written any engine specific code like using LIMIT, which MySQL and Postgres support but MSSQL doesn’t).

PDO has another big advantage in that it has support for something called a Prepared Statement. With a prepared statement, the SQL query is parsed by the engine by taking a SQL statement and a list of parameters and putting them together itself instead of relying on a fully built SQL statement. This becomes much safer because the DB engine does all the work on properly quoting the values coming in. The side effect of this is that the worry about the developer being safe is offloaded somewhere else, so by using PDO and prepared statements the developer doesn’t need to worry about if a parameter has been sanitized.

Let’s go back to our first example, with the $_GET parameter. What would this look like with PDO?

It’s a bit longer, but not so much that that there is a ton of extra work involved. What we did was create an SQL statement using placeholders, which in PDO can either be a ? or named like our example, which was :id. We run our SQL through the prepare() method on our PDO connection, which returns a statement object. This statement object gets executed, and at the same time we pass in the values for our placeholders. We can then get the user by calling the fetch() method on the statement.

We can rest assured that the SQL code is now safe from injections. That’s it! That is the single most effective way to combat SQL injections.

For older legacy applications switching out to PDO can be a major undertaking. Drupal did this in Drupal 7, where they replaced their underlying database abstraction layer to use PDO. Drupal didn’t use the database specific functions all over the codebase which made it somewhat easier to swap out, but if your application is riddle with calls to mysql_* or pg_* functions you will want to replace them all with PDO commands.

Do your part to help clean up the bad examples out there. If you ever do new code, use PDO. If you ever give examples, do it using PDO. Maybe we can make the internet a little better, and help knock SQL injections (and other injection types) off of the top of the OWASP Top 10.


Brick by Brick, Round 2

It used to be that when you launched a new website you would have two to three years before the design started to feel dated.  Given how quickly things are moving now, a design can start feeling stale after as little as six months.  The battle against dated design is constant.  While its design was only sixteen months old, we had gotten really sick of the design of our blog, Brick by Brick.   We needed a change.  So today we are pleased to launch a new version we think is a huge step forward (see a before and after here).  Following is a breakdown of the primary improvements we made.


I’m stating the obvious here, but your blog should really be about your content.  The design should get out of the way and let the posts be the star.

Our primary focus in redesigning our blog was to better showcase the content itself  by increasing readability.  To achieve this we:

  • Switched our primary font to Georgia.   We chose Georgia because it works well with the font used in our logo (Avenir), is a pleasure to read, and isn’t used on every site on the web like Arial. I think it adds a bit of elegance to the blog.
  • Jumped on the big type bandwagon and upped the sizes of our fonts throughout.
  • Switched from full justification of text to the justify left, ragged right style.  Full justification is more elegant and looks better on first glance, which is why it is still the dominant approach in book publishing.  Left justified, ragged right is easier to read online and has a bit more of an informal look, which we thought appropriate for our blog.
  • Changed to a one column layout.  Our previous blog had a sidebar with a list of recent posts and a subscribe box.  We found that very few people were clicking on any of that stuff, and going to one column gives us room for larger images to accompany our posts.


We have a talented team of designers that we frankly don’t utilize as much as we should on our blog.  To rectify this we decided to have our design team develop quick illustrations to accompany most of our posts.  They did the illustration for this post, as well as for this one and this one.  I love them.  I think they really add something to our blog.


Our new blog is completely responsive, so that the layout adjusts along with screen size.  This means it looks great on a desktop, tablet, or mobile phone.  Nearly all the sites we are building now are responsive to some degree, so it made sense that our own blog would be.  We think this is how sites will be designed moving forward.

Let us know what you think.

Unit Testing In Drupal

PHP is a language that traditionally has not had unit testing as part of the development process. A large part of that was that way back when, there just weren’t any good tools for doing testing. Another major factor is that many of the learning resources for PHP do not mention doing things like unit tests, which is a major contrast to languages like Ruby. I personally think this has helped lead to the notion that PHP code is much harder to maintain than other languages.

PHP is nearly 20 years old now, and today we have the tools to do proper unit and functional testing without having to go through the pain of writing those kind of systems ourselves. At The Brick Factory, we tend to use the Drupal CMS quite a bit, and thankfully Drupal has a proper testing system built right in.