<![CDATA[Engineered Web]]> 2012-05-15T23:07:50-04:00 http://engineeredweb.com/ <![CDATA[Drupal 7.14 API Compatibility Breaking Change]]> 2012-05-15T20:30:00-04:00 http://engineeredweb.com/blog/drupal-7-14-api-incompatible-change Minor Drupal versions are usually for bug fixes, security updates, and the occasional new feature that doesn't break backwards compatibility. Compatibility changes are reserved for major Drupal releases. There are exceptions such as Drupal 6.2. It was such a big deal there is an update documentation page just for this release. When Drupal 7.14 made an API breaking change without providing documentation or notification to module developers I was quite surprised. The lack of detail made it difficult to track down the changes when I had a broken codebase. Here are the details so others can, hopefully, have an easier time if they run into this problem.

Continue Reading »

]]> <![CDATA[Speedy 1.0 Released]]> 2012-05-07T15:30:00-04:00 http://engineeredweb.com/blog/speedy-1-released Minifying the JavaScript distributed to a browser is important for performance. The speedy module came into being in an effort to make this easy for Drupal sites to implement everywhere. Today the 1.0 release of the module comes out providing minified JavaScript for Drupal 7 core.

Continue Reading »

]]> <![CDATA[Why It Is Hard To Minify On The Fly]]> 2012-04-17T09:55:00-04:00 http://engineeredweb.com/blog/why-hard-minify-on-the-fly One of the tips to speed up websites is it minify the JavaScript. It's simple, effective and the major players already do it (except Drupal). In the discussions for Drupal 8 and how we can speed up Drupal 7 we've been talking about how we go about providing minified JavaScript files for browsers and there are two camps. One camp wants to ship minified files and the other wants to minify on the fly. While minifying on the fly would be nice it turns out that this is really hard for Drupal and other CMS systems.

Continue Reading »

]]> <![CDATA[An Hour A Week To Better Documentation]]> 2012-04-10T07:50:00-04:00 http://engineeredweb.com/blog/an-hour-better-documentation If you're like me, a lot of your projects aren't very well documented. If you look over Github or Drupal.org a significant number of projects are poorly documented. I'm only aware of a few people who regularly document their projects well. In an effort to improve the documentation on the projects I maintain (or try to maintain) I've started to schedule an hour per week to just write better documentation.

An important element to note is that this is scheduled time. I've added it to my calendar and scheduled it into my week. To keep this as a useful part of my time I've scheduled it for the second hour of my work week. This gives me time to get through my email and any communication I need to get done (or any slow starts). Then, I start writing documentation before the week gets in the way.

If you'd like to start writing better documentation I invite you to join me in spending an hour a week improving the documentation in our projects.

Continue Reading »

]]> <![CDATA[Faster Mobile Sites]]> 2012-04-05T12:00:00-04:00 http://engineeredweb.com/blog/faster-mobile-sites-drupalcon-denver 87% of the time it takes to load a web page happens in the front end. This it taken from actual measurements of the top 50k websites. When we want to look for ways to speed up our sites we should look to where most of the time is occurring. At DrupalCon Denver I presented an introduction to front end performance in the session Faster Mobile Sites. This introduction talked about why front end performance is important, covered some details about what's technically happening, offered some simple solutions to get going, and talked about some useful tools.

Continue Reading »

]]> <![CDATA[Drupal 8 and Front End Performance]]> 2012-04-03T00:00:00-04:00 http://engineeredweb.com/blog/drupal-8-front-end-performance At DrupalCon Denver I spoke on Front End Performance improvements we can make to Drupal, why they are important, and provided some information about what's happening technically so we can spot more cases to improve. This presentation was targeted at low barrier to entry changes we can make in Drupal 8 with the short amount of time we have until the feature freeze. If you're interested in front end performance, making Drupal really perform on mobile, or just want to heckle me checkout these slides and video.

Continue Reading »

]]> <![CDATA[Why Minify JavaScript?]]> 2012-03-29T00:00:00-04:00 http://engineeredweb.com/blog/why-minify-javascript When I was at DrupalCon Denver I suggested that all production JavaScript should be minified. This seemed like something simple that I wouldn't get any push back on. After all, the major JavaScript packages do it and the performance recommendation tools all recommend it. I was wrong. Over the past couple weeks I've received push back from numerous people who've told that me if you use gzip (or deflate) compression there's no need to minify JavaScript. So, here is a case for minifying JavaScript.

Continue Reading »

]]> <![CDATA[Introducting the Speedy Module]]> 2012-03-21T00:00:00-04:00 http://engineeredweb.com/blog/speedy-module Website front end performance is important. Better than 85% of the time it takes for a page to load occurs in the front end. One of the low barrier to entry ways to speed up a site is to make sure the JavaScript sent to browsers is minified. This is considered a standard practice with other common platforms, like Sharepoint and Wordpress, already doing this. The Speedy Module brings minified JavaScript files to Drupal core.

Continue Reading »

]]> <![CDATA[Drupal, HP Cloud, and PHP]]> 2012-03-20T00:00:00-04:00 http://engineeredweb.com/blog/drupal-hpcloud-php Cloud computing is something a lot of Drupal developers are interested in these days. As someone who works on the cloud, works for a cloud provider, and does a lot of Drupal work I want to see Drupal and HP Cloud (my cloud of choice) easily work together. So, we are releasing PHP Bindings and a Drupal module that uses them to bring the HP Cloud to Drupal.

Continue Reading »

]]> <![CDATA[LossLess Theme Image Optimization with ImageOptim]]> 2012-02-13T00:00:00-05:00 http://engineeredweb.com/blog/Losless-Image-Optimization-With-ImageOptim I used to think that exporting images from Photoshop for web and devices produced optimized images ready to use in my production sites. Sure, there are optimization techniques you can use for PNGs and JPEGs that I would need to incorporate. But, since Photoshop is considered one of the best imagine editing programs on the market I expected it would do a fantastic job exporting images.

I've since learned there are a number of techniques for producing smaller file sizes without compromising quality that Photoshop doesn't use. For example, 8-bit PNGs with alpha transparency. On the advice of Nathan Smith I've started using ImageOptim to losslessly compress my theme images.

Continue Reading »

]]> <![CDATA[Protocol Relative URLs in Drupal 7]]> 2011-12-27T00:00:00-05:00 http://engineeredweb.com/blog/11/12/protocol-relative-urls-in-drupal-7 When I first started tackling the problem of https and Drupal caching I wanted an interim solution and started by making the database caching layer smarter. Neil Drumm had the idea to use protocol-relative (a.k.a, schemeless) URLs. This turns out to be a great idea and thanks to some hooks in Drupal it's something we can implement fairly easily.

Continue Reading »

]]> <![CDATA[Drupal Does Not Respect https:// When Caching]]> 2011-12-26T00:00:00-05:00 http://engineeredweb.com/blog/11/12/drupal-does-not-respect-https-when-caching One of the problems I recently discovered with the Drupal cache is that it doesn't properly handle https transactions when caching happens. Let's take a look at understanding the problem, an interim solution for the database cache, and finding a long term solution.

The Problem

page-cache-https-issue.png

The page cache properly respects https because it uses a full url including the protocol when generating a cache id. But, Drupal uses multiple layers of caching with the html in a page. For example, the content of blocks can be cached. What if the html for a block has absolute URLs pointing back to the site and those are generated on the http version of the site. Then this is cached. Then this cache is used to create the https version of the page. Then those cached absolute URLs are not using https.

Media Module, Where I Found The Problem

The example that caused me to understand this problem was the media module. With the media module you can embed images and video into a text area (like the body of an article). Media tags are converted to html by the filter system and the results are cached. Images, for example, use absolute URLs (this is part of core and is a good thing for some use cases). If the cache for this text was generated on the http version of the site the path to the image on the https version of the page will use http as the protocol.

This opens up all kids of possible issues. Just imagine someone in a coffee shop thinking they are on https only to have cookies sent back to the server for that image in plain text. Or maybe you have a better imagination than me and can think of something more sinister.

Nested Caching

The issues is nested caching of html and how many of the nested caches don't respect the protocol like the page cache does. This can apply to any html that's cached across any modules.

Fixing Database Caching In The Short Term

To work around this problem I've started a database caching layer that works around this problem by respecting https for most caches. I don't really like this solution and there are some definite hacks in how it works. The real solution should be to have the code saving and retrieving from the html caches be smart enough to include the protocol in the caches. Unfortunately, a cache backend can't fix the places the cache is used.

A Long Term Solution

An issue for a long term solution is already open. If you have any experience in this area, it impacts your sites, or you want to help out please head over there so we can fix this moving forward.

Continue Reading »

]]> <![CDATA[DrupalCamp Michigan Registration Re-Opened]]> 2011-10-17T00:00:00-04:00 http://engineeredweb.com/blog/11/10/drupalcamp-michigan-registration-re-opened DrupalCampMI-2011.pngWhen we first started planning DrupalCamp Michigan we didn't have high expectations for turnout. Southeast Michigan, where the camp is being held, is not known for a large or active Drupal community. When we sold out less than 3 weeks after we had the idea for the camp it was a very present surprise. But, we knew there were more people who wanted to come and an opportunity to reach more people. So, we've added more space and re-opened registration.

Special thanks to Jason Savino for jumping all over this, coordinating with others in the local community (especially Mike O'Connor from the Commerce Guys who was also working on this), and making the extra space happen quickly.

Continue Reading »

]]> <![CDATA[The First DrupalCamp Michigan]]> 2011-10-03T00:00:00-04:00 http://engineeredweb.com/blog/11/10/the-first-drupalcamp-michigan DrupalCampMI-2011.pngThis December 3rd will be the very first DrupalCamp Michigan. Our initial go at a DrupalCamp will be a one day event at the Crowne Plaza in Novi. The event is being sponsored and attended by the local Drupal shops of Commerce Guys, Mustardseed Media, Switchback, and Commercial Progression.

If you're interested in attending head on over to http://drupalcampmi.org for more details and to register. Space is limited.

Continue Reading »

]]> <![CDATA[The Drupal Community and Front End Performance]]> 2011-09-20T00:00:00-04:00 http://engineeredweb.com/blog/11/9/the-drupal-community-and-front-end-performance Drupal has a presence problem when it comes to front end performance. Drupal has for the most part ignored front end performance. According to a study by Strangeloop, 97% of the time it takes a mobile page to render is in the front end. For desktop browser the front end makes up 85% of the time. These numbers may feel high. But, when pages take 500ms to render in Drupal but 6 seconds to display in an end users browser you can see where this comes from.

The presence problem for Drupal can be seen in several places:

  1. A the past few DrupalCons how many sessions have touched on front end performance? I can only recall one of them while there have been many covering memcache, apc, and other server side technologies.
  2. Take a look at the documentation pages on profiling Drupal. Or, search for documentation pages on performance. You'll find discussions about apache benchmark, learn about varnish, etc. You won't learn about font end performance.
  3. Drupal doesn't provide minified JavaScript. For production environments this is considered a standard practice.
  4. The Drupal 8 development "gates" RFC gives 1 of 6 performance items to font end performance. The other 5 are tips/gates in detail for back end issues we've commonly run into. The front end one is a basic one liner.

Front end performance is a big deal. This is more so true as we enter into the dominance of mobile where mobile devices are low powered and on high latency networks.

What We Can Do About It

Pointing out problems is no good without solutions. The problem is in the amount of face time front end performance gets. So, lets get it some face time.

  • At DrupalCamps let's start presenting on it.
  • Drupal companies could benefit from having someone knowledge in house. Come up with ways to add it to your expertise. Maybe hold a book club and discuss a Steve Souders book.
  • When we learn about useful tools like ImageOptim or Sprite Cow lets share them.
  • If you see a contrib module serving JavaScript up that has not been minified file a patch. You can use UglifyJS easily through the web. UglifyJS is what jQuery uses.

Front end performance is a big deal. It's the largest part of the performance equation an end user experiences. Companies have done studies showing the financial and usage impact of end user performance. Let's elevate front end performance to the place it needs to be in the Drupal community.

Continue Reading »

]]> <![CDATA[SplFixedArray, An Underutilized PHP Gem]]> 2011-09-08T00:00:00-04:00 http://engineeredweb.com/blog/11/9/splfixedarray-an-underutilized-php-gem Arrays in PHP are not arrays per the typical array data type. Instead, as Matt Butcher recently pointed out arrays in PHP are similar to hashes in other languages. This can be a very important point to know when tracking down bugs in code and to programmers coming to PHP from other languages. But, what if we wanted something like a traditional array data type? Maybe something that preserved numeric order. Enter SplFixedArray.

Continue Reading »

]]> <![CDATA[JavaScript Theme Functions in Drupal]]> 2011-05-16T00:00:00-04:00 http://engineeredweb.com/blog/11/5/javascript-theme-functions-in-drupal Drupal has an extensive theming system which includes theme functions that can be overridden and an extensible template system. There is an expectation that all markup go through the theme system and it is considered a bug when that doesn't happen. Most of the talk surrounding this system focuses on the server side system and what we can do in PHP. But, that's not all there is to the theme system. Drupal provides a theme system for JavaScript as well. One with callbacks that can be overridden by themes, just like on the PHP side.

Theme Functions

The central function to the theme system is Drupal.theme(). It is the JavaScript counterpart to theme() and works in a similar manner to what theme() did in Drupal 6.

The first step is to define a JavaScript theme function within a modules JavaScript file, then Drupal.theme() can use it. To define a theme function simply create a new function in the Drupal theme prototype namespace like: 

Dupal.theme.prototype.displayName = function(name, url) {
  return '<a href="' + url + '">' + name + '</a>';
}

Once this is done the function can be used like: 

var name = "John Doe";
var url = "http://example.com";
var display = Drupal.theme('displayName', name, url);

Just like the Drupal 6 theme() function usage, the arguments minus the first one are passed to the theme function itself. The first argument is the name of the function in the Drupal.theme.prototype namespace.

Overriding Theme Functions in Themes

Not only does this system allow us to reuse theme functions as templates, it provides a mechanism for themes to override these theme functions. For example, a module defines a theme function like the one above and uses it. But, a theme wants to change the markup. The theme can define an override function like: 

Dupal.theme.displayName = function(name, url) {
  return '<a href="' + url + '"><em>' + name + '</em></a>';
}

This theme function has a slightly different name. Drupal.theme is the namespace instead of Drupal.theme.prototype. The function name is the same as is the function argument signature.

When Drupal.theme() sees this override function it uses it instead of the one defined by the module.

What Should Go Through Theme Functions?

The obvious answer is that all markup should go through theme functions. But, there is more to front end presentation than CSS and markup. For example, animations. It's not uncommon for JavaScript to cause something to display. What if a theme wanted that to slide in rather than just show up in the page? This is not something you can accomplish via markup and CSS changes.

So, instead of thinking of these theme functions as a place for markup consider putting from end presentation in them. All of it. Drupal JavaScript theme functions are something we need to use more. It is the system we currently have and one we should embrace.

For more information on the topic please see the Drupal.org handbook page.

Continue Reading »

]]> <![CDATA[Translatable Strings In Drupal JavaScript]]> 2011-05-01T00:00:00-04:00 http://engineeredweb.com/blog/11/5/translatable-strings-in-drupal-javascript Drupal is known for being highly translatable. The localization team has done a fantastic job building out tools to make Drupal translatable and it's rare to find a module that doesn't properly wrap its strings in the t() function or the lesser known format_plural() function. While the Drupal community is doing fairly well on the PHP side, many people don't know there is a translation system for Drupal JavaScript as well through the use of the Drupal.t() and Drupal.formatPlural() functions.

Continue Reading »

]]> <![CDATA[Build your JavaScript With jQuery 1.5.2 in Drupal 7]]> 2011-04-05T00:00:00-04:00 http://engineeredweb.com/blog/11/4/build-your-javascript-with-jquery-1-5-2-in-drupal-7 Shortly after Drupal 7 launched the version of jQuery shipped with Drupal became outdated. Drupal 7 ships with jQuery 1.4.4 but the jQuery community has shipped jQuery 1.5.2. When we are developing the JavaScript in our shinny new Drupal 7 we are already using an outdated version of jQuery. But, there is a solution. The jQuery Update module provides an update for core to jQuery 1.5.2 and jQuery UI 1.8.11.

Continue Reading »

]]> <![CDATA[Drupal 8 JavaScript Excellence Roadmap]]> 2011-03-17T00:00:00-04:00 http://engineeredweb.com/blog/11/3/drupal-8-javascript-excellence-roadmap Over the past several months there has been a bit of talk attempting to answer the question, how can we make our JavaScript something we can be proud of and others want to use. Through the conversations, which included a Birds of a Feature session at DrupalCon Chicago, we (a number of people in the community) have come up with eight points of attack to make the JavaScript in Drupal 8 awesome. These aren't everything we hope to accomplish but are an important piece of the puzzle.

Continue Reading »

]]>