In early February a gathering of developers came together in Acquia’s offices to decide the fate of the Drupal 8 initiative known as WSCCI (Web Services and Core Context Initiative). This event has been blogged about a handful of times already by Dries Buytaert, Larry “Crell" Garfield and Daniel “sun" Kudwien so I won’t rehash what has already had a lot of robust and detailed coverage. One of the conclusions from the sprint was that an entire class of problems that WSCCI was trying to solve—mainly around improving Drupal core’s layout and block system—was a large enough problem that it really deserved attention as its own proper, separate initiative.
Why a new initiative?
While rescoping WSCCI, it became obvious that there were three separate scopes into which WSCCI was creeping.
- Web Services
- “Frameworkification" of Drupal core
- Page Layout
Page layout, and the various foundational work required to get there, are all well within the scope of what Drupal 8 would like to deliver. But this can’t all fall under WSCCI, and as such, a new initiative was decided upon, and I was asked to lead it.
Ok, so... what is this new initiative then?
This initiative aims to bring unity to a system of disjointed output components (blocks, page callbacks, menus, theme settings, and more) and provide a standardized mechanism of output, new tools for placing content on a page, and a potential for performance gains amongst other benefits. Blocks as they currently exist have out-lived their usefulness as a basic Drupal component. Placement of blocks is a common shortcoming of the core system, as is the use of multiple instances of a single block, which is impossible without contributed modules. A number of other very popular solutions have been around for a while (e.g. Context, Panels, Display Suite) that change the notion of how blocks work, and what can be done with them. The goal of this initiative then is to build a best of breed solution leveraging the tools and experience developed in Drupal Contrib.
Currently, Drupal doesn’t treat all content equally, and there are so many different types of things on screen at the same time (page callback output, blocks, theme settings, etc.) that it can be daunting to keep up. Instead of building pages via a page callback as “primary" content, and then blocks and other bits of “secondary" decorating the page, the goal is to make any output on the page anywhere a block. Not a “block" as traditionally thought of in the limited Block module in Drupal 7 and below, but a “smart block" that is context-aware and utilizes per-instance block configuration. Additionally, instead of regions being theme-specific, the capability to add regions would move to the hands of the site builder. A palette of layout options will be offered to select from (3-column, grid, etc.), including the ability to nest layouts within layouts, and layouts could factor in contextual data (e.g. a different layout for articles vs. page nodes).
How do we get there?
First and foremost, I need your help! :) A lot of thought has gone into the steps involved in doing this long before the WSCCI sprint in Boston; being offered this position has encouraged me to really focus and prioritize that list of things into what I hope are deliverables that are practical for Drupal as a whole, and can stand alone should the next phase of development not land in time for our Dec 1st feature freeze. What follows is an outline of sorts, first detailing the systems we need in core in order to even consider this initiative achievable, and second the work involved in delivering on this initiative.
Step 0: Dependencies outside of this initiative:
- Contribution to WSCCI’s foundational work with Request/Routing/Response.
- We’re going to leverage Symfony’s Request, Routing and Response systems from the WSCCI initiative. Since HTML is just one type of REST response, once this is enabled, we will take over the HTML response system and build a new set of tools for delivering Drupal’s content. We are essentially the text/html web service response of web services. Step one is getting Symfony’s Request object in core.
- Configuration Management Initiative.
- The new block system we are architecting depends heavily on custom configuration management objects per block instances, and without CMI, we will be completely crippled. We need to get this framework reviewed and committed to core as soon as possible. UPDATE: Committed 3/2/12
- Finalization of the Plugin subsystem.
- The Plugin system is a unified way of dealing with various “pluggable" elements within Drupal: for example, blocks, swappable subsystems (e.g. cache layer), and text formats, etc.
- The plugin system has been modeled after CTools but with an OO approach. CTools’ solution for this was always very OO inspired (even supporting OO plugins). The system is very robust, providing generic factory solutions for multiple use cases with the ability to extend as necessary, and a wrapper system for calling plugins of various type easily.
- As soon as the initiative’s repo is setup and ready to go plugin development will continue in a branch specifically for plugins. Until that time you can get a sneak peak in my repo that I’ve been using as a git submodule.
Blocks Everywhere Phases:
- Create a standard interface and class specification (plugin) that works to satisfy existing needs of blocks.
- Includes meta data about the block, configuration forms, validation, submission, rendering and a few other things like contextual awareness.
- Migrate existing blocks to the new structure.
- Includes a lot of work in the blocks administration system.
- First real check point for the whole system. Until this much is done the system is not a complete enough product to do anything.
- Move page elements (title, logo, primary links, etc) to the block system.
- There’s already issues in the core queue for some of this, such as Convert primary and secondary menus to blocks. We need to decide which of these could most benefit from being worked on now, with core’s current block system, and then refactor to the new block system later, and which ones to wait on until the new block system is in place.
- Integrate forms with the new block system.
- Many current “page callbacks" in Drupal are drupal_get_form() with a particular $form_id passed as a “page argument". How do we best integrate all these forms into the new block system? Should we convert each form into a block plugin class, or create a single “Form" block plugin class that can take a form id as a configuration or context argument, or something else? We’ll need to do some experimentation, and this will be subjected to lots of code review and iterating based on feedback.
- Similarly, the Symfony approach relies on reflection of variable names to do a lot of its magic, and drupal_get_form() totally breaks this with its typical use case.
- We’ll need to consider how best to make form redirects and dynamic content configurable. We’ll also need to integrate form POST handling with the WSCCI initiative (which plans to implement separate routing for POST vs. GET requests). While implementation details are still unclear at this time, the end goal is to enable our administrative tools to become plastic and re-arrangeable in such a way as to allow install profiles and distributions to provide a more custom tailored administrative experience.
- Integrate non-form “page callbacks" with the new block system.
- Some page callbacks, like node_page_default() (the list of node teasers shown on the front page in a default Drupal installation), will need to be made into first class block types, complete with their own unique configuration options (e.g., how many teasers to display).
- For the rest, there’s an open question on whether to make all of them first class block types, or leave them similar to the functions they are now, but passed the contextual information they need to ensure their dynamic content isn’t tightly coupled to their default URL, so that custom sites and distributions can rearrange their URLs and page placement just like with any other block. I am currently biased towards the former, but the pros and cons of each of these with respect to API consistency, impact on page configuration UX, and impact on core and contrib developers still needs to be discussed in more detail.
- New layout system
- In order to deliver a layout administration tool many helping hands will be required during the previous 4 phases so that this phase, and those following it can progress as close to simultaneously as possible.
- Layouts are a bit of a new concept for core and what will be done here is breaking the dependency between a “theme" and it’s “page.tpl". Page.tpls will largely go away in favor of reusable layout components that can be controlled and populated through the administrative interface.
- Layouts are a lightweight plugin type intended to be easy to create for “designers". They will contain their own js, css, administrative css (if necessary), some sort of image representation of what they look like, a configuration xml definition (for the CMI config system) and a tpl file with their appropriate output. The objective is to remove the need for site builders to need to be building their own HTML, and to make building custom HTML for designers insanely simple.
- Layouts are intended to be nestable and reusable, not only in the sense that you could have multiple of the same layout on a page together with different content, but also in the sense that a pre-configured layout (for example: a header or footer) could be easily reused and nested into a container layout.
- Logically a library of layouts will develop here and things like grid or responsive layout plugins could exist hopefully lowering the barrier to entry on getting sites that depend on these systems up and running more easily. A strong starter library in core would be a big win.
- Mentioned previously a theme becomes completely disconnected from a layout, so changing the theme is really about individual elements a theme may care about, and the css intended to exist for given layouts.
- As core (and other modules) begin providing various layouts, it seems natural that themes would begin to supply css that corresponds to the most popular layout plugins, and/or supply their own layout plugins. Logically layout packages begin to take the place of “base themes".
- In order to setup all of this work with layouts, a new administrative system will need to come into being that allows for default layouts for a site to be defined, and then some sort of variation on layouts based on url and other potential criteria.
Conclusion
In short, we have a ton to do and I will need as much help as I can get from people familiar with the concepts I’m discussing here or those who are willing to learn and help convert the existing system. My employer, Commerce Guys has agreed to donate 20% of my time to this initiative, which is insanely generous and I am lucky to be in a position to help push this initiative forward. If you’re interested in getting involved this effort we will probably work in #drupal-wscci on freenode. I’m EclipseGc on IRC, drupal.org and twitter. I look forward to engaging the community in this initiative. I think we have the opportunity to do something really special here.
Anonymous (not verified)
This is a totally huge and worthwhile leap for Drupal to be making, it's not only a missing piece of the current puzzle, but a factor that will propel D8 ahead of other frameworks.
I've thought over this a lot (not with as much clarity!) and I would stress the need for layout system to be as accommodating as possible for designers/themers. Even though layout can (should) be handled within a UI, the demands of those trying to use it shouldn't be limited in ways they are currently. ie. style what Drupal provides vs provide sensible defaults.
This is a great step towards not being able to identify a Drupal site at all, which is 100% amazing. I guess the right place to put forward ideas/comments should be the http://groups.drupal.org/drupal-8-blocks-layouts-everywhere-initiative right?
Kris Vanderwater
Yeah, that's the right GDO group.
I'm actually very confident that I can provide designers with a really robust and awesome solution. The group that is going to take a lot of time and effort to serve properly is actually site builders, and so we'll need as many helping hands as possible in this regard.
Anonymous (not verified)
Is that something like magentocommerce layout system ? oh my goodness. It's the worst I ever heard in D8. It's totally not create for "designers". It's for programmers. Hope that not as worse as I think.
Kris Vanderwater
If you've looked at CMI you'll note this isn't anything to be worried about. The xml is not for the layout, it's just a very lean file designed to save information about the layout. Think of it as really shallow xml based key value pairings. Something like:
<label>2 column stacked</label>
<tpl>two-column-stacked.tpl.php</tpl>
<css>css/two-column-stacked.css</css>
<admin_css>css/two-column-stacked-admin.css</admin_css>
<js>js/two-column-stacked.js</js>
<icon>two-column-stacked.gif</icon>
Really should be super easy copy/paste sort of stuff where you just change the values for yours. Nothing that designers (or anyone really) should fear. BTW the above example is probably about the most complicated one of these xml files will get. Hopefully that allays fears. This is purely a utilization of the new CMI layer as some amount of discovery, and that discovery aspect may in fact change in the implementation.
Anonymous (not verified)
I don't understand why Context and Boxes (plus Spaces and Features) are not being considered as an alternative. They work well, don't they?
Kris Vanderwater
This is a comment that will, no doubt, come up a few more times, so let me treat this with the seriousness it deserves.
Features
Features is great, but 99% of what makes features features is the exportable nature of the system. The Configuration Management Initiative is really much much closer to features than any other consideration in core.
Spaces
This is really not something that even enters into the conversation. Spaces & Purl are kind of tied together here, and very few others solutions exist other than Organic Groups & User based spaces. This is not really a core consideration, and even if it were, I suspect that the Symfony Request object would simplify those systems.
Context & Boxes
Great solutions no doubt, but Context module really tried to be nice to Drupal core's block system, and what we need is more than just exportable placement and visibility of existing blocks. Core's block system is very incapable for many situations, this is why systems like Panels exist, and it's why we're focussing more on that solution. It's not that context module isn't a great solution for what it does, it's that Context module attempts to fix problems we shouldn't even have with this solution, so they're different enough that we needed to focus on the solution we wanted instead of putting bandaids on our old solution, and that's essentially what Context module is, a bandaid. I give this overview as someone who has extensively used both system. I've done quite a bit of work in Open Atrium, did a long stint using context module, have been a long term Features & Strongarm user, so I understand both sides of this argument very well, and honestly Panels is the far more capable solution, and it maps much closer to where core is heading with the new Symfony components. I hope that answers your question fully.
Kris
ontological (not verified)
Work in this area will improve user experience. Thank you for leading this initiative.
Reading the points above I did wonder if there is time for so much? I also wondered if this initiative impacts other initiatives like mobile and configuration management? Maybe there are ways to simplify. For example, if we can put blocks wherever desired, do we really need to be able to put layouts within layouts?
Kris Vanderwater
@ontological
So, we want layouts within layout so that you can setup something like a "header" or "footer" and then reuse them again and again without having to set that stuff up for each new page you build. As for impacting other initiatives, not really. We could have some impact in the HTML5 and Mobile initiatives, but I think the impact there will be very manageable.
@jstoller
I understand what you're saying here, but keep in mind there are a lot of people building a lot of really high level sites utilizing these sorts of tools today. Display Suite has proven thus far to be a pretty effective "gateway drug" to panels for the people using it in my experience. I can understand not having needed those level of tools yet, but it's a pretty common need within the community so hopefully we can find the proper middle ground between all the solutions that exist currently. Still a lot of this is going to be influenced by panels.
@Anonymous
Products like Open Atrium etc will need to be rethought to a certain degree, however many of the features that are going into core here should give them the robust tool sets that they were inventing at the time to get these sorts of things done. Will it be exactly the same? of course not, but I don't see any reason that these sorts of products won't continue to be VERY viable. In short, I think they'll be even MORE doable.
jstoller (not verified)
As a designer/themer, I keep looking at Panels, but I've yet to work on a site that I felt warranted its use. I've found the Display Suite and Context combination far more appropriate. I would caution against tying the new solution too closely to panels.
When I work on a site, I generally don't want the layout to be configurable once I set it. I also don't want to feel like I'm fighting against bloated features that I don't need when I create that layout. Panels seems great for developers and site builders who don't want to code their layout, or for giving end users configurable dashboards, but I worry what it means for designers who don't mind getting their hands dirty in the theme layer and want to build a cohesive site.
Anonymous (not verified)
Thanks for answering my question so fully. It helps me understand what is being proposed.
Any thoughts about what might happen to solutions like Open Atrium or Open Public that are based on Context, Features, etc. once your initiative is in place in core (D8)? Would D8 break them totally? Meaning, would there be any way to upgrade them to D8?
Christopher Pelham (not verified)
Wow. This is what I have been visualizing (from a site builder's perspective) and wanting since I first encountered Drupal 4.7. And for awhile I was hoping that Earl would do this with CTools and Panels until I realized that contrib could only provide band-aids to core rather than replace core, and so then I wondered why the core developers didn't take this on or convince Earl to join them... ;)
I wish I were a developer so I could jump in and really help you with this because it does sound like a like to get done this year, but it also sounds like, if all the core initiatives get more or less finished, then Drupal 8 will be super. super powerful and much more useable.
Have you looked at the drag and drop layout tool that is being developed for Omega? Even though it's not done yet, you might be pull some ideas or inspiration from there that are a bit different from the Panels layout UI.
Digidog (not verified)
As I have outlined in this http://digidog.de/digidog.de/notes/blocks-n-pages-drupal-7-8 blogpost a while ago, there were really something in need, and I am more than impressed again, how fast points like this get perceived, addressed and tackled down in Drupal community.
++ for this initiative and I will give input as much as I can.
Greetings from Berlin, Germany
brantwynn (not verified)
No mention here of how blocks will be handled on the datastore. This seems like the elephant in the room right now... Should blocks not be entities in D8?
Kris Vanderwater
@bratwynn
I made a few allusions to how that would be handled in the data store, but I guess I didn't outright say it. The intent here is to save block instances (i.e. each individual block on the page) as config (i.e. Configuration Management Initiative) data from a data store perspective. Essentially the new plugin system will provide a foundation upon which blocks will be built, and each individual block will be injected with configuration data relevant to their settings.
Blocks should not be entities, CUSTOM BLOCKS on the other hand make perfect sense as entities, but their placement, and configuration will still be CMI data. CMI data provides file based representation of the datastore, so it makes a lot of sense to save stuff this way because this is essentially an "export" in D7 terms, and leveraging that for blocks makes a LOT of sense with the various problems we're trying to solve.
Ole Noerskov (not verified)
While I realize that the shortcomings of the Block-system need to be addressed, I worry that we will end up with a Panels-like system in core.
I think it's absolutely crucial to think about use cases here - and I worry about the lack of input from people that are not hard core developers.
We need to think not only about what developers need or wishes for - but also about the impact that these changes would have for "end users" - web editors, sitemanagers etc.
I dont build websites - but I do deal with clients working as a consultant and project leader on several Drupal-projects. While I have never had any difficulties explaining the Block system to clients they go blank when I show them Panels - in fact I've stopped doing that at all.
We face two distinct problems here if we choose a core system as complicated and convoluted as Panels:
Developers would be happy - at least the developers that have become heavily reliant on Panels.
Now - I'm not trying to discourage you from evolving the Block system - it needs to be looked at. But if you choose a default system much more complicated than Blocks then you need to be aware of the dangers: Please involve web editors in the initiative.
My advice would be: Consider keeping a simple system in core and make the Panels-like system optional.
Kris Vanderwater
@Ole Noerskov
I understand what you're saying here, and I think it's a legitimate concern. If I might extend my own vision a little bit, I think that would be beneficial at this point.
Panels was never intended to be handed to end users/clients. Some "get" it, and thats great, but they were never the intended target. Obviously any core solution can't ignore end users on the same level so we have to solve that problem. I think opening this system up in core gives us a lot of potential benefits because there are some great UI people doing great work in core and the panels notion is solid, it just needs to be made palatable for the majority of users. To that end we will probably do a handful of things: (obviously none of this is set in stone, I'm just throwing spaghetti at the wall)
These are just a couple of ideas that I'd like to test on real live end users. I think there's a happy medium somewhere and we just need to experiment a little. At the same time, the Panels teams is working really hard on their "In Place Editor" (IPE) and seeing what notions work there for users, so we will hopefully inherit a lot of what they learn.
In short, I agree with your reluctance here, but only in so far as "panels is hard, we need to make something like it that is easy(er)". What we don't want to do here is sell ourselves short when we could have something truly ground breaking here.
Johan Falk (not verified)
Really looking forward to all of this. Kudos for taking this on!
Christopher Pelham (not verified)
I can understand wanting to be cautious about bringing the Panels UI into core but not the flexibility that Panels itself brings.
We need to be able to put whatever bits of content we want wherever we want it, re-using it in multiple places if that's what we want. And we need each bit of content to understand in what context it is appearing and we need to be able to choose the order that the fields (if there are fields) appear in each location that the bit of content appears.
We also want sometimes to be able create and use a layout that can apply to (almost) all of a site, or to certain content types or sections (defined in various ways), and then at other times we want to be able to define a different layout for just one particular page.
I think that much is indisputable. Not every site needs that but every site builder would like that freedom and power.
So the key is just to figure out how to make the UI as understandable and usable and friendly as possible. It is not true that layout templates always only need to be made before a site is launched. Some sites, many sites, grow and evolve and the flexibility to move things around would be appreciated.
I think part of the current difficulty with the Panels UI is that it shows all the options (like half a dozen screens of them) without clearly indicating which ones you can skip over. The Preview feature is clunky because you don't always get a real preview (with CSS applied) or link to jump to the live page. And then when you want to add content to a row you are given SO many content options (options are good but...) with no guidance about which to choose or why. Should I add a block, a block view, a page view, a panel view...? And then after you add content, the subsequent settings screens are unpredictable (especially when dealing with content that has multiple fields). Do I format them within panels or within views....?
It would be much easier to use in my opinion if we had in place layout and format editing. Say a user with the privilege to do so could just click a gear or icon and turn on in place layout editing on given page. Then the sections of the page become outlined and can be dragged around. Click another drop-down action from the gear and we can insert or delete rows or columns.
Then in-place editing of the actual block (or whatever you want to call it): if it's a node then we should be able to re-order the fields (just as we can in views) and change the HTML tags (if relevant). Then we should be able to specify if we want these changes made only on this page (this context) or in multiple contexts. If we want it changed in multiple contexts then we should be able to enter the new context rule there.
Finally, anytime we edit a node (or block? or entity? no sure...) we should also be able to see a list of all the contexts in which the node is programmed to appear and a list of the rules that govern the layout of the node according to the context, all of which we should be able to edit. That way we will be less likely to fix how something looks on one page but unintentionally screw up how it looks in another place that it appears that we may have forgotten about.
If we can do this, then we don't even need a separate thing called a block, do we? We'd just have nodes and entities and views (queried lists of nodes and entities), and then we'd have these associated rules regarding where to place them and what order to display the fields in each placement according to context.
And then Views could be much simpler because it could just focus on the queries (spitting out the desired list of nodes/entities) and all the UI controlling the formatting, layout, etc. would be pulled out and would be in core and accessible at each placed instance of the view (just like it would be accessible for each placed instance of an individual node or entity).
Then we wouldn't have so many different configuration pages with overlapping effects. It would be SO MUCH MORE STREAMLINED. :) I wouldn't have to think: oh do i change this in Views, or in Panels, or in Display Suite or in blocks....? There would just be one place.
pixelwhip (not verified)
This is going to be a huge change to the way we build and theme sites. It's both exciting and scary. I imagine there will be a lot of resistance from the theme community-- as evident in jstoller's and Ole Noerskov's comments above.
I have similar fears. By nature, us front-enders are very territorial of our markup. My fears can be quelled if we can be assured one thing-- Frontend developers have a consistent means to manipulate ALL markup on the page. Personally, I don't care if this is through a template file, configurable through the UI, preprocess functions, secret handshakes or whatever. I just want to have final say in the markup that is sent to the browser and want to exercise that right in a consistent fashion. Whether adding a class to the page header tag or the spans enclosing separating characters in a breadcrumb, a consistent method of doing so, will go along way in the success of this initiative.
I have used panels on a couple projects. While I have found it frustrating at times, in terms of UI and the resulting markup, it has a lot of power and potential. It allowed me to create some very complex layouts in a relatively short time. I think this will be a huge step forward for Drupal and believe it's in capable hands.
I do have a couple thoughts/questions. This is what I gathered from the diagram above.
Can blocks be nested within other blocks? I submit yes, but don't know if that's realistic. If that's the case, blocks should also contain a layout and the cycle repeats. I think this would be less confusing than layouts directly nested within other layouts.
On the markup side, layouts are a group of regions within a containing element. Regions are basically html sectioning elements or or no container element at all (Which one, is up to me :)) In order to prevent divitis, the absense of layout should still be considered a layout. Meaning, one option for layout is no containing element at all. Similarly, a region doesn't need an explicit containing element.
Am I on track here?
Kris Vanderwater
Mostly on track here yes, so let's dive into that a little more.
Keep in mind I came to Drupal as a themer, so I care very very deeply about how this initiative affects your workflow.
In regard to nested layouts in blocks, I actually illustrated that in the above image, however I left out the containing block in the hopes that it would limit some confusion expressed in earlier iterations of this blog post. In short yes, we'd like to be able to nest layouts, and while that can make for some major evil, it can also be used for good.
In regards to controlling your markup, the notion here is essentially 2 fold.
1.) Layouts are a simple system where if you want to make something it's 100% about your markup and css/js to do so. Regions will be named, if you want divs around a region put divs, if you don't, don't. (etc)
2.) Containers for the actual block output. What we do here is not fleshed out at all, but panels has a notion of removing the output around a content_type completely (to help prevent divitis) similarly it lets you define a wrapper so if you wanted something complex with color changers and drop shadows and other insanity you could get it. I don't know exactly where we'll go with this concept but there needs to be a controllable wrapper around the output of each individual block probably.
In short I think you'll find that your control over most output will remain similar to what it is now, but a bit more granular, and hopefully cleaner. I am happy to flesh this out more in subsequent posts, and I think a series of blog posts on what Designers/Site Builders/Developers can expect from this initiative is probably in order, however I have a lot of ground to cover between now and Drupalcon, so it will probably have to wait that long in any event.
I hope this sheds a little light on where we're probably going.
Ole Noerskov (not verified)
@kris - if you don't show the Panels interface on a Panels-centric site to the editors - are they not left with very little flexibility?
Also - I've worked with several developers that didn't like the Panels approach at all.
I personally would be happy with much less than what you plan to do: a per page version of the block system (being able to reuse blocks in different ways across a site) and blocks that new a little more about the outside world.
But I do predict that you guys are smart enough to create something so bad ass that I'll learn to like it :-)
Kris Vanderwater
That's the intent ;-)
Tabitha Winter (not verified)
Hi
My focus is much more on project management and usability. If I can help in anyway using those skills please let me know.
Tabitha
squiggy (not verified)
I agree, this would be awesome to build into D8. Let me know if a can land a hand! I would love test and I have a lot of experience creating panels plugins and using CSS frameworks.
-s
ontological (not verified)
@Kris - "Layouts" is an overloaded term and maybe that was confusing. Getting a clear terminology and description of the outcome is an important step. I get the sense that maybe either it is still evolving or maybe the description is still being refined. In the hope that it is useful, something like this, with a corresponding "story" told at the end, makes sense to me:
Story:
Themes could provide Page Layouts and Regions similar to how they work today. The user downloads a theme that has a number of defined and styled regions. In the UI the user arranges some basic blocks (header, footer, sidebars, etc) and saves that as a Page Layout marked as default. Then if the user wants, say, a slide show on the home page, the user clones the default page, adds a slide show block to the "featured" region, enters the conditions for using the page layout (), and saves it. Of course the theme could provide page layouts, similar to the TPL template files today and the user could select those as well as creating their own via cloning.
Does this having any correspondence to your direction?
Best regards
jec006 (not verified)
How will you support responsive style designs in a panel-style world? This seems like a fairly major issue as responsive design has become a large movement in the Drupal theme world.
AdamGerthel (not verified)
I agree with a lot of the points regarding a more flexible content and block system, but this really scares me:
Theming should always be left to the theme layer, and never be in a UI. I can see where developers that are forced to implement someones design are coming from, because it makes things easier for non themers to do "theming". But for themers, added CSS is always a bad thing, and most themers work hard to remove it.
A "layout" is a very vague term. To me, a layout defined by a UI in Drupal should do nothing more than set an order of markup. A layout to me is something quite graphical, like a two column or three column layout. This should never ever be something that is decided in a UI, because themers will simply do their best to override it anyway.
Kris Vanderwater
Adam,
I understand your point here, but let's break this down before we get to sold on a specific direction.
1.) Theme's currently provide a layout, one which is probably never good enough for your specific use case, one which will always require you to edit a rather convoluted page.tpl in order to get what you want. Page tpls are full of crap of all sorts. They are consistent only in the fact that they are inconsistent... trust me I know, I worked really hard in the D7 life cycle to bring some sanity to our defaults (stark).
2.) Chances are you have a css framework you like and use regularly. Chances are, if you're doing responsive, or grid based layouts you have some core css sheets you are constantly porting forward and keeping for your uses. Chances are also good that you have a handful of layouts, or layout strategies you mix and match to get the sort of pages you want. A 12 column grid can only be sliced so many ways.
Understanding these truths of design, layout plugins are a nice new tool in your bag because you can change the content placement, number of columns, etc w/o changing or hacking themes. Designers will be ENCOURAGED to write their own layout plugins. These are kept simple on purpose, to support the designer's needs while still supporting the system. Layouts are just being separated from the theme in such a way that you could maintain a library of layout strategies you prefer to utilize, instead of having to build custom new page.tpl files for every new site.
Anonymous (not verified)
I read your blog post with intrigue, as many of the concepts you're putting forth resonate completely with the motivations behind the Livethemer module (http://drupal.org/project/livethemer). We took the concept way beyond just layouts though, but doing layouts in core is a huge step in the right direction :)
Drupal themes are (currently) so much at odds with the functional granularity of the rest of Drupal. A site will use 10, 20... whatever number... of contrib modules but ONE theme. Like or not, you get that theme and nothing but that theme. Breaking this down for D8 would be huge... it's basically one of the things that drove us to create Livethemer in the first place.
Looking forward to what we can do with D8 layouts inside Livethemer :)
Jeff
Add new comment