Over the years of Drupal 8 development we've heard a lot of talk about "Panels in core" or "Blocks everywhere" or "Layout all the things!" and even SCOTCH(?). What does it all mean? Is Panels actually in core? Well, no, but there are some cool improvements in Drupal 8. I decided to follow the breadcrumb trail to figure out what this initiative was really about and how it ended up, now that Drupal 8 is in beta. Join me for a little bit of a trip back through the life of the Blocks and Layouts Everywhere (SCOTCH) Initiative.
In March 2012 Dries announced a new Drupal 8 initiative, called the Layout initiative. A team of core people had taken a look at the Web Services and Context Core initiative (WSCCI, or Whiskey) and decided to narrow the scope of that project to make it more attainable. Part of what was descoped in WSCCI became the new Layout initiative. Since Layout was a subsection of the larger WSCCI (Whiskey) initiative, it got the nickname SCOTCH—scotch being a sub-category of whiskey.
When the initiative was announced the project lead, Kris Vanderwater, wrote up a post about all the work they were shouldering. The core idea is to "provide a standardized mechanism of output, and new tools for placing content on a page." It is addressing the underlying problem that contributed tools like Panels, Context, and Display Suite have been trying to solve in various ways. The idea is to take the best ideas from those solutions and create a unified, core way of handling it. You can see the basic roadmap and some of the progress in the Blocks/Layouts Everywhere Meta issue.
The end goal basically boils down to two main pieces: turn all page output into blocks (using the new plugin system), and add a new layout system that will allow site builders to control their pages. Pretty awesome, huh? Also, a lot of work.
The first step on the path was to get the new core plugin system settled in, so the new, fancy blocks could make use of it. You can read all the details about plugins in a few articles Joe has written on the topic (Drupal 8 Plugins Explained and Unravelling the Drupal 8 Plugin System).
In addition to the base plugin system, there was a push to make sure plugins could be contextually aware. The idea was to make the new blocks smarter than in Drupal 7, so that we could solve the flexibility problems inherent in the old system. In order to decouple the code that figures out where, and under what circumstances, a block is supposed to show up, new conditional and contextual plugin systems were added to Drupal 8. Both of these systems were largely driven by blocks needing these features, but these new plugin systems can be used anywhere in Drupal now.
With plugins in core, the next step was to get all of the existing Drupal blocks switched over to the new system. Using the plugin system turned the old, pokey core blocks into flexible super-blocks. This allows us to to do cool things like have multiple instances of a block. This was a huge amount of work by a lot of people. It took about a year to get the "blocks as plugins" foundation in place.
With the architectural foundation set, to achieve the fully flexible page components goal, a number of tickets were created to start converting other elements into blocks—things like the site title and logo, menus, and page elements such as title, tabs, messages, etc. The site and menu work was completed in 2014, and the page elements are still a work in progress. Then there are the forms and various page callbacks to tackle. We have a lot of "hard-coded" page elements in Drupal 7, and tracking them all down and turning them into blocks is a long process.
Getting our page elements into a flexible and robust block system was the first major goal of this initiative. The second phase was to get a new layout system in place that would give site builders better control over these blocks. The bulk of this work involved decoupling layouts from themes (that is, in code) and creating a system that could be managed through the UI instead. For the first step, a new module, Layout, was created for Drupal core, which required themes to declare their layouts in this new way. This got committed to core on October 15, 2012 and a new meta issue, [meta] Unified Blocks and Layouts (SCOTCH+WSCCI+Spark+Field UI), was opened to track the next steps needed to accomplish the ultimate goal, and to bring together all of the pieces and projects working in the blocks and layouts space.
Work continued to barrel ahead with both the blocks and layouts work. In 2013 the reality of the Drupal development cycle began to assert itself though. The feature completion phase ended on February 18, 2013, meaning no more big features going in. We needed to move Drupal 8 into the clean-up phase to start nailing down the APIs and rein in the scope. July 1 was set as the API freeze date, where this clean-up phase would end.
As July approached there was a lot of chatter about the state of the Layouts portion of the SCOTCH initiative. The big discussion point revolved around the fact that the new Layout module wasn't actually being used anywhere in core yet, and the API freeze was approaching fast. There simply wasn't time to get the implementation in place, and the UI work for layouts was still a long row to hoe. An issue was opened to remove Layout from core. On August 31, 2013 the Layout module commit was reverted, removing it from core. It made little sense to ship Drupal 8 with unused code.
We may not have layouts, but we do have a much improved block system in Drupal 8, and many more elements that are in blocks, making them easier to work with. We also have some pretty kicking underlying context and conditions APIs. To see more of what we do have coming in Drupal 8 from this work, check out Kyle's article and video The Block System is Finally Useful in Drupal 8, and Joe's article and video A Look Inside Drupal 8's Block Plugin API.
The Layout module wasn't discarded when it was removed from core. You can find it and use it in itscontributed project form for D7 and D8. (The 7.x version is part of the Spark distribution, the 8.x version is what was in core and removed.) You can bet that people are still working very hard on this concept in the core issue queues. We've moved the issues to target Drupal 9, and the work will keep on chugging away.
The fact that we didn't end up with a new layout system in core may seem like a failure to some, but honestly the scope of these changes was incredibly massive. The amount of work that has gotten in, and the improvements we will see in Drupal 8 are HUGE. I, for one, am incredibly thankful for the work that has been poured into this project, and I have a lot of excitement for what we'll see in Drupal 8. If you'd like to keep up to speed on what is going on with this work, you should check out the Blocks and Layouts Everywhere (SCOTCH) Initiative groups page.
Drupal Developer having 9+ year experience, implementation and having strong knowledge of technical specifications, workflow development. Ability to perform effectively and efficiently in team and individually. Always enthusiastic and interseted to study new technologies
One of iOS 5′s marquee features is the ability to backup and restore devices from iCloud without the need for iTunes or any of those pesky wires.
The name salsa sounds fun, warm an inviting, and yes, it is true of the HTC Salsa. The first thing that caught my eye was the build quality.
So you are interested in Drupal 8, right? I know I am, but with all these fundamental changes, many developers out there (including myself) need to do some serious work adapting their skillset to be able to work with it.
