Setup And Example Use Of Apps Module In The AppServer Environment


Apps is a module that can be looked at as a subsequent step in the evolution of features. It appears friendlier and more acceptable as a tool you can use for adding new capacities to the site. One can fulfill such additions without any damage to usability and, as it is, Apps module as an everyday tool is bound to be intelligible both for a power Drupal developer and a standard user. It's definitely easy and fun: with use of this module (Install app) your clients will from now on, be able to ship the new functional just with one klick.
Apps is likely to remind a standard user of chrome web store whereof one can select the required CommerceBox-related "add-on" (its standard version). Note that apps is made up of two parts - the server side and the client side. The client side displays the list of all applications that can be installed and additionally informs a user of the newest updates. The server side is provided by the appServer module. It is into getting the json object that contains data on every app (names, ratings, versions etc.) of the client side. Let us investigate the above in detail.

Server Side Set Up

As discussed, appServer module is in charge of the server side and with it you can get the apps adjusted via UI. It also creates a Server Type taxonomy dictionary as well as two content types, App Release and App. Below, we are going to give you an idea of what they are for.

The server in the Server Type dictionary of taxonomy having been installed there can be created a term which will be accepted for a kind of a server to be indicated on the client side.

The app proper is formed with use of the App Release like node, and it is set up through filling in the fields, such like Name (required), Changelog, Logo, Screenshot, Manifest, Server type. While the fields Name (required), Changelog, Logo, Screenshot are quite explicit and save explanations, the most important events happen in Manifest. To have it compiled we suggest you may look through the OAS (Open App Standarts).

To be going on with we have to penetrate into the mechanics of apps creation: besides the modules to be downloaded and installed (known as Dependencies in the manifest), we have to also indicate the custom module (known as downloadable and machine_name in the manifest), which will enlist all Dependencies designated in the manifest. In fact, this is the only one module to become activated and when installing the app on the client site, yet inasmuch as it contains dependencies on other modules, the rest of the modules will get activated automatically.

Let us have a try of the following example to analyze the manifect:

name = Test content
description = Creates test content
machine_name = app_test_content
version = 1.0
downloadable = app_test_content 1.0
author = internetdevels
author_url =
dependencies[test_content] = test_content 7.0
downloadables[test_content 7.0] =
downloadables[app_test_content 1.0] =
libraries[test_libery] = test_libery 7.0
downloadables[app_test_content 1.0] =  


name: our app's name;
description: app's description;
machine_name: our custom module machine name (downloadable). The module foulder will be searched up by this name as well as .module file;
version: the app's version number, which will be displayed on the "Details" page;
downloadable: the key in the module array that is in charge for the correct download of the module described in the machine_name;
author: app's author name;
author_url: reference to the author page;
dependencies[key]: the downloadable modules data array, key - module's machine name, the value being the key to the downloadable array;
libraries[key]: downloadable libraries data array, key — the library name, the value being the key to the downloadable array;
downloadables[key]: the downloadable elements array, key - the key defined in the dependencies, libraries, downloadable, the value being a link to the downloadable archive.

It's worth noting that, like in the instance of 7.x-1.0-beta7 version of the module, when writing out dependencies[test_content] = test_content 7.0 in the manifest you come to omit putting in the gap between the name and the version, that will through up an error message due to failing of the module search; once a space has been put in place, though, it gets the whole thing going.

As it is, we have completed the server adjustment. You may have noticed that there is another content type created by the above module - App - which takes care of the banner wherein the recommended app will be displayed. We have particularly focused on the Machine Name field in it. Here we state the machine name which we indicated in the manifest, and there in the releases field the node's name should be indicated, the one which was created in the App Release. The app that we have created will, thereafter, pop up in the taxonomy term (in the Featured App field) to be designated as the recommended one.

Well, the server is complete now. Access the /app/query/%tid page in which %tid is your taxonomy term number. If everything's done right, you are to have displayed the page containing the json array of your app and thus you can proceed to setting up the client side for further processing the above.

Setting up the client side

The client side setting comes down to writing out hook_apps_servers_info:

function test_apps_servers_info() {
  $info =  drupal_parse_info_file(drupal_get_path('module', 'test') . '/');
  return array(
    'first' => array(
      'title' => 'Test app',
      'description' => 'Let’s test app',
      'manifest' => '', // ссылка на ранее созданый вами сервер.
Once accessed the /admin/apps page, you are supposed to see the available apps, though it may as well require clearing the cache. Ok, go for it and enjoy.

The above described engine has been implemented on the basis of CommerceBox distribution package. Those who are keen on accessing the inside of the apps are free to download and install them, so as to 'put a face on a name' and get a better idea of them.

5 votes, Rating: 5

Read also


The look of the login/registration form can now be changed using administration tool. This is possible with our Customize login form module.


In this article we will speak about Drupal core installation as a submodule. We will not dwell upon the very concept of a submodule here for long, nor try to consider its dis/advantages. What we...


At times, content importing appears to be the task which is far from trivial. Writing the import assignment out "from scratch" when aimed at covering each and every instance can't be practical,...


The article describes the CMS Drupal deployment process as performed with use of Oracle DB on Debian server.


Experienced Drupal developers can hardly do without Drush (Drupal shell) utility as it speeds up a good deal...

Need a quote? Let's discuss the project

Are you looking for someone to help you with your Drupal Web Development needs? Let’s get in touch and discuss the requirements of your project. We would love to hear from you.

Join the people who have already subscribed!

Want to be aware of important and interesting things happening? We will inform you about new blog posts on Drupal development, design, QA testing and more, as well news about Drupal events.

No charge. Unsubscribe anytime