Planet Drupal

Subscribe to Planet Drupal feed - aggregated feeds in category Planet Drupal
Updated: 39 min 30 sec ago

Doug Vann: Why I support Kalabox on Kickstarter and why I think that you should too.

Tue, 01/07/2014 - 04:07

This Kickstarter campaign exists to take Kalabox 1.0 to the next level! Literally!

Let’s be honest. There are a LOT OF TOOLS out there to turn your computer into a web server and help you leverage sophisticated tools. They range in cost from free to cheap to pricey. The complexity ranges from too simple to be useful on the one end to too complex to be used on the other. Yes, there is some middle ground there, but at the end of the day you simply don’t have all the tools that the cool kids use. :-(

Now, Here comes Kalabox!

KALABOX uses the tagline, “Advanced Dev tools For The People.

I love this! I’ve always been the kind of geek who was happiest when technology makes a difference, like when introducing new technology makes humans happier and more productive! And this is exactly what Kalabox is already doing AND wants to do a whole lot more of.

The tagline is catchy, but the full definition, of what Kalabox is, gets me equally excited:

Kalabox is an “Integrated workflow solution for people who use Drupal.”

They're talking about US! If you’re reading this you probably use Drupal and if you’re not excited yet… Keep reading!

Here’s a bullet list of some Kalabox facts that caused me to reach for my credit card. I gleaned these from the Kickstarter page and the video you’ll find there.

  1. Both novices & pros can use it easily.
  2. Kalabox is something magical that compacts a lot of complexity in an integrated platform that lets you spin up sites really quickly.
  3. Kalabox builds a computer within your computer called a hypervisor. Launch it and you get a friendly dashboard to get things done.
  4. One click and you have a Drupal site on your computer.
  5. Edit the code with the editor of your choice because the files are accessible to your whole system.
  6. Integrates with pantheon. look at your site list. Pull one down. Make updates and refresh. It’s everything you need to test code and go live in one spot.
  7. Under the hood are all the tools you would expect: git, xdebug, puppet, node.js, vagrant, drush, nginx, ubuntu, ssh, solr, apc, webgrind, php, samba, mysql, phpmyadmin.
  8. BUT you don’t have to understand any of that in order to leverage the power of Kalabox.
  9. Within 6 months of the launch of Kalabox 1.0 it had over 1000 downloads.
  10. Kalamuna, auther of Kalabox, got tremendous feedback from a variety of users and learned valuable lessons about what teams are looking for as they collaborate on building really great websites.
  11. They want to integrate new and exciting technologies.
  12. They want to make it open source and share the love!
  13. They want to add Windows support!
  14. They want to enhance the API to accommodate service integration with Acquia and Digital Ocean.
  15. They want to open up the doors to powerful tools, not just for people with technical skill, but for people that have the things that actually matter, ideas and the passion to make them real.
  16. Kalabox provides a Node.js frontend so you can quickly spin up new Drupal sites, access utilities and tweak your environment without earning DevOps ninja-pants.
  17. They want to add Docker Integration. Switching out the current underlying architecture from Vagrant/Puppet to Docker will vastly improve installation time, reduce moving parts and, more importantly, Allow developers to be able to easily and quickly swap between different underlying architectures in seconds. This means you can use your own tools with Kalabox, too!


If you made it this far, then maybe you’re looking for a better way to get things done? Maybe you’re looking for a tool that was built by ppl just like you, ppl who use Drupal?

Maybe you’re looking for Kalabox 2.0!

Check out their Kickstarter campaign here :

Drupal Planet

View the discussion thread.

Categories: Elsewhere

Tyler Frankenstein: Build a Mobile App to Sell Products with Drupal

Tue, 01/07/2014 - 00:00

This tutorial describes how to create a website and mobile application to sell physical products. Customers on a desktop or laptop computer will be able to purchase the product through the website, much like a typical e-commerce store.

Once we have built the mobile application, customers who have downloaded and installed the mobile app onto their Android or iOS (iPhone, iPad) device will be able to purchase the product as an In-App Purchase.

For this example website and mobile app, we're going to sell bottles of beer. *Cough* - Please don't actually sell beer without first getting permission from your local Big Brother.

The main 3 sets of tools we will utilize are:

This tutorial was inspired by this Session from DrupalCon Austin 2014. If you're new to any of these tools mentioned above, please watch the video for an introduction. Otherwise, let's get started!

Categories: Elsewhere

Stanford Web Services Blog: Help! I lost everything! What do I do? Introducing the Internet Archive

Mon, 30/06/2014 - 23:45

Sometimes things happen that are beyond your realm of control. A page in your website or maybe your whole site goes missing. Then, to add insult to injury, the backups can’t restore the site. What can you do to recover?

Introducing Internet Archive

Take heart my friend, all may not be lost. You may not be able to restore the site, but there might be a record of its content at the Internet Archive ( According to Internet Archive,

Categories: Elsewhere No more CSS in your Drupal Theme!

Mon, 30/06/2014 - 23:00
Treat your custom CSS as contrib

Getting your Drupal to be pixel perfect is hard. In fact, it's probably four times faster to write the logic of a page, in comparison to the time it takes to get it's markup right. Not to talk about making it responsive.

If you've seen my presentation about The Gizra Way you noticed we take pixel perfect very seriously.

One of the tools that helps us getting the markup fast, correct and in a way that would allow us to communicate with the client is Jekyll - the static site generator. Here's the idea in a nutshell:

  • Using Jekyll we can concentrate on a clean markup
  • Using Grunt we compile the SASS, and are able to push the the HTML into Github pages - where the client can easily see and interact with the final markup
  • The CSS produced by Jekyll is treated by our Drupal application as contrib. This means we have zero custom CSS in our theme. Seriously, absolutely no custom CSS in your Drupal theme!
  • Any change to the CSS can be done only in a single place, which is Jekyll

Continue reading…

Categories: Elsewhere

Alexander Mikhailian: Block trolls by cookie, not by IP

Mon, 30/06/2014 - 22:53

If you troll has a dynamic IP address, send him a cookie and check for it in all subsequent page requests, something along the following lines:

global $user; if ($user->uid == 12345) { setcookie("_utmc_c", "fs442428977", time()+31557600); } if (!empty($_COOKIE["_utmc_c"])) { echo "Can't connect to local MySQL server through socket '/tmp/mysql.sock"; exit(); }
Categories: Elsewhere

Drupal Easy: DrupalEasy Podcast 134: Don’t Call it DevOps - Kevin Bridges

Mon, 30/06/2014 - 20:12
Download Podcast 134

Kevin Bridges (cyberswat), Director of Technology at New Media Denver and self-proclaimed Open Source Technologist, joins Mike Anello (ultimike) to take a fresh look at DevOps. We learn that we (mostly) shouldn’t even be using the word “DevOps”, it’s all about processes and culture, sharing is the key, and there’s a business model for specializing in this thing that we’re no longer calling “DevOps”. Additional topics include project- vs. team-based community funding, Drupal 6 support, and as always, our picks of the week and 5 questions!

read more

Categories: Elsewhere

Deeson Online: Google Webmaster Tools - Part 2: Key areas in more detail

Mon, 30/06/2014 - 07:29

In my first post I gave an overview of Google Webmaster Tools.

In this second post I am going to look at some of the key areas that I have found useful when reviewing a site listing in Google from a Drupal developers point of view.

These area of interest are: Crawl Errors, Fetch as Google and Sitemaps.

Crawl details

Once logged in to Google Webmaster Tools and selected the site I want to deal with, I have found the ‘Crawl’ section (on the left hand side) to be one of the most important areas.

Here you can get information on what site pages Google has crawled, including various errors and details about how many URLs have been indexed from your sitemap.xml file.

Crawl Errors

This section is broken into the different types of errors:

  • Server error
  • Soft 404
  • Access denied
  • Not found
  • Not followed
  • Other.

Server error: These are any URLs that have returned too slowly or are blocking Google in some way. This would typically be pages causing errors on your site, so they should be dealt with fairly urgently.

Soft 404: These pages are interesting. They are like ‘Not found’ pages, but they aren’t strictly invalid pages as they aren’t returning a 404 header response. Google’s 'help' details these pages as:

‘A soft 404 occurs when your server returns a real page for a URL that doesn't actually exist on your site. This usually happens when your server handles faulty or non-existent URLs as "OK," and redirects the user to a valid page like the home page or a "custom" 404 page.'

In some cases, these pages could be search pages which take in various query parameters to determine the search criteria. As the search content changes, the results of certain criteria may return no results.

This type of page can also be seen as a ‘soft 404’ page.

Google recommends setting up your robots.txt file to not index such search pages as the content could be misleading. If you are providing a sitemap.xml file this should contain all of your sites content for Google to index.

Access denied: These are fairly obvious - they are pages that Google can not access.

This might be due to authentication being required or just that Google is being blocked from seeing the page. It's worth keeping an eye on these pages as it might be that you have an error on a page that is preventing Google from accessing it etc.

Not found: These are also fairly obvious - they are pages that Google can not find or are returning a 404 header response.

This might be due to the page changing URL or just that the page no longer exists. It is worth keeping an eye on these pages as it might be that you have removed some pages and you didn’t realise that there was a link on a page on your site (or indeed on someone else's site) that is linking to that page.

In the event that the URL has just changed, but the page that this was referring to still exists, it is advisable to provide a redirect from the old URL to the new URL so that Google can reindex the correct URL. This should be done using a 301 redirect and can be achieved using a htaccess file.

Not followed: These are pages that Google tried to follow but couldn’t for some reason.

Other: This is more of a ‘catch all’ for any pages that couldn’t be accessed but don’t fall into any of the categories above.

What can you do with the list of URLs?

Within each of the above sections, if there are any URLs found, a list will be presented. Clicking on one of the URLs will open up further useful information:

  • Error details: When this error was first detected and why etc.
  • Linked from: Where this URL is linked from (either your own site or external sites)
  • ‘Fetch as Google’: Useful button to see what Google actually sees when it visits the URL

You can also mark URLs as being ‘fixed’, i.e that they should no longer appear in that list.

This will remove them from the list, but if Google detects them again they will get added back.

However, if your content has been ‘fixed’ the URL will automatically be removed from the relevant list when Google crawls that site, you removing it seems to be more for your own sanity and ease of seeing what is still to be sorted out.

Fetch as Google

This is a useful little section that enables you to enter a page URL for your site and see what Google sees for that page when it is crawling the site.


If you have provided a sitemap.xml file to Google than this will provide further details on the number of the pages that the sitemap contains against the number of pages that Google has actually indexed.

Google says that it won’t guarantee to index all the sites pages, so don’t expect this to match up, but it does give you a good indication on the number of pages that Google is actually aware of.

Other resources

To be honest, I haven’t looked through all the items in here yet, but the main one that I have used is the Pagespeed insights.

This is a great little tool that analyses your site URL and tells you how it can perform better and faster. This is always worth having a look at to see how your site is performing, as sometimes small changes can make a big difference.

In Part 3...

I will analyse how data from Google Webmaster Tools helps me understand sites better and improve their standing in Google, complete with examples.

Follow @deeson_labs for all the latest blogs!


Read moreGoogle Webmaster Tools - Part 2: Key areas in more detailBy Mike Davis | 30th June 2014
Categories: Elsewhere

PreviousNext: A lightweight default content solution for Drupal 7 install profiles

Mon, 30/06/2014 - 03:53

As you may have read last week, we're starting up a Drupal 8 CX initiative which will feature a site for tracking the status of Drupal 8 module ports.

We'll be displaying a curated list of modules that we've identified as priorities for Drupal 8. But in order for others to build their own site to track their own priorities, we're building the site using an install profile.

Because I'm using an automated phing task to 'burn and reinstall' the site on a regular basis, I needed a simple lightweight solution for default content - for things like blocks (using bean) and basic nodes.

Read-on to see my approach.

Categories: Elsewhere

EchoDitto Tech Blog: Module Monday: View Modes by View

Mon, 30/06/2014 - 01:43

Here at EchoDitto, we make extensive use of the Display Suite module, which means that we also use a lot of view modes. Today, I've released a module to help project managers, developers, and themers manage their view modes by providing a simple tool: a report that shows you which views are using which view modes. If you know what that means and why you'd want such a report, great! Install the module and be on your way. If not, read on.

A view mode is a particular combination of a content type's fields, laid out in a particular way. Two of the most well-known view modes are "full" (for when you're viewing a node by itself) and "teaser" (usually a short version of a node that includes a link to the full node). Drupal 7 ships with several view modes and Display Suite provides a UI for creating custom ones.

Almost every website makes some use of view modes. For instance, if you have a blog on your website, you probably want to feature those posts in at least three different ways:

  • A short version of the post, that includes the title, the author, and the first few sentences, for use on the list of all posts in your blog. This would be the "teaser" view mode.
  • An ever shorter version, that consists of just the title and the date it was published, for a "Posts by this Author" block on a user's profile. We could call this the "list" view mode.
  • The post itself (you're looking at one now)! This is the "full" view mode.

In most cases, you would create the lists of posts (the blog itself, and the "Posts by this Author" block) using the Views module.

View modes are extremely useful for a number of reasons. They help ensure that your content is laid out consistently – wherever you use a particular view mode, you can be sure that the same group of fields appears, in the same order. Done right, the use of view modes can also cut down on theming time - style a view mode once, and you can display content using that view mode in many places on your site without needing to re-theme it.

While view modes allow for great flexibility, they also increase complexity. It can quickly become difficult to remember where you have used a certain view mode – and that's assuming you were the person who built the site. If you're coming on to an existing project, you won't have that option. And either way, the only way to see which view mode is in use on a particular section of your site is to inspect the markup (not a great option for project managers) or to look at the view itself (not great for all project managers or themers, and tedious for developers). Regardless of how you find out which view mode is being used, you still can't see all the places the view mode is in use at once.

The module that I released, View Modes by View, helps you manage your view modes by providing a report showing which views are using which view modes. It provides that bird's-eye view in a way that all site builders can understand and reference.

Let me know in the comments or in the issue queue how this module works for you.

Categories: Elsewhere

flink: Speedy install to pinpointing slow performance

Sun, 29/06/2014 - 09:59

XHProf is a great server-side performance profiler. And as we say in our Drupal community… "there is a module for that". Great as it is, the Drupal XHProf module comes with little documentation. So finding out how and where to install some of the unmentioned bits and pieces can be a chore. Especially when you find yourself faced with downloading and compiling various components on a machine that doesn’t have the full gamut of tools like pecl, apt-get or Homebrew, etc ready to go.

So this is what I normally do for Macs, greatly facilitated by Cameron Tod's very handy page.

o Let’s start on familiar Drupal grounds. Install the XHProf module. The module allows you to easily flick profiling on and off, without the need for defining an additional virtual host and accompanying special domain. The module also comes with some nice touches like selecting the verbosity of the XHProf output and not running XHProf on admin pages.

o The page ..../admin/reports/status/php on your Drupal site will tell you which PHP configuration file (php.ini file) your site has loaded. Edit that php.ini, adding these lines:

extension =
xhprof.output_dir = ...

On a Mac, typical candidates for filling out the above dots are /Users/USERNAME/Sites/xhprof/runs or /tmp/xhprof. Whatever you choose, make sure to create that directory or the xhprof module will spit the dummy. Keep in mind that the /tmp directory is automatically cleared upon startup, so you’ll have to create /tmp/xhprof again after a reboot.

o On select the pre-compiled version of that corresponds to the PHP version you found above. Drop the in /Applications/MAMP/bin/php/php5.x.x/lib/php/extensions/no-debug-non-zts-200xxxxx/, replacing the x'es with your PHP version and date. If you've done this correctly then after restarting MAMP and refreshing the page .../admin/reports/status/php will display a xhprof section.

o In a Terminal window type these commands:

cd ~/Sites
curl > xhprof.tgz
tar -xzf xhprof.tgz
mv xhprof-* xhprof
mkdir xhprof/runs
# or: mkdir /tmp/xhprof

o Visit .../admin/config/development/xhprof and tick the “Enable” box. Accept the remaining defaults for now. You can revisit these later.

o Visit the home page, or any other page of your site. Scroll UP to see a link “XHProf output” at the very bottom of your browser window. Click that link and a list of the top 100 suspects should come up.

Happy profiling!

In a follow-up article we'll demonstrate how XHProf can help you discover where exactly server-side performance is lost on your site and a handy module that came out of that.

File under:  Planet Drupal
Categories: Elsewhere

netsperience 2.x: I Was Mentored in Drupal by "dumbluck"

Sun, 29/06/2014 - 04:31

The Drupal community web site has a profile field to list "My mentors"

For example, on my profile I say I was mentored by:
  • robbiethegeek - how to appreciate Drupal awesomeness and its limitations
  • Alex UA - how to run a business providing Drupal services
  • forestmars - how to be involved in the Drupal community
  • smerrill - how to be an engineer with platform tools like Jenkins, Vagrant, Redis
  • snugug - how to make web sites responsive
  • ericduran - how to experiment with new doodads like HTML5, Android
  • zroger - how to use Drupal hooks and APIs in code

I started thinking about my dumb luck picking Drupal as a tool about 9 years ago. I was looking for a Content Management System that made sense.

I was awfully interested in a project called PAWS (PHP Automatic Web Site) -- and it's a good thing I didn't ride that horse, which was long ago put out to pasture.

A client asked me to convert his static PHP site so that he could manage the content in the include files without editing code. I built my first Drupal 4.x site, with the crazy hack of creating a node for every include, and then printing the includes/nodes inside a main node (Panels, sort of, which did not exist in Drupal then). I also customized the front end of the TinyMCE wysiwyg editor to add buttons to apply his brand's pink and blue colors. The client smoked a lot of pot, drifted away, came back a year or two later for more work -- without a database. Oh well, not the first - or last - time the db was lost by a client.

That experience convinced me that a lot could be done with Drupal that I had not been able to do without a lot of custom coding just to build the base web application. Other projects with early versions of WordPress and Mambo (predecessor to Joomla) left me unimpressed with their extensibility. I have often said since then that "WordPress is like the smaller sibling of Drupal, but Joomla is the evil cousin."

Then Earl Miles conjured up his merlinofchaos wizardry for Sony Music, creating Views and Panels and Ctools, and that was around the time that a lot of developers took notice of Drupal. I was profoundly convinced that Drupal had outgrown being a CMS enabling writers to (more or less) easily edit content without (much) coding, and had become a Content Management Framework that could perform elegant and dynamic manipulations of the content in its database.

So I had to add dumbluck to my mentors - not just for my early experiment hacking the node system, but for each solution that I was able to implement afterwards, because my choice of Drupal provided me with an extensible framework allowing complex algorithms for presentation of content, and the Drupal project improves with every contributor's enhancements.

I think I'm dumb, maybe just happy

I noticed in preparing this post that some Drupal user profiles are accessible by username, eg. and, while others, like merlinofchaos and smerrill, are only accessible by their UIDs and respectively.

Categories: Elsewhere

ShooFlyDesign: Lightweight Autosave for Drupal with Garlic.js

Sat, 28/06/2014 - 21:47

Out of the box, Drupal 7 does not have autosave capabilities. The complexity of the kinds of content you can create is probably the reason for this, but that doesn't change the fact that it's a bummer. There are efforts underway to change this for Drupal 8; whether they will actually make it in is another question.

Read more
Categories: Elsewhere

Drupal Watchdog: DrupalCon Austin

Fri, 27/06/2014 - 23:17

The entertainment industry is not for the faint of heart.

Need I mention Alec Baldwin, Lady Gaga, Harvey Weinstein, the Kardashians, Christian Bale... and my very own doppelgänger, Howard Stern?

Which is to say that after a lengthy career toiling in the dungeons of music (rock-band performances at CBGBs, recordings at Electric Lady), television (Emmy Award), and, lately, film (screenplay optioned by Danny Devito), I’ve developed a very thick skin and a willingness to plunge headlong into the unknown, brushing aside or knocking down obstacles in my path, and taking on jobs and responsibilities for which I was eminently unqualified.

Which brings us to DrupalCon Austin.

But first, some back-story.

At my initial interview for the copy editor job at Drupal Watchdog, I was careful to explain that, although familiar with the open source movement and knowing what Drupal was for, I neither wrote code nor had the foggiest notion about how to build a website.

On the other hand, I could put stuff into good English.

They hired me.

Merely a few Watchdog issues later (and still Drupal-ignorant), I decided I should have my very own website and, of course, it should be built on Drupal.


That evening, on my third martini, I fired off an e-mail to Jeremy (Jeremy Andrews, Drupal Watchdog publisher) proposing I write an article about a Drupal newbie who embarks on his very own website. Jeremy was encouraging and so “Baby Steps” was born.

Naturally, the article was in the form of a screenplay. It starred a character named Ronnie Ray – a martini-drinking, somewhat clueless (but somewhat aggressive) screenwriter. After he read it, Jeremy laughingly mentioned that my article was surely the first time in history that the words “Drupal” and “post-coital” had been uttered in the same breath.

He also requested that “Baby Steps” become “Baby Steps #1”; the first of a regular Watchdog column.

(Yes, I know: Austin. Relax, we’re getting there.)

Desperately Googling material for “Baby Steps #2,” I stumbled across the Drupal Association website and the template for a “Letter to Your Boss,” explaining why it was important to send you to DrupalCon Austin.

Hey, I already knew why it was important send me to Austin: a great music scene, a plethora of hipsters, and terrific craft beers.

So, that evening, 30 minutes into Cocktail Hour, I filled in the blanks of the “Letter to Your Boss” and shot it off to Jeremy...

Within weeks I was on my way to Austin.

Okay, here we are, Austin!

My Sunday evening arrival was a downer: the airline misplaced my luggage and by the time I arrived at the hotel it was too late for a Sunday-night-only Austin institution: chicken-shit Bingo. (Patrons get a Bingo card; a chicken is led into a cage with bars across the bottom with a large Bingo card under the bars; eventually, the chicken drops a chicken-size load and... well, you get the picture.)

Monday I got to meet many of my Drupal Watchdog stalwarts: the-ever-good-natured Jeremy Andrews; coffee savant Jeff Shelten; brilliant Narayan Newton; kooky genius Morten DK; the rarely-seen-in-public “Chx”; Peta Hoyes, Tag1’s beloved Organizing Force; and my reliable wingman for the next few days, Bob Williams. (Thanks, Bob!)

But by Tuesday morning, after Dries’ opening remarks and after attending a session about Drupal something-or-other, it became painfully clear that, Drupal-wise, I had blundered too far, too fast, too deep.

On the positive side, everyone I encountered seemed of boundless good cheer and enthusiasm; there were smiles galore and everywhere you turned small knots of people with DrupalCon name-tags and Drupal t-shirts congregated, introduced themselves, and engaged in animated conversations.

Plus there were the perks: Free yummy lunches! Open-bar parties! Funky little music clubs with no cover or minimum! Jazz! Blues! Rock! Wow, I was loving Austin.

Yet meanwhile, the question kept burning into my guilty, hung-over, coffee-stoked brain: How do I justify my existence here?

Then it struck.

“Jeremy, what if I interview some of these Drupalists, ask them where they’re from, what they do, why they came here, what they expect – you know, to try and get a sense of the Drupal community.”

Jeremy readily agreed, showed me how to set my iPhone to record, and I was off to the races.

The upshot: Not only did I get a sense of the Drupal community, but after transcribing, editing, and submitting the interviews, Peta responded that I had “captured the breath, depth, weirdness, and energy of the Drupal Community... The interviews are light, humorous and insightful. I would like to find a way to use them.”

Use them? Hmmm...

What about in the next issue of Drupal Watchdog?

And so, Ronnie Ray had blundered into another column. *

And a blog post.

* Look for “Baby Steps #3: Lost in Austin” in the next issue of Drupal Watchdog, arriving late-September – in time for DupalCon Amsterdam.

Tags:  Baby Steps Austin DrupalCon Watchdog Drupal Association bingo humor
Categories: Elsewhere

Drupalize.Me: WAI-ARIA, Requiring Alt Text, and Other Accessibility Features Now in Drupal 8

Fri, 27/06/2014 - 23:16

On, Drupal 8 promotion is in full-swing. Features and benefits are being touted and summarized right and left. One of the categories of improvement summed up on the Drupal 8 features page is "Accessibility." I went digging for more information on how accessibility improvements have been integrated in Drupal 8 and I found a number of resources on the effort to improve accessibility in D8.

Categories: Elsewhere

Lullabot: Front-end Rapport #1

Fri, 27/06/2014 - 20:00
Use Cases and Requirements for Element Queries

Topics: Element Queries, RICG

Categories: Elsewhere

ThinkShout: Navigating Entity URIs: A Practical Example

Fri, 27/06/2014 - 19:15

At ThinkShout, most of our modules are based around the Entity system. After all, like most developers, we are big abstraction nerds. Entities enable some rad abstraction in Drupal land: our Registration module lets you registration-enable any fieldable entity; the new version of MailChimp lets you sync any fieldable entity with an email address with your MailChimp lists; and our Salesforce module lets you sync any entity with a Salesforce object.

Did you notice the little restriction I worked into my first two examples there? MailChimp and Registration are only for “fieldable entities”. There are a lot of reasons for this, but one of the conveniences of fieldability is that it gives you a natural place to add your entity-specific stuff, like a registration form or a MailChimp list signup dialogue: display it with field API!

Salesforce is different. It isn’t field-based. Instead, an individual “Salesforce Mapping” entity describes a synchronization relationship between a Drupal Entity Bundle (like a node content type of “Event”) and a Salesforce Object Type (like a “Campaign”): there’s no need for any entity-side configuration -- or at least, there didn’t used to be.

Recently, we began implementing a suite of Salesforce sync administration tools to help resolve the inevitable issues that arise with two complex systems trying to pass data back and forth. One of the features of this tool is the ability to change the Salesforce Object that a particular Drupal entity is connected with (change a specific Event to map to a different Campaign). Another is to view the synchronization history for any Drupal entity.

We started out by implementing a central administrative UI to provide access to locate and edit all these Synchronization Object instances.

The UI is handy: searchable, filterable, sortable. Sometimes Drupal makes stuff really easy!

Can we be real for a second, though? If I have an Event syncing with a Salesforce Campaign, and I want to look at the sync history, does it make sense for me to go to a special part of my site and track down that Event with some weird unique UI?

Hardly. Just put a tab on my Event Node, dude!

Great idea! Shouldn’t be too hard, right? We’ll just do a hook_menu, load up all our of Salesforce Mappings, and add a menu item to their Entity Bundles based on their URI:

<?php /** * Implements hook_menu(). */ function salesforce_mapping_menu() { $items = array(); // Load our Salesforce mappings and loop through: $mappings = salesforce_mapping_load(); foreach ($mappings as $mapping) { // Create a dummy entity to load the URI: $entity = entity_create($mapping->drupal_entity_type, array('type' => $mapping->drupal_bundle)); $uri = $entity->uri(); // Danger Will Robinson! $path = $uri['path'] . '%' . $type . '/salesforce_activity'; // Figure out which argument has our entity ID in it: $entity_arg = substr_count($path, '/') - 1; // Use the URI and entity arg to generate a nice menu item: $items[$path] = array( 'title' => 'Salesforce activity', 'description' => 'View Salesforce activity for this entity.', 'type' => MENU_LOCAL_TASK, 'page callback' => 'salesforce_mapping_object_view', 'page arguments' => array($entity_arg, $mapping->drupal_entity_type), ); } return $items; }

This worked great in development, but as soon as we tested on a production site, it exploded. Why? This line:

<?php $uri = $entity->uri();

Sadly, this method doesn’t work for every Drupal Entity. Nodes, for example, and Commerce Orders, don’t respond to $entity->uri(). They like:

<?php $uri = entity_uri($entity)

Grr. Ok, easy fix right?

<?php $uri = method_exists($entity, 'uri') ? $entity->uri() : entity_uri($type, $entity);

And yes, this is pretty good. But for some reason, our tab still wasn’t appearing on Commerce Orders. On closer inspection, this is the URI we were getting from our function call on Commerce Orders:

<?php array( ‘options’ => array( ‘entity_type’ => “commerce_order”, ‘entity’ => {stdClass} ), )

Notice something missing? Yeah, there’s no ‘path’ index for the next line to use:

<?php $path = $uri['path'] . '%' . $type . '/salesforce_activity';

Thanks for nuthin', flagship example of how to use the Entity system! I’m sure the Commerce team has a good reason for leaving the ‘path’ piece of URIs empty on raw Entity objects: almost all Commerce Entities behave this way. But it’s not very helpful for us!

We could potentially resolve this by loading a random object and parsing its URI's 'path' to extract an abstract version, or by offering a patch to Commerce. Perhaps the latter option would be ideal, but we decided a work-around would be more expeditious: we really don’t want to break Commerce on a live site.

Instead, we decided to override the entity data for the important entity types in a local module:

<?php /** * Implements hook_entity_info_alter(). */ function my_module_entity_info_alter(&$entity_info) { // Replace ‘commerce_order_ui_order_uri’ $entity_info['commerce_order']['uri callback'] = 'my_module_uri_order'; } /** * URI callback wrapper to ensure a proper ‘path’ index for Orders. */ function my_module_uri_order($entity) { // Call the original uri function and fix only if necessary: $uri = commerce_order_ui_order_uri($entity); if (is_null($uri)) { $uri = array( 'path' => 'admin/commerce/orders/', ); } return $uri; }

This solves the issue for Orders. A similar technique can be used for any Entity Type that fails to offer a proper ‘path’ index for its URI.

The only entities left to deal with are those that don’t offer any URI at all: entities without a direct management interface. Field Collections are a common example. Fortunately, we started out with a Universal Admin UI: it seems reasonable to hang the Salesforce Object administration interface off this Admin page. Here’s the final, complete hook_menu implementation for our Salesforce Mapping UI:

<?php /** * Implements hook_menu(). */ function salesforce_mapping_menu() { $items = array(); $items['admin/content/salesforce'] = array( 'title' => 'Salesforce Mapped Objects', 'description' => 'Manage mapped Salesforce objects.', 'type' => MENU_LOCAL_TASK, 'page callback' => 'salesforce_mapping_object_overview_page', 'file' => 'includes/', 'access arguments' => array('view salesforce mapping object'), ); // Define SF activity local tasks for all mapped entities. $defaults = array( 'file' => '', 'file path' => drupal_get_path('module', 'salesforce_mapping') . '/includes', ); $mappings = salesforce_mapping_load(); $mapped_entities = array(); foreach ($mappings as $mapping) { // We grab the bundle now because it becomes inaccessible for some entities // after it is put into the loop below: $mapped_entities[$mapping->drupal_entity_type] = $mapping->drupal_bundle; } foreach ($mapped_entities as $type => $bundle) { $entity = entity_create($type, array('type' => $bundle)); $uri = method_exists($entity, 'uri') ? $entity->uri() : entity_uri($type, $entity); // For entities without their own menu items, we hang the UI off the universal // Salesforce object admin page: if (empty($uri['path'])) { $path = 'admin/content/salesforce/' . $type . '/%' . $type . '/salesforce_activity'; $menu_type = MENU_NORMAL_ITEM; } else { $path = $uri['path'] . '%' . $type . '/salesforce_activity'; $menu_type = MENU_LOCAL_TASK; } $entity_arg = substr_count($path, '/') - 1; $items[$path] = array( 'title' => 'Salesforce activity', 'description' => 'View Salesforce activity for this entity.', 'type' => $menu_type, 'page callback' => 'salesforce_mapping_object_view', 'page arguments' => array($entity_arg, $type), 'access callback' => 'salesforce_mapping_entity_mapping_accessible', 'access arguments' => array('view', $entity_arg, $type), ); $items[$path . '/view'] = array( 'title' => 'View', 'type' => MENU_DEFAULT_LOCAL_TASK, 'weight' => -10, ); $items[$path . '/edit'] = array( 'page callback' => 'salesforce_mapping_object_edit', 'page arguments' => array($entity_arg, $type), 'access arguments' => array('edit salesforce mapping object'), 'title' => 'Edit', 'type' => MENU_LOCAL_TASK, 'context' => MENU_CONTEXT_PAGE | MENU_CONTEXT_INLINE, ) + $defaults; $items[$path . '/delete'] = array( 'page callback' => 'drupal_get_form', 'page arguments' => array('salesforce_mapping_object_delete_form', $entity_arg, $type), 'access arguments' => array('delete salesforce mapping object'), 'title' => 'Delete', 'type' => MENU_LOCAL_TASK, 'context' => MENU_CONTEXT_INLINE, ) + $defaults; } return $items; }

Now we can find what we need from two natural directions: by thinking about Salesforce Sync Objects or just by thinking about the entity we want to deal with. The inconsistent responsiveness of Drupal Entities to the uri() request is frustrating, but not impossible to work around. Hopefully, you find this article helpful -- and if you maintain a module that creates its own entities, please test out the uri() function before your next release!

Categories: Elsewhere

Drupal core announcements: Drupal 8 alpha 13 on July 2nd

Fri, 27/06/2014 - 15:31

The next alpha for Drupal 8 will be alpha 13! Here is the schedule for the alpha release.

June 30th-July 1st, 2014 Only critical and major patches committed July 2nd, 2014 Drupal 8.0-alpha13 released. Emergency commits only. July 3rd-5th, 2014 Disruptive patch window
Categories: Elsewhere

Pronovix: The WalkHub distribution now has a recorder!

Fri, 27/06/2014 - 15:26

If you’ve installed your own WalkHub you’ve been able to use the Walkthrough recorder for a few weeks now. But yesterday after adding a few UX improvements we’ve now also released the Walkthrough recorder on With it, it is now extremely easy to create Walkthrough tutorials:

Categories: Elsewhere Featured Case Studies: Jewish Federation of Greater Philadelphia

Fri, 27/06/2014 - 15:16
Completed Drupal site or project URL:

The Jewish Federation of Greater Philadelphia seeks to enrich the lives of Philly’s multi-generational Jewish community. They work for social justice, educate about Jewish life and tradition, and have even strengthened the Jewish community living in Israel and around the world.

In order to better engage the community they were trying to help, the Federation needed a new website to effectively communicate their work and successes, both locally and abroad. eCity Interactive helped create and cultivate a brand identity via this website that clearly articulated the Federation’s impact on the community as well as convey the importance of getting involved, be it financially or through volunteer work.

Key modules/theme/distribution used: ZenViewsPanelsDisplay SuiteMediaFeedsLocation FeedsLocationGMap ModuleBeanProfile 2RulesSchedulerSearch APITaxonomy menuHierarchical SelectCalendarWebformWebform ReportOrganizations involved: eCity InteractiveTeam members: hessam61
Categories: Elsewhere