Drupal Apps: the answer to plug and play Drupal site building?

The Apps approach to making Drupal site building easy is gaining support. But there's a long way to go before Apps can provide sites seamlessly integrating components from multiple providers.

Apps: the glue between custom sites and Drupal distributions

Apps promises to fill the gap between custom site building on the one hand and Drupal distributions on the other.

To its credit, Drupal is hugely flexible. With great tools like Views, configurable content types and fields, and a host of solid extensions for everything from groups functionality to commerce, Drupal can help you build pretty much anything. As Larry Garfield has argued, Drupal is a content management framework rather than a content management system.

But should you really need to build every site from scratch? With hundreds of thousands of Drupal sites already out there, chances are most of what you need has already been built many times over.

The main answer to the aim of making site functionality reusable is Drupal distributions. Want a news-focused site, a nonprofit site, an online community? Browse the list of distributions on drupal.org, select and install one, and you're well on your way.

But a distribution tends to come with some tight constraints. Design decisions. Interdependencies. Reliance on a particular theme. What if you don't need or want the whole deal? What if you want to pick and choose components that might come with various different distros--a bit of commerce functionality, some mapping, some search enhancements, a newsletter?

That's the space that Apps aims to fill. An app is a focused set of functionality that you can easily download and install--along with all of its dependencies.

In the 16 months since the Apps initiative was launched, dozens of apps have been produced and shared. Several distributions have been built on or converted to use Apps. The recently released Panopoly apps set provides a base designed to be used by various distributions as well as individual sites.

There are two ways to get apps:

  • Install an apps-based distribution. You'll be prompted to select and install apps as part of the site installation process.
  • Install the Apps module and an apps connector module. Some available connector modules are LevelTen apps and Debut apps. Log into your site and select Apps from your admin menu. You're connected to one or more apps servers and given a selection of apps to install.

If you're a Drupal developer and want to produce and share apps, your process will include:

  • Build an app. For hints, see the Phase2 documentation.
  • Either submit your app to an existing app server or create your own app server using the App server module. The App manifest module can help with generating the code to use on the app server.

So far so good. But how well do the available apps play together?

Interoperability: the Apps standard and Kit

Ideally, different apps produced by different Drupal shops and developers will seamlessly integrate. Interoperability is a key aim in the Open App Standard from which the Apps module emerged:

[t]he high level goal of the project is to achieve interoperability of apps between sites so that the Drupal platform does not become fragmented as specific distributions become widely adopted. That is, an app which conforms to the open app standard will be capable of being installed onto any site which conforms to the same standard.

An early initiative to promote interoperability was the Kit feature specification, which laid out "a set of guidelines that facilitates building compatible and interoperable Features". Kit was a good start, but it languished when its authors mostly moved on from Drupal development.

The close tie between apps and specific Drupal distributions has been a big factor in limiting interoperability. It's relatively easy to build an app that will play nice with other apps in the same distribution, since the apps will share a lot of common assumptions. But start mixing apps from one distribution with those of another and you'll quickly hit problems, ranging from relatively innocuous inconsistencies all the way to fatal page errors.

Issues and barriers

Layout and design

There are two main approaches to layout in Drupal distributions: Context and Panels. While it's possible to combine the two in a given site, they can easily conflict.

Can Panels-based apps mix with Context-based ones? Can we come up with a standard Apps layout approach? Discussions are ongoing both within app development circles and in the related issue queues, like this issue on Panels.

Standard solutions?

Ask any three Drupal site builders what modules they'd use to design a given feature and you're likely to get three different answers. Take mapping for example. One developer might choose OpenLayers, another Gmap, and a third Leaflet. There are valid reasons for each choice. But if you install three different apps that use three different mapping libraries, you quickly end up with a mess.

There's probably no easy answer to the question of competing solutions. The Debut feature specification makes a stab, but isn't used beyond the Debut apps set. A good start would be a inventory of existing apps and their preferred modules, so we can get an idea at least of where we stand.

Duplicate or conflicting components

What do you name the image field that accompanies an article? If you're using a Debut app, it will be called field_content_image. Install Panopoly pages and you'll get a field_featured_image. Enterprise base? field_inline_image. Add them all after installing Drupal core with the standard install profile (which creates field_image) and you'll have four different fields doing pretty much the same thing.

The problem gets worse with user roles. To work out of the box, an app needs to provide appropriate user permissions. But what roles should those permissions be assigned to? Even for virtually identical use cases, there's no consensus. For example, Enterprise base creates a 'copywriter' role for users who write content, while Debut provides a 'contributor' role for the same purpose. Install them both and - presto - duplicate roles, each with their own mess of permissions.

Fixing this type of duplication could be as easy as extending Kit to cover more naming conventions. Doing so would require some good collaboration between app authors.

Dependencies

A bit more complex than naming conventions is dependency handling.

Say you want to add a 'tags' taxonomy field to a content type. Easy--create a 'tags' vocabulary, add a taxonomy term field to your content type, and export the field to Features.

However, the result will be that the tags vocabulary is exported along with the field, meaning that any other app using a 'tags' vocabulary will conflict with - or be dependent on - your app. Moving more generic components into generic apps doesn't in itself solve the dependency issue. For example, if my_tags and your_tags both provide a tags vocabulary and are dependencies for various my_ and your_ apps, the my_ and your_ apps will have conflicting dependencies.

One way to avoid these sort of dependency problems is to keep generic components out of features. A sample implementation is the handling of the tags vocabulary in Debut Article (see debut_article.install and debut_article.module): the vocabulary is created at install time and then explicitly removed from features dependency handling.

Another approach would be to develop and agree on a set of core apps that many other apps could require. Panopoly is a potential step in this direction. For example, apps needing responsive images could require Panopoly images. The planned Spark distribution may also produce some components or apps that could be used by various distributions and app authors.

Enhancing the components of other apps

Say you're using an app that provides social linking for different content types and you're also installing other apps that provide content types (events, pages, and so on). How does the social linking app know which of these content types should have social links?

One step of complexity higher is the question of applying fields to entities provided by other apps. Say you have a mapping app that provides a mapping field. How can the mapping app enhance an app providing an event (which has a mappable address field) by adding a mapping field?

Within the the Debut apps set, individual apps can declare components available for enhancement through a set of defined .info file keys. Two examples from debut_article:

// Declare the article content type as suitable for social links.
debut[social][node_types][article] = article
// Declare the article content type as suitable for a media field.
debut[media][node_types][article] = article

Code in Debut Social and Debut Media interprets these keys, adding social links and a media field.

Enterprise base takes a different approach to providing fields, with various apps requiring Enterprise base to create an image field on their content types.

Developing some common approaches here would allow different apps with distinct approaches to recognize and enhance each other.

Visibility

Apps are provided by their own app servers. But how do you find an app server?

Look on drupal.org and you'd be lucky to find out that apps even exist. Drupal distributions are highly profiled. But the apps that many of them are built on are practically invisible. Some are listed, but they're lost among the thousands of available modules. No app yet has a large install base. To fix this, we'll need at least an "apps" category for modules. Better yet, as the Apps model matures, we could have a separate space for browsing apps alongside distributions, modules, and themes.

Security

Alongside visibility, there are security concerns with the Apps model. Regularly with Drupal, you're downloading and installing code from drupal.org and hence can rely on some security standards. In contrast, Apps has you connecting to and downloading and installing code from various servers that you as a site administrator don't know anything about.

Part of a more robust Apps framework might be hosting apps directly on drupal.org. A lot of the technical infrastructure and protocols that would be needed has already been put in place as part of the work to fully package distributions on drupal.org.

Apps tools

Apps enables an easier site admin experience by handling the download and install of dependencies, including external libraries. But it also introduces some barriers. Install an Apps-based distribution and you'll be prompted for ftp or ssh authentication--even if all the code you need is already in the install.

Overall the Apps toolset is at a relatively early stage. The good news is the Apps and Appserver modules are starting to get some community contributions building on the great start made by Phase2.

Apps: a promising start

The whole point of community open source is pooling efforts and sharing solutions. We do so with code. Can we do the same with site functionality?

Apps and the features they're built on provide a promising start. But there's a lot more work to do.

Those of us involved in building apps need to work harder on developing shared standards to make the ideal of fully interoperable apps a possibility--and then a reality.

Feed: 

Comments

promising extension to site components

having wrestled with the limitations of Features - which are negligible compared to the power inherent in Features

having used both Panels and Context without conflicting

having created many snippets of custom code, not quite a module but not really a block or template either

going to look at Apps and what they can add to the mix

as soon as I'm back in Drupal 7 - many of my Enterprise clients are still using Drupal 6 and Pressflow, and will probably continue to use them at least until D8 comes out

btw, you would probably get more comments if you retain a message that informs anonymous users that they must register or log in to post comments; "An illegal choice has been detected" message does not really explain that

also, Captcha above the Save button is a logical placement

Nice article

I'm excited to dive into the Debut app set to check out how you are implementing apps that add fields to content types defined by other apps. The approach you describe sounds really interesting.

I know that I can go check it out for myself, but are you handling removal of "add-on" fields when a secondary app is uninstalled? In other words, can I try out a Debut app that builds on another and then remove it cleanly?

A couple of relevant issues

The approach I took in debut_media.module serves more as an example than a solid model. It's complex and before repeating it elsewhere I'd like at least to refine and generalize it. Awhile back I opened a relevant issue on features.

Re removing fields, haven't addressed that yet. It's an area that needs some thought. Disabling a feature does not disown content type has discussion about whether and how to remove content types and their fields when a feature or app is removed. Media gallery's .install file is an example of removing fields via hook_uninstall().