This is a big one. There are numerous little refinements to make the API simpler to work with but I will note only the major changes.

Plug-ins

Plug-ins can no longer be activated directly from the theme administration form. If a feature is provided by a plug-in, then a feature toggle in the form will be made available. Enabling the toggle will enable the host plug-in. I think this is important because previously, it focused on the underlying organization of the code. Why should the site administrator know what a plug-in is and the particular features it provides? They shouldn't be concerned about plug-ins at all. It's the features that are important and the feature toggles are a lot more direct. There's also no need to describe what a plug-in does. The check box titles should get straight to the point.

To provide a feature:

; 'foo' is the feature key and 'Toggle Foo' is the checkbox label.
feature set[foo] = Toggle Foo

To check if the feature is enabled, use the hex_settings() function.


// If a plug-in provides the feature, it must be in this form:
//   'plugin_key.toggle_feature_key'.
if (hex_settings('plugin_key.toggle_foo')) {
  // do stuff..
}

// If a theme provides the feature,  it must take this form:
//   'toggle_feature_key'.
if (hex_settings('toggle_foo')) {
  // do stuff..
}

The reason for prefixing the plug-in key for features provided by plug-ins can be read in the Settings API section.

Plug-ins can provide it multiple features. Themes themselves can do the same. They all add to the pool of features which will eventually overwhelm the theme administration form. To limit this, the feature set can be limited by defining specific features through the .info file 'features' key. This follows core behavior. When 'features' is not defined, all features will be supported. Defining a subset of the available features will limit it to that subset. You can also set a specific order for the feature toggles in the theme administration form by defining it in the order you want it to appear.

Enabling a plug-in through the themes .info file works like before. Plug-ins should be enabled this way when it provides underlying functionality that the theme depends on. I'm sorry about changing this again but the previous 'theme.plugins' .info key is now 'hex plugins'. It's still alpha and I wanted to change this now after thinking about which way is more consistent.

Another way that plug-ins can be enabled is when certain conditions are met. This existed previously for plug-ins that declared itself a "compatibility" plug-in type. It would check for the existence of specific modules and turn itself on. There is no longer a notion of plug-in types. To get this same behavior, you have to set a new 'auto enable' info key to true and set at least one 'requirements'. It is no longer limited to modules. It can now contain modules, libraries and themes.

Plug-in example.pinfo


; Auto enable flag.
auto enable = true

; The requirements key can contain modules, libraries and themes.
; When Views module is enabled and jQuery lib exists, enable...
requirements[] = views
requirements[] = jquery

; …as long as the requirements in the dependencies are also met.
; This key is reserved for plug-ins only.
dependencies[] = foo

If the plug-in depends on another plug-in and that also contains requirements, then it will only auto enable itself when all requirements are met for the plug-in and its dependencies. It doesn't matter how many levels of dependencies there are. It should "just work".

Plug-in foo.pinfo


; Views UI module must be enabled.
requirements[] = views_ui

File override API moved into "Plex Files API" plug-in.

The base Hexagon theme had no direct use of the file path overriding API's so it's been moved into a plug-in. At the moment, Smarter Theme plug-in (now called "Plex Theme Registry") uses it and has it set as a dependency.

From this point forward, all plug-ins hosted in Hexagon will be prefixed with "plex" (plug-in + hex). This makes it clear at a glance that it's part of the base theme and available to all themes. Plug-ins hosted in other themes do not have to prefix their names with anything. This is just a convention for Hexagon base.

Debugging features moved into "Plex Debugger" plug-in.

The debugging features has been moved into a plug-in. There's some hard coding in hex base with debugging code but it's minimal. You can enable it with the "hex plugins" .info key. Example: 'hex plugins[] = plex_debugger'

Settings API

Plug-ins and themes can define default settings. Previously, it was only themes that could do this. When a setting is specific to a plug-in, accessing the setting must be prefixed with the name of the plug-in. This makes it clear on what the setting is for.

default theme setting from the themes .info file.

settings[foo] = true

default plugin setting set from the plug-ins .pinfo file.

settings[foo] = false

The above have the same settings applied but accessing them is different.

print var_dump(hex_setting('foo'));
// will output TRUE

print var_dump(hex_setting('plugin_key.foo'));
// will output FALSE

Caching API

Some major changes here and it won't matter for most theme devs but there's tons more control in how caches are handled. You can look at the docs for hex_cache_handler(). There are also extra functions to better understand the state of the caching process. See hex_cache_busy(), hex_cache_clear() and hex_cache_was_cleared().

When in development mode, you can also keep an eye on the watchdog log to see the clearing status. I have logging pushed to syslog in my dev machine and it's very useful. watchdog logging is pushed to Drupal's report page by default if database logging is enabled so it can be seen there as well.

Unified API access to themes, modules, libraries and plug-ins…

…In other words, there's a common way to get access to info data, paths, etc… For example, hex_info('name', 'hex') will retrieve the human readable name for the theme 'hex'. You can also do that for plug-ins through the same function. hex_info() will redirect the call to hex_theme_info() and hex_plugin_info() respectively.

Here's a list of unified functions:

hex_info()
Applies to themes, plug-ins, modules and libraries. Libraries do not technically use a info file since they are hosted in modules but they do contain meta data and it's availability here is made for consistency.
hex_path($name)
Get path to a given theme, plug-in, or module. Libraries do not hold path information.
hex_exists($name)
Check for the availability of a given theme, plug-in, module or library.
hex_type($name)
Get the type of a component. Applies to themes, plug-ins, modules and libraries.
hex_list($type)
Pass in a $type of 'theme', 'plugin', 'module' or 'library' to return a full list of available components.

For everything to function correctly, all the components must have a unique name.