Don't use text_with_summary in Umami

Not sure where the schema error is coming from.

Think I found the issue. Had to use a new field name vs just "body"

Actually had to change a lot. This the route we will have to go other places since the "body" field is hardset to be text_with_summary.

I think this looks like a great idea, but now I also have a worry about us having a field called body and a field called field_body if someone tries to add a new field to a content type and uses the "reuse existing field" approach. Also if you create a new content type it will automatically get the body field added.

I guess people don't need to be creating new fields and content types, since this is a fully formed demo.

I wonder could we disable the default body field from the UI fully?

@markconroy there's a bit of a chicken and egg situation between this issue and other child issues of 🌱 [meta] Deprecate text_with_summary Active .

If we eventually remove the hard-coding of the 'body' field and make it uninstallable, then Umami would just be able to ignore it entirely.

If we want to keep the hard-coding of the 'body' field, then it might make sense to switch it to a standard text field for new installs, in which case this MR might not need to change anything.

Opened a META to track decisions 🌱 [Meta] Deprecate text_with_summary Active

I'm postponing this till we decide what to do with the body field.

Rebased and this is ready for review again.

Tested againsta 11.x.

LGTM.

===
Thanks to Code Enigma for sponsoring my time to work on this.

Had another look through this. I think the confusion between body vs. field_body is something a lot of real sites already have, and going to be less confusing than having the text summary widget which then never gets used. If we change how the body field works, we could eventually rename this again back to 'body' if we want to, or just leave it as is without the dormant body field.

Committed/pushed to 11.x, thanks!

catch → closed merge request !6868