Planet Drupal

Drupal 8 needs as much prodding along as it can get to make the anticipated late summer launch in 2013.

With the launch in mind the next worldwide sprint weekend is coming up just after the London DrupalCamp weekend - on the 9th & 10th of March. Yes Mothering Sunday is also on the 10th in the UK so make sure you don't forget those ladies in your life inbetween git pushing code.

The global Drupal event calendar Drupical is doing a nice job of keeping a record of the sprint events coming up over the next few months.

read more

Episode Number:  115 Post Topics:  Drupal Contrib Drupal 7 Image Handling Drupal Planet

The Drupal 7 Smart Crop module is a Drupal module that provides an Image Style action that provides more intelligent image cropping.

In this episode you will learn:

• How to create a new Drupal image style that uses the SmartCrop action
• How to create a new Drupal image style that uses the Scale and SmartCrop action

Episode sponsored by Drupalize.me

DDoD Video: 

Cross-Posted from The Module Off Blog

We've finished up another challenge here at The Module Off! This challenge asked you to solve a problem with producing change notifications in rules:

The Challenge

Ever want to have rules send you change notifications via email? What if you only want the email to show the differences between the old and the new? Rules doesn't have a simple or structured way to get the difference between two entities. Your mission is to fix that. For instance, let's say you've implemented a help desk ticketing system in Drupal where a support ticket is a content type. When someone updates a ticket in Drupal, (i.e. set priority from low to high), you want to send an email to the ticket's assigned user showing them the change. You don't want to send the entire ticket over again, and you don't want to have to make a million different rules with individual conditions for the individual fields.

Winner: e0ipso!

e0ipso put together some great integration between the rules and diff modules. He added a new rules action to compute the difference between two entities, and then you loop over the differences and do whatever you'd like with them. You could stick them in an email, create a heartbeat news-feed-style entity out of the tokens, whatever you'd like! Definitely check out the solution and download the module. Here's his screencast showing the module in action and a bit about how its coded.

Next Up: Node.JS

The next challenge at The Module Off has a simple title: Do Something Cool with Node.JS. We're excited to see what real-time integrations you can create with the amazingness of Node.JS. So give this challenge a whirl! There's some free WebEnabled hosting at stake!

We've finished up another challenge here at The Module Off! This challenge asked you to solve a problem with producing change notifications in rules:

The Challenge

Ever want to have rules send you change notifications via email? What if you only want the email to show the differences between the old and the new? Rules doesn't have a simple or structured way to get the difference between two entities. Your mission is to fix that. For instance, let's say you've implemented a help desk ticketing system in Drupal where a support ticket is a content type. When someone updates a ticket in Drupal, (i.e. set priority from low to high), you want to send an email to the ticket's assigned user showing them the change. You don't want to send the entire ticket over again, and you don't want to have to make a million different rules with individual conditions for the individual fields.

Winner: e0ipso!

e0ipso put together some great integration between the rules and diff modules. He added a new rules action to compute the difference between two entities, and then you loop over the differences and do whatever you'd like with them. You could stick them in an email, create a heartbeat news-feed-style entity out of the tokens, whatever you'd like! Definitely check out the solution and download the module. Here's his screencast showing the module in action and a bit about how its coded.

Next Up: Node.JS

The next challenge at The Module Off has a simple title: Do Something Cool with Node.JS. We're excited to see what real-time integrations you can create with the amazingness of Node.JS. So give this challenge a whirl! There's some free WebEnabled hosting at stake!

Tags: Drupal Planet

The SmartCentres project was built using an "installation profile" development strategy.

For those who are not familiar with it, the brief summary mentions a cleaner, leaner codebase resulting in a more stable development process that is reproducible from team member to team member. Many Drupal teams are using this process and this is fantastic step forward.

The Custom Config module can be found on github and aims to build on top of the "installation profile" development strategy.

1) A faster way to update.
hook_update_N is a great place for database alters, data migration, or other larger tasks. In our workflow, however, we've been using hook_update_N to execute single lines such as module_enable('some_module') or variable_set('some_var', 123). This leads to install files being way larger and uglier than they should be. "Run Install Hooks", and "Run Post Install" are introduced to replace the need for hook_update_N. Hitting the "Run Install Hooks" or "Run Post Install" callback pages will use the module's own custom_config_module_implements function to find hooks and install files only from our custom or features modules. In order for this to happen, custom and features modules must use the folder structure convention of modules/custom or modules/features. But, all other contrib install hooks are ignored, so we're free to safely hit the "Run Post Install" page without worry of contrib modules.

2) Helper functions.
If you're creating or updating blocks, running queries, or adding terms, Custom Config is there to help. We've got a small handful of hooks you can implement to do most of these setup tasks. Checkout custom_config.api.php to find out how to implement these.

3) The ever exciting post-install phase.
Block modifications, queries, and terms are all executed after the entire site is built. Using hook_init and a custom variable, the module is able to tell if this is the first time a page is being hit after installing. This is important if you need to ensure that features modules are installed and have properly setup their respective blocks, vocabularies, or some other requirement is met. Also, using hook_postinstall you can run any commands after ensuring that the entire site is installed and configured.

4) A place for custom configuration.
From time to time, a project requires a custom configuration form. The question eventually pops up, where does this page live? There's never a single good answer to this, custom_config tries to help by creating a menu item where custom configuration forms should live. Also, that page has two tabs by default "Run Install Hooks", and "Run Post Install" which simply serve as callbacks.

5) Drush integration.
If you're into drush, and I don't know why you wouldn't be, then you'll be happy to hear that both callbacks to run the install and post-install hooks are available as drush commands: drush cc-ri and drush cc-rpi

So, the next time you're starting a project as an installation profile, give custom_config a look over, and think about how it might help you!

 

Second Category: CodeTags: drupal-planetMain Category: TechniqueSocial Buttons:  Tweet Tweet !function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs"); (function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "//connect.facebook.net/en_US/all.js#xfbml=1"; fjs.parentNode.insertBefore(js, fjs); }(document, 'script', 'facebook-jssdk')); (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/plusone.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();

My friend and co-acquian, Bryan Braun, recently released a new, beautiful, minimalist blogging theme on Drupal.org called Writer. I'll let Bryan make the official introduction:

"The story is quite simple. I am a front-end developer who blogs. I searched the Drupal theme repository, but I was unable to find a blogging theme designed specifically for developers. So I made one.

This theme was designed using three driving principles:

• Brutally simple design
• Fantastic typography
• Support for code snippets

These principles guided me through the tradeoffs and helped me make various design decisions. Let's get into the details..."

For more information, take a look at Bryan's post on his blog, or visit Bryan's live demo of the theme.

If the pictures aren't enough to convince you to click that link, reflect on Bryan's closing words:

"There are many great Drupal developers who continue to use Garland or Bartik (the default Drupal themes) as the theme for their blog. These themes are fine, but they were never designed to be used for a blog (not to mention that some would say their overuse has made them tacky). I don't blame them too much... the alternative options are often bleak. Sometimes when I browse themes at Drupal.org, I feel like I'm browsing the web in 1994.

We developers deserve better."

Looks like my site might need an upgrade soon! Does yours?

7.x, drupal, theme, theming, blog

Episode Number:  114 Post Topics:  Drupal Contrib Views Drupal 7 Drupal Planet

The Drupal 7 Views Calc module provides an easy way to do calculations on the numeric data that is displayed within a Drupal 7 View.

In this episode you will learn:

• How to create a Drupal 7 Views Calc view
• How to use Views Calc to perform calculations such as SUM and AVG on a Drupal 7 field within a View

Thanks to Drupalize.me for sponsoring this episode of the Daily Dose of Drupal.

DDoD Video: 

Heather James, Acquia's Manager of Learning Services, has been in and around Drupal since the version 4 days. She says people new to Drupal "have an easier time at this stage coming to Drupal" than they did 6 years ago. Nonetheless, her early experiences learning how to use Drupal are still reflected by the questions people ask learning Drupal today. This, combined with her excitement about Drupal's potential and her background as an educator, motivated her to become a Drupal trainer. She is passionate about education ("When you're teaching, you're building a bridge from what people know to what they don't know.") and says about her job at Acquia, "I feel like I have a patron who helps me do the things I like to do, which is get out there and teach people."

heather_james_final.mp3

In this week's episode Addison Berry is joined by Lullabots Joe Shindelar, Andrew Berry, and Ben Chavet to talk about automating server set up with tools like Puppet and Jenkins. Building a Drupal site is only part of the equation to a complete project, and setting up the servers you will need, and making sure that you can reproduce the site set up consistently is hugely important. It becomes even more important as your projects and teams grow in size. We cover the basics of what the goal is, and what tools we use at Lullabot, and why we use them. This is a great overview of the topic for people who keep hearing these terms thrown around, and would like to understand more of what it's all about.

Podcast notes

• New videos out on Views Bulk Operations and Entity Views Attachment
• Lullabot is looking for a Sales Representative
• DrupalCamp London Introduction to Drupal workshop, March 1
• Drupal Sprint Weekend, March 9-10

Release Date: February 22, 2013 - 10:00am Album: Lullabot Podcast Length: 38:50 minutes (22.4 MB) Format: mono 44kHz 80Kbps (vbr)

Search Krumo is a very simple module that extends the Devel module to give us an enhanced developing experience. It provides the krumo() function's output - created by the Devel module - with a search box to look through the function results. And if you are a developer, you are gonna love this.

Sometimes, instead of using features, you need to be able define server settings in settings.php. This is especially useful when you do a lot of sql syncing as you only need to do a cache clear to start using the server settings defined in the file thus eliminating the need for feature reverts.

So without further due here is a quick snippet which will use settings.php $conf variables for Search API Solr server:

/**
* Implements hook_default_search_api_server().
*/
function yourmodule_default_search_api_server() {
 $items = array();

 $host = variable_get('solr_search_api_host', 'localhost');
 $port = variable_get('solr_search_api_port', '8983');
 $path = variable_get('solr_search_api_path', '\\/sorl');

 $items['solr'] = entity_import('search_api_server', '{
   "name" : "Solr server",
   "machine_name" : "solr",
   "description" : "",
   "class" : "search_api_solr_service",
   "options" : {
     "host" : "' . $host . '",
     "port" : "' . $port . '",
     "path" : "' . $path . '",
     "http_user" : "",
     "http_pass" : "",
     "excerpt" : 1,
     "retrieve_data" : 1,
     "highlight_data" : 1
   },
   "enabled" : "1",
   "rdf_mapping" : []
 }');
 
 return $items;
}

Then add the following in settings.php:

$conf['solr_search_api_host'] = 'https://my.search.server';
$conf['solr_search_api_port'] = '8080';
$conf['solr_search_api_path'] = '\\/sorl';

...and you're done :)

The Title Override module allows you to change page titles on nodes and generic pages. The module is really useful if you need to change a page title within the administration section of Drupal.

By using Title Override, you can manage simple page title changes in a single interface and avoid having glue code all over the place. That being said this module is great at handling static changes to a title. However, if you need to modify a specific content type title with a custom token then look at the Page Title module.

Hackathons, Code-a-thons, Code sprints, Hack days, Hackfests, Codefests, call them what you will; they have been going on for quite some time. In recent years, this has moved past the idea of a specific programming language or software to such things as civic hacking, fashion, icons, and more.

As Code Across America and International Open Data Day approach and people across the world come together to help release and utilize public data and make technology that helps their communities, I have been thinking critically about what is the real value and purpose of what I will generally call Hackathons (we so need a better word).

My main idea is this: Hackathons are community building events. Plain and simple; that is their sole purpose. Dress them in whatever activity you want, its still all about strengthening connections among people. I see many organizers let this idea go wayside in place of activities like building apps or clearing the issue queue. I also often hear the idea of community building talked about as a side benefit of hackathon events, but by defining succes of a hacakthon in terms of community building, I fully believe these events will become much more meaningful and productive to everyone involved. So let me explain in more detail.

Let's describe a hackathon a bit first

Hackathons are pretty general events where people of a community come together and work on project(s). Often the actual activities of a hackathon resemble something like the following:

• People meet in person
• Idea generation or task delegation
• Team or group forming
• Building or working (hacking)
• Presentation or judging period

To better define the space that is a "hackathon", here are some general examples of what I would lump into the term "hackathon event"; trying to provide enough variety to show that subject and tasks can be quite different.

• Civic Hackathon. Technologists and civic leaders making applications for their communities.
• Iconathon. Designers and artists coming together to make reusable icons for everyone.
• Code Sprint. Coders sprinting towards the next release of a software product.
• Data Day. Data nerds come together to try to liberate and utilize (public) data.
• Internal Hackathons. Like a code sprint, but for a specific organization or company.

What is community building?

Just to make sure we are on the same page, let's define this a bit more. Community building is simple; its the act of bringing people together for a shared cause and creating connections where there were none before and/or strengthening existing connections. That's it. But keep that in mind as we go through this.

The value of community building is that you grow the size of your community with more participants and also strengthen everyone's ties to the community as a whole, which translates to your community becoming more sustainable and more capable of accomplishing its mission, whatever that may be.

By building a stronger community, you are building more sustainable solutions.

• If your community is focused on creating civic technology, better connections produce sustainability and ensures real needs are met.
• If your community is designing icons, building relationships means knowledge and inspiration sharing, enhancing the artistic pool.
• If your community is all about a specific software, building community means less burnout, more throughput, and more adoption.

So, why a hackathon?

If our primary goal is community building, why not just hold an ice cream social and let people mingle and talk to each other? Good point. Holding a happy hour or ice cream social in your community would be a great idea and would probably strengthen your community, given the audience.

And that's where the answer comes in -- given the audience, i.e. the members of these communities, a hackathon is the best activity for community building. The people in these communities want to build and create and learn with and from each other. In fact, these communities are defined by the things they make Their members want to feel productive. Working together and collaborating builds bonds and strengthens personal ties much better than a beer will (beers can pretty great too).

Sunlight Foundation's recent article says that community building is not the focus of a hackathon and that application building is, and the article makes the comparison of a hackathon to a Habitat for Humanity event. But here's the thing, hackathons are about coming together to find new and innovative ways to tackle problems or otherwise lending one's specific skills to a problem; a Habitat for Humanity event is focused on getting bodies to help build things that have already been planned out, but the skills of the individuals are not important at all. This would translate to a Habitat for Humanity session where a foundation was set, then the volunteers would try to find the best way to build a house; it would probably be really bad unless you had experienced contractors, carpenters, and electricians. But I am not trying to knock what Habitat does; getting volunteers together to build a house is a great activity, and if your community has a set project and plan and all you need are volunteers, do think about it in this way, but a hackathon should not be run like this.

Hackathons are not for everyone, and depending on your community and goals, you may want to hold other sort of events.

What about the apps, the issue queues, the code, the icons?

The activities of the day are not the same as the reason for holding an event. The activities of a hackathon can be fairly different, stretching from everyone working on an existing project in a code sprint, to building new apps at a hackathon, to data wrangling at a open data day, to drawing icons at an iconathon, and more. These are really important and are the focus of what people are practically doing; telling people to come to a Community Building Marathon would probably not convince many folks to attend. But this is not the reason for holding the event; people could do these things by themselves, but they come together because they value their connection to the community.

You aren't going to finish these activities at the hackathon. You aren't gonna come out with anything more than prototypes for applications; even if you close out every issue in the queue, there will still be more tomorrow; you can ship a new release, but there's always another one; you will draw lots of icons, but probably not make any finished ones; there's always more work to be done. This does not mean its not worth the time and energy that people are willing to put into the event, but expectations need to be realistic. Again, it's not about the activities, its about how the activities actually build stronger communities so that this work can continue into the future.

Prototyping and experimentation

The ideas of experimentation and prototyping are very critical to successful community building. These are the ideals that have led to such a strong community of computer hackers. By providing an event where experimentation and prototyping are promoted, people can feel more comfortable with taking risks, learning new things, and being more open with each other. Focusing on finishing activities will often conflict with this.

Promote the work

Given that people are giving their time, energy, and expertise to draw icons, triage issues, scrape data, and more, it is really important that these activities are collected and put on a pedestal after the event. This is not about the actual work, its about promoting the people that did the work.

But we want to create sustainable, stable applications to help your community, you say?

That's great! But a hackathon won't make that happen. Don't get me wrong, some amazing projects have come out of hackathons that have gone on to be great things. But these are rare cases, and at best the hackathon simply played the role of getting the right people together, not providing an environment to fully foster that project. Holding a hackathon that is solely aimed at making great applications is like playing the lottery; sure, you might get a winning ticket, but most of the time you are gonna be disappointed. This is not even to speak to the mechanics of making good applications in which a day, a weekend, or even a week could not produce a sustainable solution to a problem.

If you really want to foster sustainable applications and projects, hold an event or series of events that brings together real funders and established product teams and build those relationships. A hackathon can be a real good step in getting those product teams together, but it will not provide sustainability to them.

What about contests?

First, let's distinguish between hackathons that are contests, and long-running, remote (not in-person) contests, for instances ones that are on Challenge.gov. The latter is actually a productive way to promote innovation and given certain conditions, will actually lead to some significant, long-term projects. The former is a bad idea in my opinion.

Contests at hackathon promote competition, which in a community of people where you want to strengthen relationships with, could have negative results. Also, as discussed above, hackathons do not create long-term projects, and giving significant money to a project that was prototyped over a day or two with a team that may have never met before is not a good investment of money.

On the flip side, contests do provide incentives to people that might not have them in the first place; but it is arguable if this is actually the type of behavior you want to promote. If the prize money is in small, relatively trivial amounts, and almost everyone gets a prize, contests can provide a level of competition that promotes innovation and experimentation that might not be there.

What is success?

If you accept the premise that a hackathon is a community building event, then what does success look like? It is the number of connections made and the quality of relationships at the end of the event; it is not the number of apps built or issues closed or even the quality of the projects produced. Some specific metrics:

• Fun was had
• New connections were made
• People learned new things
• People know how to keep in touch with the community
• Teams continue to work on their projects
• People come to the next event

Planning your hackathon

When you plan your hackathon, ensure that your primary focus is community building and that your activities lend themselves to that idea; you will have a fun and successful event if you do this. Some ideas to keep in mind:

• Do no harm. Make sure you are not doing things that sever connections or lessen community.
• A charismatic, empathetic, vibrant facilitator is so crucial. The person that leads the event needs to understand the core of community building and what needs to happen to facilitate it.
• Ensure everyone feels productive, no matter the skill level, or if they show up late, or even if they dont have a computer. You'll need extra facilitators for this.
• Make sure everyone can speak their ideas if they want to. This needs to be constructive, of course.
• Make sure all relevant audiences are there. Go out and get them! Only having coders working on applications will result in incomplete ideas and solutions.
• Everyone is equally important. Seriously. Make sure this is activated.
• Collect names of participants and promote their work after the event.

In conclusion

I am not trying to say that people are doing bad jobs when running their hackathons, but by keeping in mind that hackathons are just community building events, you will find a lot more success with your events.

Let me know what you think.

Credits

I have had the amazing fortune of being apart of some great communities and knowing fantastic people that have allowed me to participate, lead, and critically think about these sort of events. I have not fully attributed them in this article, but will soon.

Note that the Sunlight Foundation article linked to above is really great; I just think the original premise is a bit off.

Topics: communitydrupal-planet

Going from static design files to a completed Drupal theme can be a daunting task. I often get asked "strategic" questions by companies who are looking to hire a designer/themer for an upcoming redesign and aren't quite sure what skills they should be looking for. And I often get asked by new-to-Drupal designers how they should approach the task of transforming their design into a Drupal theme. In these conversations the following question (almost) always comes up:

Should I create a static HTML page of my design and convert that into a Drupal theme?

Can you guess what my answer is?

Five years ago, when I was first writing Front End Drupal, the answer would have been "Yes!" Five years ago there were fewer moving parts to creating a Drupal theme. There were fewer contributed modules. Responsive design wasn't even an idea yet. Five years ago I don't think that "mobile" was even a thought for most businesses, let alone a concern.

But today, in 2013, my answer has definitely changed. Now when asked if people should create a static HTML page of their design before converting it into a Drupal theme, my answer is "No!" In fact, depending on your budget size for the entire build and the type of site you're building, you may actually want to skip "static" design files for each layout (and layout variant if you're building a responsive site) and have your designer supplement their work by creating "style tiles" instead of piles and piles of page-specific layouts.

Designing for a style, instead of a specific layout, is a different workflow though. You'll need to have a relatively experienced content strategist, designer *and* themer to help you navigate this workflow for theming Drupal. Pixel precise designers are much easier to find. But here's the problem with pixel perfect design: it relies on exact markup. Drupal is markup-heavy and can drive a themer crazy if every single tag, and every single class must be exactly perfect. These days, it's easier to skip the "static" step and get into Drupal as fast as possible. Sure, you'll still want to refactor some markup (or maybe just start with a different base theme), but the point is that you aren't starting from thin air.

Themers who want markup purity tend to be coming at their work from an Model-View-Controller (MVC) perspective...which isn't what Drupal does. We're a Presentation-abstraction-control (PAC) framework. The main difference between the two (in laymen's terms) is the fragmentation of the output/markup files. Our system has lots of little nested template fragements which are compiled, or collected, into a whole. This means if you want very, very precise markup, you have to alter a lot of little files. Some of us love it because you can get really fine grained control in very tiny places without having to touch all of the markup, others hate it for exactly the same reason.

Regardless of which camp you're in, there doesn't seem to be a lot of information about building themes that talk about these software design patterns. A quick search reveals the following tutorials and articles (most are quite old). If you've got others you'd like to add to the pile, please leave them in the comments. Things get very technical very quickly...but hey, this is a list of links about software design patterns. It's supposed to be technical.

• MVC vs. PAC (from Crell in 2006!)
• Building a site on Drupal using MVC
• Drupal as an MVC Framework (the difficulties of integrating Zend + Drupal)
• An Object-Oriented Approach for Drupal Module Development (or how you will go slowly crazy if you try to treat Drupal like an MVC framework)
• A pretty awesome description of the MVC pattern and how module developers can take advantage of it (when it's appropriate): MVCZ: Model, View, Controller, and Zombies.
• (Software) Design Patterns of Drupal

As web applications become richer and more complicated the amount of JavaScript running them increases. More code means longer download times which means more waiting before your application or web site is usable. Thankfully there’s an easy solution that’s already widely used in the web development community: minification. Minified JavaScript strips whitespace and renames variables to produce a smaller download size.

Removing whitespace is pretty straightforward, but renaming variables is a more abstract concept. With tools like UglifyJS this is handled for you but here’s an example of what’s going on. Let’s look at this simple function that takes a parameter and alerts a message with that variable:

var sayHi = function(name) { alert('Hi ' + name + '!'); };

With script minification the above code will be changed to this:

var sayHi=function(a){alert("Hi "+a+"!")};

without altering the behavior of the function. As you can see, all whitespace that can be removed has been and the variable “name” was changed to “a”. The end result is the removal of 26 characters from the code. It’s not hard to see that the savings from minification will quickly add up!

You can take this one step further by wrapping your code in immediately-invoked function expressions (IIFEs). That’s a pretty scary looking name, but chances are you’ve seen these before, this is an example:

(function($) { $('h1').css('text-decoration', 'blink'); }(jQuery));

The function wrapped in parentheses is immediately invoked with jQuery as its argument. Within the function jQuery is accessed with the $ variable. Abstracting variables in IIFEs is not required though, consider this case:

(function(Drupal) { Drupal.behaviors.sayHi = { attach: function(name) { alert('Hi ' + name + '!'); } }; }(Drupal));

Minifying this code produces the following:

(function(a){a.behaviors.sayHi={attach:function(a){alert("Hi "+a+"!")}}})(Drupal);

Keeping the “Drupal” variable in your script makes sense because that’s the namespace you’re used to accessing it with and it does have meaning in the code, but by including it as an argument to the IIFE UglifyJS will replace any instances of “Drupal” with a shortened variable.

What about Drupal?

So, this is pretty cool, right? Unfortunately Drupal 7 doesn’t provide minification out of the box. Thankfully, there are contrib solutions to this problem! The Speedy module provides pre-minified scripts but unfortunately needs to be re-released every time core is updated or you need to re-minify the files yourself on core updates.

I wasn’t completely satisfied with this approach so I built uglify.me and a companion Drupal module, UglifyJS, to do script minification on the fly. uglify.me isn’t the only “minifier-as-a-service” out there, but I wanted to be able to throw something up quickly and be fairly confident that it wouldn’t upset some other poor developer out there hosting their own service.

The uglify.me service accepts POST requests of un-minified JavaScript and returns the minified version. Simple! The UglifyJS module provides an API to expose Drupal scripts that should be minified:

/** * Implements hook_uglifyjs_info(). */ function mymodule_uglifyjs_info() { return array( drupal_get_path('module', 'mymodule') . '/js/mymodule.js', ); }

The downside to this approach is that each script will create another request to the uglify.me service when the site cache is cold. If you expose a lot of scripts to the UglifyJS API this will be time consuming and could cause timeouts.

If you’re running Pressflow 7.20.1+ or apply this patch to core and you have JavaScript concatenation enabled (which you should, if you’re in production) the UglifyJS module will automatically minify the concatenated scripts. This greatly reduces the number of requests to the web service and overhead associated with minification.

Caveats

The biggest issue that I’ve encountered with this module is the requests made to the external web service. If there’s a problem connecting to the remote server the time spent waiting for the response is wasted and can cause timeouts on cold caches. This is mitigated if you’re using Pressflow 7.20.1+ since core will not request files to be rebuilt if the hash of the concatenated scripts did not change.

The uglify.me service also currently strips some header comments from scripts which would could remove any copyright or license information if they exist. This should be fixable from the uglify.me service, so if it’s bothering you and I haven’t had time to fix it before you need it, As of uglify.me v0.1.0 any comment containing the words “license” or “copyright” (case insensitive), or the common build tags “@preserve” and “@cc_on” will not be stripped from the source code. This is controlled by a regular expression so if you find a general case that’s not met by the current regular expression open a pull request to fix it!

Conclusion

Script minification is a great way to reduce your site’s download footprint and increase usability. If bandwidth and performance are concerns you should be minifying, regardless of your ultimate solution. Informal testing on the recently released Full Plate Living site showed reduction in the front page’s download weight by an average of 110KB*. Not monumental, but not too bad either.

Happy minifying!

* Note: The UglifyJS module is not currently in use on the production Full Plate Living site, but it likely will be soon!

Do you love FileMaker? Do you work with (or for!) someone who does? I’m now a Drupal Developer at Mediacurrent, but my last position (at Georgia Tech’s Office of International Education) involved a lot of FileMaker work, and this FileMaker integration would have been a lifesaver, so here goes!

This post is a quick addition to my previous tutorial: Loading Only One Field From An Entity or Node in Drupal 7. The tricky part there was what to do with node's field data and how to properly display it? Well there are lots of approaches there, but I see three which are of “Drupal Way” kind:

Read on about Working with Drupal Fields: Getting Single Field Values For Display and Manipulaton

Hey guys,
I'm going to be putting together a mini-series on Newsletters in Drupal 7. Just about every site can benefit from having a mailing list, so I figured I'd flesh out the options that are available, right now, for Drupal 7. I'm hoping to have someone on the show to talk about each of the following modules.

Tags:  newsletters, planet-drupal

In the 7 video of this 10 part Drupal video tutorial series on the Views module, we look at the Views API and how to integrate a custom module with Views 3 so that we can build views based on our custom content.

The Views API allows you to leverage the awesomeness that is the Views module when you are doing custom Drupal development and so I show you how to link up our database fields to view fields, filters, sorting, arguments and relationships.

Once this is done, I walk you through building another view based on our custom module and again, we take a quick look at using relationships and contextual filters.