Allow themes to be included in App

I think this module needs to allow for themes that are packaged in apps (modules) to be recognized by the theme system. To that end, each app should have a list of themes it provides in it's info file.

apps[themes][] = my_theme
apps[themes][] = my_other_theme

It then can use http://api.drupal.org/api/drupal/modules%21system%21system.api.php/funct... to expose those, by name, to the theme system.

While I can see the utility of setting a default theme, I don't know that it's the job of an app.

Apps should meet interoperability standards, which includes ensuring that they don't stray into site-wide configuration territory. If two different apps both set a default theme, how would the 'winner' be determined? 'theme_default' is rightly included in the Kit Feature Specification's list of restricted variables. It should be handled only in one place on a site. So, by definition, it's not the prerogative of an app.

(Admittedly, the Kit spec is dated and limited, but it's nonetheless useful and is explicitly adopted in the Open App specification.)

So, probably, this functionality belongs somewhere other than Apps.

@CoffeyMachine Now hearing how we need to deal with multiple themes in an App (last one defined gets enabled) I dont really like the idea of enabling the theme by default. What I think might be best is within the config section of an App that provides a theme(s) either allowing them to be enabled there, or notifying the user that this app provides theme(s) and a link to the appearance page to enable.

So in talking through this with nedjo on IRC, the question that keeps coming up is, why must a theme be specifically inside an app/module. Can we make it a separate theme that is another downloadable? Or if there is no accompanying module (or app) functionality can the theme itself be the main downloadable?

As it turns out, in some scenarios there is a need for a theme and a module to be very tightly coupled. In the case with CoffeyMachine, he has an theme that is largely useless without some feature overrides (provided by the Features Override module). In general themes can (and should) be separate downloadables and not bundled IN an app, but in a case like this theme/overrides, I can see the case.

This is an example of his app/theme. https://github.com/CoffeyMachine/openinternational-app

So that being the case I'm going to do a deeper review of this patch.

@CoffeyMachine: thanks for the further explanation. It's a lot clearer now what you're aiming to do.

Definitely the question of how to tweak and customize generic elements to a particular design is important.

The use case we are targeting here is when we want to have a theme that is built for a particular distro, like OpenPublic.

That's my main concern with this direction: it sounds like it would risk or even promote further compartmentalization of Apps as tied to a given distro with all of its specific, internal assumptions--about image styles and views and view modes etc. Recall here the interoperability aim in the Open App Standard:

the 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.

Tightly tying a theme to a particular module seems to push against best practices of contributed theme design. And there's probably good reasons that the API docs for hook_system_theme_info() say "Only use this hook for testing purposes". Sticking themes off within modules is a confusing hack.

So let's try to reframe the aim here in a way that's more in line with the interoperability aims of apps. Maybe: how can we effectively provide different "skins" for sets of apps?

A first question would be: how can we provide a standard set of elements to be altered? I've take a first rough crack at this question in the Apps compatible module. Needs a lot more discussion and work--but it's a start.

The second question would be: how can we best provide skins? Here features override might indeed make a lot of sense. But do we really need a highly customized theme? Could we instead do the skinning at the module/feature level? Could we do so in a way that didn't assume a particular theme or even a particular base theme?

I'm not sure. Maybe we'd hit some limitations somewhere. But if that was the approach, we'd be a lot more likely to end up with something interoperable.

Cross posted, restoring status.

@nedjo I hear what you are saying, but I think the reality is that themes will definitely be developed with certain distros in mind. Consider a tool like Open Atrium. Once it is on Drupal 7, there is no way that a theme developed for OA would be applicable for any other distro, but still even then, the theme itself should be the app not included in the module/app.

The use case we are having is rather different. Here a theme is developed for the default modules of OpenPublic, but to provide that different look & feel, we need to change contexts/views/styles, etc. The theme itself is crippled without the module. The ideal way around it is to have the theme depend on the override module, but theme's can't depend on modules (not yet even in 8) so in order to not have a theme out there in contrib space that is downloadable, yet crippled without it's companion, we should include it in the app directly. Some additional use cases are a theme specifically for a node edit form that can't implement the hooks needed to enable itself on just that page, pretty useless without the module.

Just so I'm clear, I am in 100% agreement that the *preferred* way is to have the theme as a dependency of an app and a separate downloadable, but I think we give extra flexibility by allowing it and we do have the use cases for it, so I'm going to go ahead and review and if all is working I'm going to commit the patch. As part of the commit I will add some details to the readme about the functionality and about how it is not the preferred method.

@febbraro: I totally see the use case and agree that it's a valid one.

The part I'm trying to push back on is the direction that apps are internal to a particular distro and that we should introduce new apps APIs specifically to facilitate that. As I noted in #11, the OAS is explicitly committed to avoid that outcome.

There are two things that the apps module can provide.

(a) One is a handy way to download stuff for a particular distro. That's currently the main use case, and it's been met admirably.

(b) The other is to facilitate interoperability, so that distro-based work doesn't fragment Drupal development. So far, with a few exceptions, progress on this second front is scanty.

There's an obvious potential tension between (a) and (b). What's handy and easy internally for a distro is seldom what helps interoperability. We can of course give up on (b) and go full on for (a). But at a big cost. We end up with apps that have no chance of meeting the interoperability aims we started out with.

Say I have a site connected to three app servers and want to mix and match apps from the different sources. How do I intuit that certain of those apps aren't really apps at all, in the original sense, but are instead only applicable within a given distro? That trying to enable them will inevitably break my site? (Abstracting for a moment from the fact that that's true now of almost all apps from different sources ;))

One alternative is to do what's traditionally been done. Keep distro-specific development in the distro. It's on drupal.org. It's available. But it's not an app.

Is there a midway meeting place? A way that distro-specific code can be easily shared through the app interface without giving up on interoperability? I don't know. I'd just like to look for one before committing to a direction that seems to be throwing up our hands and giving up on the idea that an app is by definition interoperable.

I opened #1751926: Proposed OAS addition: distro-specific apps. It would be great if we could get that fixed first. See also #1733376: Require a change to the Open Apps Specification for any Apps API change or addition.

It's a shame this subject has not been elaborated any further, for adding themes to apps would provide us with more opportunities as well as would expand Drupal theme system itself. Incidentally, we are considering moving our CommerceBox package over to apps. And we are keen on implementing fast switching between the themes (one package with a range of related themes or subthemes) without adding them into the profile core, so that –as we think – this would help us avoid expanding the package size and would allow creating a really flexible tool for themes' update and generating in our package. We suggest trying to make the apps functionality wider and starting to add themes to it, at last. Our main idea is to have a theme downloaded and placed via apps whilst switching it on and configuring its settings might be accessible in the main module (downloadable) environment.
For example if we add the followint to the manifest:

themes[omega] = omega 7.x-3.1
themes[ninesixty] = ninesixty 7.x-1.0
downloadables[omega 7.x-3.1] = http://ftp.drupal.org/files/projects/omega-7.x-3.1.tar.gz
downloadables[ninesixty 7.x-1.0] = http://ftp.drupal.org/files/projects/ninesixty-7.x-1.0.tar.gz

We will have a totally unpacked theme which can be switched on in the hook_enable() at the main module (downloadable):

function hook_enable() {
  $enable = array(
    'theme_default' => 'omega',
    'admin_theme' => 'ninesixty',
  );
  theme_enable($enable);
}

We'd appreciate any ideas on this subject that anyone would share.

system_rebuild_theme_data is not cached at all, so calling it each app == ouch!

Could someone update the issue body to reflect current objective of this patch?