Constructing ad-hoc FieldLayout from config vs referencing saved FieldLayout records

[michaelrog]

Instantiating ad-hoc field layouts via FieldLayout::createFromConfig() is super easy.

And, conveniently the field layout editor submits its data already formatted as a 'config' blob.

With that in mind — if I'm developing a custom component that provides a field layout — Is it a bad practice to just store a config in the SavableComponent settings and construct the FieldLayout on-demand from that saved config?

As far as I know, all the native components take care to save the FieldLayout record(s) separately in the db, reference them by ID, and handle updating them through Project Config. BUT... It seems like I can get away with not going through that more involved process, and everything still works fine.

The possible downsides I can imagine, using this ad-hoc approach, include:

• I don't get help from the db (fks) to automatically remove a field from extant layouts upon deletion.
• The layout config looks a lot messier stored as a giant associative array in Project Config, as opposed to the nicely-formatted structure of other natively-saved layouts.

However, all these downsides seem more aesthetic than functional, at least on first pass. For example, the FieldLayout will calmly skip over any field that doesn't actually exist (e.g. on that has been deleted since the config was saved). And, other savable components include big ugly associative arrays in their Project Config sometimes, so is it really that bad?

• Does this ad-hoc approach actually work as trivially as I think it does?
• Is this an intended/advisable option for implementation?
• What am I missing? (especially gotchas I'm likely to encounter further down the road)

[brandonkelly]

Yeah should be totally fine.

I don't get help from the db (fks) to automatically remove a field from extant layouts upon deletion.

The fieldlayoutfields table is hardly even used anymore. Really just there to aid older field layouts that haven’t been saved since before Craft 3.5. So this isn’t a big deal.

[brandonkelly]

Have you tried this?

$fieldLayout = FieldLayout::createFromConfig($config);
$fieldLayout->type = Link::class;

[michaelrog]

Yeah — but EVENT_DEFINE_NATIVE_FIELDS gets fired from inside of setTabs(), so assigning the type after createFromConfig() doesn't currently work for registering native fields.

[brandonkelly]

Ah, ok. This should work then:

$config = ['type' => Link::class] + $config;
$fieldLayout = FieldLayout::createFromConfig($config);

[michaelrog]

Ah, ok. This should work then:

$config = ['type' => Link::class] + $config;
$fieldLayout = FieldLayout::createFromConfig($config);

Great — That's how I'd expect it to work, also. Alas, as currently implemented, createFromConfig() instantiates tabs using $config['tabs'] and ignores all other properties in the $config.

Created an issue: #11929

I'll try to pop over a PR to fix that. 👍🏼

[michaelrog]

heh you're too fast. 😅 Thank you!!!