Bricks - Alternative workflow

Kirby 2 Solutions 🎉
1

I’ve come up with a new really interesting workflow.

A normal structure

assets/css/product.css
assets/css/category.css

snippets/product.php
snippets/category.php

CSS files are grouped together in a the assets folder. The snippet PHP files are grouped together in the snippets folder.

Patterns structure

Kirby Patterns have a different structure:

patterns/products/product.css
patterns/products/products.html.php

patterns/category/category.css
patterns/category/category.html.php

Instead of grouping the files by type they are now grouped by “module”. Delete the category folder and all that has to do with the category is gone.

Bricks structure

I’ve now taken that approach one step ahead. Instead of just having the snippets as patterns I felt the need for grouping even more stuff.

bricks/product/style.css
bricks/product/blueprint.yml
bricks/product/controller.php
bricks/product/template.php
bricks/product/snippets/tags/tags.css
bricks/product/snippets/tags/tags.php

bricks/category/routes.php
bricks/category/style.css
bricks/category/blueprint.yml
bricks/category/controller.php
bricks/category/template.php
bricks/category/hooks.php

It was similar to the approach I had for making plugins. I’ve started a plugin called “Kirby Bricks” which automatically register the files and folders it finds with the matching files.

Benefits:

  • Kirby is now truly modular.
  • Delete a brick and everything, I really mean everything about that brick will be gone.
  • The file structure will be really flat, all in one place. There is almost only plugins and bricks left.
  • I don’t work with for example all the blueprints at the same time. I work with a “brick” a part that contains blueprint, controller and template. I now have access to all the important files directly.
  • It’s easier to spot things that are no longer needed.
  • It reminds about plugins, but it’s really modules/bricks of your site.

What do you think?

7 Likes
2

I love the idea as it totally fits my preferred workflow.
Would like to check this out in my next project if it gets released.

Thanks for your great work!

1 Like
3

can i understand it to clean up things much more? for example

within each bricks/{page-type-here]/ folder we define everything we need css,js, controller blueprint etc.?

for example we’ll have

bricks/blog/
bricks/blog.entry/
bricks/default
etc.
with all css, js, templates etc. within?

I generally like the idea. but e.g. blueprints (for now) also can be used to define global fields, controllers can be used by e.g. plugins as well.

4

Nice idea. But the benefit of using snippets in various templates / bricks is gone. And combining bricks to a molecule or even bigger organisms would be difficult.

Otherwise I like the flat hierarchy.

5

@carstengrimm @abroess

Thank you for your feedback.

I agree with you that some things are bound to a template and some things are not.

When it comes to snippets. Some can be bound to a template, but there can also be global snippets like header and footer that should appear on every page.

I have a few solutions in mind.

1. Use site

Below you can see a site brick. Site is sometimes used by the core as a general site name. Because all the snippets in a snippets folder are registered they can be used anywhere.

It does not have to be named site, it can be anything but I think it’s consistant. Global field definitions can be added here as well.

With site.php (the filename matches the folder) you can load anything for example register the field defintions.

bricks/category/blueprint.yml
bricks/category/controller.php
bricks/category/template.php

bricks/site/blueprint.yml
bricks/site/site.php
bricks/site/snippets/header/header.php
bricks/site/snippets/header/style.scss
bricks/site/snippets/footer/header.php
bricks/site/snippets/footer/style.scss
bricks/site/definitions/some-field-definition.yml
bricks/site/definitions/some-other-definition.yml

I kept the category brick just to show that it’s the same thing.

2. Use bricks as snippets

It’s already also possible to not use the bricks as template groups, but as snippet groups. So in this case a brick is a snippet, just like a snippets folder.

In this case the snippet register the name of the brick folder.

bricks/header/style.scss
bricks/header/snippet.php
bricks/footer/style.scss
bricks/footer/snippet.php

3. Use snippets as before

Even if this is an alternative workflow it does not prevent you from using the normal one, or combine them.

bricks/category/blueprint.yml
bricks/category/controller.php
bricks/category/template.php

snippet/header/style.scss
snippet/header/snippet.php
snippet/footer/style.scss
snippet/footer/snippet.php

I still use the snippets grouped as modules, the way the patterns work in the examples

Still experimental

This is still a very experimental idea so I’m really glad for all the feedback I can get to keep it in the right direction.

What do you think about this @carstengrimm @abroess?

6

Well, I think the nicer way is, to put all items under the “bricks” hood. With the possibility to adress singles bricks or group them to bigger bricks is cool. I would prefer “global” instead of “site” by the way. But that’s my personal choice :wink:

I realy like this mockup. It would definitly replace my usage of the patterns plugin.

7

With the possibility to adress singles bricks or group them to bigger bricks is cool.

Do you have a clear idea of how you would do that, how the folder structure would look like?

I’ve tried some more and this test is still evolving.

First the folder structure looked kind of like this:

bricks/category  # template
bricks/product   # template
bricks/header    # snippet
bricks/gallery   # snippet
bricks/page      # template
bricks/menu      # snippet

When having like 30 bricks or more it’s really hard to know what is a template and what is a snippet.

I changed it to this:

bricks/snippet-gallery
bricks/snippet-header
bricks/snippet-menu

bricks/template-category
bricks/template-page
bricks/template-product

The benefit is that it’s clear what is a template and what is a snippet. Also the sorting by filename helps.

While it works, when having more than 30 bricks the template bricks are pushed down to the bottom and the list is long. Another thing against it is that every snippet needs to be named snippet- which is a little more work than just setting an unprefixed name.

Later on I changed it again

bricks/snippets/gallery
bricks/snippets/header
bricks/snippets/menu

bricks/templates/category
bricks/templates/page
bricks/templates/product

A separation between snippets and templates by having a folder for both of them. Now no folders needs to be prefixed.

The last change

I thought, why even have a bricks folder…

snippets/gallery
snippets/header
snippets/menu

templates/category
templates/page
templates/product

Then why even go through all this if it still ends in the original folder structure?

The big difference will be that the template folder is very different as it can look like this:

template/product
template/product/blueprint.xml
template/product/controller.php
template/product/template.php

template/category
template/category/blueprint.xml
template/category/controller.php
template/category/template.php

It will not collide with the current way Kirby set templates because it’s looking for files and here we always have a containing folder.

It’s not set in stone so I’m still really interesting to see your approach and hear your thoughts @abroess. Other people are welcome to have feedback as well. :slight_smile:

8

Perhaps your’re right: Why we should have a “bricks” folder with the same folder structure as the orginal kirby base? Hmm, what about two different Plugins, working with templates? When you choose “bricks” as main folder, the original folder structure is not influenced by the plugin.

I think a clean separation should be the better way to go ahead.

9

Hmm, what about two different Plugins, working with templates? When you choose “bricks” as main folder, the original folder structure is not influenced by the plugin.
I think a clean separation should be the better way to go ahead.

I’m not sure I understand what you mean. Anyway I released my plugin yesterday:

github.com/jenstornell/kirby-bricks

It’s made with the template module part in mind. That’s because I feel that I nailed that part. There is snippet support as well, but you can also use the native snippet way.

Except for that it’s possible to set up some custom stuff, like this:

templates/about/blueprint.yml
templates/about/about.php

In about.php you can include or register whatever you want if you miss something that is not in the plugin.

1 Like