Flux RSS

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.

• Read more

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:

• Larry "Crell" Garfield, lead architect of the WSCCI initiative
• Daniel "sun" Kudwien, top Drupal core contributor
• Fabien "fabpot" Potencier, lead developer of the Symfony project
• Kris "EclipseGc" Vanderwater and James "neclimdul" Gilliland, who have helped develop and implement the plugin system as part of WSCCI
• Greg "heyrocker" Dunlap, initiative lead of the Configuration Management Initiative for Drupal 8
• Moshe Weitzman, long-time Drupal core contributor
• Angela "webchick" Byron, community cat herder and Drupal 7 core co-maintainer
• Randy "rfay" Fay, Justin "beejeebus" Randall and Alex "effulgentsia" Bronstein, core developers and sane voices of reason with an outside perspective
• Dries Buytaert (me), project lead

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:

1. The items encompassed under WSCCI really spanned at least 3 separate major areas: Web Services, more robust ESI-based layouts (think Panels only more powerful), and cleaning up our underlying toolset to be a more loosely-coupled framework.
2. The underlying architecture to support RESTful calls to Drupal that makes all of the other things possible was deemed the most important thing to focus on.

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

• An underlying framework that is a first-class REST citizen. That means developing web services becomes easier and more efficient, because the plumbing is already in place. An HTML page is a particular case of a REST service.
• Because the core system will be fully REST-ified, we'll be able to improve existing APIs and expose Drupal content in a natively RESTful way. For example, our current AJAX system doesn't comply with REST standards, but with these changes, can be cleaned up to do so.
• That in turn makes Drupal-to-Drupal communication, content staging, content sharing, and a host of other related tasks easier.
• The use of widely used libraries and techniques makes Drupal more approachable to new developers.

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:

• December 1, 2012: Feature freeze. No new features are allowed (unless specifically exempted), focus turns instead to API and UI clean-ups and polishing of existing features.
• February 1, 2013: Code freeze: focus on bug fixes, stabilization. No API changes, instead focusing on bug fixing, preparing for release, and getting the count of critical bugs down to 0.
• August, 2013 (DrupalCon Europe 2013): Drupal 8 released, to wild, international fanfare. :-)

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" ?>

The Facebook Photo Sync module enables the ability to have ImageField images automatically uploaded to a dynamically generated Album upon Node creation.

Facebook Photo Sync was initially developed for Moat Media by Realityloop.

 
Features
Support for standard facebook accounts and facebook Pages.
Dynamically...

read more

oEmbed module allows the easy embedding of third party videos using the Link field (from the Link module). One small problem I had was that I wanted to show listings of oEmbed videos, but as thumbnails instead of videos. This module creates a simple field formatter for the Link field called oEmbed Thumbnail...

read more

Use HTML5 to display PDF files instead of ask for installing plugins to your browser.
Demo: http://mozilla.github.com/pdf.js/web/viewer.html
Getting started
check out pdf.js from https://github.com/mozilla/pdf.js and make pdf.js file in the build directory following its README. ( (WARNING: pdf.js is...

read more

BugHerd is an issue tracking system built for desginers and web developers. This module allows you to quickly and easily add BugHerd to your Drupal site. The module allows you grant access to BugHerd by roles and even turn it off in the admin area.
You can sign up for a free 30 day trial of BugHerd...

read more

Adds the password set form as an optional fields on the one click login. In other words, we encourage (hustle) the user into setting their password as they log into the site via a one click login.
This module borrows heavily from user.module.
This project was sponsored by NumbersUSA.

Project Information
...

read more

Purpose: White list admins when they log in so they can submit html content without the cloudflare challenge screen.
This simple module creates two new permissions "cloudflare whitelist" and "cloudflare blacklist." Any user with a role with the respective permissions will be either whitelisted when...

read more

Maxima API to interface. Use with caution

Project Information

Maintenance status: Minimally maintained
Development status: Maintenance fixes only
Module categories: Content, Third-party Integration
Last modified: February 13, 2012

read more

Natural language date format, "colloquial recency."
Turns CCK time ago and submitted by dates into length-of-time appropriate output:
“last Thursday”
“yesterday"
“a week ago”
“a moment ago”
“October 3rd”
“Mar. 26th ‘12.”

Date outputs are usually pretty clunky. Drupal at least...

read more

Tools and libs for Drupal development under GNU/Emacs IDE (applied to Xemacs too). Project primary targets:
Full functional drupal-mode with hooks and documentation browser
Drupal specific snippets for Yasnippet
Integrate Emacs with Drupal & PHP development tools
Drupal 7 and above compatibility

GNU/Emacs...

read more

Allows your Drupal site to gather statistics on how many times your content (and other entity types) have been "shared" with social/sharing services like Twitter, Google+, Facebook, etc. Also provides an API for other modules to hook into and provide their own share counts.
Also provides views integration...

read more

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??

read 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:

1. Enable Color, if you haven’t yet.
2. Copy the color directory from the Garland theme into 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:

• It’s probably a good idea to add a comment to your style.css reminding developers to resubmit the colour settings after making changes to the stylesheet. Color rewrites the stylesheet, so changes aren’t picked up until the stylesheet is regenerated.
• The Color preview appears to use hardcoded HTML. The gradient is created by color.js, and there doesn’t seem to be a way around it. Our workaround is to use CSS to hide both the preview and the header above it. Unfortunately, there is no div that encloses both the header and the preview.

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:

• soapq.js: a SOAP API relay
  • https://github.com/elliotttf/soapq.js
  • http://drupal.org/project/soapq
• PubHub: a PubSubHubbub implementation in Node.js
  • https://github.com/elliotttf/PubHub

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.