Make the blueprint allow logic

Kirby 2 Suggestions đź’ˇ
1

Maybe it’s been suggested before but I see many reasons why it would be nice for the blueprint to have logic.

With logic I mean I could generate a blueprint with PHP, that it’s not read from a static yml file but from a PHP file that generates the yml data.

Then then panel would still parse the blueprint data as normal, just like a static file.

Maybe something like this:

Notice the php extension:

$kirby->set('blueprint', 'article', __DIR__ . '/blueprints/article.php');

If it’s a PHP file, run it. If it’s a YML file, read it.

Feedback?

2

I’m sure there’s a good reason why we don’t have logic in the blueprint yet and I’d love to hear it. It would be very powerful and very useful.

1 Like
3

I see your point, but as always: What is your use-case and which information would you like to use in the dynamic blueprints to decide on the blueprint options?

4

This is the case:

As far as I know the blueprints don’t handle logic at all. It would require to figure out a way to duplicate the fields automatically before the blueprint is loaded.

Another question. Is there a reason why you don’t seem to want to implement this feature? From my perspective it would not be that hard to code. Also, I’ve seen many requests of this feature, it’s not just me.

:slight_smile:

5

The problem with your approach is that you can’t have two fields with the same name in a single blueprint. So all fields that come afterwards with the same name will be ignored.

6

I forgot to mention. I’ll use a prefix for them.

7

You mentioned in your first post that you see many reasons. I’d love to hear more of these :slight_smile:.

I’m not so convinced that duplicating the fields is the best approach, actually.

8

Another thing that would be possible is to have file includes. Sometimes I have a lot of data in a blueprint that I need for other blueprints. I can use field definitions, but that’s just one file for each field setup. I mean includes for larger groups of data. Maybe you have another approach for that problem.

I really want to know this:

What is the reason to not implement a solution for allowing logic in the blueprints? What harm would it do?

Kirby often is great at open up possibilities. And with this feature I think it would create new possibilities that we can’t even think of yet.

9

Oh, I’m not saying we should not have logic, I can even remember that there was a time when I would have liked it myself, but I can’t remember why that was. Maybe it was includes, but half of the problem was solved with field definitions. Although I must admit that I’d love to have blocks of repeated fields myself. And it would probably be easier to extend such blocks with PHP logic.

1 Like
10

Logic would help with conditional rules I think
"if this page has children then display this"
“if this page has an rss representation then display this”

Or am I not seeing this straight?

1 Like
11

Yes. I had that in mind as well, but could not come up with a good enough example of it quickly that makes sense.

Your examples are good enough I think. :slight_smile:

12

I’m not sure, because a blueprint is usually mainly static. Otherwise you would have to have as many conditions in your templates/controllers as there are possible options in your blueprint. In such cases, it probably makes more sense to use different blueprint/template combinations?

13

It’s kind of specific to some scenario.
If you have projects with individual pages and some of this projects can have also subpages. If you want to add a select field on the page to pick which subpages to display only if there are subpages, it makes sense. And in your template, if something is selected in that field display it. Otherwise continue.

I generally agree with Jens on this. It’s amazing how the flexibility given by Kirby has opened doors that were unthought off. Developers given some flexibility will always push the boundaries of what was thought feasible. I’m sure introducing flexibility in the blueprints would lead to even more awesome use cases we would never think off. For me the biggest benefit today would be to include groups of fields.

1 Like
14

The main issue I see with dynamic blueprints is that they may change in between one edit operation.

Depending on your logic, you might get into a situation where the user gets a specific form, fills it out and some fields are then changed or removed again when saving (for example if the fields depend on other pages). This leads to data loss.
Sure, if you are careful and only use logic that won’t change, this will be fine. But every feature we implement must be foolproof, otherwise people are going to have a lot of issues with it.

2 Likes
15

Alright. Then I understand your point of view. I can see the risk of this kind of behavior, but I guess the risk is on the site developer, not on the Kirby crew?

If the risk is on the site developer, it does not need to be foolproof? I mean, we developers does wrong things all the time. That’s often how we learn. You can’t stop us from doing wrong.

Or do you think this would add more support on your shoulders? If you are given these choices what would you choose?

  1. You think it’s a good idea but the plan for it has to be well planned and that takes time.
  2. You think it’s a bad idea in general and don’t want it… ever.
16

Yes. It will make the Panel behave strangely in edge cases and finding the issue will become much harder.

Both. :slight_smile:
We’ll keep this suggestion open in case someone has a great idea, but for now, we won’t be able to implement it in a solid way.

17

I started using mustache to generate blueprints - if thats what you’re missing I could share my gulptask for that (it’s really not complciated)

Another thing that we have is https://github.com/medienbaecker/kirby-fieldtoggle

which you can use to do “logic” - you can probably even improve on it to make it related to things like checkboxes and empty fields etc etc - shouldn’t be too hard…

Or are there more complex use cases for this than those two things?