Ed Walsh Development
Member login
- Hello, Guest
- Log in
Cocomore (via DrupalFire)
I was already planning to provide an overview of what’s been going on in the various Drupal 8 initiatives even before last week, when Dries announced the timeline for Drupal 8, which includes a “feature freeze” for Drupal 8 in only a little more than nine months from now, and planned release at the DrupalCon Europe, in late August 2013.
Drupal 7’s Plateau of Productivity?
While most of the top Drupal 6 modules are now available, in some state or another, for Drupal 7, and I would certainly choose Drupal 7 for a large Drupal-based project that is not expected to be deployed for some time, from the outcry of protests I think there are a lot of people who would not agree that Drupal 7 is yet at its Plateau of Productivity. There is still plenty of reason to build sites on Drupal 6, especially if you need particular features (e.g Nodewords / Metatag functioning properly, among others) and if you need to deploy the site now, with those features ready for use. Dries indicated that he thought Drupal 6 reached its Plateau of Productivity in late 2009, about 18 months after its initial release. At that point, there were fewer than 20,000 sites using Drupal 5 and more than 200,000 sites using Drupal 6. While this order-of-magnitude-greater-usage is not likely to ever be seen comparing Drupal 7 vs Drupal 6 usage (at least not before Drupal 8 is released), I do think that it’s significant that Drupal 7 usage has finally overtaken Drupal 6. That said, I don’t think we are truly at Drupal 7’s Plateau of Productivity, the point where building a new site on Drupal 6 would be “pointless”. Both in terms of time-after-release and usage statistics, it is arguably premature to say we are quite to that point yet.
Quibbling aside, I also don’t think it matters whether we believe we have reached the Plateau of Productivity for Drupal 7, or not — and it certainly doesn’t matter whether we are all in agreement about that. I do think we are ready to see core development for Drupal 8 get kicked into high gear and I don’t think it will significantly delay the development of the contrib modules or resolving core issues in Drupal 7 which are the final barrier, in my view, to truly reaching its Plateau of Productivity. Additionally, many of the fixes and features going into Drupal 8 are regularly being back-ported to Drupal 7, and there is increased discussion of relaxing the criteria for what can be back-ported to Drupal 7, so I see the increased attention to Drupal 8 core development as exciting: a win-win for the whole Drupal community. We now have a release date for Drupal 8, which is important for business decisions, and a better timeline to facilitate a roadmap for the final stages of determining feature inclusion.
Drupal 8 Core Initiatives
Currently there are 6 official Drupal 8 Core Initiatives which are working on various aspects of desired improvements to core. There are others likely to be added to the list as soon as a bit more progress has been made on the current list and/or as qualified individuals step up to take on some of the other “top 10” desired improvements we had on our collective community wishlist. Some of the improvements require fixes to issues plaguing Drupal 7 and 6 and have been backported. Most of the others involve dozens, if not hundreds, of related issues. Following is a brief summary of each of the current core initiatives and what their priority goals are for Drupal 8. In the interest of brevity, the explanations leave out a lot of juicy details, but for those who haven’t been paying close attention and who might like to get involved, I hope this summary is useful:
Web Services and Context Core Initiative
The Web Services and Context Core Initiative (WSCCI, pronounced “Whiskey”), formerly referred to as the “Butler” project, is a core initiative led by Larry Garfield of Palantir.net, aka “Crell” on Drupal.org. While the traditionally typical HTTP request has been for HTML pages, the modern Web has brought with it the need for HTTP services which deliver information which is not necessarily in the form of HTML. This is especially true for mobile applications, but also applies to feeds and other communications via HTTP. The goal is to “take Drupal from being a first-class Web CMS to being a first-class REST server which includes a first-class Web CMS”. Really, this initiative spans a huge range of related issues and without writing an article many times the length of this one, I could not possibly cover everything, but…
Matthew Saunders (via DrupalFire)
Want to save $50? If you're planning on going to Drupalcon Denver today is the last possible day to get in at the early bird pricing. At midnight Mountain Time, the price goes from $350 to $400. That extra $50 in Denver would a REALLY nice meal for a couple of people with drinks. It could get two people into the official party. It is an Association membership with $20 left over. Come on? What are you waiting for? REGISTER today to access more than 104 sessions including core conversations, three GREAT keynotes, more Birds of a Feather conversations than you can shake a stick at. That does not even include the networking opportunities.
If you register today, that comes to $70/day. That increases by $10/day tonight (February 21/2012) at midnight.
Larry Garfield (via DrupalFire)
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).
Lullabot (via DrupalFire)
Since version 2.0 of the Views module shipped back in 2008, site builders have been able to use its Exposed Filters feature to create slick user-filterable lists without writing a lick of code. Unfortunately, complex views with lots of exposed filters can easily become cluttered -- some filtering options only make sense when others are also selected, for example. Views Dependent Filters solves that problem, allowing to hide and show exposed filters based on other filters' values.
Configuring the module is a bit opaque: using it requires adding a "Global Dependent Filter" to your existing view, then positioning it between the two exposed filters whose behaviors should be linked. For example, you might add an exposed Content Type filter, then the Global Dependent Filter, then an second exposed filter that's only applicable to one of the content types. The Dependent Filter's configuration options will allow you to choose which values from the first filter should hide or show the second exposed filter.
Metal Toad Media (via DrupalFire)
In the world of sorting, sometimes 'newest first' or 'oldest first' just doesn't cut it. During a recent Drupal project, we had a client who wanted to be able to control the order of their marquee images in random ways via a drag and drop interface.
Enter the Draggable Views module. In about thirty minutes, I was able to set up custom drag and drop functionality for several content types on their site. Let's dive in and I'll show you how it's done. If you prefer a video tutorial, skip to the end of this post.
Dries Buytaert (via DrupalFire)
Last weekend, we held a sprint at the Acquia offices for the Web Services and Context Core (WSCCI) Initiative for Drupal 8. This was an important sprint for the future of Drupal. This blog post provides a high-level overview of what was discussed and agreed upon; the different sprint participants will be laying out more technical details in follow-up blog posts.
Overall, a wide range of experience levels, skill sets, and perspectives were brought to the table, with the goal of the sprint being to clearly define the initiative’s scope, get agreement on what we wanted to accomplish and why, and lay out a clear plan for how to accomplish this.
In attendance were:
Scope
The WSCCI initiative, as envisioned by Larry Garfield, was originally set to address Drupal's web services and flexible page layout capabilities. We discovered that both would require significant changes to Drupal core, and it was difficult to build consensus online, so we decided to get together for 3 days and to flesh out what we actually wanted to accomplish, and how.
At the sprint, we first attempted to articulate all of the problems that WSCCI was trying to solve, which included: multiple page layouts, better UI/UX to manage blocks, partial page rendering (ESI, AHAH), contextual blocks, different response types per delivery callback/URL, plugin system / swappable subsystems, lazy loading bootstrap (convert subsystems to PSR-0 classes), infrastructure for building web services, dependency injection, and so on.
We then did a round of voting where we could each choose 3 of those things in order to try to determine which of those were the most important.
Two things became instantly clear during this exercise:
Scope resolution
After a good chunk of discussions, all were in agreement to scale back the scope of the initiative to just the "Web Services" piece, and spin off the Layout/blocks/related-UI parts to a separate effort.
Furthermore, some efforts, such as PSR-0 and Unified Plugin system, were only semi-related to the WSCCI initiative in the first place, and just happened to become relevant for it. Work on those efforts will continue as part of the general Framework community efforts.
Architecture
Fabien was able to offer a tremendous number of insights as to how various Symfony2 components could help provide underlying structure for Drupal core to support Web Services out of the box. Essentially, most of what the WSCCI team had been trying to work toward, in the abstract, was already implemented within Symfony2. While some implementation details were different than what we had in mind, the end result is almost exactly what we have been trying to accomplish. We therefore agreed that the best way forward was to leverage several Symfony2 components within Drupal as a way to speed progress toward that end.
Benefits
Some of the concrete benefits that would come out of these changes are
Why does this matter?
As it has evolved into an increasingly powerful system, Drupal has gotten increasingly complex and is not as easy to start developing with as it once was. Many developers are nervous about continuing that trend. Managing complexity is a challenge faced by many software projects, and one approach is to use standardized patterns and components.
Due to its long support for PHP 4, as well as some unique needs, Drupal does not take full advantage of standardized patterns and components. The complexity of the custom code that’s used and the non-standard architecture combines to create a barrier to entry for developers new to Drupal (both experienced and novice developers alike).
Meanwhile, the web is constantly changing around us. Web services and mobile are more important than ever, and with that comes the need to have more flexible page and layout capabilities. Now feels like the right time to modernize Drupal’s capabilities to bring it to the forefront of modern PHP systems and web systems in general.
While changing Drupal's core plumbing to address these needs, it's also a good opportunity to do so using more widely understood and modern techniques and libraries. Leveraging the work of a fellow open source community lets us get a jump on these changes to build a more powerful, more flexible, and more easily learnable system in less time than it would take to go it our own.
While these changes may seem large, and some of them are, we believe that they will achieve the right balance between empowering Drupal's design and architecture, and moving toward more modern, standard, well-tested code and techniques to empower a new generation of developers. I hope you are as excited as we are!
Dries Buytaert (via DrupalFire)
Last summer, I blogged about how I think about Drupal release date planning, tying it to the Gartner hype cycle and the corollary Drupal mood cycle.
The release timeline I laid out in my previous blog post was a Drupal 8 release 18 months after Drupal 7 had achieved the “Plateau of Productivity", the point in time where developing in Drupal 6 seems mostly pointless due to the maturity of Drupal 7.
At that time, I said that I felt that Drupal 7’s “plateau of productivity" was about 6-9 months away. Today, almost 9 months later, I think that by any reasonable measure we are currently there. There are over 300,000 live Drupal 7 installations, which represents nearly 50% of all reported Drupal sites. The top Drupal modules all have Drupal 7 releases, the vast majority of which are either stable releases or release candidates.
Having reached the “plateau of productivity" also means that I feel comfortable announcing the Drupal 8 release timeline (after catch and I talked about it). Without further ado, here is how the rest of the Drupal release cycle breaks down:
Timeline:
This means that Drupal 8 is 18 months away. Time to shift Drupal 8 core development into higher gear!
The ~6-month window for bug fixes laid out here is obviously much shorter than the 18-month window for bug fixes we ended up having with Drupal 7, but the hope is that the issue count thresholds that we’ve introduced this release will ensure this process is much shorter than in Drupal 7, since we’ll be going from approximately 15 down to 0, rather than approximately 300 to 0.
This timeline also means that if there are Drupal 8 initiatives you’d like to see happen, or other specific features or things you want to see fixed in Drupal core, now is the time to make those things happen. If you’ve never helped with Drupal core development before and would like to, stop by IRC during Core office hours, or join us at DrupalCon Denver. There will also be plenty of other sprints at DrupalCon around various Drupal core initiatives, and you can always start your own!
See you in Denver and in the issue queue! :-)
Lullabot (via DrupalFire)
Phing is a PHP tool that allows us to automate processes -- typically, it's used for building and deploying software. It's similar in functionality to the Apache Ant project and uses XML files to execute tasks that are defined as PHP classes. Best of all, it has a tonne of cool tasks already baked in! These include tasty things such as unit testing, file system operations, code sniffer integration, SQL execution, shell commands, 3rd party services and version control integration.
Ok, that sounds good. How do I use it?
You can install Phing easily through PEAR.
$> pear channel-discover pear.phing.info
$> pear install phing/phing
The default name for a Phing build file is build.xml. This file contains a number of targets, which are like different functions that you might find in a PHP file.
<?xml version="1.0" encoding="UTF-8" ?>
Lullabot (via DrupalFire)
If you've ever needed to assemble an iPhone or iPad-ready Drupal site on short notice, you know that it's easy to miss some of the details. Once you've finished a responsive design and figured out how to avoid burying mobile users in heavy images, it's easy to forget the high-res Web Clip Icon used by iOS when a user saves your site to their device's home screen. Without one, a squeezed-down screenshot of your site will be displayed on their home screen. It's possible to hard-code a Web Clip Icon into your theme's markup, but with the Touch Icons module, it's as easy as uploading a custom favicon or logo image.
Installing and enabling Touch Icons adds two additional checkboxes to every theme's settings page. Like the Favorite Icon and Site Logo options, activating them lets you upload a custom image file that should be used as your site's iOS home screen icon. That's it -- there's nothing more to configure or set up!
Technically, nothing prevents you from customizing your site's theme and embedding these touch icons yourself. If you're using an out-of-the-box Drupal theme, however, it's easy to forget. If you need to add a bit of extra polish for iOS users, this is an easy way.
Károly Négyesi (via DrupalFire)
While surely time clocks worked well for an assembly line worker, I have always found the push to clock my hours similarly rather annoying and this puncher makes me froth with rage. It's all sorts of wrong to force a creative person to work on an hourly basis. First, if I am able to solve something quicker, am I to earn less...? Worse, if I take a long time, perhaps even miss a deadline then you are to pay me more??
Lullabot (via DrupalFire)
Lullabot powers The Recording Academy website for third year
When the 54th GRAMMYs begin this Sunday evening, millions of people will be glued to their televisions -- and a large number of them will also simultaneously be on their computers and smartphones to catch up with the online-only behind-the-scenes action. This type of web traffic calls for a responsive and robust site to handle it all.
Lullabot recently launched a new design for GRAMMY.com. The new site carries over all the functionality from the previous iteration, while adding all the responsive web design goodness users have come to expect from high-profile sites.
The Recording Academy's Kevin Colligan explains the importance of a responsive design for GRAMMY.com:
This responsive approach isn’t just cool, it’s vitally important because more and more people are surfing the web on smartphones and tablets. Over the past 30 days, about 17% of our visitors were on mobile devices. And we expect that percentage to rise steadily.
The GRAMMYs site provided many challenging scenarios in building a responsive design. The media-heavy nature of GRAMMY.com means that we had to work with not only resizing images, but also restructuring the page to fit appropriate advertising, Facebook comments, inline YouTube videos, and various positions of embedded Ooyala videos. Besides simply responding to the size of the screen, all video content also has to be HTML5 compatible of course, to help mobile devices that don't support Flash, such as iOS devices or the new Chrome for Android browser.
Sacha Chua (via DrupalFire)
We spent a few hours trying to figure out how to use Color to make our custom Drupal 6 theme configurable. Color rewrites your CSS to include the user-configured colours, and adds the resulting stylesheet link to your header.
The first trick was to get the colour picker to show up on the theme settings page. The documentation wasn’t clear, but the easiest way to get started seems to be to copy the color/ directory from the Garland theme into a subdirectory of your theme, and then customize it from there. You will also need to follow the Drupal 6 or Drupal 7-specific instructions for calling the Color module when preprocessing pages.
Color searches your style.css (and imported stylesheets or other stylesheets defined by the ‘css’ part of your $info array) for colour definitions. Any colour that exactly matches one of the colours defined in the default scheme is replaced by the colour in the selected scheme, with the caveat that the base colour should not appear in the stylesheet. If the base colour is found in the stylesheet, it will be replaced by an empty string. In your stylesheet, make sure your base colour uses the shortened version (ex: replace #cccccc with #ccc) or use a very similar colour instead (ex: #cbcbcb).
So, the easy way to colourize your theme:
Color will attempt to figure out unspecified colours based on those colours’ relationship with the base colour. This can lead to interesting combinations. If there are colours you do not want Color to change, put them in a section after a comment like this:
/*******************************************************************
* Color Module: Don't touch *
*******************************************************************/
All colours specified after that comment will not be rewritten.
Some gotchas to watch out for:
Read the original or check out the comments on: Drupal 6: Adding color support to your theme (Sacha Chua's blog)
Lullabot (via DrupalFire)
A client that has a lot of physical locations asked me how to improve search engine optimization (SEO) for those locations. They have web pages for each of their locations and were concerned about making sure all those individual location pages are getting ranked well. This doesn't seem to be a very well documented subject, but I found a number of ways to make sure that Google and other search engines know more about the physical locations that are related to a web site.
Google, in particular, has been making locative information more important than ever. If Google has any information about where I am located (and it usually does), it will push results in my location to the top of the search results list for any term I search for. For instance, if I search for 'Coffee' into a normal Google search, I get results like this, even though I didn't add anything about my location in my search terms. This makes it clear that having accurate location information in my web site must be very important.
Four Kitchens (via DrupalFire)
Drupal is a great platform, but it can’t do everything. As your site grows, you’ll likely encounter use cases that Drupal can’t or shouldn’t do. Some examples include interacting with third-party APIs while preserving good page loads, or performing repeated actions (polling, etc) that result in site updates. Fortunately, separating these kinds of problems from Drupal and moving them to specialized “sub-stacks” within or near your Drupal stack is easy to do.
Enter Node.js. If you’re unfamiliar with it, Node.js is described as follows:
[…] a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
- From nodejs.org
The relevant part of this description that I’ll be focusing on is node’s “event-driven, non-blocking” model.
Third-party API communication
It’s becoming more common to integrate Drupal sites with third-party APIs. API integration is a great way of making your site more powerful without having to build a lot of functionality yourself. The problem is that a lot of third-party APIs are slow. A normal Drupal session runs in a single thread and blocks until all code finishes executing. If you are communicating with a third party during a user session, you can end up degrading user experience through slow page loads, confusing error messages, etc.
Handling this problem with Drupal queues is becoming more popular, and for good reason. Queueing API requests takes the transport out of the user session and shouldn’t affect user experience, but it also means your requests have to tolerate some delay (until the next time the queue is processed). We’re starting to see this more frequently on large Drupal sites and the trade off between user experience and immediate data propagation isn’t always an easy one to balance with clients.
So in this example, Node.js’s “event-driven, non-blocking” model means that you don’t need to wait for the API to respond before you can respond to Drupal. Node.js accomplishes this using callbacks, which if you’ve used jQuery before you should be fairly familiar with. The program will make a call and continue working, and when a response comes back, the callback will be executed. When written correctly, you can achieve nearly parallel execution of tasks — something that’s very difficult, and often impossible, to do in Drupal.
So how about an example of doing this? Consider a case where you want to update a third-party API with user information when the user’s profile is saved. Normally you would wait for the API to respond during the page request, but if you use Node.js as an API relay, the node server will immediately respond that it received the request, allowing the page load to finish quickly. The node server will then relay the request to the API. When a response is received it will call back Drupal with the results. Conceptually, it looks like this:
Moving the API communication out of Drupal allows you to speed up page requests and split off functionality that’s not well suited to a blocking model. There are many places you can typically do this with Drupal, not solely limited to API communication.
Repetitive jobs in Node.js
Another area that’s a good candidate for a Node.js-Drupal marriage is in repetitive jobs that need to be run very frequently. Again, Drupal queues can fulfill some of this need, but if you need to repeat the job very frequently, Drupal-based solutions are not usually ideal due to their high overhead (having to bootstrap Drupal every time you need to repeat the job). It would be better to bootstrap Drupal only when there’s work that actually needs to be done.
An example of this could be polling an external API for data that needs to be added to your site. Thanks to node’s event driven model in relatively few lines of code it can perform this action without generating a lot of overhead on the server while it’s waiting to repeat:
var http = require('http');
var options = {
host: 'localhost',
path: '/poll'
};
var interval = setInterval(
function pollSomething() {
http.get(options, function onGet(res) {
res.on('end', function onEnd() {
// Do something!
});
});
},
1000
);
This code will repeat a get request to http://localhost/poll every one second. When the response is complete you can add some logic to determine if Drupal needs to do any work, then make another call to Drupal with the payload from localhost. Any site-specific business logic still remains in Drupal, you’re just offloading the grunt work to an engine that’s more efficient at doing it.
Proof of concept
To see some real-world examples of the two use cases I’ve described here, check out the following code:
The key as a developer is to remember that Drupal is great at a lot of things — just not everything. If there’s another tool that’s better suited to the job you’re trying to do, use it! Just because Drupal is usually flexible enough for you to get it to do what you want doesn’t mean that you should bend it that way.
Metal Toad Media (via DrupalFire)
Our new theme has just been released!
This theme was developed with a few goals. Great HTML5 support based on the excellent Boilerplate HMTL5 template, full SASS support, and a base fixed/flexible responsive layout similar to Zen but with built in mobile support, all while keeping the code base small. Like Basic, the stripped down version of Zen, this is designed to run alone, not to run as a master theme with sub themes.
Károly Négyesi (via DrupalFire)
Two years ago I wrote a blog post about why not to use github. I simply was wrong. As jQuery won the JS framework war so did git won the DVCS war and one of the reasons is actually github. I have been using github to host private projects for my clients and the service / workflow is really top notch -- fork from the UI, hack, send a pull request, comment the diff line-by-line, do the minor fixes in the online editor on spot, click the merge button, done. Nicely done.
