Apps compatible provides methods to help multiple apps or features to play nicely together.

This module does nothing on its own and should be installed only if it's required by another module.

Features and distributions using Apps Compatible

Why this module?

Apps and features, used as building blocks of Drupal distributions, are intended to provide discrete areas of functionality that integrate together. However, in many cases there are shared components - roles, taxonomy vocabularies, fields, etc. - that are required in multiple apps or features.

If multiple different distributions each use Features to provide their own version of these shared components, the different distributions will be mutually incompatible, as they will have conflicting dependencies.

Despite its name, Apps compatible is not explicitly tied to the Apps module and may be used with any app, feature, or non-feature module.

What does this module do?

Shared components

The main focus of Apps compatible is to provide API methods that features modules can use to create and use shared components.

While Apps compatible uses the same export formats as used by Features, it does not use features for creating shared components. Instead a custom API is used to:

  • Avoid the dependency problems that Features introduces.
  • Allow apps or features to use selected shared components - e.g., one or two shared roles - without inheriting the full set of shared components.

Apps compatible ships with the definitions of several shared components:

Roles

  • administrator: a site administrator role, typically assigned the administrator role setting. All permissions that are assigned via Features should be assigned to the administrator role.
  • editor: a content administrator role. While this role may be assigned the 'administer nodes' permission by a particular distribution, individual features and apps typically should assign this role admin access to all content types that they provide.
  • contributor: a content contributor role.
  • manager: a site manager who has access to tasks like administering content types and users.
  • member: a member of an organization; could be used by membership-based organizations to assign a subset of website users membership privileges.

Taxonomy vocabularies

  • tags: a freetagging vocabulary.

Field bases

  • body: a body field.
  • field_address: an address field. Requires Addressfield (addressfield), Chaos tools suite (ctools).
  • field_content_image: an image field to accompany content.
  • field_link: a link field. Requires Link.
  • field_media: a file field.
  • field_tags: a taxonomy term reference field to the 'tags' vocabulary (also provided by Apps Compatible--see above).

Methods to facilitate interoperable apps and features

As well as providing methods for shared components, Apps compatible includes a collection of methods handy for developing interoperable features and apps.

Developer usage

These instructions assume the 2.x branch of Features.

To use this module to write interoperable Apps or Features:

  • Create your feature as usual, but don't yet add any of the components provided by Apps Compatible, or any components that depend on them.
  • Write the Apps Compatible integration for your feature. See the API documentation for documentation and an example.
  • Edit your feature's info file to add a dependency on Apps Compatible and also on any modules listed above for the components you're adding. For example, if you add the 'field_address' field base, add the following to your feature's info file:
    dependencies[] = addressfield
    dependencies[] = ctools
  • On a development site on which your feature has not yet been enabled, download Apps Compatible, Features, and any other dependencies of the Apps Compatible-provided components you're using.
  • Enable your feature. The components you declared in your hook_apps_compatible_info() implementation should be installed on your site.
  • If you are using any field bases supplied by Apps Compatible, using the Features UI, recreate your feature and add field instances for those field bases. You will see that those field bases have been automatically detected and added to your feature, along with any additional dependencies they require. De-select any such auto-detected field bases, but leave the auto-detected dependencies selected. Save the recreated feature. Features will have added to your info file one or more lines like the following:
    features_exclude[field_base][body] = body
    This line tells Features not to automatically detect this component when subsequently rebuilding the feature.

Project Information

Downloads