The Blocks and Layouts Initaitve has come a long way since its initial inception, and there are a lot of people working in this space. We had a phone call together which is documented at https://docs.google.com/a/acquia.com/document/d/1sCAnSD6o7Q5sXo3H_cCRTyP.... Here's an updated roadmap that covers what each team is working on.
There are essentially five "prongs" of this initaitive, all working in parallel:
- Underlying APIs: Take a request, turn it into a page with a layout and blocks.
- Blocks Everywhere: Create the concept of "smart" blocks that are contextual, and ensure everything output on the page is a block.
- Blocks/Layouts UI: UI for creating landing pages, assigning layouts to them, and placing blocks into layouts.
- Spark Responsive Layout Builder: Dynamic layout creation using dynamic breakpoints, grids, and regions.
- Improved Field UI: Leverage layouts and regions in field UI to make a more streamlined experience.
Here's what's entailed for each, and places where you can jump in to help!
Blockers for everything else
We need these two issues dealt with before we can move forward on the various sub-initiatives.
- Displays: #1817044: Implement Display, a type of config for use by layouts, et. all These are effectively the "contract" by which all of the sub-Layouts initiaitves will communicate what a layout entails. We need to establish this before we go off jaunting off in other directions.
- Sample layouts: #1814520: Create 2 basic sample layouts: 1-col and 2-col Need something concrete to play with in the other patches.
None of these are specifically blocked on anything else unless they're so noted.
Fundamental Underlying APIs (EclipseGc + sdboyer)
These are what's required to take a request and serve it up as an HTML page, which in D8 means a display (layout instance) containing multiple block instances.
- Displays: #1817044: Implement Display, a type of config for use by layouts, et. all Defines what a layout entails.
- Roles: #1816968: Introduce region 'types' to layout spec Groups regions so that they can be used across layouts.
- Controllers: #1812720: Implement the new panels-ish controller [it's a good purple]: Renders out results of a display.
Blocks Everywhere (EclipseGc, naxoc, ???)
- Blocks as Plugins: #1535868: Change notice: Convert all blocks into plugins This is necessary plumbing for multi-instance, configurable blocks. Blocked by #1728816: Ensure multiple entity forms can be embedded into one form.
- Conditions: #1743686: Condition Plugin System Abstracts out block visibility to a general condition API that can be used for more than just page or role visibility. Blocked by #1535868: Change notice: Convert all blocks into plugins
- Convert ALL THE THINGS (site name, logo, etc.) to blocks (post-feature freeze)
- Block caching (post-feature freeze)
- Block context injection (post-feature freeze): Hoping to leverage Entity Property API here.
Landing page / block assignment UI (Gábor, Bojhan)
- Landing page creation: #1787942: Allow assigning layouts to pages Allows assigning layouts to pages, which is the only way to actually see a layout do anything.
- Assigning blocks to regions: #1787956: Make blocks relate to layout instances instead of themes Now that we have layouts and regions, let's add blocks to them. Most likely blocked by #1535868: Change notice: Convert all blocks into plugins.
Spark responsive layout builder (Gábor)
Meta issue: #1813898: [META] Add editable responsive layouts to Drupal core
Northstar designs: https://projects.invisionapp.com/share/7M73WEBZ
- Dynamic regions: #1813910: Add region module to Drupal core (for editable responsive layouts)
- Grid builder: #1816650: Add swappable (dynamic) grid systems to core
- Repsonsive layout builder: #1741492: Add a responsive layout designer to Drupal core
- Mobile preview bar: #1741498: Add a mobile preview bar to Drupal core
Improved Field UI (Swentel, Stalski, zuuperman)
Meta issue: #1770720: [META] Gradual changes to Field UI
- #1786198: Make consistent regions in code for fields UI overview screens : Add region concept to field ui.
- #367498: Introduce 'display' as a way to group and reuse instance and formatter settings.
- Potentially use of modal for configuring formatter settings - see #1667742: Add abstracted dialog to core (resolves accessibility bug)
- Use temp store - over at #1642062: Add TempStore for persistent, limited-term storage of non-cache data - so we can kill #857312: Add a "changes not applied until saved" warning when changing formatter settings
- #552604: Adding new fields leads to a confusing "Field settings" form
|request-handling-steps.png||197.83 KB||Ignored: Check issue status.||None||None|
|blocks-everywhere.jpeg||42.74 KB||Ignored: Check issue status.||None||None|
|page-prototype.png||58.8 KB||Ignored: Check issue status.||None||None|
|responsive-layout.png||89.55 KB||Ignored: Check issue status.||None||None|