We have a site with a members area where users can edit content in the frontend. It’s based on Uniform using a custom action to create and update pages.
Until recently, we were passing data to checkboxes fields as arrays and they were correctly converted to a comma-separated list in the content file just fine. But something changed in one of the recent updates in June/July: updating existing pages still works just fine but if a user creates a new page from the frontend using $parent->createChild($data) checkboxes are stored in YAML array syntax.
Before we got this:
----
Categories: one, two, three
----
Now we get this on page creation:
----
Categories:
- one
- two
- three
----
This causes trouble when filtering pages based on the categories because the storage format is inconsistent and cannot be split easily anymore.
Is anybody aware of a change in the core that might have caused this behaviour?
To clarify the situation, creating a pages on the frontend (wrongly) stores in YAML format, updating the same page from the frontend again stores the content comma-separated again. So $parent->createPage() and $page->update() seem to parse input data differently. And I don’t know why.
I looked into it and it seems to be a real v5 regression (introduced already with 5.0.0):
Passing a checkboxes value as an array to $parent->createChild(['content' => [...]]) writes YAML list syntax to the content file, while the same array through $page->update() writes one, two, three.
Kirby 4 ran the create payload through the form layer. Kirby 5 removed that pass and replaced it with a plain array merge. The Form moved into the Panel Kirby\Panel\PageCreateDialog::sanitize() - which is probably why it hasn’t come up before yet.
Created an issue: `Page::create()` does not apply field save handlers · Issue #8411 · getkirby/kirby · GitHub
Oh, wow, I didn’t expect that. Thanks for the Github issue!
@distantnative Do you have an idea how we could work around this on our end for now?