Kirby Bricks - Modules/patterns/components approach

[jenstornell]

github.com/jenstornell/kirby-bricks

There is a solution in the forum about this as well. I want to keep them apart to let the plugin and the solution/discussion evolve by themselves, maybe in different directions.

“Old” Native structure

templates/about.php
templates/contact.php
templates/projects.php

blueprints/about.yml
blueprints/contact.yml
blueprints/projects.yml

controllers/about.php
controllers/contact.php
controllers/projects.php

New Bricks structure

about/template.php
about/blueprint.yml
about/controller.php

contact/template.php
contact/blueprint.yml
contact/controller.php

projects/template.php
projects/blueprint.yml
projects/controller.php

Benefits with Bricks

• It’s modular. Delete about and everything bound to about will be gone.
• Everything is right there, not spread out through several folders.
• It can give a better overview of what parts you use and which you don’t.

Much more information is in the docs:

github.com/jenstornell/kirby-bricks

[seehat]

I love this approach and used some code to serve assets, like kirby core does with plugins:

<?php

$kirby->set('route', array(
  'pattern' => 'assets/bricks/(:any)/(:all)',
  'method'  => 'GET',
  'action'  => function($brick, $path) use($kirby) {
    $bricksroot = ( ! empty( kirby()->roots()->bricks() ) ) ? kirby()->roots()->bricks() : kirby()->roots()->templates();
    $root = $bricksroot . DS . $brick . DS . 'assets' . DS . $path;
    $file = new Media($root);
    if($file->exists()) {
      return new Response(f::read($root), f::extension($root));
    } else {
      return new Response('The file could not be found', f::extension($path), 404);
    }
  }
));

[jenstornell]

Nice to hear about that! It looks nice and is an interesting approach.

I often merge every asset of each type into a single file which I place in the native assets folder. That makes the website load faster, which is good for users and search engines.

[seehat]

How do you handle images in bricks? - Do you also copy them to the native assets folder and how do you set the path to the images? Are you doing this with gulp?

[jenstornell]

Ahh, now I see what the route is really for.

Images with Gulp

I don’t recommend Gulp moving images. I’ve done it myself and I saw a few big problems with it:

• Gulp does not discover new files so when I add new images, they are not moved to the assets folder directly.
• Even if Gulp is restarted the images are not moved to the assets folder. A change needs to be done to the file or a gulp task needs to be executed.
• Move and delete does not sync with the assets folder.

Maybe there are smart plugins to solve the issues above but in general I feel that Gulp moving images is a wrong approach.

Merge your solution to Bricks?

I think your solution is really good. Maybe we could merge it into the Bricks plugin? Would that be fine with you?

[seehat]

Yes, that’s the reason for the route.

I had also problems when moving images with gulp and not use it anymore.

Of course, it is absolutely fine. Please merge it.

[jenstornell]

Kirby Bricks 2.2 released!

github.com/jenstornell/kirby-bricks

This is a complete rewrite from version 1. You can read about all the changes compared to version 1 here: https://github.com/jenstornell/kirby-bricks/blob/master/docs/differences.md.

While the first version was more of a proof of concept, this is a much more well planned release.

Folder prefix

It’s possible to prefix your folders to see which bricks contains templates and which contains snippets, but it’s optional. https://github.com/jenstornell/kirby-bricks/blob/master/docs/folders.md

Nested bricks are supported (good for snippets) as well and it takes folder prefix into account.

Snippet controller

Controllers bound to a snippet. I’m using it myself all the time. https://github.com/jenstornell/kirby-bricks/blob/master/docs/snippet-controller.md

Autoload

Maybe you have code just for a brick and don’t want to create a whole plugin for it. Then it’s possible to add a load.php file. https://github.com/jenstornell/kirby-bricks/blob/master/docs/files.md

Register your brick manually

If you have a plugin and want to register bricks manually you can do that with registry set: https://github.com/jenstornell/kirby-bricks/blob/master/docs/registry.md

Assets support

It’s possible to link to assets, similar to how plugins works: https://github.com/jenstornell/kirby-bricks/blob/master/docs/assets.md

Notes about Bricks UI

Bricks is the core and Bricks UI will be the visual preview of the bricks, similar to how Kirby and the Panel are separated.

I have a finished version of Bricks UI locally, but I want to test it more before the release but it’s working really well so far.

[fabianmichael]

@jenstornell

Gulp does not discover new files so when I add new images, they are not moved to the assets folder directly.

Hey Jens, I had similar issues with Gulp and the watch method. I solved this by using the gulp-watch plugin, which is able to detect new files and does not crash when renaming a folder: gulp-watch - npm

Hope, this helps.

[jenstornell]

The first test seems to work a bit better than before but it’s not perfect.

Saving a new file and copying a file does trigger gulp so that part works. Renaming and deleting a file makes it crash. I thought the plumber I added would prevent errors like that.

gulp.task('css', function() {
	return gulp.src(['assets/scss/style.scss'])
		.pipe(watch('bricks/**/*.scss'))
		.pipe(plumber())
		.pipe(sassGlob())
		.pipe(sass())
		.pipe(autoprefixer())
		.pipe(gulp.dest('assets/css'))
		.pipe(rename({suffix: '.min'}))
		.pipe(cssmin())
		.pipe(gulp.dest('assets/css'))
		.pipe(notify("CSS generated!"))
	;
});

I think that it’s sassGlob that does not play along. When adding scss-files all the time, sassGlob is really a big help.

TypeError: Cannot read property ‘toString’ of null at transform (\node_modules\gulp-sass-glob\dist\index.js:67:31)

But because it works a bit better than before I keep this setup for now, until a new solution appears. Thanks!

@texnixe @lukasbestle Can we split this topic into two? Gulp discussion is another topic.

[jenstornell]

I need a new name for this plugin, simply because Kirby uses bricks for something else.

I will merge Kirby Bricks with Kirby Bricks UI. It will end up being similar to Kirby Patterns.

So, help me pick a new name for it (even if you don’t use it):

• Kirby Parts
• Kirby Chunks
• Kirby Bits
• Kirby Fractions

Show results

Own suggestions are welcome as well.

[aoimedia]

Kirby Blocks ?

…I do like Kirby Bits too!

[texnixe]

+1 for blocks (and some more chars)

[jenstornell]

@aoimedia @texnixe

Without saying too much, it looks like Kirby will use that word for something in the future. https://getkirby.com/next

It looks like Kirby Bits will be the winner, but I hope I can get at least 10 votes before I go ahead with anything.

[texnixe]

I’ll throw in components, segments and particles as options

[jenstornell]

Thanks!

Components is also kind of taken in the future. Let’s see…

• Kirby Segments
• Kirby Particles

I really like Kirby Particles. My guess is that it will never be used by Kirby itself and it says what the plugin does quite well.

I tried to throw your alternatives in there, but I’m not allowed to edit a poll when 5 minutes has gone. If you want, you can probably add them with your access level.

[franzwalter]

I’ve used site/components as a folder to store the site’s snippets, modules, templates ever since you first published the plugin. I liked the term because it is a bit more generic; in particular because the single bricks could contain js, scss, php code or just a custom template blueprint.

[texnixe]

No, unfortunately, I can’t edit the poll either.

[carstengrimm]

i started transitioning my content to default bricks. and just a little feedback - it’s a little frustrating having hundreds of diffrent templates with a full set blueprint, templates and controllers. is there any way to automate the copy/rename stuff?

i haven’t tried yet, but does @auto also fallback to bricks? e.g. when i put javascript and css files from assets/css/templates and rename them to css.css?

in addition: what about the remaining things in a few folders, such as “site”, user fields, custom fields, etc.

[jenstornell]

i started transitioning my content to default bricks

What do you mean with “default bricks”? Often there is only one default brick and that is for the default template.

hundreds of diffrent templates

Do you really need a hundred templates? In my site that I’m currently redesigning, I use 4 templates and it has around 50-100 pages.

is there any way to automate the copy/rename stuff?

You can probably create a PHP script for it.

i haven’t tried yet, but does @auto also fallback to bricks? e.g. when i put javascript and css files from assets/css/templates and rename them to css.css?

I’m not sure how that part works in the core. What Bricks does is register the template.php with the folder name for example projects. Then the core will know that there is a template called projects, but if it has a relation to @auto I don’t know.

Remaining things

in addition: what about the remaining things in a few folders, such as “site”, user fields, custom fields, etc.

Custom stuff that you feel don’t belong to the plugins folder can be placed in one or more brick folder(s).

Example:

The folder structure you might create:

bricks/custom/my-custom-field
bricks/custom/my-custom-function

Then in bricks/custom/load.php you write something like this:

require_once __DIR__ . DS . 'my-custom-field/my-custom-field.php'
require_once __DIR__ . DS . 'my-custom-function/lib.php'

A bit of documentation around it is here (not much): https://github.com/jenstornell/kirby-bricks/blob/master/docs/files.md#loadphp

[carstengrimm]

well. 100 templates are overexaggerated. but they can easily add up quite quickly depending on the content. this was my main point on trying out bricks since my template / controller / blueprint folder was loaded with files and i have had issues browsing though them when making changes.

an example for that is having a blog:

• blog/template.php
• blog.content/template.php

while these are only two templates / bricks, it could contain 100’s if not thousands of pages as you describe having only 4 bricks in total…

i then have a few other templates for other contents like:

• shop (1 page)
• shop.category (a few pages)
• shop.product (a few more pages)
• shop.checkout (1 page)
• shop.order (a few pages)
• shop.orders (list) (one page)
  and others for content depending on the content obviously. within the bricks folder i have stored 31 bricks without “sites, default, error and a few others which are less common used”

it’s not negative feedback just saying transitioning is alot of work. if creating a new project with plainkit and using bricks right away it’s not a big deal i guess.

at least everything works just fine for now.