Drupal Planet

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 43 weeks 5 days ago

Acquia: Lukas Smith on open source communication, PHPCR, and more

Wed, 2014-03-05 10:19

Part 1 of 2 - I had the great pleasure of speaking with Lukas Smith at SymfonyCon Warsaw in December, 2013. Lukas is a major contributor to open source, touching a range of projects, including the Symfony framework, Drupal, and much more. He is one of the 50 most active contributors on GitHub. Thank you, Lukas!

Categories: Drupal

ThinkShout: The Technology Behind the New ThinkShout.com

Wed, 2014-03-05 08:00

Now that we've covered the goals, strategy and process for our new site, I wanted to dive into the technology choices we made. First, the obvious: unlike most of the sites we've launched over the last four years, this one is not built with Drupal. Instead we used Jekyll, one of a fast growing list of static site generators (SSG), along with Foundation 5, GitHub, and Amazon S3 for hosting.

So, why not Drupal?

We love Drupal. We're committed to it. We actively contribute to and participate in the community. But the reality is that Drupal is not the right fit for every project. Structurally, our website is fairly simple brochureware along with a blog. That does not fit the criteria that we generally tout as Drupal's strengths, namely complex data structures, custom applications, third party integrations, and numerous features encapsulated into a single website. In addition, we wanted our website to focus on our clients and the ThinkShout team, and we were excited about the flexibility a Jekyll site afforded us in crafting unique user experiences for each section and page without having to do battle with Drupal's theme layer and developer workflow to achieve them.

Our own website afforded us an opportunity to leverage a new technology and development process at a much lower risk point than doing so for a client. Keeping in mind all the Drupal caveats I've already stated, we have always avoided calling ourselves a "Drupal shop", whatever that actually means. What we don't waver on is providing value to our forward-thinking clients by crafting elegant user experiences and leveraging open source technology; this often, but not always, means using Drupal. Our new site allowed us to explore the process of building, launching, and maintaining a Jekyll site so we can better evaluate the kind of client engagements it would be a good fit for.

Finally, we wanted to use Jekyll just because we could. We are geeks and technologists at heart, and love trying new things. That can be hard to do sometimes when demand for Drupal is so high and we're keeping busy with our client engagements. Using a new platform for our own website gave us an opportunity to experiment and learn with a concrete goal (and schedule!) more or less on the clock. Sounds like a win to me.

Some Jekyll benefits

The following list is far from comprehensive, but includes some of the things we were most excited about using Jekyll this first go around.

Project velocity

Since we already use Jekyll and Foundation for wireframes and prototyping, we went from early concepts and prototypes to final site build in no time at all. Iterations also went much faster as we weren't encumbered with Drupal's configure/export/enable Features based development workflow.


While we are well aware that Drupal doesn't inherently limit the design and user experience of a site, it certainly can take considerable effort to bend Drupal's complex data structures and theme layer to your will. Without those limitations, we were free to push creative boundaries and explore unique user experiences. And iterate on those experiences. And experiment with new layouts for each section and even page. In short, we felt comfortable experimenting with the user experience because the cost of mistakes was fairly low.

Performance and maintenance

The final site as served to end users consists only of static assets: HTML, CSS, Javascript, and images. The speed is limited only by front end optimizations and the latency on your file server. Combine it with a CDN and the site is, as we like to say, stupid fast. Our very unscientific performance benchmark using apache benchmark for 1000 requests with a concurrency level of 100 comparing the Jekyll site staged on GitHub pages to our old site running in production on Pantheon (one of the absolute best Drupal environments out there), showed the following (Pantheon v GH Pages):

  • Requests per second: 63 vs 289
  • Time per request: 1566 vs 344
  • Failed requests: 221 vs 0
  • Transfer rate: 1629 vs 177
  • Time to complete 100% of requests: 15667 vs 1480


The process Data migration

Migration was not a major issue given the nature of our site combined with the fact that we were taking the new site as an opportunity to rework much of the copy, including our portfolio. We, did, however, need to migrate our blog. Jekyll ships with a migration class that supports Drupal, which didn't quite meet our needs, mostly due to a lack of support for taxonomy terms. We used it as a starting point, though, and with a few minor changes, had our own migration script which converted our Drupal blog history into a set of Markdown files in the new site structure. We decided to use Disqus as the commenting engine on the new site and, while there are some great examples out there of migrating Drupal comments to Disqus, and we appreciate the value of some of our comment threads, in the end we decided it wasn't worth migrating them over and are starting with a clean slate for comments.

Jekyll plugins

Jekyll plugins are written in Ruby and are processed when the site is built. There are three categories of plugins.

  • Generators create content.
  • Converters change text, E.g., from Markdown to HTML.
  • Tags define liquid tags to use in your templates.

There are number of builtin plugins which cover basic blog features and a rich ecosystem of contributed plugins, covering things like generating a sitemap.xml and RSS feeds. We did find that we needed to create a few of our own as well, which, once we got the hang of it, was very straightforward. For example, we are storing all of our team members in a data file and are generating a team member landing page for each person using a generator plugin. We also wanted to mimic Drupal's tag landing pages, so we wrote a generator plugin for that plus a filter to output the tag list on blog detail pages.

Content management

While the idea of cloning a repository and editing markdown files in one's favorite text editor is appealing to some folks, it's jut not a realistic expectation for many users, especially when you throw git into the mix. Enter Prose.io, a content authoring environment from our friends at Development Seed made for managing sites hosted on GitHub. It has special affordances for Jekyll, but can work with any static content. In addition to a nice content editor, you can define metadata for your posts presented as form elements.

This configuration:

prose: rooturl: "blog/_posts" siteurl: "http://thinkshout.com" media: "assets/images/blog" metadata: blog/_posts: - name: "layout" field: element: "hidden" value: "post" - name: "short" field: element: "textarea" label: "Short teaser" - name: "author" field: element: "text" label: "Author short name" - name: "tags" field: element: "multiselect" label: "Tags" help: "Enter one or more tags to categorize your post, E.g., Drupal, nonprofit, RedHen." alterable: true

Yields this form:

Aside from Prose.io, content can, of course, be managed the old fashioned way by cloning, adding, and pushing files via git. In addition, content be managed directly on GitHub which recently added file creation and has a nice editor and preview feature for markdown and html files.


We initially planned to host the site on GitHub pages because it handles the compilation of Jekyll source code, presents a unified project for development, issue tracking, and hosting, and is free and reliable. However, we found two critical limitations: Jekyll can only run in safe mode which means no third party or custom plugins and no support for redirect rules. After researching a few options, we settled on an Amazon S3 bucket configured for static web hosting.

  • It's super simple to add CDN support via Amazon's Cloudfront.
  • Rich ecosystem of tools and libraries. s3_website is a fabulous tool that has made it simple to publish the site with a single line command, s3_website push.
  • We already use S3 for backup/archiving at ThinkShout.
  • Support for complex redirect rules, gzip compression, and any other http headers.
  • Cheap, reliable, and, as mentioned above, fast.
Deployment workflow

Among the many reasons we love working with infrastructure partners like Pantheon and Acquia is the elegant and simple deployment workflow they provide, with automated git based deployment to a dev site and push-button migration to staging and production environments. Without the help of those platforms, we're on our own for previewing new features, staging content, and deploying code. We've settled on the following.

  • We created a separate S3 bucket for our staging site.
  • The git repository has 3 main branches, dev, master, and live. Feature branches off of Dev are used for feature development, any content or data is pushed to master which is deployed to the staging site, and content and new features are merged into live before being deployed to produciton.
  • Prose.io, where most content is managed, is mapped to the master branch.
  • We have rake tasks in the project root for deploying to staging and production, as well as building and previewing the site.

The process is far from perfect.

  • It relies on process and training, there are no enforced rules and workflow.
  • Deployments themselves are manual.
  • Content editors can only preview content within the site context after it gets pushed to staging if they don't have a local Jekyll environment.

This is perhaps the biggest gotcha we've encountered so far using Jekyll, especially as we consider which client engagements it will be a good fit for. There are promising solutions, including Development Seed's Jekyll hook project to automate deployment. We're excited to learn from our own experiences and those of others to find the best way for clients to manage their Jekyll sites.

Miscellaneous Jekyll gotchas

A lot of the challenges around using an SSG really depend on where it's hosted and others are inherent to the approach. The items below encapsulate some of our experiences and are just one data point in deciding when Jekyll or another SSG is a good fit.

  • GitHub pages and other pure "file system" based approaches don't support true 301 redirects. There are javascript based hacks which are less than ideal. Obviously a bigger issue if upgrading an existing site. ThinkShout.com is hosted on S3, which does support .htaccess style redirect rules.
  • Pretty URLs are generally in the form /about/ rather than just /about.
  • Contact and other web forms must rely on a third party system to accept and process submissions. We tried integrating a Google form and then settled on an embedded ZoHo CRM lead capture form after we settled on ZoHo as our CRM.
  • Comments must be handled by a third party provider like Disqus. Since we were excited to switch to Disqus anyways, this was a nonissue.
  • Site search must rely on a third party indexer or use a Javascript based approach that doesn't scale or handle non-text assets.

It was fun to use a different platform for our new website. We learned a lot. We love the "light weight" nature of Jekyll and the flexibility it afforded us. We view the project as a major win and would do it all over again. It gave us experience and valuable lessons that we can apply to client engagements.

But Jekyll is far from a panacea for all use cases. It presents many challenges that we don't even have to consider when using Drupal. For projects that require complex data structures, custom application development, site building capabilities for end users, and numerous integrated features, Drupal is an obvious choice. Even more importantly, for projects that need to leverage a rich ecosystem of contributed functionality that relies on a dedicated community, Drupal is an even stronger choice. And we're honored to be a part of that community and continue to engage and contribute to it.

But we had fun with Jekyll, are happy with the results, and look forward to finding exciting use cases for our clients where it will be a great fit.

Categories: Drupal

DrupalCon Austin News: 3 simple tips to getting your session selected

Wed, 2014-03-05 07:54

The call for sessions closes tomorrow at midnight, and chances are you still haven't decided whether or not you'll make the leap and submit your talk. You've presented at local camps, and watched the videos from past DrupalCons, maybe you've even thought, "I could do that!".

Well, what's stopping you?

We expect to have over 130 speakers present this year, and believe it or not, you could be one of them.

Do we have your attention? Good - now let's get started!

Categories: Drupal

Aten Design Group: DrupalCon Austin: Call for Sessions

Wed, 2014-03-05 07:16

DrupalCon Austin is fast approaching. There are already a huge number of session submissions (152 at my last count!) but there's always room for more. We're fortunate to have four folks from the Aten team helping with session selection. Here's what they're hoping to see from each of their tracks:

User Experience Design Ken Woodworth

I’m excited this year to be co-chairing the User Experience Design (UXD) track with Aaron Stanush from Four Kitchens. The UXD track is where you’ll learn all about research, prototyping, content strategy, and visual design for Drupal. Have a topic you would like to share? Submit a session! We’re looking for sessions on the following topics:

  • Prototyping for Drupal
  • Content strategy
  • Authoring experience
  • User testing
  • Design process
  • Visual design

This is an exciting time for User Experience Designers. The ways we think about content and users is evolving and the UXD track is a great place to learn how.

Front-End John Ferris

Techniques in front-end development move super fast and developers are going to have even more tools at their disposal with the upcoming release of Drupal 8. I’m excited to have the opportunity to co-chair the Front-end Track in Austin along with Kathryn McClintock of Amazee Labs and Ivan Boothe of Root Work.

The front-end track will feature:

  • Twig and the new Drupal 8 theme system.
  • Front-end development best practices and workflows.

The front-end track at DrupalCon Austin will give you a headstart on Drupal 8 and provide insight into tools and current best practices for Drupal 7 and the wider web community.

Case Studies Jon Clark

DrupalCon’s new Case Studies track allows presenters to tell the whole story of important Drupal-based projects. The track is open to case studies from any field, including nonprofit, education, government, media and the corporate sector. I have the pleasure of working with Zach Chandler, Web Strategist at Stanford Web Services, as co-chairs for the track this year. We are encouraging session proposals to focus on one of three themes:

  • Breaking new ground; redefining what's possible
  • Solving common problems
  • Embracing failure as a path to success

We’re excited for this track to highlight Drupal projects that are truly innovative, that have created better solutions to problems that we all face, or that have delivered hard-fought wins after overcoming initial losses.

Site Building Karyn Cassio

This will be my first time as a global track chair for the Site Building track, and I am excited to be working with Erik Summerfield from Phase 2 in Austin, and Dann Linn from MetalToad in Portland.

Site building is where we take all 22,000+ building blocks of Drupal and put them together to create value. One of Drupal’s strengths is how much someone can do without digging into the code using multiple layout tools, data modeling, and loading little blocks of social functionality.

When submitting your site building sessions consider the following topics:

  • Information Architecture in Drupal 8
  • Flexible theming in Drupal (how will twig make themes more flexible to site builder)
  • Views (contrib) is dead long live views (in core)
  • Content layouts future (scotch)
  • Spark!
  • Websites quick and dirty
  • Building site building platforms
  • Applied content strategy
  • How to contribute as a site builder
Hurry! Submissions are due on Friday, March 7th.

You should submit yours now: https://austin2014.drupal.org/submit-session

Categories: Drupal

Modules Unraveled: 098 Indivizo - A SaaS App Built With Drupal with Bálint Kléri - Modules Unraveled Podcast

Tue, 2014-03-04 23:00
Published: Wed, 03/05/14Download this episodeIndivizo
  • First off, what is Indivizo?
  • Why is it a good approach to use video interviews in the selection process?
  • Where did the idea come from?
  • What is your target group?
  • Switching to the technology side… What’s the biggest architectural decision when building a Saas app?
  • What are the pros and cons for these two?
  • Which direction was taken with Indivizo? Why?
  • What is the server infrastructure behind Indivizo?
  • What are the key modules of the installation profile of Indivizo?
  • How are the videos recorded?
  • You mentioned a question databank. How does that work?
  • Big organizations often have existing systems in place. Can you integrate with those?
  • What is it like to build a product with Drupal
  • Where are you at with Indivizo?
NodeSquirrel Ad

Have you heard of/used NodeSquirrel?
Use "StartToGrow" it's a 12-month free upgrade from the Start plan to the Grow plan. So, using it means that the Grow plan will cost $5/month for the first year instead of $10. (10 GB storage on up to 5 sites)

Episode Links: Bálint Kléri on drupal.orgBálint Kléri on TwitterIndivizo on TwitterIndivizo WebsiteTags: 
Categories: Drupal

Darren Mothersele: My Review of Drupal Camp London 2014

Tue, 2014-03-04 17:00

Last weekend I was back at City University for the second Drupal Camp London. This year even bigger than the last, with over 600 attendees!

I reviewed my post from last year and it seems that I attended a lot fewer sessions this time around. That could be because I hadn't been to a Drupal event for a while, so I spent more time catching up with old friends and talking about the future of Drupal. I also ran two Bird of a Feather sessions on Atomic Design, Design Patterns, Death of the Themer, automated theme building, and general issues around bringing design into the development workflow, in particular for agile projects.

Friday Training day

Before the main Camp starts on Saturday there is the Business and Training day. The main CxO event is happening in another building, and has a strong line up of speakers. While this is going on I'm down in the basement of City University with Ronald Ashri giving an "Introduction to Drupal" training.

We've actually got a large group with mixed abilities so we've prepared a flexible training that covers a lot of material. Ronald prepared a comprehensive overview for the morning session. We went off-piste a few times, including some interesting discussions around configuration management and best practises. In the afternoon I prepared several demonstrations around an example site with content I had automatically imported from DBpedia. This covered content type configuration, simple Views configurations, some more advanced Views, and we even touched on creating custom workflows with Rules module. We had lots of good feedback about the training so I think this day was a success! A highlight was seeing how well my demo of the Rules Link module was received. Since I discovered this module I've used it on every project, so it was good to share this with others.


On to the main Drupal Camp...

Breakfast and chatting

After getting directions from the very hospitable Alex Elkins from City University, I arrive in time to find breakfast being delivered. There are several familiar faces around, so I take the time to catch up with people I haven't seen for a while.

After leaving the canteen and heading out towards the rooms where the sessions are taking place, I made a stop in the "sponsors room". This room seemed a bit strange to me. Why would sponsors pay a premium to be hidden away in a room off to the side? Last year you couldn't move for sponsors, they were all over the place! But I guess this is a side effect of the growth of the camp, and needing more space. Anyway, I decide to pop my head in to see who's around.

I had a great chat with the guys from Pulsant about their various options. At first I was surprised that they hadn't heard of Docker, but then perhaps not everyone is as excited about this as me. I'm using Docker extensively now in Apiary and I do believe it will revolutionise our industry. Anyway, I quickly realised that this wasn't Pulsant's thing anyway, they are focused on the actually boxes and wires that run this stuff, and they seem to really care about getting that right. I've seen them supporting lots of UK Drupal community events, so it was great to finally speak to them.

I then got talking to iKos about the work they are doing with Drupal Commerce and SagePay. This is something I'm probably going to be making extensive use of on a couple of projects, so I'll plug their free ebook Integrating Drupal, Commerce and Sage Pay. Well worth a read.

Entity operations

All this chatting means I miss most of the first session and just make it in time for the end of Joachim's presentation of entity operations. I bump into an old colleague on the way out who's excited about going away and building some custom entities so I guess Joachim must have given a persuasive demo!

Demo Framework

Another coffee break, more chatting and I almost miss the next session, but determined to actually see something I rush off to find Annika's session on the Demo Framework. I hadn't seen the Demo Framework before, but essentially, it looks like a distribution of Drupal with EVERYTHING in it, pre-configured to show off some of Drupal's sexiest features.

From a technical point of view I really liked the combination of features and migrate module to create demo scenarios. With Features packaging up the functionality, and Migrate module used to package demo content.

There was an amusing question from someone after this presentation who asked if it was dangerous to show clients all this functionality up front. They seemed concerned that it would then be hard to justify high prices after the client had seen all that Drupal could do. I think perhaps this person should attend one of Jeffrey McGuire's sessions on selling the benefits of Drupal and open-source. My own opinion is that that you should always be providing value, and that when you provide value to a customer, it should not be hard to justify your price when it's based on the value you provide.


Doesn't feel like I've been here 5 mins and already I'm eating lunch? It's no break from the Drupal action though, as Daniel from Kendra Initiative has got a few people together to show off the mockup I made for a collaborative rights management tool for musicians. This is the start of a Technology Strategy Board funded project to develop an application to manage collaboration, metadata and rights, so I may well be blogging about this again in the near future.

Rules Rule Commerce

This session was pitched as an intermediate session, so I took along Alice, who is a relative newcomer to Drupal, but has been picking it up really quickly. Unfortunately, Sven's session was more of an introduction so there wasn't anything new here.

Harmony Forum

After leaving the Rules session I bumped into some people who had just come from a session around the corner on Harmony Forum that sounded excellent. Drupal is lacking a good Forum option, so I was interested to hear what this was about.

The most exciting thing in the open-source forum world at the moment is Discourse. I had looked at integrating Discourse with Drupal a while ago but not got very far with it. There's an existing Drupal module, but it proxies all requests via Drupal (which seemed like a bad idea from a performance and maintenance point of view) and it works against an old version of Discourse. I strongly believe in using the right tool for the job, and that not everything has to happen in Drupal, but this "integration" seems far too tightly coupled.

I'm undecided if integrating with Discourse, or building a modern forum solution natively in Drupal would be the best course of action. I think the answer will depend on the scale of the site in question. On smaller sites it makes sense to have everything under one roof, but I think for larger sites a separation of concerns offers extra scalability options that may be worth the overhead of supporting two systems. It's good that we potentially have both options.

Next Generation DevOps

Barney Hanlon gave us a tour of state-of-the-art DevOps in what he called the "Five Stars of DevOps". Namely: Monitoring, Security, Performance, Automation and Scalability.

As I tweeted at the time, this was a real highlight of the Camp. I've been doing a lot of DevOps stuff recently, it's a really exciting area to be working and it's advancing quickly, so it's always good to hear what other people are up to. Barney presented this stuff really clearly and obviously knows his stuff. The slides from his presentation are available here.

In large-scale Drupal deployments I always encourage scaling out over scaling up. With effective DevOps automation, the pain of maintaining multiple systems is reduced, so you can benefit from using the most appropriate technology for each task. Barney summarised this with the question:

Am I doing something in my application that is done better by the infrastructure or an external service?
- Barney Hanlon

I've been making extensive use of Puppet throughout my DevOps work. It's based on Ruby, and I found the Puppet configuration files easy to work with. Barney highlighted something that had been bothering me about the Puppet approach, in that you need to have the Puppet Agent on the machine before you can provision it via Puppet. Not quite a chicken and egg style paradox, but it does mean you need someone other mechanism to first bootstap the machine and get the Puppet Agent on to it. Barney, instead recommends the use of Anisble. This is a pure SSH-based approach so needs no extra software on the machine to get started. I plan to move Apiary's initial bootstraping process to Ansible and still make use of Puppet, but then probably soon move all the configuration into Ansible.

Barney presented an interesting stack he called the "SPDY sandwich". It had multiple instances of Nginx with different responsibilities. I've done this before for various reasons including load balancing and SSL termination, but Barney is using two layers of SPDY/Page speed optimisations. Perhap's now it's time to go and look again at supporting SPDY! This blog post seems like a good place to start, any pointers welcome!

Barney re-iterates his point about not doing things in the application that can be done better by infrastructure, and he demonstrates this point using an example where he configures OpenResty to manage CSRF tokens. OpenResty is a web application server built on Nginx making use of the Lua scripting language. This opens up a whole new world of possibilities!

And of course no presentation on DevOps would be complete without some talk of Docker. I think I've said this before, but Docker is going to revolutionise our industry. Barney explained some of the current limitations (runs as root!) but Docker is still not ready for production and in heavy development. I did like the example scenario he gave where PECL dependencies could be installed in a Docker container and shared.

BoF - Death of the Themer

I finished the day with some impromptu BoF action. I was keen to get James Panton and Jamie into a room to discuss some of the ideas I've been having recently around challenges of bringing design activities into a development workflow (in particular Agile).

Last year James had presented on the Death of the Themer, and Jamie has been doing a lot of work with atomic design and live style guides. Unfortunately, they were coming to the Camp on different days, so I had to run two separate BoFs.

I'm going to write up the BoF notes and post them here separately. If you're at all curious about atomic design, style-guides, or automated Theme generation drop me a line, or look out for an announcement on Twitter.

Sunday Measuring Success (Piwik)

My training partner from Friday, Ronald, starts Sunday with a discussion of analytics. A lot of what he says applies to any website and analytics software combination, but I'm particularly interested in the fact he's using Piwik. I've been hearing a lot about Piwik recently, and I've been meaning to check it out. You may remember I mentioned it on a post in my "Cloud Survivalist" series, as Google Analytics is the only Google service I have not yet found a replacement for.

I'd already decided, after talking to Ronald on Friday, that I was going to start using Piwik, but it was good to see it in operation. Ronald gave some good examples, including tracking content items wherever they appear, not just looking at page views. He did this by showing how to add tracking codes to content items in any view mode, so they are tracked in lists and views as well as full page view.

Ronald shared a couple of tricks they have implemented to use learnings from analytics to drive content placement. He showed how you could use activity to automatically optimise content placement by doing things like moving items in a nodequeue on CRON based on reading data from the analytics API.


Paul Reeves gave an in-depth look into the guts of the new Drupal 7 powered platform at MTV. I'd been involved in the architecture and development of this, but it was good to hear Paul explain the wider impact of the work we did.

More BoF...

The BoF continues from yesterday. As I said before, I'll post my notes up as a separate post, probably some time next week.

Wrap up

I might have attended fewer sessions than the previous year, but I left Drupal Camp feeling like the weekend had been a success. The sessions were just a small part of what Drupal Camp is about. It was more about the conversations, meeting up with old friends, making new connections, and throughout all this seeing common threads of conversation, perhaps indicating the current Drupal zeitgeist, namely...

  • Drupal 8 is not going to be ready this year.
  • Drupal 7 is the best it's going to be. D7 is a solid robust platform for developing on, and deserves a life beyond D8, a Drupal 7 LTS perhaps?
  • Rules Link is an awesome module
  • DevOps!
  • Atomic design is more than a current trend, and there's an opportunity for design to become a more integral part of the development workflow.

(or maybe that's just me).

Finally, a big thank you to all the organisers: Tim Deeson, Hedley Smith, George Hazletood, Leon Tong, Ben Wilding, Alex Burrows, Della Deme, Farez Rahman, John Kennedy, (did I miss anyone?).

Oh, and of course City University!

Categories: Drupal

Metal Toad: Drupal vs. WordPress? Who Cares?! They Are Both Open Source.

Tue, 2014-03-04 16:57

Every week I hear about someone choosing WordPress over Drupal (or vice versus). While there are certainly differences between the two platforms, they are more alike than people typically care to admit:

  • Both are used as content management systems.
  • Both are built on the LAMP stack.
  • Both are free open source.
  • Both are supported by massive and highly active communities
  • Both are significantly better than the traditional closed source alternatives that are still entrenched in the enterprise.

For the visually inclined the overlap of just the LAMP stack is shown here:

Categories: Drupal

Drupal core announcements: Join the extended Drupal 8 sprints in Austin from May 31st through June 8th!

Tue, 2014-03-04 10:28

We have a great tradition of extended sprints around big Drupal events including the ones we did around DrupalCons in Prague, Portland, Munich, Denver, as well as Drupal Dev Days like Szeged, Dublin and Barcelona. While there is a sprint day included in DrupalCons (usually) on Friday, given that a lot of the Drupal core and contrib developers fly in for these events, it makes a lot of sense to use this opportunity to start sooner and/or extend our stay and work together in one space on the harder problems.

DrupalCon Austin is next up! DrupalCon and the Drupal Association continue to recognize the need for extended sprints as part of the schedule and are providing space on Monday, and helping organize space for the weekends before and after also! We are still looking for additional sponsors for the weekend sprints before/after to help with coffee, tea and maybe food.

Travel Plans

Now is the time to consider if you can be available and book your travel and hotel accordingly!

Practical details
May 31st (Sat), June 1st (Sun), and June 7th (Sat) and 8th (Sun). (There is already a DrupalCon sprint day on Monday June 2nd and Friday June 6th 2014 at the DrupalCon venue as well).
We start each day at 9am and have space booked until midnight.
Sign up, join the fun Sponsors

Lead sponsor: Drupal Association

Looking for sponsors

We are looking for more sponsors to be able to pay for extra expenses. If you are interested sponsoring or if you need sponsors to cover expenses, please contact me at https://drupal.org/user/258568/contact

#node-310893 .picture, #node-310893 h3 { display: none; } #node-310893 .field-type-datestamp { margin: 0 0 2em 0; } #node-310893 dl { margin-bottom: 1em; } #node-310893 dd { margin-top: 0.5em; } #node-310893 h3.content { display: block; }
Categories: Drupal

Drupalize.Me: Exploring the New Drupal 8 Display Modes

Tue, 2014-03-04 10:17
Last week as I was looking over the Drupal 8 landing page on Drupal.org, I noticed a section titled "Customize display and form modes" and my curiosity was piqued. I fired up an instance of Drupal 8 on Simplytest.me to take a look. After a bit of poking around, and a little bit of confusion, I sorted out what this new feature means for us. It's a pretty neat thing, but let me start by explaining the roots of this in Drupal 7, with the concept of "view modes."  
Categories: Drupal

mark.ie: Drupal Open Days Ireland 2014 Announced

Tue, 2014-03-04 09:51
Categories: Drupal

Drupal Association News: A Million Drupal Sites... And Counting!

Tue, 2014-03-04 09:32

It’s official! According to the Drupal.org project usage stats, Drupal has more than a million sites (1,005,489 as of February 15) live and in production on the web. Here is a link to the press release

Categories: Drupal

DrupalCon Austin News: DrupalCon Austin Call for Case Studies

Tue, 2014-03-04 09:03

Dear Drupal World, we are excited to offer you a new track for DrupalCon this year, it's name, Case Studies. This is the artist formerly known as the Higher Ed, Non-Profit, and Government Track. We think that boiling this track down to the heart of the matter -- case studies-- is a smart move that also opens up submissions from media and corporate projects.

Please consider submitting a case study before the deadline of March 7th!!

Categories: Drupal

Drupal Easy: DrupalEasy Podcast 124: 78 in Pasadena, 79 in Orlando

Tue, 2014-03-04 06:43
Download Podcast 124

Christefano (christefano) and Lee Vodra (nodiac), co-founders of Exaltation of Larks and DropLabs and Nate Craddock (nate_craddock), Drupal developer at Princess Cruises join Ted, Andrew, and Mike to talk about Greater Los Angeles DrupalCamp - GLADCamp. A few mentions of Florida DrupalCamp, the battle for the body field, and Drupal 8 versioning also find their way into the podcast, along with our picks of the week!

read more

Categories: Drupal

Deeson Online: DrupalCamp London: How to get the best talent into Drupal

Tue, 2014-03-04 03:34
DrupalCamp London: How to get the best talent into DrupalBy Lizzie Hodgson | 4th March 2014Eric Gaffen, Global Manager, Talent Acquisition at Acquia, spoke to Deeson Online to explain why nurturing great Drupal talent is important for the whole of the Drupal ecosytem. He also highlighted how Acquia are collaborating with higher education institutions to bring Drupal into the curriculum.

Categories: Drupal

Web Omelette: Adding menu items with wildcards to Drupal 7 menus

Tue, 2014-03-04 01:10

In this article I am going to share with you a quick tip on how to get your custom menu item into an actual menu on the site.

A problem I encountered when declaring a menu item using hook_menu() is that if the menu item contains a wildcard, it just won't go into the menu. You can easily specify a menu_name and if you have no wildcards, it will show up nicely in the menu you specified. If however, you need some wildcards, it won't.

I needed one such menu item (imagine that) to be placed in one of my menus on the site. After trying all sorts of things and failing miserably at them, I decided to go at it through a preprocessor function and declare my menu item there. So let me show you how I did it and maybe you can tell me some better, more correct, ways to do it.

First of all, I needed to see where my menu was being printed on the page (it was the Secondary Menu in fact). If you look at the Bartik theme in the page.tpl.php file, you'll notice the following block:

  <?php if ($secondary_menu): ?>
      <div id="secondary-menu" class="navigation">
        <?php print theme('links__system_secondary_menu', array(
          'links' => $secondary_menu,
          'attributes' => array(
            'id' => 'secondary-menu-links',
            'class' => array('links', 'inline', 'clearfix'),
          'heading' => array(
            'text' => t('Secondary menu'),
            'level' => 'h2',
            'class' => array('element-invisible'),
        )); ?>
      </div> <!-- /#secondary-menu -->
    <?php endif; ?>

This is basically where the Secondary Menu gets printed onto the page. And since it's in the page.tpl.php file, we can go ahead and write a preprocessor function for the page in the theme's template.php file. I always have the Devel module installed locally so I can debug variables, so if you are following along, make sure you do too.

function bartik_preprocess_page(&$vars) {

You'll notice I am hacking the Bartik theme but I'm only doing this for education purposes in order to see what's behind the hood. It will not go into any website like this. And make sure that if you do this, you don't redeclare the same preprocess function in the same theme or you'll get an error.

Having said that, with the function above, I am debugging the variables array that goes into the page.tpl.php file to be displayed. And what do you know, one of the keys of this array is secondary_menu. Great. Inside we have a number of elements keyed by the class name that gets applied to each menu item when it gets printed. If we look inside each element, we can gather what we need to add to this array in order for it to display another menu item: a href (path to which the menu will link) and a title (the link title that will be displayed).

If you are using wildcards, you need to make sure though that when building the href, you have all the necessary information in this preprocess function to actually build it. I needed to current user ID so that was available (plus I could always take the user object from the global scope).

So to add an example menu item, you'd do something like this:

$vars['secondary_menu']['my_menu'] = array(
  'href' => 'path/you/want/' . $id,
  'title' => 'My dynamic menu item',

Please note that the $id is fictional and you have to gather it from somewhere if you want to include it in the URL. I was just giving an example. But if you refresh the page now, the Secondary Menu should include your new menu item.


As a bonus, I'll show you how to add attributes to the item you include in the menu. If we wanted to add a button class to the menu link, instead of the above, we'd do this:

$vars['secondary_menu']['my_menu'] = array(
  'href' => 'path/you/want/' . $id,
  'title' => 'My dynamic menu item',
  'attributes' => array('class' => array('button')),

Notice the extra attributes key we pass along. There you can include also other attributes that will get processed by the core drupal_attributes() function.

You can use this same technique to add classes to existing menu items as well, not necessarily new ones you are adding. A little theming lesson as well, similar to how we added classes to form elements in the article on theming forms.


There is one problem with this approach, reason for which I kept trying to do it properly using hook_menu().

Since you are adding the menu item through the template preprocess function, it will only be displayed in the Secondary Menu of the page.tpl.php file that prints it out.

Let's say you have a block.tpl.php that for some reason needs to print out this menu as well. In this case, your new menu item won't show up. You'll have to include it in the preprocess function of the block.tpl.php as well (for e.g. bartik_preprocess_block()) the same way we did above.

In Theming | Drupal var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Categories: Drupal

ThinkShout: Announcing the Release of the PHP Wrapper for iATS Payments

Tue, 2014-03-04 01:00
Supporting iATS Payments’ Open Source Contributions The Release of Its PHP Wrapper Library

This week, in conjunction with iATS Payments, ThinkShout is excited to announce the release of the iATS Payments PHP library, a comprehensive wrapper around iATS web services exposing customer, processing, and reporting functionality in an easy to consume PHP library. Any PHP based system, including Drupal, Wordpress, and Magento, can now easily integrate the processing of online payments and donations via iATS Payments. The library includes a test suite built using PHPUnit with complete code coverage so developers can feel confident in the code they’re using and a full set of documentation generated by phpDocumentor.

ThinkShout worked closely with the iATS team to define the requirements for the library before jumping in to write the code, which we reviewed together every step of the way. The end result of the collaboration is a win for everyone involved, iATS Payments, ThinkShout, and, most importantly, the nonprofit community.

The Growing Importance of Online Giving Tools

By many reports, the nonprofit sector saw double digit growth in online giving in 2013. As nonprofits continue to invest in online outreach and advocacy, it could not be more important that these organizations leverage easy-to-use donation forms and other online fundraising tools that integrate tightly with their donor databases.

Seamless donation forms (i.e., forms that are built into an organization’s website) provide a better user experience for potential supporters. They also convey significantly more credibility and professionalism to donors that might not be familiar with the online giving experience.

Once an online donation has been received, it is critical that these financial transactions are captured within an organization’s donor database (or CRM). “Best of breed” online giving solutions integrate tightly with CRMs to provide additional donation processing features from directly inside of the CRM user interface.

Why iATS Is Our Recommended Service for Nonprofit Payment Processing

At ThinkShout, we are constantly evaluating new payment processing services that can enhance the online giving features that we develop for our clients. About a year and a half ago, we were introduced to the good folks at iATS Payments. iATS has quickly become our payment processing service of choice for the nonprofit sector.

In addition to its social mission and great customer support, iATS provides a suite of world-class payment processing tools, including one of the leading integrations with Salesforce and a robust API. We have leveraged these features for a number of our clients to build enterprise-grade e-commerce and paid event management solutions that support real-time integration between Drupal and Salesforce.

Next Steps: Deeper Integration Between iATS and Drupal Commerce

Now that we have a solid foundation, ThinkShout will work closely with iATS Payments and the Drupal community to rewrite the Drupal Commerce iATS module to make it even easier to integrate payment processing via iATS into Drupal. ThinkShout will leverage its integration experience with MailChimp and Salesforce to ensure the module is flexible enough to serve a wide variety of customized use cases while still being a powerful “out of the box” tool for site administrators. Look for a release over the next month.

Meet the iATS Payments and ThinkShout Teams at the NTC

ThinkShout and iATS Payments will be at the Nonprofit Technology Conference in Washington, D.C. from March 13th to 15th and we encourage developers and nonprofits alike to stop by our booths to learn more about the PHP wrapper and the other services offered by iATS. Stephen Bestbier of iATS Payments and Lev Tsypin of ThinkShout will be on site at NTC and look forward to discussing many facets of iATS Payments’ integrations for nonprofits. Visit iATS Payments at booth #427 and ThinkShout at booth #231 to learn more.

For more information about iATS Payments, visit their website at www.iatspayments.com.

Categories: Drupal

Drupal core announcements: No Drupal core release on Wednesday, March 5

Mon, 2014-03-03 22:02

The monthly Drupal core bug fix release window is scheduled for this Wednesday. However, the last Drupal 7 bug fix release was only two months ago, and we haven't yet had many changes to the development version since then. As a result, there won't be a Drupal 7 bug fix release in March.

Upcoming release windows include:

  • Wednesday, March 19 (security release window)
  • Wednesday, April 2 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categories: Drupal

Marzee Labs: Coding as a team: automation using Phing

Mon, 2014-03-03 20:00

Drupal development as a team is tough: finding a balance between code and configuration saved in the database is one of the hardest challenges to overcome. When working in a team, it is even more important to control the development cycle, having different people work on different features at the same time, and automate as much as possible of the repetitive tasks you’re really to do.

In this series, we’ll look at the recipes we use at Marzee Labs to make Drupal development as a team a success. The very first ingredient, and the base of everything else: automating your build processes.

Introducing Phing

We’ll start with Phing: an automation tool that replaces all your shell scripts and establishes a to-the-point development flow for your team.

Phing is a PHP build tool based on Apache Ant that does a great job of organizing tasks in targets, written using an XML-based syntax. For Drupal development, we find that using Phing gives us this extra layer on top of Drush to make building and testing Drupal sites so much easier.

Want to start developing a new feature and need a clean Drupal installation? phing build is your answer. Need to change back to the master branch and work on a hotfix? Start with phing build and you’ll be sure to not mix configuration from the different branches.

What do I need to get started?

Here are are the ingredients you need to get started with Phing and automate your Drupal development:

  • Store your configuration in code. Risking to state the obvious here: for Drupal 7 that means using the Features module.
  • Develop your Drupal site as an installation profile. This allows you to re-install your site at any given time from your profile. After you’ve launched the site and you have a production version, you also need to provide an upgrade path.
  • Use Drush makefiles to document modules, themes and libraries that constitute your project.
  • Install Phing using PEAR
A practical tutorial: building a site from scratch using Phing

Enough theory? Let’s have a look at a practical example: we’ll clone MZ Box - our Phing boilerplate - and use this build a fully functional Drupal 7 site base on our MZ profile, which contains all our favourite modules, libraries and some settings to kick off your project.

$ git clone https://github.com/marzeelabs/mz_box.git $ cp build.properties.example build.properties

This clones the boilerplate repository and creates a new build.properties file which will hold all configuration specific for your project. You should create a new SQL database and update the database connection string in build.properties.

Next, we’re going to make the project: Phing will take care of cloning the MZ profile, and calling drush make to download all the modules and themes.

$ phing make

If all goes well, you’ll read BUILD FINISHED.

You now have a full copy of Drupal core, the MZ installation profile, and contrib modules, libraries and themes in place. Now would be a good time to add all these files to the git repository and push them upstream to your new repository. Our first step is done!

Next, we’ll want to install the site. If you look at build.default.properties you’ll see that drupal.profile = mz so the mz installation profile is the default profile that will be installed. We’ll need to run

$ phing build

and - after a couple of minutes - you’ll read again BUILD FINISHED (note: you can see the entire build log on Travis ).

And voilà: you have a fully installed Drupal site. We’ve also added some goodies in the build target such as configuring a test editor account and adding a quick-switch for the Masquerade block so you can easily switch user accounts for testing.

You can run phing build as much as you want to re-install the Drupal site, and keep a peaceful mind when developing new features.

Reviewing Phing targets

If you analyze the phing build target in the build.xml file, you see that every build runs these targets:

  • site-install
  • enable-dev-mode
  • run-migrate
  • config-masquerade
  • check-features

For example, the enable-dev-mode target activates development and UI modules and disables the Views cache:

<target name="enable-dev-mode" description="Configures this installation for use in development" depends="setup-phing-drush"> <!-- Enable development and UI modules --> <drush command="en" assume="yes"> <param>devel,views_ui,context_ui,field_ui</param> </drush> <!-- Disable views data caching --> <drush command="vset" assume="yes"> <param>views_skip_cache</param> <param>1</param> </drush> </target>

You can easily create new targets and have them depend on one another to automate common tasks. You can also run these targets independently. For example,

$ phing enable-dev-mode

will prepare your current sandbox for development, and

$ phing -l

will list all the available targets with a short one-liner to explain what the target does, which is great to communicate tasks to the other members of the team.

Using Phing in a team

When adopting the git flow model, Phing is the missing link to re-build the site for a feature branch and developing features in isolation.

After switching to your feature branch, the only thing to do is run phing build, work on your code and configuration (stored in code), push changes back upstream, and ask anyone in the team to review these changes by running phing build on the feature branch.

Phing will establish a common language within the team and make it easy to share development recipes and best practices as documentable targets.

What else can I do with Phing?

We’ve only scratched the surface of what you can do with Phing to automate your Drupal development. We use Phing to automatically migrate mock content using the Migrate module, run an automated test stack, and provide continuous builds everytime new code is pushed to the repository (check out our Travis logs).

The take home message is that building a Drupal site should be as easy as running phing build, and with that - we’ve complied with the second step of Joel Spolsky’s Joel Test to Better Code: “Can you make a build in one step?”

Featured image credit: Daniel Wehner / Flickr

Categories: Drupal

Mark Shropshire: DrupalCamp Charlotte 2012 Videos Released

Mon, 2014-03-03 18:18

Thanks to hard work by the folks at the SouthEast LinuxFest, many of the 2012 DrupalCamp Charlotte presentations have been released on video. Two of the tracks are now represented in Youtube playlists below. Watch the southeastlinuxfest YouTube channel for more videos in the near future.

Hot Drupal Track Playlist

Classic Track Playlist

Blog Category: 
Categories: Drupal

groups.drupal.org frontpage posts: Should Drupal.org participate in political issues?

Mon, 2014-03-03 17:42

Recently, the Association posted a discussion here in groups (https://groups.drupal.org/node/398548) which resulted in the Association registering Drupal.org to participate in TheDayWeFightBack (https://drupal.org/node/2188053). As we have discussed, there were technical issues we could have addressed differently (see the discussion: https://groups.drupal.org/node/407283), but we also heard from many community members who felt that Drupal.org should never be involved in any kind of political campaign at all. An in this case, I'll use "political" with a small "p" to indicate the very broadest definition - from political candidate campaigns to "political" stances.

In fact, as an example of politics with a small "p," we were recently asked to participate in the Open Innovation Network (http://www.openinventionnetwork.com/) by signing on as a supporter (though the patent work obviously does not directly affect us).

I promised to address this question specifically in a follow up post - so here it is! We want to hear from you, but we ask that you please help make the conversation as constructive as possible. These discussions get heated quickly, so here are some ground rules:

  • Critique the idea with logic, not emotion
  • Don't critique the messenger, just the idea
  • Try not to take criticism of your idea personally
  • No swearing

Finally - help us have a broad conversation. Share this post widely.

Categories: Drupal

Powered By