At DrupalCon Chicago there was a ton of energy around Drupal's staging and deployment problem. At his keynote, Dries identified this as one of the major initiatives for the Drupal 8 cycle, and following the keynote three Core Conversations were given on the topic by myself, David Strauss, and Howard Tyson. Those talks sparked conversations which continued through the week and generated a lot of really cool ideas. This post is intended to document the ideas that were discussed (at least the ones I heard) and to use those ideas to foster further discussion.
I personally think it is important to air and think about a lot of different ideas, even if they seem unworkable at the outset, or are too much of a reach for a core release. Shoot for the stars and adjust as needed! Lots of these ideas seem to be gaining traction but I would love to keep talking and throwing things out there.
Much of my core conversation was centered around the fact that the line between what is content and what is configuration has become so blurry that it no longer makes any sense. A couple of good examples of this are a nodequeue that has five hand-selected nodes in it, or a Panel that uses a node as context. Users don't know or care that the line is blurred here, they just want to push their site live. I did not provide a solution to this larger problem, I mostly wanted to reset the conversation from being about 'configuration management' to being about 'everything management'. I did provide three pieces of low hanging fruit we can fix to make the staging problem (in particular content staging) more manageable - make sure everything in core has a reliably unique identifier, make everything exportable, and fix up our save/load APIs so that they don't need to rely on forms or other systems in order to operate properly. If we can reliably export and save everything in Drupal, then implementations of how to deploy this data can be left to contrib. You can see my slides at http://www.slideshare.net/heyrocker/core-conv.
Howard Tyson presented his ideas for creating a Settings API for Drupal. This system is inspired by CTools in that it allows definition of settings to be exported that can be specified in module code and overridden by the database or settings.php. One of the pieces of functionality Howard has added is is 'Relations' IE dependencies. Settings can be associated with each other and other things in Drupal like modules. You can depend on modules, or you can create your own groups to bundle settings together. The Settings API also provides a log that records all settings changes and allows changes to be synched through update.php. You can see Howard's slides at http://www.slideshare.net/htyson/system-settings.
David Strauss presented his ideas for replacing our existing configuration system with on-disk storage in JSON. The main reason to use JSON is convenience over other storage formats like XML, despite the fact that they are more human-readable. This data would exist only on disk - read when a page is loaded and written when a page is saved. It would never be stored in the database at all and the files would be canonical (thus the term 'exportable' would no longer apply here). A new top-level writeable directory would be created to store these files (much like the files directory now.) One big advantage of this system is that it becomes much easier to deploy code that depends on specific settings, something that is pretty difficult to do now outside of update functions and the like. There was a lot of discussion around this idea through the week.
chx has actually already posted a patch which starts to address the storage of variables on disk that need to be used in the bootstrap process. His patch can probably seen as a starting point towards the kind of system that David described and also integrates some of the same ideas as Howard. See http://drupal.org/node/1059972.
During my presentation and in a blog post afterwards, fago proposed using entities as a foundational unified API for all Drupal objects. This would be available to provide the APIs needed by all objects. Not all APIs would necessarily need to be on all objects, but we should provide them such that any entity could opt in if they want. A centralized entity API would also be an enabler for web services, which is another one of Dries' core intiatives for Drupal 8. His blog post can be found at http://wolfgangziegler.net/Drupal-8%3A-Approaching-Content-and-Configura....
On Friday after the code sprint, myself and several other people (I think it was crell, eaton, eclipsegc, fiasco and sdboyer?) talked more about the entity ideas. Some random thoughts from that discussion.
- Entities as currently implemented are too heavy.
- It would help if entities could have properties as well as fields.
- Entities should be real classes with an interface. This would provide some the ability to provide, for instance, $entity->unique_identifier(), and depending on your use case you could provide a machine name, a uuid, or even a remote ID if you were based on remote data.
The interesting thing for me is how all these ideas collide and mesh in many places. For instance, David's canonical disk-based configuration is excellent but without UUIDs then the data within it can be corrupted and difficult to push. Something like Howard's Settings API or a more simplified base class for settings could help act as an abstraction layer. Etc. All these are great thoughts but we still lack an overarching vision which I personally think is pretty important.
Lets keep the ideas and discussions going. I'm sure there was more talk that I didn't even get to be a part of last week. Lets hear it!