Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 45 min 17 sec ago

Mediacurrent: Internationalization and Drupal P.2

Wed, 08/01/2014 - 18:17

In my first post on Internationalization and Drupal we discussed, in detail, why translation is so important and how Drupal determines the correct language to use when serving content to the user.

This next post focus will be on configuring Drupal to use different languages, and then demonstrating how to translate content into the enabled languages.

Categories: Elsewhere

Appnovation Technologies: 9 Cool HTML5 Sites

Wed, 08/01/2014 - 17:57
HTML5 opens the door for all sorts of possibilities that were previously unavailable under older versions of HTML. From semantic markup to powerful APIs, sites built with HTML5 position themselves to be relevant well into the future. Here are 9 great examples of what HTML5 can do. var switchTo5x = false;stLight.options({"publisher":"dr-75626d0b-d9b4-2fdb-6d29-1a20f61d683"});
Categories: Elsewhere

Phase2: The Full Story Behind Phase2′s New Front-End Super Stars

Wed, 08/01/2014 - 17:47

For the past 13 years, I’ve been part of a team of multi-talented individuals at a boutique web firm called SuperStar Media. Born out of the dot-com bust, Superstar was conceived by my business partner and long time friend, Sean Kelley, and myself. Armed with two Macs, key connections in the music biz, and a healthy dose of passion for creating things people love to use, we built something very special that defined our lives for over a decade. All good things must come to an end, but as one door closes, another one opens. That door just happened to be Phase2, and it was our decision to close the other one. To fill in the story a bit more, lets go back a few years.

In the beginning…

From humble beginnings circa 1995, I was (still am) a huge fan of a local band who made it big in my hometown of Bremerton, Washington called MxPx. At this time, the web was the wild west and anything was possible. As a fan,  I built their first website which quickly became the official version. The site was a canvas for me to play around with illustration, typography, layout, and of course everything else that goes along with an early generation website. There were no cascading style-sheets or ubiquitous open source cms platforms readily available, just inline font tags, tables and perl. Fun right? Actually it was, and I learned a heck of a lot.

As this all unfolded, Sean Kelley and I were graduating from college with dreams of big corporate jobs in the web industry. The sky was the limit, and things never looked better for those in our shoes. What could go wrong? Pop, there went the bubble. After what seemed like an eternity applying for jobs, we recycled an old discarded band name ‘SuperStar’ and began our adventures on our own.

It wasn’t hard to find work in the music industry; we were creative, worked like dogs, and our rates were a fraction of the what the larger firms were charging. Thanks to the connections we made with Mxpx, we never once did any advertising or marketing, it was all word of mouth. As projects kept landing in our lap, we always turned to our friends first for help, such as our first employee Chris Clark, and second Mike Walpole. We felt it was important to bring our friends to the top with us, and we knew we could count on them to work as hard as we did. We were right, and to this day I am surrounded by good friends who helped us get to this point.

Throughout the years, we were able to hone our craft on high-profile websites that pushed the limits of our creativity. I’ve had the pleasure of designing sites for Christina Aguilera, Bette Midler, Kings of Leon, Eagles, and many more. Being a nimble company that could flex to the needs of the given project, our repertoire of work expanded beyond entertainment clients. From education to corporate, non-profit to publishing, we were growing up and growing larger.

Along with world-class design, we built our own proprietary cms and project management solutions for clients and internal usage. At last, we had the clients, the talent, and the tools to tackle the big jobs. We were set right? Once again, the universe felt the need to throw a wrench into SuperStar by way of something called Drupal.

And then came Drupal.

With closed systems that we had built and maintained for our client base, we focused inward instead of exploring what others were using at the time. We found clients were now turning us away because we lacked Drupal skills, and our proprietary tools were now undesirable. What would we do, abandon our proprietary tools that we spent years building in favor of this Drupal thing? We saw no other choice, so the plug was pulled.

After several years, we found ourselves at the top of our game once again. Drupal had been good to us, and our team had expanded to the point of opening an office in Portland with some of the best front-end developers in the Drupal-sphere. After spilling some scotch on my old college buddy Chris Bloom at a Drupalcon in San Francisco, he became a partner at SuperStar Media and then brought in Jeff Crisamore, Courtney Koppenhaver, and Peter Schuelke. Our team now had a reputation for being ahead of the curve, friendly, hard working, and most importantly people who could extend in-house teams when overflow was needed.

Enter Phase2.

From the moment we started working with Phase2, we knew that our cultures aligned in a way that we had never seen before. Fortunately, they felt the same way about us and began booking up every available hour. Soon, almost everyone on the team was working on Phase2 projects and integrating into their respective groups. It didn’t take long for discussions to come about regarding coming onboard. We had always kept an open mind about joining other teams, but now that the idea was more of a reality, Sean and I needed to have some heart-to-heart talks.

Do we put SuperStar Media to rest, the company we put blood (I cut my finger when building a tin partition), sweat and tears into? Sean would finally be able to pursue his dreams of being a serial entrepreneur,  I could focus on my craft, and our team would receive the benefits of a larger company.

Ultimately, we agreed that it was time for the next step in our lives. Coming onboard with Phase2 was an opportunity that we couldn’t pass up, and it seemed that the stars were aligning for this decision to be made. Sean was at the point where he was getting very excited about opportunities after SuperStar, and I was already ingrained in Phase2 projects along with our guys.

As we shed a tear while closing the Bremerton office, we feel good knowing that Sean is already working on his next entrepreneurial venture, and ready to take on the world. Mike Walpole decided to go off on his own, where he’s busy writing music for the WWE. The Phase2 door is wide open for the transitioning team, with plenty of smiling faces and new and exciting challenges to solve. As it started 13 years ago, I will begin this new journey armed with my Mac(book), dear friends, and a sense of adventure to build things people love to use.  Check out the Portland Business Journal’s article about our big move to Phase2 here.

Categories: Elsewhere

Drupal Association News: Drupal is Turning 13 – Join the Party!

Wed, 08/01/2014 - 17:45

Congratulations Drupal community. You are now raising a teenager!

On this January 15th, it will be 13 years to the day that Drupal 1.0.0 was released. 

Categories: Elsewhere

Lullabot: Sending a Drupal Site Into Retirement

Wed, 08/01/2014 - 17:00

Drupal is a great tool for creating a site. It has lots of modules and functionality that allow you to build interesting and complex features. But sometimes those sites lose their relevancy. It's a site for an event that has passed, for instance. Or a site for a topic that was really important at one time but now is mostly useful as a reference for the content it contains. Or it's a site you just don't have time to keep on top of.

Categories: Elsewhere

Modules Unraveled: 091 Pinger and with Chris Hertzog - Modules Unraveled Podcast

Wed, 08/01/2014 - 07:00
Published: Wed, 01/08/14Download this episodePinger
  • What is the Pinger module?
  • How does it check for uptime?
  • Why is it needed? Why did you feel the need to develop it?
  • Why did you decide to build this with Drupal?
  • How does this integrate with Drupal? What aspects of Drupal does it leverage?
  • What are you using for charts?
  • What is
  • What is the benefit of using as opposed to just installing the Pinger module?
  • How much is it?
  • Why Saas?
  • Do you have any plans for upcoming features?
Coupon Code

Use coupon code "drupal6" for a 6 month free trial of any plan on

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: Chris on drupal.orgChris’ BlogPingerPingCheck.inTags: 
Categories: Elsewhere

Open Source Training: Entity Views Attach: Use Views Almost Anywhere

Tue, 07/01/2014 - 20:10

Entity Views Attach (EVA) is a wonderfully useful Drupal module which makes Views more powerful.

EVA allows you to automatically attach any view to content, comments or terms.

We're going to show you 2 examples of EVA in use. Both of them solve problems that were asked by our members this week. First will see how to sort terms however we want and then we'll see how to add an image for a file download link.

Categories: Elsewhere

Dcycle: Do not clone the database

Tue, 07/01/2014 - 20:07

It is generally agreed that cloning the database downstream (that is, from development toward production) is a bad idea, if only because by doing so all production content is lost; most developers use Features, Context, some variation on a site deployment module, or a rudimentary written procedure to move new configuration downstream.

However, in a dev-stage-production workflow, the database is often still periodically cloned back upstream:

In such an approach, anything not in Features or a site deployment module exists solely in the database. For example: any content, your default theme, and other information (such as variables not exported with Strongarm or block placement information not exported with Context) are defined only in your database and not in code. Therefore, to create a realistic development environment, it is tempting to clone your database.

I'll explain why I think database cloning is the wrong approach, and then look at other ways to achieve the same goals. Finally, I'll look at some situations where cloning the database is a good idea.

Why is cloning the database the wrong approach?

Cloning the database is wrong for the following reasons:

  • The database is not under version control.
  • The database is not in a known-good starting point.
  • Database cloning makes automated testing harder.
  • Database cloning makes continuous integration harder.
  • What if there is more than one "production" site?
  • Your production database may be very large.
  • Your production database may contain sensitive data.
  • Fixes to a cloned database will "work on my machine", but not elsewhere.
The database is not under version control

In Drupal, the database contains all configuration, content types, variables, views, and content; and none of this is under version control.

A good development practice is to put everything except content into code, and into version control, via Features, Context, Strongarm, and a site deployment module. These are code and can be kept under version control.

The database is not in a known-good starting point

One important aspect of writing modern software is the importance of automated testing, and the importance of knowing that our test will always yield the same result. This is the concept of a known good starting point, discussed in the book Continuous Delivery. The production database changes continually, for example when new comments or content are added. If your tests, either manual or automated, depend on a cloned production database, there is always a chance that different versions of the database will be yield different test results.

Database cloning makes automated testing harder

Because of the importance of having a known-good starting point, Drupal automated tests which require the database always work in the following manner:

  • Build a brand-new temporary (throw-away) database from scratch.
  • Perform a plain installation.
  • Create the required content and set the required configuration.
  • Perform the test.
  • Discard the throw-away database.

For example, let's say you have a block appear when there are more than 20 registered users on your site. The only way to accurately test this is to have your test control the number of users, and test the presence or absence of your block. If the only way to deploy a new environment with your site is to clone the database, the test has no real way of creating the conditions (active theme, block placement, active modules) to run this test.

However, if you are using Features and a site deployment module, all your tests needs to do for the above example is to:

  • (1) Enable your site deployment module.
  • (2) Make sure the special block does not appear.
  • (3) Create the 20 users.
  • (4) Make sure the block does appear.
Database cloning makes continuous integration harder

Continuous integration (CI) and continuous deployment are quite popular these days, with good reason, because without CI, automated testing is not that useful (because developers tend to ignore tests).

Basically, CI runs a script on every push to version control. So: every time there is a change to the code base, the tests can be run and either pass or fail.

I have seen many shops experiment with continuous integration, and in many cases the Drupal site is recreated by cloning the production database. Therefore, the CI server's test site is always in an unknown, unversioned state. So when a test fails, it is impossible to say whether a change to the database caused the fail, or a change to the code did.

In my experience this causes frustration and confusion, and eventually will cause your CI server to be worthless, and hence abandoned.

What if there is more than one "production" site?

When we are cloning the production site's database, what do we mean exactly? Take the following example: we are developing a code base for a university with dozens of faculties. Each faculty uses the same code base but a different theme, and some slightly different settings.

It doesn't make sense for new developers to clone one production database rather than another for development, so often a random choice is made, leading to uncertainty.

Consider your codebase to be a software product which can be deployed on any number of sites, just as any software. Would it make sense for developers of a word processor to clone the computer of one of their clients during routine development?

Your production database may be very large

Beyond the logical considerations, cloning production databases can be unwieldy, requiring one to remove cache tables, finding a mechanism to either copy all files and images, ignore them, or use placeholder files and images (that does not feel right, no?). Still, you can quickly find yourself with very large databases.

Your production database may contain sensitive data

Once your production site actually starts being used, you end up with much sensitive data there: email addresses, hashed passwords, order history, addresses, or worse. Consider the consequences if you dump this database on a developer's laptop (which will eventually be stolen or lost).

Fixes to a cloned database will "work on my machine", but not elsewhere

So you've cloned a database on your laptop, and you changed some configuration on administration pages, and now the problem seems fixed, you've made a demo for your team and your client. The next part is messy though: a list of admin screens to click through on the production site to reproduce the fix (ugh!), or, as I've already seen, cloning the development database downstream (double-ugh!). Both methods are error-prone and do not record the fix in version control, so a month from now you'll forget how it was done. In fact, you will find yourself in a sysyphian effort of repeatedly fixing the same problem over and over, and explaining to your clients and your team, with the help of out-of-date wiki pages, email exchanges and undecipherable comments on issue queues, that you are not an incompetent oaf.

What are the alternatives to database cloning?

We generally clone the database to have a realistic development environment. Among other things, during development, we need to have:

  • The same configuration and features.
  • Realistic content.
  • Some exact problem-causing content.

This is possible without cloning the database. Here are some tips and techniques.

Getting the same configuration and features as production

In an ideal world any Drupal site should be deployable without cloning the database, by getting the code from git and enabling the site deployment module.

You are most likely, however, to inherit a site which is a mess: no site deployment module, no tests, with Features, if they exist at all, likely to be overridden on the production site. On some projects you'd be lucky to even have a git repo.

One might think that for such sites, which we'll call legacy sites for the purpose of this article, cloning the production database is the only viable option. Unfortunately, that is true, but it should only be a temporary solution, to give you time to extract the important configuration into code, and to create a site deployment module.

Let's say, for example, I get a work request to "fix a little bug on a site which is almost ready". The first thing I do is to clone the entire site to my laptop, with the database and all, and and determine which configurations, features, and variables are affected by the bug. Let's say the site in question has 20 content types, 20 views, 50 enabled modules, three languages and a custom theme.

But the bug in question only affects 2 content types, one view, 3 modules and does not require the custom theme or i18n. I would start by generating a feature (if one does not exist) with the required views and content types, and a site deployment module with the feature as a dependency and a basic automated test. Now I can use test-driven development to fix my bug, push everything back to version control and to my continuous integration server, and deploy to production using drush.

Thus, every time an issue is being worked on, a site gradually moves from being a legacy site to a modern, tested site with continuous integration (don't do it all at once as you will get discouraged).

Realistic content

For developers, Devel's devel_generate module is great for generating lorem ipsum content with dummy images, so even if you don't clone your database, you can still get, say, 50 (or 1000) blog posts with 5 (or 50) comments each.

During automated testing, several DrupalWebTestCase API functions allow you to create as much dummy content as you want, being as specific as you want.

Some exact problem-causing content

I have recently had to deal with a bug where the a site's "layout was periodically going berserk". That was the exact issue title, and I was lucky because my client was thoughtful enough to provide a screenshot and even the source code.

This problem could be tracked down to a often-seen misconfiguration of views and marked-up content: views would trim all body fields to 100 characters, which works fine with standard lorem ipsum, but in the real world the client was using markup in the content, so if a <div> tag would appear before the 100 character mark, but end after it, the ending tag would be omitted, screwing up the html.

Several colleagues who are used to cloning the database concluded that this a limitation of generated content.

I see this situation as more of an opportunity, and have come up with a way of altering generated lorum ipsum to suit your needs. So, when starting to work on such an issue, first make sure that your generated content better reflects real content, both for developers and for the automated tests.

When is it OK to clone the database?

"Don't clone the database" is a good rule of thumb, but in some cases cloning the database is good idea, for example in the following cases:

  • For backups and restores.
  • For hard-to-debug "production-only" problems.
  • As a temporary measure to update a legacy site.
  • For proproduction environments.
For backups and restores

Code is not everything. The database contains your content, so you need to have a strategy to clone your database somewhere nightly, test it often, and make sure you can restore it. This is mot easily done by cloning the database.

For hard-to-debug "production-only" problems

Once in a while, you will have a problem which only manifests itself on a production site. Reproducing this type of problem systematically can be best achieved by cloning your production database to figure out what the problem is (never work directly on production, of course).

As a temporary measure to update a legacy site

As mentioned in "Getting the same configuration and features as production", above, most projects are a complete mess once you get your hands on them. We'll call these legacy sites. The only way to move important configuration information into code is often to clone these sites temporarily until you have working Features and a site deployment module.

For proproduction environments

For some critical projects, you might decide to continually deploy, but not directly to production. In such circumstances, you might have your Jenkins projects continually deploy to a preproduction site (cloned from production before each deployment), to give the team, and the client, a few hours or a day to walk through the changes before approving them for deployment to production.


Since being interested in Drupal dev-stage-prod, deployment and testing, I have often come across colleagues who systematically cloned the database, and have always felt uneasy about it, and in writing this post I have set out to explain why. The post turned out a lot longer than I thought, and the main take-away is that we should all consider our sites as software products, not single-use sites.

As software products, we need standardized deployment methods, both initial and incremental, via a site deployment module.

As software products, we also need to implement modern testing and continuous integration techniques.

As software products, we need to be able to deploy anywhere, with no environment dependant on any other.

Such a focus on reproducibility will hopefully pave the way to more dependable tests, a better understanding of what is content and what is configuration, and faster, more efficient and more consistent development.

Tags: blogplanet
Categories: Elsewhere

Phase2: New Year (Re)Solutions.

Tue, 07/01/2014 - 18:54

As we begin a new year, we tend to think about the challenges and exciting new ventures in 2014.  We are excited to take on new projects this year and create innovative creative solutions for the digital challenges we help our clients solve with open source technology. Sometimes people forget that the web is still a frontier, and as such, is constantly evolving. Big brands, like Google, Facebook, and Amazon are always innovating. Their work sets a standard, but it’s not always clear the effort or cost involved in it. Here is the reality: these companies spend millions of dollars building proprietary code and often contributing to open source libraries, and they constantly test the effectiveness of their approach to be more successful.

In this post, we are going to focus on the nexus of where business problems meet common technical challenges and the innovative open source solutions that we have developed in the past year.

Successful innovation depends on solving problems. There are all sorts of problems, but let’s start with 3 main types we often encounter.

  • Business Problem – This is a problem specific to how your business works. It likely does not need a technical solution. However, the reality is that sometimes changing peoples hearts & minds is harder than a basic engineering solution. The choice to confront a human issue or craft a technical response should depend on business value.
  • Application Problem – Regardless of the framework, language, or infrastructure used, there are often challenges and frustrations that result in more cost and time expended to accomplish a given task. Even though solving the application problem does not directly serve a business value, it is sometimes necessary in order to accomplish the business need.
  • Common Problem – This is a problem that is common across the web. It does not have a standard solution, though might have been solved to a limited extent. Typically it involves more expense to solve a common problem than a client organization without a technical mission could incur.

In order to frame some of the solution spaces we are interested in covering, we’ve Included some fictional yet inspired quotes – and some conversational user stories  to illustrate the problems and  solutions.

Flexible Forms

“I am looking to find new interactive ways to digitally engage readers for an online magazine  that has recently decided to drive readers to action based activities… oh and the deadline is yesterday!”

As a site administrator for a publishing site, I’d like to be able to create a form for a special user initiatives that  I’m promoting through twitter, so that I can generate buzz about a new focus and online publication…oh and I need to this in the next hour!

Forms aren’t new to the web, and open source solutions for creating and managing forms have grown more advanced. The standard Drupal solution for forms, the Webform module, provides a “what you see is what you get” experience for building forms and has become a full-fledged SAAS offering at However, there’s still custom development work involved in getting the form to display just right, in allowing an unusual form of input, in posting form results to a specific service or via a formatted email, or enforcing some kind of business logic. Often the purpose of forms is stretched to handle things like event registration, sign ups, and scheduling if a more specific application is unavailable or difficult to integrate with a web site.

We’ve met challenges from many clients to build one-off or managed form systems with a variety of integrations, and we’re looking forward to the next project that lets us continue to refine solutions in this space.

Robust Ecommerce and Donation Processing

“I wish I could create a specific page for campaign donations, but my site only has one way to make an online donation without having to hire a development team to build a custom page!”

As a Development Officer for a national non-profit that focuses on Veteran’s rights, I’d like to create a custom funding page that encourages donors to contribute directly to a fund that sends veterans to natural cooking school so that I can reach people directly who care about funding this specific initiative of healthy eating and PTSD.

We’re also excited about the growing field of payment processors, virtual currencies, and online marketplaces. We’ve worked on ecommerce solutions for enterprise clients and donation systems for nonprofit organizations.

Solutions range from building a self-hosted, custom e-commerce applications, to leveraging proven third-party services. In some cases, a custom approach is needed to provide a fully branded experience, sufficient forward-looking flexibility, or alignment with basic business needs. In other cases, organizations benefit from using a tried-and-true, familiar service, like Amazon Marketplace or Crowdrise.

We understand the importance of helping clients find the right solution for their specific ecommerce and payment processing services.

Mobile Messaging and Push Notifications

“I’m on the road and I feel out of touch with my web based sales pipeline!”

As a busy sales executive for my growing socially responsible global business, I am constantly on the road and would like to have a mobile push alert sent to my phone when a new lead or sales question is filled out on my website so that I can have a quicker way to keep my finger on the pulse  of the market without having to be in my inbox.

Now nearly every project accounts for mobile devices in some way. We’ve built sites from the ground up that are “fully responsive” or provide a specific mobile experience, and also “retrofitted” existing sites to add mobile capabilities. The web is shifting to improve support  for mobile browsing.

We’re excited for more opportunities to engage mobile users through messaging and push notifications. Providing direct updates to mobile devices to promote critical information or to facilitate discussions can provide an increased amount of sustained connections with site visitors and user members.

Responsive Maps

“I’m stuck in midtown and I need to find out which trains are delayed in real time!”

As a site visitor to a municipal transportation website, I would like to access an easy to read detailed map that contains information about the best form of transportation from my mobile phone so that I can easily get to my next destination.

Maps have played an important part of the way information is presented on the web. With mobile devices, maps are taking on an even more immediate and utilitarian role: they help us get where we’re going, find something we need, or provide context about where we are.

We’ve taken several approaches to integrate maps with web sites. We see more opportunity for building stand alone map presentations that integrate custom datasets and provide the look-and-feel of a map application on desktop and mobile devices alike.

Information Crawler

“The arts organization that my foundation supports is doing such great work, but I don’t have enough time or resources to feature the constant stream of amazing content and events they are putting on! I wish my website had a dynamic way of featuring all these amazing art initiatives!”

As the grants manager for a family foundation that focuses on supporting a wide variety of arts organizations, I’d like to be able to feature articles and updates from my grantees in a special search section so that I can highlight ongoing successes without having the overhead of posting content.

One of the values of the web is presenting information in a common format that can be aggregated and searched. Traditional approaches to search are to narrow the scope to a single site for on site search experiences or to leverage a search provider like Google.

Some use cases call for a more configurable approach, where one can control the web site or other resources crawled and how the index is constructed and how the relevance of the content is calculated. This includes when the search index should encompass multiple web sites or data from other kinds of sources, like spreadsheets or external databases.

We’ve built search solutions for several clients, and are interested in building more complex applications for crawling, aggregating, and indexing data.


The motivation for this reflection on problems and solutions is our excitement for new challenges, new solutions, and new technology.  We’d like to hear from you about your problems, solutions and goals for the New Year!  We look forward to finding a way to help develop innovative solutions with open source technologies.

Categories: Elsewhere

Drupalize.Me: An Introduction to RESTful Web Services in Drupal 8

Tue, 07/01/2014 - 15:04

One of the Drupal 8 initiatives that really excites me is Web Services. Drupal has never been easy to work with as a web service, but all that is about to change! In this article I am going to explore what has been going on behind the scenes with RESTful Web Services in Drupal Core and attempt to implement some working examples. After reading, you will be able to create a new node on your site via the Drupal 8 Core REST API.

Related Topics: Drupal 8, service
Categories: Elsewhere

Drupal Easy: DrupalEasy Podcast 120: Megapage!

Tue, 07/01/2014 - 15:03
Download Podcast 120

Chris Shattuck (chrisshattuck) from joins Andrew and Mike to talk about learning and teaching Drupal 8 developer programming concepts, including the almost 3 hours of videos that are already available on (object-oriented PHP, autoloading, namespaces, etc…) We also talk about faster PHP, Drupal 8 in the wild, anger a future guest, and short pants.

read more

Categories: Elsewhere

OhTheHugeManatee: How to Remove a Drupal Install Profile

Tue, 07/01/2014 - 13:23

Install profiles are a great way to throw together a functional Drupal site really quickly. In Drupal 6, an Install Profile was just a blueprint for setting up a site really quickly. What you did after the site was installed was your own business! But in Drupal 7 profiles are much more integrated with core. The assumption is that when you use an install profile, you want to rely on the profile’s maintainer for all your updates. This is not always the case.

Very often your site will diverge from the install profile as it takes on a life of its own, and it will be useful to convert it to “vanilla” Drupal. Today I’ll use a relatively simple example of a musician site which is moving away from the Pushtape distribution. Later I’ll return to this subject with the much more in-depth example of moving a community site away from Drupal Commons.

Move things around

Install profiles have all their files stored in the site root’s profiles/ directory. The first step is going to be moving everything out of there. In the case of pushtape, we have libraries, modules, and a theme stored in there. We’re going to move them to a more normal location.

1 2 3 4 5 6 7 8 9 # mkdir sites/all/libraries # mv profiles/pushtape/libraries/* sites/all/libraries # mkdir sites/all/modules/custom # mv profiles/pushtape/modules/pushtape_* sites/all/modules/custom # mv profiles/pushtape/modules/* sites/all/modules # mkdir sites/all/themes # mv profiles/pushtape/themes/* sites/all/themes

Next we need to see if there are any variables set in the install profile which really depend on the profile directory. If there are, we’ll have to set them again with the new path.

1 2 3 # cd profiles/pushtape # grep 'profiles/pushtape' * -R pushtape.install: variable_set('sm2_path', 'profiles/pushtape/libraries/soundmanager2');

In this case, we see one variable_set which tells the system where to find the soundmanager2 library. We can update that easily enough with drush:

1 # drush vset sm2_path 'sites/all/libraries/soundmanager2'

Now we have to update Drupal’s setting for which install profile was used to create the site.

1 # drush vset install_profile standard

In some cases this will be enough to work. Personally I like to keep my modules folder more organized, so I go the extra mile:

1 2 3 # cd sites/all/modules # mkdir contrib # mv !(custom|contrib) contrib

I also separated out the custom code from the features. You can figure out which custom modules implement features with find . |grep features, and move them into a separate directory manually.

Clearing caches

Once you’re done moving things around, CLEAR CACHES. Drupal keeps an index of module, library, and theme directories, and you just broke it.

1 drush cc all

The only problem is, in many cases you will have moved a module that is required for drupal bootstrap. So you’ll have to get the handy drush tool Registry Rebuild, and run that before your cache clear:

1 2 3 # drush dl registry_rebuild # drush rr # drush cc all

That’s it – your site is now officially a vanilla Drupal install. Test by removing the profiles/pushtape directory, clearing caches, and browsing around your site.

NOTE: With a more complex install profile I expect to encounter more difficulty. Stay tuned for the post on extricating yourself from Commons later this year!

Categories: Elsewhere

Web Wash: How to Send Follow-Up Emails Using Rules Scheduler in Drupal 7

Tue, 07/01/2014 - 08:47

On a community website, it's a good idea to send some type of follow-up email a week or month after a user registers. This email can be used to ask for feedback or promote useful features.

This type of functionality can be built in a few ways. You could use a 3rd party email service like MailChimp or AWeber to send the follow-up as an auto-responder.

Another possibility, is to send the follow-up email directly from Drupal.

In this tutorial, I'll show you how to use Rules Scheduler (part of Rules) to send a follow-up email one week after a user registers.

Now, every website is different and you may want to send this email after three days or one month. By using Rules, you can adjust this type of configuration directly from Drupal without writing any custom code.

Categories: Elsewhere

Larry Garfield: Beyond Abstract classes

Tue, 07/01/2014 - 08:18

Recently, Anthony Ferrara has been posting a periodic "Beyond" series about software design philosophy. Some in particular have hinted at concepts I've been pondering as well. With his blessing, therefore, consider this a continuation of that series.

PHP 5.4 is not exactly new, but it's finally starting to see actual usage by a decent number of people. Its most notable new feature is Traits, which in PHP are implemented as, essentially, compile-time copy-paste. Conceptually, though, they're a way to mix functionality into a class without using inheritance, and without requiring a separate distinct object for composition. (At least in PHP; the term "trait" appears in other languages for similar but subtly different tools.) That's not to say that they're a surrogate for composition; they most certainly are not. They serve a different purpose, that is, providing code for a class to reuse without using inheritance.

Recently, I was reading an article (the link to which, of course, I cannot now locate) discussing the implementation of inheritance, such as it is, in Go, Rust, and other new-wave concurrent languages. It made an interesting point that crystallized for me why it is I am so excited about traits. Specifically, it noted that there are not one but two kinds of code reuse: interface reuse and code reuse.

read more

Categories: Elsewhere frontpage posts: GLADCamp (Greater Los Angeles Drupal Camp) on March 7, 8 & 9, 2014, in Pasadena, California!

Tue, 07/01/2014 - 08:02
Start:  2014-03-07 (All day) - 2014-03-09 (All day) America/Los_Angeles User group meeting Organizers:  christefano GavinBurnett impboy_ie jmosmith joe_pixelrow nodiac oseldman pcoleman Stew-bee Techivist WonderWoman Event url:

Greater Los Angeles Drupal Camp (GLADCamp) is a free, 3-day event coming up on March 7th, 8th & 9th, and is at Hilton Pasadena & Convention Center in Pasadena, California.

We're planning a conference that's packed with 3 full days of pre- and post-camp activities, including trainings, topic-based summits, a job fair, a barn raising to benefit a local non-profit, parties, and more!

Stay tuned to this event announcement, the website and @GLADCamp on Twitter for upcoming news and announcements.

Important Dates

Here's our tentative schedule for the next couple of months:

Session submissions start on January 13, 2014
GLADCamp is 3 days dedicated to all things Drupal, and we're looking for session proposals on everything including site building, coding, development, e-commerce, theming, design, performance, security, site showcases and case studies.

Training submissions start on February 3, 2014
Training companies and individual trainers are welcome to propose a training to be scheduled on Friday, March 7, 2014. We currently have two training spaces, but we might have more depending on demand.

Barn raising applications start on February 10, 2014
Continuing our tradition of holding "barn raisings" for non-profit organizations, we'll be reviewing applications from non-profits who would like to participate in a code sprint dedicated to building their website or adding much-needed features.

1st round of selected sessions will be announced on February 17, 2014
We're combining some elements of barcamp-style organizing with traditional conference planning, and will announce a preliminary schedule on February 17th. This is also when folks coming from out of town should start getting their travel arrangements together.

Final schedule will be posted on February 24, 2014
2 weeks before the conference, we'll have a finalized schedule so everyone will know which sessions to look forward to!

Categories: Elsewhere

Blink Reaction: Thank you for a great 2013.

Tue, 07/01/2014 - 01:08

We'd like to say thank you to Drupal and all our clients and supporters for a great year. 2013 was a year of accomplishments for Drupal and a great year for our clients and all of us at Blink Reaction. I’m particularly proud of our work to bring Drupal learning to the forefront of our mission with new and existing clients on the journey we call open source. Here are some highlights we thought you’d like to celebrate with us:

Categories: Elsewhere

Drupal core announcements: Learn more about Drupal 8 and help the wider Drupal community by writing up a Change Notice

Mon, 06/01/2014 - 22:09

A happy 2014! What a great year for a Drupal major release!

Have you started learning the new Drupal 8 APIs? Are you porting your modules forward to an 8.x branch? Are you a curious site builder ready to adopt the new hotness that will be Drupal 8?

Well now is the time to jump in and start learning. And one of the best ways to learn is to teach. Speaking from experience, authoring a change notice is an excellent way to explore a sub-system of Drupal 8. You are, in a sense, documenting your personal learning as you work to understand the change, why the change was necessary and how users will write code against the new system. And everyone benefits from your efforts.

What is a change notice? Well, when a significant change is made to Drupal, the developers and committers will require that a change notice node be published that describes the updated code and if applicable, how the change alters a previously existing API. We have a detailed explanation of how to write a change notice. Generally, you will spend 20 to 40 minutes on this task. Here is the current list of issues that require a Change Notice. Right now there are about 40 issues that require a notification to be written.

Very often the developers involved with an issue patch will author the change notice. When this does not happen, the issue is marked with a Needs change notification tag. Any open change notices will block the creation of a Drupal release candidate, so they must all eventually get written. Change notices are a vital means to help Drupal developers understand how to alter their coding practice from Drupal 7 to 8.

If we got 40 people to each pick an issue and write up a change notice, we could clear out the queue today! That's quite an achievable goal.

Categories: Elsewhere

Urban Insight: A New Form of Online Publication by LACMA

Mon, 06/01/2014 - 18:00

We recently had the privilege to work with the Los Angeles County Museum of Art (LACMA) to launch their first online scholarly catalogue. Featuring objects from Southeast Asian art, the catalogue makes information about works in LACMA’s collection available in a new, media-rich format.

Categories: Elsewhere

Microserve: MixItUp and Drupal Views

Mon, 06/01/2014 - 17:45

Recently I had to create a View with exposed filters that refine the results by certain taxonomy terms. In the meantime, the design team came across the MixItUp JQuery library and recommended it for the View in order to improve the user experience. It turns out that combining Views with this library was relatively easy and the result was quite impressive. In this post I will briefly describe how this library works and one way you can combine it with Views.

About the MixItUp plugin

MixItUp is a JQuery plugin that provides animated sorting and filtering for ordered and categorised elements, such as unordered list elements (



    • Cats


    • Sort by age


    • ...


    [Taxonomy term value]

    In order to make these elements behave as filter controls, some classes and attributes had to be added, which was done with JavaScript as described in the next paragraph.

    JavaScript code

    So far some of the required classes were added in the View, but the attributes and the classes in each filter and each filtered element still needed to be added. These requirements were handled with the JQuery code below:

     // Selecting from every list item in the View // the values that match the filters (the practice // areas and surname each list item is showing) and // adding to this list item these values as classes $(&#39;ul.mixitup li&#39;).each(function() { $(this).find(&#39;div.practice-areas div&#39;).each(function() { var str = $(this).text(); str = str.trim().replace(/\s+/g, &#39;-&#39;).toLowerCase().replace(&#39;&amp;&#39;,&#39;a&#39;); $(this).closest(&#39;li&#39;).addClass(str); }); $(this).find(&#39;.field-surname&#39;).each(function() { var str = $(this).text(); str = str.trim().replace(/\s+/g, &#39;-&#39;).toLowerCase().replace(&#39;&amp;&#39;,&#39;a&#39;); $(this).closest(&#39;li&#39;).addClass(str); }); }); // Adding to every option in the exposed filters, // the class &quot;filter&quot; and the attribute &quot;data-filter&quot; // with the value defined in the option&#39;s value //Practice Areas dropdown $(&#39;#edit-tid option&#39;).each(function() { $(this).addClass(&#39;filter&#39;); var str = $(this).text(); str = str.trim().replace(/\s+/g, &#39;-&#39;).toLowerCase().replace(&#39;&amp;&#39;,&#39;a&#39;); $(this).attr(&#39;data-filter&#39;, str); }); // Triggerring the &quot;click&quot; event when an option is // selected, for the MixItUp to handle the filtering $(&#39;#edit-tid&#39;).change(function(){ $(this).find(&#39;option:selected&#39;).trigger(&#39;click&#39;); }); //Surnames dropdown $(&#39;#edit-tid-1 option&#39;).each(function() { $(this).addClass(&#39;filter&#39;); var str = $(this).text(); str = str.trim().replace(/\s+/g, &#39;-&#39;).toLowerCase().replace(&#39;&amp;&#39;,&#39;a&#39;); $(this).attr(&#39;data-filter&#39;, str); }); // Triggerring the &quot;click&quot; event when an option is // selected, for the MixItUp to handle the filtering $(&#39;#edit-tid-1&#39;).change(function(){ $(this).find(&#39;option:selected&#39;).trigger(&#39;click&#39;); }); // Calling the MixItUp plugin for this View $(&#39;.mixitup&#39;).mixitup();

    Categories: Elsewhere