Acquia

9 April, 2015

After more than a year and probably hundreds of patches, yesterday it finally happened! As of 13:11:56 CET, April 8, 2015, Drupal 8 officially has page caching enabled by default![^1] And not the same page caching as in Drupal 7: this page cache is instantly updated when something is changed.

The hundreds of patches can be summarized very simply: cache tags, cache tags, cache tags. Slightly less simple: cacheability metadata is of vital importance in Drupal 8. Without it, we’d have to do the same as in Drupal 7: whenever content is created or a comment is posted, clear the entire page cache. Yes, that is as bad as it sounds! But without that metadata, it simply isn’t possible to do better.1

I’ve been working on this near-full time since the end of 2013 thanks to Acquia, but obviously I didn’t do this alone — so enormous thanks to all of you who helped!

This is arguably the biggest step yet to make Drupal Fast By Default. I hate slow sites with a passion, so you can probably see why I personally see this as a big victory :)

7 November, 2014
Conference
DrupalCamp Ghent
Location
Ghent, Belgium
Description

In Drupal 8, we’ve significantly improved the way pages are rendered. This talk explains the entire render pipeline, in some detail.

But it also covers:

Tags

7 December, 2013
Conference
Drupagora 2013
Location
Paris, France
Description

For this short talk, I chose two particular improvements in Drupal 8 that will make a big difference for future Drupal sites’ performance and ops (infrastructure requirements).

The addition of cache tags is the most important new feature to have a huge impact on back-end performance: it allows for much smarter/better cache invalidation, and hence through better cache hit ratios help increase performance and reduce infrastructure requirements.

31 May, 2013

Drupal 8 will ship with big authoring experience improvements: WYSIWYG editing & in-place editing, thanks to the Spark distribution that Acquia — my employer — is sponsoring.

But how well does it fare with the growing importance of structured content? Do Drupal 8’s WYSIWYG & in-place editing enable it or prevent it?

The new web world order: many form factors

The Big Thing of the last few years: the advent of mobile. Inherent to that: websites that are optimized for mobile devices and act as data providers for apps.

A new form factor — mobile devices — changed web development forever. Before mobile, the life of web developers and authors (content creators) was relatively simple: make sure websites work well on a few typical screen sizes (let’s deny the existence of Internet Explorer 6 and all the misery it caused).

But … we cannot predict what’s next. We cannot predict new content consumption form factors. That’s where content strategy becomes vitally important:

content strategy is to copywriting as information architecture is to design

15 August, 2012

We had already let you know that we would be using Aloha Editor as the WYSIWYG editor in Spark. In short: it has a very complete feature set, a proven plug-in system, solid cross-browser support, it can do “nested editables”, and so on; but most notably it’s the best WYSIWYG editor out there that can do “true WYSIWYG”.

Sprint

To accelerate the integration of Aloha Editor into Spark’s Edit module, we decided to do a code sprint with the Aloha Editor developers. Acquia flew out Théodore “nod_” Biadala and Wim Leers to Vienna (Daniel “sun” Kudwien unfortunately wasn’t able to make it), to hack three days (July 16–18) in a row to get us as far as possible. Three of the Aloha Editor developers were working full-time with us.
We’d like to thank Aloha Editor’s parent company, Gentics, for their generous contribution and amazing hospitality.

The most notable goals were:

10 July, 2012

A few weeks ago, we showed the in-line editing prototype we had built for Spark, which has now blossomed into Edit module. Additionally, we also pointed out that we were in the process of selecting the WYSIWYG editor to use in Spark. This selection process was performed in the public Spark issue queue, in order to gather community feedback and to attempt to reach consensus. 73 people followed that issue, about two dozen of whom contributed to the discussion as well.