Blocks 'n pages, Drupal 7 & 8

There are many possible situations, where it can hit you: crisscrossing logic in a system. Self-contradictory and self-destructing. But mostly unevitable for reasons lying behind a long developement decade. Drupals "blocks meet templates" scenario could be one example for it. I think, I don't need to append here how awesome Drupal is for readers of this post, since the most of them know Drupal maybe better than me. And since I'm not a developer, but a project-lead for projects with a considerable impact swiping web development on a daily basis, my interest in scripting languages like PHP and systems like Drupal is self-explanatory and not new.

Even after developing an own CMS back in the days autodidacticly, there surely are a lot of Drupal core developers who are rather more suitable for discussing a certain API of Drupal core than me as a non-developer. But after chatting with Drupal core developers like webchick, sun, davereid, tim.plunkett and many others about blocks in Drupal 7 and how they will change in Drupal 8 and where it goes and some points where it turned out that my view could be interesting to discuss, I decided to write it down on my scratchpad here. Don't take it as advice nor as a "this is how it should be", rather as thoughts to discuss, questions and the try to describe some scenarios with a non-native tongue.

Now let me get back to what I sad about crisscrossing logic. For some Drupal arrival it may be confusing or new to find template files in the Drupal installation folder containing 90% php code. And maybe some of them may even wonder about how many files there could come up after time. And still a few of them maybe will come to the conclusion soon, that it isn't such a bad idea to have many small php files each of them covering a certain level inside a website layout and its onionskins to have a full control over all these levels of boxes in a layout: The page, the content group, the single content, the form, certain regions with grouped or listed content, or even repeating small parts like links or image handling under certain conditions. They will start to imagine how awesome Drupals possibilities are and sooner or later they will swipe blocks and how they depend to template regions and will like the idea, of having the options at hand, to change groups of content in certain template regions with a mouse click or depending on certain rules. But maybe a few less of them will be interrupted then in their joy of understanding the grace of this idea and how nicely it all makes sense when looking ... finally ... into the page.tpl.php.

This is where the crisscrossing part in the logic comes in: hard coded system regions like system-messages, contextual admin menu items and admin tabs, logo, site-name and site-slogan, primary und secondary menu blocks, syndication elements, etc. Why does it stop here in terms of flexibility? First they may think, hm there's surely a reason for that. But after another two months they will come back to the question and say: Wait. Couldn't it still be all blocks? Why page.tpl.php looks so cluttered while node.tpl.php works perfect as a tpl container. Wouldn't it be nice to change the system blocks under certain conditions too? Like other blocks. Some may say, yeah that's what the if/else loops are for, you know? But no. I don't want an fully if/else cluttered page.tpl.php, still missing one two scenarios on the end or going bak into it every 3 months for other condidions. Thats what the backend is for from the users point of view (usability?).

Why stopping here with the flexibility blocks can bring? Why not leaving the page.tpl.php file as blank as node.tpl.php, just being a handler/container to keep the "flexible theming layer" idea up as much as possible? Why not gaining the option to change the behaviour of this blocks dynamicly, conditionally like other elements? It looks like the conceptional idea of the theming layer has stopped short before page.tpl.php. And since there seem to be many out there who like the "Drupal vs. Wordpress" game (don't ask me why), I can't wait to place the joke here with the finishing question: Why suddently this kindof "let's simply throw it in - Wordpress" way on the end of the road?

We may discuss a pocket track, a colt meat here since blocks seem to change conceptionally in Drupal 8 a bit, but let me show up an example before we go to Drupal 8:

The theme you see here (don't judge it yet) is a beta version of our drafted idea (called magrid on drupal.org) of a fully flexible modern "all-days-again" theme (nope, not another starterkit!), with simply 6 up to 10 clickable options made for the beginning of the development process, but also with options for coming back on an online production site to change some parts fast and effective in mind. Let's say you decide later that you want to have a fixed width or rather a full width layout but don't want to see the page collabse after changing that (smart css classes)? Or later a responsive mobile first layout. Or a layout fitting to different! css grids and you also want to switch from a 10px to a 20px gutter, but rather with a horizonal instead of a vertical look and feel? But wait, with the logo at right instead of left? You want to have a portfolio kind of frontpage then, or rather some newspaper-like teasers, or postcard-like showcase-elements and a background-image animation without starting another development process again on the site? No problem. Just take a short look on the checkboxes and you're gone.

I don't tell you that for promoting the theme. I tell you that because of the limits we reached. It's all only one/two mouse-clicks away with this own theme creation for us. And that's only possible because of Drupals awesome possibility to let us develop handlers for this theming options as a application layer in between. Options to create a theme, which can be handled like a little application inside of the Drupal application. Image_style altering, preprocess_node/blocks/page/whatever functions to add css grid classes and change them dynamicly, loading and unloading jQuery plugins depending on the options you choose on the theme settings page, etc, etc. That's awesome. That's Drupal. And that's why people argue about ugly themes in the Drupal, because without knowing how Drupal works you don't understand that it is impossible the theme a flexible application liek Drupal out of the box for a default usecase.

But enough hymns of praise, by trying to gain the most possible flexibility I finally stuck on the point when I started to think of options to (lets say) change the logo size and position on subsites without cluttering page.tpl.php with if/else scenarios, which never ever can cover all situations for all times. For example, when the user has logged in and checks his profile, or to move system-messages in a developer block beside the contextual edit tabs when the admin has logged in. (To be honest I found it always annoying to have a outlogged version of the site we work on somewhere else, because of tabs and other stuff destroying the all over preview of how the changes really look like, when I work on them.) And that are only a few counted situations where the awesome flexibility of Drupal gets crisscrossed by the way how the page.tpl.php is concepated with including system regios for now. Or let's say it better: why are blocks has missing features which force the page.tpl.php to take that over that way. Again, to use 12 if/else statements in the page.tpl.php can't be a smart solution, since 11 of them are not the case for a decade but has to get run thru' since I make another decision and want to change something on it and have to go thru' the lops in the page.tpl.php again. Also for performance it would be better to have the opportunity to rather have this parts as system-blocks in the blocks editor available to leave out what isn't needed yet.

You may say know, like mostly in the Drupal community, you are not the only one who has missed that on blocks and like mostly in the Drupal community, there are already modules covering that. I know, and I used some of them and recommend them also on the magrid sandbox page. Thanks to sun and fubhy, who helped me to re-collect modules from the drupal.org repository, which are handling/altering or extending block functionality and its implementation method (sometimes I suffer from Alzheimer's syntoms :-) ) .

http://drupal.org/project/block_class
http://drupal.org/project/block_api
http://drupal.org/project/boxes
http://drupal.org/project/bean
http://drupal.org/project/delta
http://drupalcode.org/sandbox/Crell/1260830.git/blob/refs/heads/wscci-pl...

The most interesting ones in this discussion are the two last on that list for me. There are surely more. Please help to fill this list with missing ones in the comments, and I will update the article then because I would like to write up a short "which-makes-what" on every module of them.

But with or without that modules. My final question is, isn't better implemented in the core block module then in an addtional block_block_module? I would like to vote for some of the functionality in core before the Drupal 8 circle closes.

[HERE IS A MISSING PART I WOULD LIKE TO DISCUSS BEFORE ABOUT BLOCKS IN DRUPAL 8. PLEASE COME BACK FOR THAT PART LATER]

I hope you understand what the article is/will be about. I had a better version of it already at hand, but sadly I lost it by a browser/text editor freeze here and had to reproduce the content later. Which is mostly feeling worse than what you had before. I think you that kind of feeling.