Last updated March 6, 2015.
One of the things that makes Drupal great is the power it puts into the hands of non-developers to do awesome and amazing things on the web. A large portion of our community made a transition from non-developer to developer thanks to the accessibility/hackability of Drupal from an API perspective in Drupal 7 and below. In Drupal 8, however, things have become more... complicated. While flexibility is greatly increased, so too is the mental overhead as well as verbosity for doing even simple tasks.
This initiative is about making some key changes to the "DX" (developer experience) of Drupal in order to make it more accessible to people who need to extend Drupal to make it do cool things, but don't necessarily have a background in programming.
Reporting DX Issues
I tried porting my module to Drupal 8, and I'm concerned about D8's developer experience. How can I help fix it?
Please tell the core developers about it; we'd love for you to love Drupal 8 as much as we do!
- Search for open or all 8.x issues with the DX (Developer Experience) tag.
- If you don't find an existing issue, create an issue with the DX (Developer Experience) tag.
- Include some details like what you expected, what you tried, what happened instead, where you got stuck, what would've worked better for you, etc.
- Post a link to the D8 DX meta issue to bring it to the attention of those watching the issue.
We'll use this "user testing" data in order to formulate a plan of attack for fixing DX in D8.
- Newbies learn first and foremost by copy/paste/modify. We should continue to support the ability for folks to do this, particularly on basic tasks.
- We should make the common things easy, the less common things doable. https://gist.github.com/webchickenator/4409685 is a list of all D6 and D7 hooks, sorted by usage to help ferret these out.
- Drupal 8 at this point is not going to fundamentally change the way it does things; for example, we're not going to switch back to procedural functions for everything, we're not going to remove the plugin system.
- However, we can certainly look for ideas to abstract away complexity, tedious amounts of "boilerplate" code, and other mental hurdles, especially for the "90% cases" in contrib.
A vocabulary for discussing DX issues
DX issues tend to fall into the following buckets:
- Complexity: When we're exposing way too much "how the sausage is made" details in user-space code. Back when we had silly things like $this->translationManager()->translate($string) instead of $this->t(). As a module developer, should not need to know or care that there's a translationManager in order to simply print a translatable string.
- Verbosity: These aren't complex (in most cases they're easy to learn and/or copy/paste) but are little annoying pebbles in your shoe that grate on you every time you encounter them. Over-abundance of boilerplate code is an example of this.
- Learnability: An overwhelming number of new concepts, a lack of a mental model to tie everything together, etc. (This definition needs work.)
The (DRAFT) Hit-List
In general, any major/critical issues with the DX (Developer Experience) tag. Here are a few specifics. This list is still under heavy development while we work out a broader plan. Feel free to add your own here as well!
*: PSR-0 was defined as a way for different PHP frameworks to share code with one another. By contrast, contributed Drupal modules are Drupal-specific and not intended to be shared, and directory structures that promote code re-use are overly verbose and irrelevant for this case. The upcoming PSR-4 standard helps address this.
*: Right now, making even a simple "hello world" page requires grappling with concepts like the Dependency Injection Container. This patch introduces a base class with common dependencies already there so that module developers can just get to work creating their page callbacks.
*: Ditto for forms.
* In general, stop the leaky abstraction insanity:
*: Turns 2 PHP classes and 4 lines of YAML into 4 lines of YAML. Nice.
*: This is the most frequently-accessed resources of developers; let's make sure they can find all the things.
*: Fragmentation is a huge DX issue. There are tons of valuable resources out there, but it's really hard to find them.
*: This bites every single person who is trying out annotations for the first time (and even the 10th time). By making these arrays behave like PHP arrays, it greatly reduces the irritation associated with using them.
*: Nothing stops a 3 day bug hunt safari like a well placed assert. Adding assertions to catch what would otherwise be obscure error messages raised by bad config yml files will reduce a lot of stress.
*: Longer term (8.1.x) overhaul the error handling system to stop the phenomena of the white screen of doom once and for all and insure that something useful can be learned about any error.
*: "ControllerInterface" as a name is too generic, and implies it should be used for all page controllers, even though it's really only needed for those who want dependency injection. Rename this so it's more clear.
*: Symfony has changed from "pattern" to "path" as the name of the YAML key to define a route path. We should adopt the same so people don't get confused when reading Symfony documentation.
*: Right now, we use Drupal in modules but \Drupal in classes. This consistently screws up everyone and makes patch reviews harder. See broader discussion at .
Somewhere in-between / not evaluated yet
*: Type-hinting with interfaces rather than classes provides for more flexibility in contrib, but EntityInterface is too generic. Introduce entity-specific interfaces to help with this, as well as give developers an easy reference to see what properties/methods $node has.
*: Reduce the number of classes needed to define a new plugin type.
*: We switched to OO code in most places, but aren't making any use of one of the fundamental concepts of OO code. This is silly.
* There are a series of issues around simplifying plugin discovery to make it more approachable:
*: @Plugin is too generic, and there are no docs for what e.g. an Block plugin needs vs. a Views plugin. By introducing plugin type-specific annotations, this can be resolved.
*and : Be sure all these new DXs have high-quality code to copy and paste.
*and : Allow module developers to use PHPUnit so they can write high-quality code.
*: Don't require silly use statments on plugins
* : Makes things more consistent
* : Don't know exactly how yet, but we need to make this easier to do.
* : Boilerplate--;
* : Same :)