Hello, i am a fan of drupal 7 and hate where it is going with 8/9. Backdrop cms is very tempting and just started playing with it.

Ive a question though, i like to handle most stuff with my theme instead of depending on modules and libraries and that gives me freedom and independence.

What i dont understand is, why do i need a seperate layout concept while i should be defining them within my theme instead? After all the regions are theme-dependent.

Most helpful answers

> Also, where do we report bugs for core modules?

Please, do report bugs in core here - https://github.com/backdrop/backdrop-issues/issues.

Also, make feature requests or comment on existing feature discussions. We really want to hear more opinions from users in the core issue queue. Again, do not hesitate to open issues for bugs you find, especially in regards to the upgrade process. We really want to improve that. 

It's hard to remember where all the resources are for Backdrop CMS, so if you don't know where to go, the best place to start is on the Resources page in the Support menu of BackdropCMS.org. 

https://backdropcms.org/support/resources

From there, you will see a link to all the github repositories. 

https://backdropcms.org/resources/backdrop-cms-github

Please, also provide feedback on the process for reporting bugs and suggestions on how to make it easier. 

 

 

Please see for example the starting line in the core boxton template. It starts with a wrapper div with style <div class = "layout-boxton ... >

Each template can have such a wrapper HTML element with class with a unique name of this template name and through this unique class in CSS files of an active theme with different CSS selectors you can manage all active templates on the site, it is not necessary to have CSS code in the templates themselves.

And to note something you may not have noticed yet - in Drupal, when you change the theme, all blocks are shifted or disappear if the new theme has different regions. Separating the theme from the layout in Backdrop CMS makes it so that changing the theme does not shift anything in the structure of the blocks, because they are located in the template, not in the theme. This is a huge advantage. That is why there is no CSS in templates - they are not responsible for the visual presentation of the site, but only for its structure.

And this is a significant step in achieving a very important and fundamental principle in web design - distinguishing content from presentation.

Another important advantage you will see as you become more familiar with the template system is that the templates and layouts based on them have a powerful logic controlled easy by the admin panel that makes them behave differently according to different contexts - something that was impossible with the good old page.tpl.php in Drupal.

Don't worry that different themes can display one layout in different ways. Isn't that exactly the purpose of the theme, to change the design of the site?

About the theme and layout templates as a set - if you use ready-made core templates, or those written in the naming Backdrop conventions for HTML elements, or if you strictly follow the naming requirements for the HTML elements that make up the template code with the community requirements , then your theme will work with any template compatible with these requirements.

For example, the standard official header name on the Backdrop Template page is

<header class = "l-header" role = "banner" aria-label = "<? php print t ('Site header');?>">
      <div class = "l-header-inner container container-fluid">
        <? php print $ content ['header']; ?>
      </div>
    </header>

In my own template I use <header id ="header" instead of <header class = "l-header" ...

I have my own reasons for this.

But if you have, as I have, your own preferences for naming HTML elements, and that determines the CSS selectors in the theme, yes, then the theme and template are a set and can only work together.

Personally, this does not bother me, because the themes I develop are not for sale and I use only for my projects and I am facilitated by a unified technique for building HTML code in the template, which I have been accustomed to since the time of Drupal 6.

Comments

mazze's picture

Hi Aubergine, welcome to the Backdrop Forum... Layout does what page.tpl.php did in Drupal 7. However, Backdrop DOES require a layout template to be used. But you can choose a simple one-region layout and keep on working the way you did in Drupal 7. I also do a lot of custom code in node--mycontenttype--myviewmode.tpl.php (e.g. printing fields directly). But at the same time, some things are way better to be used in layouts, I really recommend that you give it a try...

BWPanda's picture

After all the regions are theme-dependent.

They were in D7, not in Backdrop though.

Consider a basic layout: header, sidebar, content and footer. There are many ways this could be styled, coloured, etc. Different themes can display this layout in different ways.

Having said that, with my own sites I have developed a custom layout that suits me, and a custom theme that I sub-theme from on each site. These two things work together to give me a truly customised experience.

So if you want the same experience you had in Drupal 7, you'll just need to create a custom theme and a custom layout.

Also note though that it's possible for a theme to override template files and CSS from layouts, so you can also find an existing layout you like, then further customise it in your theme.

Different themes can display this layout in different ways.

Exactly that is what is puzzling me, one site mostly has 1 theme, why would i need several themes thus need a modular layout foundation which is controlled within another aspect of the site?

Or let me ask this way, if i somehow try to sell/distribute free a theme for backdrop, do i tell the clients; "you need these layouts to be setup before you can use this theme"?

Anyways, i think its currently the very early days for backdrop but i see a good future for it.

Don't worry that different themes can display one layout in different ways. Isn't that exactly the purpose of the theme, to change the design of the site?

About the theme and layout templates as a set - if you use ready-made core templates, or those written in the naming Backdrop conventions for HTML elements, or if you strictly follow the naming requirements for the HTML elements that make up the template code with the community requirements , then your theme will work with any template compatible with these requirements.

For example, the standard official header name on the Backdrop Template page is

<header class = "l-header" role = "banner" aria-label = "<? php print t ('Site header');?>">
      <div class = "l-header-inner container container-fluid">
        <? php print $ content ['header']; ?>
      </div>
    </header>

In my own template I use <header id ="header" instead of <header class = "l-header" ...

I have my own reasons for this.

But if you have, as I have, your own preferences for naming HTML elements, and that determines the CSS selectors in the theme, yes, then the theme and template are a set and can only work together.

Personally, this does not bother me, because the themes I develop are not for sale and I use only for my projects and I am facilitated by a unified technique for building HTML code in the template, which I have been accustomed to since the time of Drupal 6.

Hi Aubergine!

I also wanted at the beginning to work with Backdrop in the way I knew from Drupal, but I quickly learned to work with templates. It takes a little time, but then there are many benefits.

The main thing is, do not try to edit page.tpl.php. This file can be edited as custom template to add items to the head or body section of page.tpl.php. that are not part of the Backdrop, such as Facebook scripts or some statistics code. But the regions are not in it, page.tpl.php uses the regions defined by the template. Sometimes I put there custom metatags.

page.tpl.php plays in Backdrop a role similar to html.tpl.php in Drupal.

Regions are managed and created in the template file, just as was previously done in page.tpl.php in Drupal's time.

The original system templates that come with the Backdrop cored are located in the core/layouts folder and you can use one of them but without editing it because it will be changed the next time the system is updated. You can copy one of the templates there and put it in the layouts folder in the root directory, which is usually empty after installation - this is in place for your templates - because the advantage of Backdrop is that it can work with many different templates for different parts on the site. There you can edit and play with your templates and they will remain untouched in case of core update..

You can also create a completely new custom your templates in this folder and do in them everything you used to do in Drupal via page.tpl.php. How to do this is described here:

https://api.backdropcms.org/layouts

But then you have to make Backdrop to recognize the new templates and include it in the list of available templates, this happens by the admin panel of the address (I give an example with the template for Default Layout, there are several others by default) -

admin / structure / layouts / manage / default / configure

All layouts and their templates are there:

admin/structure/layouts

It may not work the first time, but I understand from your post that you will not give up easily, the effort is rewarded many times over and it is amazing how many new opportunities this system provides.

Welcome to Backdrop CMS!

Also, where do we report bugs for core modules?

Like, after disabling dashboard, remnants of layout and menu options for dashboard are still editable unless you completely uninstall the module.

> Also, where do we report bugs for core modules?

Please, do report bugs in core here - https://github.com/backdrop/backdrop-issues/issues.

Also, make feature requests or comment on existing feature discussions. We really want to hear more opinions from users in the core issue queue. Again, do not hesitate to open issues for bugs you find, especially in regards to the upgrade process. We really want to improve that. 

It's hard to remember where all the resources are for Backdrop CMS, so if you don't know where to go, the best place to start is on the Resources page in the Support menu of BackdropCMS.org. 

https://backdropcms.org/support/resources

From there, you will see a link to all the github repositories. 

https://backdropcms.org/resources/backdrop-cms-github

Please, also provide feedback on the process for reporting bugs and suggestions on how to make it easier. 

 

 

Okay, as i keep looking at the source files and playing with things, i find some good sides for the layouts concept. But in the long run, i see bad sides as well.

Lets assume i use several layouts for home and many different content types with all shared and/or different blocks configured. And suddenly i felt the urge to configure my header block to remove the user menu.

Now i have to go through all different layouts and edit all the header blocks individually or is the header block is static on all layouts? Currently i have to go through all of them and doesnt seem to be static.

Sorry if these are all stupid questions.

Check out the "Copy Blocks" module, I use this regularly to "mirror" an entire region (usually header/footer) on various other regions so that when I change the default header or footer region it is also changed on all of those other layouts automatically:

Another thing bothering me about the layouts concept is;

While looking at the core supplied funny named layouts, none of them supplies any css to actually layout those defined regions besides the legacy ones and so the theme is supposed to be responsible for the actual layout.

Now obviously as all suggested above, most sites will use custom layouts suitable for their themes and noone will be using those stock layouts, then what is the point of those?

Please see for example the starting line in the core boxton template. It starts with a wrapper div with style <div class = "layout-boxton ... >

Each template can have such a wrapper HTML element with class with a unique name of this template name and through this unique class in CSS files of an active theme with different CSS selectors you can manage all active templates on the site, it is not necessary to have CSS code in the templates themselves.

And to note something you may not have noticed yet - in Drupal, when you change the theme, all blocks are shifted or disappear if the new theme has different regions. Separating the theme from the layout in Backdrop CMS makes it so that changing the theme does not shift anything in the structure of the blocks, because they are located in the template, not in the theme. This is a huge advantage. That is why there is no CSS in templates - they are not responsible for the visual presentation of the site, but only for its structure.

And this is a significant step in achieving a very important and fundamental principle in web design - distinguishing content from presentation.

Another important advantage you will see as you become more familiar with the template system is that the templates and layouts based on them have a powerful logic controlled easy by the admin panel that makes them behave differently according to different contexts - something that was impossible with the good old page.tpl.php in Drupal.

I use the core layouts all the time. I don't try to override them in my themes. If a need more regions I either copy a core layout and put it in the layouts folder and tweak it, or I create a flexible layout in the UI.