Framework, Platform, Application, Features, Product, Workload
This is an attempt to summarize some recent discussion about Drupal 8 direction and development, it is heavily biased towards my own opinions and is not intended to be either neutral or comprehensive. There is still plenty to discuss around all of this, while there has also been a significant move towards a consensus on some areas as well.
First, framework vs. product is a false dichotomy. Drupal core is both a crap framework, and a crap product, either of them on their own would have died a very quick and lonely death some time ago.
This has described this as the platypus problem. While it’s a problem, it’s also a strength. Let’s replace ‘platypus’ with ‘human’:
- can’t run fast
- can’t jump high
- looks naked without any clothes on
- wastes resources
- opposable thumbs
- self conscious
- good at adapting to environments and altering those environments to suit its needs.
Sounds like Drupal right?
Various Drupal ‘competitors’ might be described as cheetahs, peacocks, blue whales, ants - they are generally more single purpose, monolithic, lower level, and/or prettier - whether more numerous or less.
If core is neither framework nor product now, what is it? And how might it look in 2-3 years?
As well as a platypus, Drupal is often described as a framlication, for me this has always been it’s core strength as well as a cause for confusion and difficult choices.
It contains a mixture of APIs and features at all levels. Currently these are all mixed together, often with bizarre and unexpected dependencies (mostly on system.module), but in general they provide a good basis from which to build other stuff.
Here’s a table that attempts to conceptually differentiate how things break down in terms of core feature sets, how this relates to specific components, and some desired outcomes for what things might look like in Drupal 8.
|Level||Description||APIs and dependencies||Implementation/features|
|Framework||Very low level functionality, usually included in most PHP 5.3 frameworks. Minimal interdependencies within this layer, or very clearly defined.
This is used to build platform functionality.
|Database layer, error handling, configuration system, session, cache, queue, lock, module/hook system, theme system, form handling, logging, router.
These should have no dependencies except possibly on other internal APIs.
It should be possible to add and remove APIs at this level via contrib.
At the moment this includes both /includes and modules. It might do in Drupal 8 too.
| MySQL, PostgreSQL support. Memcache, Redis
These usually have external dependencies which may or may not be available on different environments.
It should be easy to add and remove implementations at this level via contrib.
Stuff at this level could potentially be used outside Drupal. Or by drush.
(this is still a framework for any definition other than ‘micro-framework’).
Low level functionality that provides elements used in web siteunctionality that provides elements used in web sites or other web applications.
These are used to build application and product level functionality.
Users, entities, fields, vertical tabs, views, panels, blocks, ajax, states, actions, tokens, voting API.
Can freely depend on framework level components, but should have minimal or clearly defined dependencies on each other.
Should be easy to add, remove and replace APIs at this level from contrib.
nodes, comments, file and image uploads, path aliases, menu, taxonomy, relation, stark, blocks again, rules, views, services.
It should be trivial to add and remove implementations at this level via contrib.
Some implementations in turn expose APIs.
(this is still a platform, for any definition other than ‘framework’).
Higher level functionality that allows platform and framework functionality to be combined together and used as a coherent platform.
It is built using the framework and platform.
Core site building experience / site construction kit
APIs start to thin out at this level, except for ones inherited from the platform or framework level.
Can freely depend on framework and platform level components, but should have minimal or clearly defined dependencies on each other.
/admin, module and theme management, status report, web installer, log viewer, update status, toolbar, overlay, Seven, contextual links, field UI, Views UI.
It should be easy to add and remove implementations at this level. via contrib.
|Features (not features module as such)||High level functionality that is tailored to particular use cases.|| Mainly dependencies and configuration, bits of glue code.
Shared and re-used on multiple levels, may also depend on others.
|Polls, forums, Bartik, image gallery, shopping cart, workbench.|
Packaged functionality designed to meet specific use cases.
It is built on all the previous levels.
It’s OK to have lots of sideways dependencies here, these will mostly be created via setup and configuration though.
Some of these are just conveniently collected sets of modules, some also give you a head start setting those modules up.
Setup happens here, but not runtime code.
Standard profile, Drupress Blogging profile, Drupal Commons, Commerce
Download, install, fully-fledged ready to rumble products. (Compare with Wordpress.)
To get to this point there are several major pieces of work that need to be done:
- Improve the low level framework via refactoring or replacing APIs.
- Improve the platform and application layers
- move APIs downwards into the lower level framework and platform for shared dependencies
- bring platform/application-level features that are buried in /includes and system module up to the level they belong.
- Fix long standing bugs, architectural and usability issues here.
- This is a lot of work and is going to require touching tens if not hundreds of thousands of lines of code. To make some space for this to happen,make that easier, we need to move some legacy features (at any of the four levels, but starting with ‘product’) that add more maintenance burden than they’re worth out of core. Either explicitly state that we’re deprecating some old features, or find maintainers for them. If we can’t do either, work on outreach to fix that and refactor them to bring them up to date.
- Ensure that new features that are added (at all levels) match the longer term goals and make things easier rather than harder, and that people will continue to maintain them after the initial work to get them in.
- This is a lot of work (so much I’m saying it twice), and we will also be maintaining Drupal 7 for at least four years. Nurture and develop ‘short tail’ contributors via office hours and MAINTAINERS.txt both to help with Drupal 8 development and continue maintenance of Drupal 7.
- Define the product or products that is/are essential for Drupal to provide on the day that 8.0 ships (is it only a site building platform, do we need use-case specific examples, how are these presented?). This is the territory of the snowman project. This may result in new features being added at the platform and application levels, as well as potentially removing some too. (I am completely ignoring the packaging issue here, deliberately - if it holds up an 8.0 release, simply moving things around doesn’t make anything move faster, there’s a lot of other stuff that needs to be done regardless of that, and changing packaging could make things worse, especially while all our code is interdependent).