The engineer field is born: https://github.com/jenstornell/field-engineer
The big benefit is that there is no modal which by itself has many benefits:
Planned: Unlimited nesting
style: table
style: items
I added some extra data. A textarea and some checkboxes:
What do you think?
I love it. This makes a lot of sense.
For style: table, where do you click to edit the rest of the fields? (long text, check it)
Thanks! 
I’m not sure what you mean. If you use style:table with a long text you need to scroll down a bit to edit the other fields. I think style:items is a better fit for long vertical fields.
Do I understand you correctly? Do you have another idea in mind?
I just added a screenshot of a “long” text. It pushes down the next row naturally.
(The UI here is a bit different, but the function is the same)
I guess my question is, how does style: table handle an entry with 10 fields?
Now I understand what you mean.
It’s like any html table. It will try to squeeze the fields in as good as it can. Ten fields/columns is probably too much for style:table. The fields are listed directly in Engineer, without the entry layer (that the structure field uses).
It could be possible to add a new feature to make an overflow-x: scroll if it’s a common need, with many fields in one row. Then the table would be scrollable left/right.
Okay, that makes sense. I originally thought your first two screenshots were showing the exact same data.
I should have thought of that. I have now added a sentence that says that there are some extra fields in the style:items example. I wanted to show that style: items is better suited for many fields, because you can add grids like width: 1/2 etc.
Sorry for the confusion.
I’ve started working on a new much bigger version, but in the meantime I release a minor version that just fixes some of the major bugs: https://github.com/jenstornell/field-engineer
Changelog
option: children
What do you want to see first in the next release of the plugin?
0 voters
Haha, none of the above, but validation 
It already have html5 validation. If you for example use type: number and write letters, it will prevent you from saving and the browser will tooltip you on which field is wrong.
Is it html5 validation you mean, or is it javascript validation you have in mind?
I actually mean using Kirby’s validation methods…
Ahh, that’s a tricky one, because I run everything on the client side. Maybe I will figure something out, but I don’t think it will be the in the next version. 
After much hard work it’s finally here, a new version of Kirby Engineer.
It’s a complete rewrite from 0.3 and you can create really complex field structures with this version.
Supports:
It’s now also possible to buy licenses, but be sure to try before you buy.
If you are experience any issues, please report them on Github (not in this forum). It makes it much easier to keep track of them.
Much more information on how to use this plugin is provided at Kirby Engineer.
Download from Github https://github.com/jenstornell/field-engineer
From the changelog:
In this example I show:
In case you want to try this setup, here is the blueprint for it. Just be sure to install the required fields first.
fields:
my_engineer:
type: engineer
fieldsets:
hero_images:
label: Hero + Images
fields:
hero:
label: Hero
type: hero
width: 1/3
images:
label: Images
type: images
width: 2/3
switch_quickselect:
label: Switch + Quickselect
fields:
switch:
label: Switch
type: switch
width: 1/2
quickselect:
label: Quickselect
type: quickselect
options: images
width: 1/2
Github: https://github.com/jenstornell/field-engineer
This release has a name and it’s called “Grid”.
The main reason for that is because sub engineer field now have support for width like width: 1/3.
From the changelog:
width can now be set to engineer fields.The above example as blueprint. Be aware, you need to install the Hero field plugin for it to work because that field is used in the example this time.
fields:
my_engineer:
type: engineer
fields:
wrapper:
label: Wrapper
type: engineer
width: 1/4
fields:
hero:
type: hero
text:
label: Time
type: time
Github: https://github.com/jenstornell/field-engineer
It might be a nag to answer the question “Do you really want to delete this entry?”, but it’s much safer, especially for people with butterfingers. It’s especially important for the Engineer field because removing an item will remove every sub item as well.
I clicked an item and on the trash icon (that will hide on delete):
I clicked on the parent and the trash icon. In this case the children will be removed as well:
It’s much easier now when you have the visual preview of what will be deleted.
If engineer.debug is enabled in the config it will register a set of blueprints that can be used for debugging. For you as a user it can be used as a inspiration to get started. So far there is just one blueprint and it will list all fields. Be aware that it only works for Kirby 2.5.2 because of a bug.
engineer.label.fallback is no longer available or needed.width from the previous version has been changed to rowWidth to not collide with the native width.From the changelog:
width option for rows is renamed rowWidth instead. It will make it more future proof and prevent collisions with width on the root of the engineer field.engineer.label.fallback is removed. No good reason for a label fallback.I was about to include support for the list field, but a last minute DOM bug with that field prevented me from support it with this release.
Github: https://github.com/jenstornell/field-engineer
After my vacation I’m back with a new version of this plugin.
Maybe I will remove the repeated labels in a later version, but for now they are still around a while longer.
This is how it looks like when you have saved the data. Just a nice table:
v0.9
style: table reimplemented.engineer.debug is on.style: table label issue fixed. Thanks Dreytac.v0.8
panel-fields.yml that tests all supported native fields built into the Panel.supported-fields.yml that tests custom made fields that are supported by Engineer.working-fields.yml that tests custom made fields that should work out of the box.grid.yml that tests width, rowWidth and buttons on multiple levels.nesting.yml that tests nesting on multiple levels.fieldsets.yml that tests fields, fieldsets and empty sets on multiple levels.options.yml that tests field options default, icon, readonly, help, placeholder and required.Hi!
I’m getting the following error in the backend-panel:
Parse error: syntax error, unexpected 'default' (T_DEFAULT), expecting identifier (T_STRING) in *X*/site/plugins/field-engineer/lib/presentation-array.php on line 52
Kirby Version: 2.5.8
Blueprint-code:
title: Projekt
pages: false
options:
template: false
status: true
url: false
delete: true
preview: false
files:
type:
- image
- video
fields:
my_engineer:
type: engineer
fields:
first:
label: Text
type: text
second:
label: Image
type: image
This also happens if there’s no field-engineer-call in the blueprint-code.
Do you have any advice?
Thanks!
Thanks, I’ll check that.