Planet Drupal

The Boost is often a great help with speeding up web sites of small to medium size and/or hosted on shared hosts. It works by writing the entire cached page to a disk file, and serving it entirely from the web server, bypassing PHP and MySQL entirely. This works well in most cases, but we have observed a few cases where boost itself becomes a bottleneck. One example was when 2bits.com were called to investigate and solve a problem for a Fortune 500 company's Drupal web site.

read more

When building a Drupal website, you may be considering whether to include adverts on the page.

Clicks on adverts on your website can earn you a regular income, supplementing your core business.

This tutorial explains how you can use Google Adsense to monetise your website, without annoying your existing users.

Before you start

As with any change to your website, you will need to consider how adding the adverts will affect your existing visitors.

A tactic that I use to minimise annoyance is to remove all adverts for authenticated users (visitors who have signed in).

This works because it gives visitors the choice to hide the adverts, whilst keeping the adverts for those who are more likely to click - people who found the website, but it wasn't quite what they were after.

Also, think about who will click on your adverts. I tend to think of two use cases:

1. "Passing By"

This is a visitor who stumbled upon your website, but it wasn't what they were looking for.

2. "Finished Reading"

This is a visitor who has read to the end of the webpage, and now is looking for somewhere else to go (perhaps on a similar topic).

How to implement the adverts:

In this article, I am assuming that you will use Google Adsense to serve your adverts. If you're just starting out with adding adverts, this is a good choice, as it is easy to use and provides good returns without a lot of configuration.

1. Sign up for Google Adsense

In order to gain revenue from Google Adsense adverts, you'll need to register on the Google Adsense website.

You will need to fill out some details about yourself and your website, so that Google knows that your website will be suitable for ads and that they can pay you correctly.

2. Create "ad units" in Google Adsense

For every type of advert that you would like to show on your website, you'll need to create an ad unit on the Google Adsense website.

You will need a different advert for each size of advert, and for tracking advert revenue via different channels.

You can show each ad unit as many times as you like on one page, but each advert served by a single ad unit will be based on the same settings.

It can take about 10 minutes for a new ad unit to work on your website.

3. Enable the Drupal Adsense module

Whilst it is possible to use Adsense by pasting directly into custom blocks, it is better to always use the Drupal Adsense module.

The Drupal Adsense module blocks adverts from showing when the site administers are logged in (preventing accidental clicks that could lead to repercussions with Google), and makes it a lot easier to add the adverts to your website.

When you download Drupal Adsense, several modules will become available. You need "Adsense core" and "Managed ads".

4. Add blocks to your website - you need to know where you'll put them (think back to your use case)

So far, you've only set things up - now you need to add these adverts to your website.

The Drupal Adsense module can insert adverts into your website in several ways - but the simplest is through the blocks system.

All of the information for this form was provided when you created the ad unit in Google Adsense.

5. Optimise

Once your adverts have been present on your website for some time (I suggest a few days to a week, depending on how much traffic you have on your website) - it is a good idea to review your adverts.  Usually, there are some easy ways to boost revenue.

There many blog posts on the internet on optimising adsense revenue, so I will not go into it in detail.

However, I will leave you with two tips:

1. Look at the statistics given in the Google Adsense reports. You can usually use these to see which ad units have higher or lower revenues - and identify which ones to make changes to.
2. Think back to the use cases that I mentioned at the start of this article - this can help you place adverts in positions that will fit into a natural flow. For example, I find that ad units work well just below the bottom of an article.

Conclusion:

In summary, whilst adding adverts to your website with Google Adsense is quite easy, it is worth thinking ahead to design how you will do it.

Think about how you will protect exisiting visitors from being annoyed by them, and then follow the steps to make the change.

Once you have added the adverts, close the loop by reviewing their performance.

Do you have any tips that you'd like to add? Please do add a comment.

Category: WebsitesTags: DrupalDrupal PlanetGoogle Adsenseadvertisingoptimisationmonetising websites

Recently two clients wanted to have a left-column navigation menu which the user could hide or display using a link in the primary menu, one on a site with a theme based on Omega, and another using a theme based on AdaptiveTheme. It wasn't enough to call the jQuery function .toggle(), however, since by the time the page has been loaded the Omega base theme has already determined that the Sidebar First region has content and the width of the rest of the page elements have been determined accordingly. Fortunately, the Omega and AdaptiveTheme base themes use CSS classes to indicate which theme regions are active, and set the width of each region based on those classes. So, all we had to do was to swap the appropriate classes each time the we toggled the display of the menu.

As it happens this is the first time I've had to insert random bits of jQuery into a theme (up until now, there was always a module for that), and I found that the necessary jQuery wrapper wasn't as well documented as it could have been, so here's a quick tutorial.

Put the following into MYTHEME.info:

scripts[] = js/toggle.js

In the file js/toggle.js, put the following for a theme based on Omega:

(function ($) { Drupal.behaviors.MY_OMEGA_SUBTHEME = { attach: function(context, settings) { // attach to menu item "Show/Hide Menu" var showOrHideMenu = $('aside#region-sidebar-first').is(':hidden'); $('.menu-12345 a').click(function(){ if ( showOrHideMenu == true ) { // div#region-content.grid-11 $('aside#region-sidebar-first').show(); $('div#region-content').toggleClass('grid-11 grid-16'); showOrHideMenu = false; } else if ( showOrHideMenu == false ) { // div#region-content.grid-16 $('aside#region-sidebar-first').hide(); $('div#region-content').toggleClass('grid-16 grid-11'); showOrHideMenu = true; } return false; }); } }; })(jQuery);

On our Omega based site, the central content region div#region-content has the class .grid-11 when the left sidebar is active, and .grid-16 otherwise (we have no right sidebar on this site). This means that when the page is loaded, the menu is displayed and the content region has class .grid-11. Clicking the menu item with ID 12345 will hide the menu, and change that class to .grid-16, which has the effect of making the content region wider. Clicking this menu item again will make the page return to its initial state.

The code for AdaptiveTheme is very similar, except that the magic CSS classes which list the active regions are on the body tag, and in this case we had to toggle the right sidebar:

(function ($) { Drupal.behaviors.MY_ADAPTIVETHEME_SUBTHEME = { attach: function(context, settings) { // attach to "Show/Hide Menu" var showOrHideMenu = $('.region-sidebar-second').is(':hidden'); $('.menu-12345 a').click(function(){ if ( showOrHideMenu == true ) { // body.one-sidebar.sidebar-second $('.region-sidebar-second').show(); $('body.html').removeClass('no-sidebars'); $('body.html').addClass('one-sidebar'); $('body.html').addClass('sidebar-second'); showOrHideMenu = false; } else if ( showOrHideMenu == false ) { // body.no-sidebars $('.region-sidebar-second').hide(); $('body.html').addClass('no-sidebars'); $('body.html').removeClass('one-sidebar'); $('body.html').removeClass('sidebar-second'); showOrHideMenu = true; } return false; }); } }; })(jQuery);

Since Drupal 7 menu items can normally only point towards external URLs or internal Drupal paths, we used the module Void Menu to allow us to create a menu item pointing to <a href="#">. Normally this would make the browser jump to the top of the page in addition to calling the attached function, but this can be avoided by returning false.

To use this on your own site, compare the HTML generated by your theme on pages with and without the region you want to toggle. You can do this by manually setting the menu block in question to not display on one particular page to see how your theme sets the content region in order to take the full width of the page. You can then tweak the above code snippet so that .toggleClass(), .removeClass(), and .addClass() switch the correct classes, and so that the function is attached to the correct menu ID.

Recently a client wanted to have a left-column navigation menu which the user could hide or display using a link in the primary menu. It wasn't enough to call the jQuery function .toggle(), however, since by the time the page has been loaded the Omega base theme has already determined that the Sidebar First region has content and the width of the rest of the page elements have been determined accordingly. Fortunately, Omega uses classes on div#region-content to indicate which theme regions are active, and sets the width of each region based on those classes. So, all we had to do was to swap the appropriate classes each time the we toggled the display of the menu.

As it happens this is the first time I've had to insert random bits of jQuery into a theme (up until now, there was always a module for that), and I found that the necessary jQuery wrapper wasn't as well documented as it could have been, so here's a quick tutorial.

Put the following into MYTHEME.info:

scripts[] = js/toggle.js

In the file js/toggle.js, put the following:

(function ($) { Drupal.behaviors.MYTHEME = { attach: function(context, settings) { // attach to menu item "Show/Hide Menu" var showOrHideMenu = $('aside#region-sidebar-first').is(':hidden'); $('.menu-12345 a').click(function(){ if ( showOrHideMenu == true ) { $('aside#region-sidebar-first').show(); $('div#region-content').toggleClass('grid-11 grid-16'); showOrHideMenu = false; } else if ( showOrHideMenu == false ) { $('aside#region-sidebar-first').hide(); $('div#region-content').toggleClass('grid-16 grid-11'); showOrHideMenu = true; } return false; }); } }; })(jQuery);

In our case, the central content region div#region-content has the class .grid-11 when the left sidebar is active, and .grid-16 otherwise (we have no right sidebar on this site). This means that when the page is loaded, the menu is displayed and the content region has class .grid-11. Clicking the menu item with ID 12345 will hide the menu, and change that class to .grid-16, which has the effect of making the content region wider. Clicking this menu item again will make the page return to its initial state.

Since Drupal 7 menu items can normally only point towards external URLs or internal Drupal paths, we used the module Void Menu to allow us to create a menu item pointing to <a href="#">. Normally this would make the browser jump to the top of the page in addition to calling the attached function, but this can be avoided by returning false.

To use this on your own site, compare the HTML generated by Omega on pages with and without the region you want to toggle. You can do this by manually setting the menu block in question to not display on one particular page so we could see how Omega set the content region to take the full width of the page. You can then tweak the code snippet above so that .toggleClass() switches the correct classes, and to attach the function to the correct menu ID.

There are currently 75 new Drupal contributors awaiting review of their first project. This is a great place to contribute to the community and learn about interesting upcoming projects, for example...

Module: PHP Execute Extended Tools What does it do?

The Devel module is a key part of many Drupal developers' jobs, including mine. Along with many other useful features, it provides a simple form to run arbitrary PHP code in the context of Drupal, allowing you to quickly test bits of code before putting them in a more permanent location.

The PHP Execute Extended Tools module extends this form, adding history and syntax highlighting. History allows you to re-execute past code snippets and syntax highlighting makes code snippets easier to read.

Look Useful? Review it!

If this sounds like something you'd like to see readily available on Drupal.org, you should review it and help make that happen.

Review It

Pro Tip: If you've never reviewed a project application before, you can find instructions for reviewers on Drupal.org and the Code Review group is happy to help more people get involved.

There are some times in Drupal 6 where you push the limits of what the blocks interface can do. If you need to display the same block, multiple times on the same page, you will start to see these limitations. An example of where this is useful is a Newsletter signup form. Sometimes a client may want a newsletter signup form to be in the footer of every page, but also displayed more prominently on the contact form page.

Post Topics:  Drupal Core Concepts Blocks Drupal 6 Module Development Drupal Planet Tips and Tricks

read more

Lullabot is a 100% distributed company: here's how we've learned to keep things running smoothly! In the beginning

When I tell new acquaintances that I work for a distributed company, they inevitably ask: “You do all of that from home? How?” We discuss this how on a regular basis, but haven't taken these conversations outside our figurative halls. In this article, all will be revealed!

Lullabot is a distributed company with clients all around the world—we don’t have a single office and almost all of us work from home. You might think that means we’re disconnected (not at all!), that we are lonely (never!), or bored (ha!). You might even think we’re nerds! You’d be right on that count, but that’s irrelevant to our working arrangements.

Being distributed requires a more deliberate approach to communication and getting “in the zone.” Here are some of the highly effective habits of our intercontinental team:

Get dressed like you’re going to work

Nine out of ten Lullabots agree (this is a made-up statistic, but keep reading) that their productivity is boosted when they prepare for the day as if they’re leaving the house to go to work. That means pants! And shoes! You don’t have to bust out a suit, but readying yourself for a purpose helps you get into a focused work mode. (The fact that you don’t actually have to leave the house just makes it a little bit happier.)

Have a schedule

Announcing the 2013 Blue Drop Awards!
http://www.bluedropawards.org/ 

It's that time of year again... Time for the Drupal Community to recognize and celebrate their own accompishments. This is not an award by a Book Publisher, or Magazine, or Podcast.
The Blue Drop Awards are FOR The Community, BY The Community! 

Blue Drop Awards by the Numbers:

1 Awards Ceremony at DrupalCon Portland! [The Drupal Association is offering space for our Awards Ceremnoy March 22nd]
$10 submission fee. [This year we're upping the ante from $0 to $10]
24 Categories [20 web-based & 4 for Modules, Themes, Books, Events] See The List
9 days left for nominations at this point in time. [Nominations close on March 15th.] Submit Your Nomination!
20 Sponsors who know the value of Community Driven Awards. Become a Sponsor!
20 more questions answered in the FAQ. Read Here

I'm looking very forward to this year's competition. We had a blast last year and learned a lot about the process of engaging the commmunity for a new idea such as this. This year we've made some changes and the feedback has been tremendous. Thanks to the awesome community, the sponsors, and the Drupal Association, we are sure to have even more success this time around!

What are you waiting for? GO NOMINATE! ;-)

Drupal Planet

This week we look at how you can programatically declare your own image styles using hook_image_default_styles(). Say your module uses images that need to conform to a certain size and position in their context. You can use this hook to create a style that you can then apply to the image in the theme layer.

Entityforms module allows site builders to create survey style front-end forms without having to write any custom code. The form results are stored in the database and can be exported out. The module is integrated with Rules (What's Rules?) which gives developers a lot of flexibility.

Entityforms is very similar to Webform, however Entityforms utilises Drupal's Field API whereas Webform uses its own field system. By leveraging Drupal's Field API, you can use any module that implements its own field like Link, Date, Email and many more. Also, the user interface for adding fields to an Entityforms form is the same as adding fields to a node, you will not have to learn a new user interface.

Episode Number:  122 Post Topics:  Drupal Blocks Contrib Drupal 7 Drupal Planet CSS

The Drupal 7 Block Class module provides an easy way to add a CSS class to a Drupal block.

In this episode you will learn:

• How to use the Block Class module to add a CSS class to a Drupal 7 block
• Cases that having a CSS class on your Drupal block might be useful

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

DDoD Video: 

My Review of Drupal Camp London 20135th March 2013Darren0 commentsdrupaldrupal-planetdrupal camp londondclondon

This last weekend was the hugely successful (and first ever!) Drupal Camp London. We had the Drupal Con in London a couple of years ago, and that was an amazing event, but somehow I enjoyed this even more. I think it was a much more manageable size, smoothly executed, and well focused. A big congratulations to the organisers. I've written up my notes from the weekend, with a bit from memory where I lost some of Saturday thanks to Evernote's security breach.

Business Day

The first day was the "business day". I've been working some long hours recently so I treated myself to a lie in by not setting the alarm. I thought I'd still make it on time, but unfortunately I missed the first half of Mark Taylor's keynote on Open Source in Government and Business. I'd seen most of this presentation before at a previous Drupal UK event. One takeaway from his presentation was that government/public sector doesn't care about licensing debates (e.g. GPL vs BSD), and it's all about cost saving. Oh, that and register on G Cloud.

Next up was the bit I couldn't miss, it's MTV. Paul Reeves gave a potted history of the use of Drupal in MTV, from being an early adopter and the challenges that bought, to the current process of standardising on Drupal and the many advantages that brings (standardisation of process). It was really interesting for me, as I'm working on the project, to see our work in context. It also generated a lot of interest in all the cool stuff we've been building.

I hovered around for the rest of the day catching up with people I'd not seen for a while, catching interesting bits of the case studies being presented. Tom Phethean from CapGemini, Joe Baker from Oxfam, Rob Collyer from Janet UK, all presented a strong case for the use of Drupal and in many cases delving straight into weak points and topics that are often used as arguments against using Drupal. Scalability, performance, security, and development workflows were all covered.

The day finished with Jeffrey (Jam) McGuire from Acquia. I'd heard from a friend who had been at TFM&A that is is possible for Acquia to do a presentation that's not an out-and-out sales pitch, but it was nice to witness it myself. Almost in direct opposing position to what Mark Taylor had said at the beginning of the day about it all being about the bottom line, Jam made a lot of sense in the way he presented the idea of being "better not cheaper" and "competing on features, not price". In comparing Drupal with a closed source competitor, he commented that the implementation costs were roughly the same, the hosting and support costs are roughly the same, but you save the licensing costs and so can spend more on the stuff you care about (design and functionality?). This is a nice match with what I love about Drupal - it's not removing the need for a web developer, it's freeing them to work on the cool stuff.

Jam also discussed an article from the Guardian about security in open source software (this one?) - a point covered several times during the day, but worth repeating - open source is not less secure than closed source. He also tackled the (sometimes tricky) job of persuading clients to contribute back, saying it's like "buying it once and getting all the upgrade for free, forever". There was also an interesting metaphor involving a restaurant, where in the restaurant business it's important to own the bricks, as when you're successful, and if you lease the premises, landlords can increase the rent.

And, that was just the business day! And, there was even more to it than that. Lots of conversations were going on around the place about Drupal 8, what's in, what's out. What should have been in, what shouldn't be in. Content staging, inline editing, addressing the needs of enterprise clients.

Drupal Camp Day One

So, I missed the keynote again. Probably attributable to the massive hangover after the Drupal Camp social the night before. Somehow managed to miss my stop on the tube, and so decided to take a long walk to the venue instead to blow away the cobwebs.

I arrived just as David Axmark (one of the co-founders of MySQL) began to talk about SQL vs NoSQL. As you can imagine, he doesn't have an unbiased view on this, but he did make some points about SQL systems being well understood and developed over about 40 years, and even now starting to support dynamic columns. Oh, and he made a point about performance optimisation by using direct row access, but that sounded scary.

First session of the day, I chose Drush Make Driven Development with Steven Jones from Computerminds. This was a nice easy start for my hungover brain as I've been doing this for a long while anyway, but I did hope to pick up some new tricks, and I did - it's called Drush Remake. Thanks Steven.

Next up was "Code Driven Development" Features and Beyond, with Steven Richards. I went along to this session mainly for the "Beyond" bit - of which there didn't seem to be any. I wish people would stop calling Features code driven development. It's not. But that's another subject, for another post some time in the near future.

Then after a bit more hungover bumbling I found Steve Purkiss' Business of Community session. I'd just recently registered with the Drupal Coop, and was interested to hear what he had to say. Instead, we were treated to a really interesting film (now available online), seriously, go watch it.

After this I found myself in a presentation about the Scald module. A competitor to the Media module. This was just a good example of what the Drupal community SHOULD NOT do. Yes, the media module is not perfect, and Scald looks great, has a nice UI, but I left the session thinking how awesome it would be if there was some combination of media and scald, combining the best of both. A good demonstration of why we should be collaborating, not competing.

I'm starting to shed the hangover now, so I make my way to Greg Harvey's "Make Your Cheap VM Fly". The anti-climax is that Greg's answer is mainly just "installed Nginx". But, saying that, I did come away with some useful tips of things to try: "Percona, it's like mysql but quicker, like mariadb but less of a departure from mysql", "Drupal APC needs 128MB shm_size to be effective", "Varnish does more harm than good if you've got less than 4GB", "memcache works well with about 512MB".

I've been doing loads of migration stuff recently, so I was excited about Ed Crompton's "Testing for Large Scale Data Migration". He presented an interesting idea, and one that I had not considered, which is to use WebTestCase (part of Drupal's SimpleTest), to test content that had been migrated. The idea is that you extend the WebTestCase class to stop it cloning the DB, so you can run tests against the current DB - scary! The base MigrationTestCase that was presented also did some other useful stuff, like loading up source and destination rows, and providing logging to CSV. This all sounded fun, but I was unsure of the point. I'd achieved exactly the same by logging exceptions as part of the migration process. There may be benefits from writing your tests separately to your migrate code, but is it worth dealing with slooooooow SimpleTest?

To end the day, I went along to Marcus Deglos' Vagrant crash course. I've heard a lot about this tech over the past few months, and I've been meaning to check it out. I already use separate VirtualBox environments for my local dev, so I'd already had to solve some of the issues (like using Samba to get around permissions problems). I'd seen a video recorded at a previous Drupal Camp somewhere else in the world (I forget where) which had left me thinking it was going to be more difficult than this, but Marcus made it very clear. He's even provided his Vagrant scripts on GitHub to make it even easier.

SUNDAY

I made it in on time for the Keynote! Yay. I definitely didn't want to miss this, as it was about Drupal distributions. I wasn't sure what was going on at first. Robert started in monotone, and I started getting this strange sense of deja vu. Then I realised he was reading something, a blog post by Dries perhaps? I was right, but I didn't realise how old the post was until he said. It was Dries' post from 2006 about distribution support in D5. The promise of Drupal Distributions has been slowly burning (very slowly) since then, and only now has it really started to take hold. But, as Robert explained, we can do much better.

Robert used the image gallery example consistently throughout his presentation. Starting with the original image module, we had an "image gallery" feature in Drupal, but over time we abstracted it and we're left with Views, Image fields, etc. Drupal has these great building blocks, but we don't have a killer image gallery. Robert demoed the slick UI of Facebook or Google+ image galleries, and then compared this to the best we have now, a nine step "recipe" for building an image gallery in Drupal. Robert tells us we have to "bring it home". And this is the promise of Drupal distributions, and Apps.

What's an App? This is something I looked at briefly, back when I used to think features was the answer. But, then Apps were very new, and not really being used. Now they are starting to appear in the main Drupal distributions, and Commerce Guys are even launching an App Store for their Commerce Kickstart distribution. I'd already been discussing Apps with Kristof Van Tomme on Friday evening, and I'd started to realise I probably want to build an App, not a distro (more about that in a future blog post!). I'd been put off by the use of Features before, but I'm starting to look at it again. There are lots of technical hurdles to overcome, such as managing shared configuration. If you've tried to do anything with Features you'll have come across this problem when you start getting conflicting features. This isn't such an issue with "distros with a common lineage", as Robert puts it. I.e. The distros from the same vendor, such as the OpenPublish, OpenAtrium, OpenPublic distros from Phase2. http://www.phase2technology.com/

But, the biggest hurdle we have to get across, is the concept of paid for apps and commercial modules. Unlike Wordpress, that has a thriving marketplace for commercial themes and paid for extensions, this has been a very controversial topic in the Drupal community. This conversation continued later in the day in a BoF...

A quick coffee, and a chat with George Boobyer about the question I'd asked during the keynote. Yeah, I'm not using Features, and I haven't for some time, but sometimes I feel like the only person who's given up on it. It's not really code driven development. There is a better way. I'll blog more about this, as clearly not many people have realised yet! I think George agreed, but I very rudely ran away as I didn't want to miss the first session!

Queue.

I'd used the Drupal 7 Queue API for the first time on the TrueTube website for managing video submissions and transcoding. It was only while working on the MTV project that I realised the full potential of using queues. I now want to use queues for everything. It's so liberating, and it really makes the admin area of sites snappy and responsive. No more waiting around for and edit form to submit. Offload all the processing, anything that doesn't definitely have to happen on the page request should be queued up for asynchronous processing.

Tom Phethean from Cap Gemini gave a good overview of the Queue API, and had some good tips and tricks along the way. There was some discussion of simple in memory queues, vs reliable database queues, and I realised I should probably look at the STOMP protocol at some point. One phrase that stuck in my mind was "death by log", a horrible thought, and I made a note to look at GrayLog at some point. I'm using Beanstalkd as a queue system, which got a mention, and I had to ask about demonising PHP. I'm using Supervisord, although we've not put this into production yet. Tom said he'd not tried this approach yet, and recommended lots of testing! I made a note to look at Drush queue running, rather than using the queue runner provided by the beanstalk module to see if that offered any advantages.

Next up, Jim from Code Enigma packed out a full room, probably of worried themers, as his session was titled "Death of the Themer". The basic premise was to remove the theming job and replace it with configuration. For someone who likes to do as much as possible in code, I wasn't sure this was going to work for me, but it sounds like it could still be compatible with my approach. I made some notes to try a few things, and perhaps I'll blog the results. Jim's basic premise is that the front end designers should be free to do what they do best with all the cool latest tools they like to play with, and Drupal shouldn't get in the way. There was a huge impromptu round of applause when Jim flashed up clean HTML output from Drupal. :)

The actual sessions part of the camp was nicely concluded by Ronald Ashri's session "Architecting Drupal Modules". As Michael Lenahan pointed out, it's like being back at uni. Ronald's academic background is clear in his presentation. I remember seeing a session he did on the Entity API back when Drupal 7 was new, and having a lightbulb moment, and this was another of those sessions. "It's not about the recipe, it's about the principles", Ronald tells us. We have to stop talking about problems in Drupal language, and Ronald points out that if we change the way we talk about problems, we change the way we think about them.

Ronald explains a hardcore application of MVC to building Drupal modules. In terms of the logic bits, he talks about presenting your functionality in clean OO patterns, and separating it from the "Drupally" stuff like submit handlers. "Solve your problems, then solve Drupal's problems". There were some questions about use of entities as the "model" bit of MVC, to which Ronald replies, "it's true that Drupal is not a clean model, but if you think about it in that way then you are clear of the compromises you are making."

I spent a large portion of the afternoon in a lively BoF on the subject of distributions, apps and paid for Drupal extensions. There was some talk of the technical challenges, although several attendees dismissed them as "just technical issues". I would have liked a bit more discussion on this, as I find it hard to see how an wide open market place for apps could ever work with any level of compatibility and interoperability. We would need common scaffolding in terms of the environment that the app is injecting into. Managing shared (and possibly conflicting) configuration seems like a very hard problem to solve. I had a look at nedjo's work on app compatibility, and it is excellent work, but we'll have to agree on lots of standards and it's much more than just shared taxonomy and user roles. That would be a great start, but there's a lot more to it than this.

Anyway, the BoF focused instead on the commercial aspect, and I agree this is the biggest hurdle, as it requires a cultural change in the Drupal community. Robert told how there was a starting to be a shift in opinion as he recalled a previous session a few years earlier where the idea was met with a lot of resistance. Robert picked up on something that Ronald Ashri said, and commented "notice the shift in audience, selling to travel agents, not site builders".

Several of the BoFers said they would be happy to pay for smooth execution of a feature. Only one person at the BoF had a strong objection to commercial modules for Drupal. Robert gave an example of a wordpress plugin that was initially uploaded to the Wordpress site for free, but was eventually taken off the free market and went commercial. Rather than the backlash that was expected the guy received more thanks from users who's clients were happy about the change as before were reluctant to trust it because it wasn't commercial.

Some hypothetical scenarios discussed included what would happen if something like Views had been commercial. Would this have been an incentive to not move it into core? Suggestions were that Apps would not be building block modules, but rather well developed features for a specific use case.

It's a difficult topic and there are opportunities out there. Wordpress has a huge market for paid for extensions. Drupal looses third party app vendors because there is no market place for them to sell, so there's no incentive for them to build modules. But, Drupal attracts big enterprise projects because of the strength of it's eco system and solid foundations. Would commercial modules and app stores dilute this?

Well, it’s been a little over 9 months since we launched the new drupalcommerce.org. As most Drupal developers have experienced, our “wishlist” of features continues to be longer than we can invest at any one time. But we’ve been patiently adding and improving on the site since we launched. Today is a special day because we’ve retired our old modules listing and launched a number of new features for our questions & answers tool.

We've got all kinds of new features and pretty screenshots to share after the break.

We first blogged about Drupal Commerce in late 2011.

Since then, there have been some huge changes in the Drupal Commerce world.

• Drupal Commerce grew enough to pass Ubercart as the most popular shopping solution for Drupal.
• A good number of large and prestigious sites moved to Drupal Commerce.
• Commerce Kickstart, their distribution which allows people to get a store up and running quickly, become the most popular Drupal distribution.

Version 2 of Commerce Kickstart was recently released and it provided a complete redesign. So we decided to take a look.

Start:  2013-03-10 16:00 - 19:00 America/Chicago Related event (ie. not Drupal specific) Organizers:  cecycorrea Event url: 

http://drupalsxsw2013.eventbrite.com/

The Drupal Genius Bazaar is your time to come network with the brightest minds in the Drupal community at SXSW 2013!

At this happy hour, you'll get to talk to leading Drupal professionals in a relaxed environment. Drink tickets for the first 300 folks at the event. (Talking to our sponsors at the event can get you even more!)

If you work in Drupal and would like to talk to other Drupal professionals, this is the event for you. If you are considering making the change to Drupal, this event is a must if you want to learn about what Drupal can do for you.

Note: You must RSVP through Eventbrite! Using the "Sign up" button below will not guarantee you a spot.

I've posted a status update for the WSCCI Initiative, and where we stand as of Drupal 8 Feature Freeze. We've gotten a ton done, but we still have a ton to do before we can really close the deal on Drupal 8 being an earth-shattering success. If you want Drupal 8 to be an earth-shattering success, see that post for the various places that we could use help right now, and how you can get involved.

Let’s extend the flexibility of the Omega theme.  With only a few clicks, you can add and remove regions from specific pages throughout your site.  Think of it as creating custom theme tpl.php files without writing any code.

Using the Delta module (http://drupal.org/project/delta) along with the Context module (http://drupal.org/project/context), you can assign page-specific layouts using the Omega UI.  Easy!

Modules and theme used in this walk-through:

Omega (http://drupal.org/project/omega)
Omega Tools (http://drupal.org/project/omega_tools)
Delta (http://drupal.org/project/delta)
Context (http://drupal.org/project/context)

Preparations:

This walkthrough assumes you have at least completed the steps in Getting Started with Omega and Drupal 7.

1. You have Drupal installed and you are happy because you also have Omega and Omega Tools installed and working!
2. Download and enable the Delta and Context modules.

 

Creating custom page layouts with Delta

For my front page, I plan on having a large, dramatic image slideshow to highlight recent company news and press releases.  That being planned, I have no real need for most of the default regions that are supplied with Omega.  I could save on the extra markup and possible display issues with the unused regions.  However, I do want those regions available for my interior pages. 

Before the Delta module, I would need to go into my theme folder, duplicate a page.tpl.php file,  change the filename to page--front.tpl.php and then systematically go into the file and remove the code for the regions I don’t need, being careful to not make a mistake in my editing. 

Honestly, this task isn’t all that difficult and most people reading this blog have done this many times with little fuss.  That being said, the Delta and Context modules allow us to not have to.  Easier is better, yes?

1. Navigate to /admin/appearance/delta

2. Click ‘ADD’

3. The form is very easy to fill out and enable.

Notice that  the admin layout is similar to most you will find throughout Drupal, including panels, page manager and Context (hint hint).

4. Click on ‘configure’.  You will be sent to a page that appears to be the Omega theme UI.  The only difference is that you are now only making changes to the Delta version of the theme.  Notice the status message.

5. Make changes to the ZONE AND REGION CONFIGURATION tab.  For my front page with minimal regions, I disabled all Preface, Postscript, Header, and Sidebars.

 

Now that we have the template for the front page, we now have to activate it.

Setting the page argument with Context

1. Navigate to /admin/structure/context.  Click ‘add’.

2. Enter the basic information in the top of the form

3.  Select PATH from the Conditions dropdown and add the paths to which you want to point the Delta template for your front page.  I have added additional paths in order to hide unneeded regions. 

4.  In the REACTIONS dropdown, select Delta and then check the ‘Front Page’ radio button to select the template you made in Delta.

Result

Navigate back to your home page and enable the block overlay by clicking the ‘blocks’ checkbox in the upper right of your screen.  Notice the difference between the front page regions and those from an interior page.  (I have already added some basic styling to the site to make this and future tutorials prettier to look at.)

Front page regions:

Interior page regions:

Conclusion

Added to your Omega Toolbox, the Delta and Context modules allow you great flexibility and power while still keeping you, the themer, in the UI instead of the code.  With about ten clicks, we have a customized front-page template.

Quick.  Easy.  Flexible. 

Oh…and don’t forget, it’s responsive!

The Community Plugin Toolkit has been released for Open Atrium 2.0 providing the documentation needed to start building Plugins. Access to the Open Atrium 2 code base is coming soon!

We often have clients request that people register on the site before they are able to download files. This is often in order to use the files as lead nurturing. Luckily Drupal has all the pieces to make this happen even though they are a bit spread out. This is how we do it.

Modules you will need:
r4032login
luxe (or logintoboggan)
private_files_download_permission... Read more

by Aaron Froehlich

Drupal has emerged in recent years as an extremely flexible and powerful resource for creating web applications. It's done that by creating an infrastructure that simplifies the process of building new functionality and an ecosystem that encourages developers to share this custom functionality. This has been a winning approach because it appeals both to highly-skilled developers who want to contribute to the open source community, as well as relative beginners who want to build rich applications without needing to write or even grasp fundamental programming concepts. The result is an ecosystem that has really thrived, with thousands of modules and a world of possibility.

However, Drupal's strength has also created a number of real problems for developers, particularly related to the long-term maintenance of those sites. The ability to piece modules together has created what some are referring to as the "open buffet syndrome", the alluring tendency for companies to incorporate large numbers of modules to meet the needs of a given project. This approach has a major impact to the total cost of ownership (TCO) of Drupal sites. It not only complicates development tasks like maintenance, updates and upgrades, but it also complicates the administrative interface and site management. Furthermore, the open buffet approach often leads to frustration for developers, who typically prefer writing code to configuring modules, leading to what some refer to as Drupal's Golden Handcuffs. 

We believe that there is a better way to develop for Drupal, which we've been referring to as "Minimalist Drupal Development". We first began thinking about MDD after reading the Treehouse Agency's article about building the energy.gov site without Views, and it just made sense. Our years of Drupal development have proven to us just how essential module selection and implementation is for a project, and how costly poor choices become over time. MDD relies on limiting the use of contributed modules, as well as leveraging Drupal core and its APIs. This creates a more performant system with fewer bugs and fewer patches to maintain, therefore lowering the TCO of your projects. It also requires that you spend more of your time writing code than configuring modules, one of the keys to developing for Drupal and loving it.

When Cornell University's College of Agriculture and Life Sciences (CALS) came to us last year, we saw an opportunity to fully embrace MDD. CALS needed a Drupal install profile that they could use to launch up to a hundred different sites, which prioritized a simplified user interface, a robust permissions and workflow system, and a range of reusable content blocks that integrate into their page workflow. So, how did we do it?

To start with, like energy.gov, the CALS platform is built without the Views module. To achieve the client's goals, we made extensive use of the Bean module, and combined that with the Block reference module. Each page on the site includes three block reference fields that allow our custom beans to appear in the first or second sidebar, as well as in the main content area. To get them there, we simply leverage hook_page_alter() to pluck them from the render array and add them to the appropriate region on the page. This has the added (and in this case, required) benefit that all of the relevant content on the page, including the blocks placed in the sidebars, gets added to the revisioning workflow and can be reverted.

There are additional advantages to using Bean that reduce the overhead on the site. For example, CALS events are managed through a 3rd party API. The traditional approach would likely include using the Feeds module to import the data into an event content type. However, that approach introduces all the associated complexities of managing duplicated data, such as how to handle edited data in one of the systems, setting up cron to keep data current, etc. Using our minimalist approach, Bean made it trivial to grab the json feed of events, cache the results, and display the block (bean) of json nodes to the user without even needing an event content type. There's no duplicate data to unify, and it takes all of 30 seconds to provide the necessary keyword(s) to include in a new block of events and get them onto a page.

Bean is just one key strategy we employed in the service of our MDD philosophy on CALS. In the future, we look forward to blogging about other strategies, including the types of choices that allow you to leverage Drupal core, and how to judiciously choose and even borrow from modules without going for a new plate at the buffet. Stay tuned as well for more about the automated test suite we wrote using Behat and Mink, which provides a full-coverage test suite for all the key functionality of the platform and provides an insurance policy that will allow them to run security and module updates with confidence. And perhaps the most important argument for MDD, from one code loving developer to another, is that we were able to build the site while spending 95%+ of our time in a text editor rather than a browser. 

So what strategies are you using to support Minimalist Drupal Development? 

Are you a Drupal developer interested in MDD? Singlebrook is hiring!