The Kernel has landed

On Friday, Dries merged in the first major work from the Web Services and Context Core Initiative (WSCCI). In short, it means we are now making use of all of the Symfony2 Components that we've pulled into core in the past few months.

It is also step one in the biggest change in Drupal's design since Drupal 4.7.

readfile() not considered harmful

If you're like me, you've probably read a dozen or two articles about PHP performance in your career. Many of them are quite good, but some are simply flat out wrong, or misinformed.

One of the old truisms that has been repeated for as long as I can recall is "don't use readfile() if you have big files, because it reads the whole file into memory and your server will explode." The usual advice is to manually stream a file, like so:

<?php
$fp
= fopen('bigfile.tar', 'rb');
while (!
feof($fp)) {
print
fread($fp, 1024);
}
fclose($fp);
?>

There's just one problem with that age-old truism: It's not true.

Refocusing WSCCI

As Dries has already reported, we held a summit meeting at the Acquia offices in Boston last week. It was a good sprint for a couple of reasons. For one, a large number of leading core developers got more clearly on the same page about the direction of Drupal core. For another, we were able to break the "too big to swallow" logjam that has been plaguing the Web Services and Context Core Initiative (WSCCI).

Top Ten Reasons To Go To DrupalCon Denver

You mean you aren't already attending what will likely be the largest web developer conference in the Western US this year? What are you waiting for? Not sure if it will be worth it? It will be. Oh, it will be...

If you still need some convincing, or if your boss still needs some convincing, here's the top ten reasons you want to be at DrupalCon Denver:

PHP project structure survey

As Drupal is in the process of considering how to restructure code to best leverage the PSR-0 standard, I figured it would be wise to take a quick survey of how some other major projects organize their code bases. This is not a complete rundown of every project, simply roughly comparable notes for those areas Drupal is currently discussing. I am posting it here in the hopes that it will be useful to more than just Drupal.

Note: This is based on one evening's work of poking around. If you work with one of these projects and have more information to provide or want to correct a mistake I made, please do so in the comments!

Backward compatible APIs

As we begin a new year, it seems appropriate that the discussion of backward compatibility has come up yet again in Drupal. It's a perennial question, and you can tell when a new Drupal core version is ready for prime time when people start complaining about lack of backward compatibility. It's like clockwork.

However, most of these discussions don't actually get at the root issue: Drupal is architecturally incapable of backward compatibility. Backward incompatibility is baked into the way Drupal is designed. That's not a deliberate decision, but rather an implication of other design decisions that have been made.

Drupal developers could not, even if they wanted to, decide to support backward compatibility or "cleanup only" type changes in Drupal 8. It is possible to do so in Drupal 9. If we want to do that, however, then we need to decide, now, in Drupal 8, to rearchitect in ways that support backward compatibility. Backward compatibility is a feature you have to design for.

Does design matter?

Last week I was at DIG London, in London, Ontario. It's normally a gaming conference, but they've added a web track and asked me to come speak. It was a fairly good experience, helped in part by their keynote, the infamous Jeffrey Zeldman talking about responsive design and related topics.

One of the points Zeldman made was that users want content their way, not the way we (web designers, web authors, and web devleopers) want it. Visually impared users want content read to them, or resized. Color blind users want a different color scheme that they can actually read. Smartphone users want content in a narrow column, without a dozen sidebar blocks. Mobile users want content offline, so they can read it on a plane. Many users want just the content, no design, and so use tools like Instapaper to strip out everything but the text of an article. RSS feeds have been around for a decade, and are now growing rapidly thanks to mobile devices, and those are generally (mostly) layout-free. If you're doing responsive design, then you're not making a design but the framework of a design that will change, and possibly mostly disappear, under certain circumstances.

Of course, that to me begs a very important question. When I asked it during Q&A, even Zeldman didn't have an answer. (Yes, I stumped the King of Web Standards. Woohoo!)

In the modern web, does web design even matter?

Drupal in the post-page era

(At BADCamp, several people were asking me to explain what the heck the Web Services core initiative was trying to do, so I got to practice my elevator pitch. This is essentially that pitch in written form.)

Drupal today is very page-oriented. Every request that comes in is responded to with a full HTML page. It is possible to return something else, and finally in Drupal 7 there is, sort of, native support to do so with delivery callbacks, but by and large any non-page response is an after thought at best and a hack at worst. The entire system is built around the assumption that we're returning an HTML page. Why else would we still load the theme system and form system for an auto-complete callback?

In the past, that hasn't been a major issue. The web was a series of pages, in practice, and Drupal is one of if not the most flexible page-generating machine on the web today. Drupal 7 is, arguably, the pinnacle of this page-oriented world.

Just in time for that world to be fading fast.

What Symfonic Drupal means

Earlier today, Dries committed a patch that adds two Symfony2 Components to Drupal: ClassLoader and HttpFoundation.

On its face it's a fairly simple patch; the new code in it is maybe a dozen lines. But it's an important part of a larger shift within Drupal to better embrace the modern web, on the server as well as the client.

The future of caching

This is not your father's Internet. When the Web was first emerging onto the scene, it was simple. Individual web pages were self-contained static blobs of text, with, if you were lucky maybe an image or two. The HTTP protocol was designed to be "dumb". It knew nothing of the relationship between an HTML page and the images it contained. There was no need to. Every request for a URI (web page, image, download, etc.) was a completely separate request. That kept everything simple, and made it very fault tolerant. A server never sat around waiting for a browser to tell it "OK, I'm done!"

Much e-ink has been spilled (can you even do that?) already discussing the myriad of ways in which the web is different today, mostly in the context of either HTML5 or web applications (or both). Most of it is completely true, although there's plenty of hyperbole to go around. One area that has not gotten much attention at all, though, is HTTP.

Well, that's not entirely true. HTTP is actually a fairly large spec, with a lot of exciting moving parts that few people think about because browsers offer no way to use them from HTML or just implement them very very badly. (Did you know that there is a PATCH command defined in HTTP? Really.) A good web services implementation (like we're trying to bake into Drupal 8 as part of the Web Services and Context Core Initiative </shamelessplug>) should leverage those lesser-known parts, certainly, but the modern web has more challenges than just using all of a decades-old spec.

Most significantly, HTTP still treats all URIs as separate, only coincidentally-related resources.

Which brings us to an extremely important challenge of the modern web that is deceptively simple: Caching.

Syndicate content