When renaming a field on a content type that has content items, one can easily get a fatal error on the frontend.

While the change is propagated to existing items, some will have the old name, some the new name. Unless the template is edited to take both fields into account, errors will occur.

Options

Twig

The `field` functions, such as `ez_render_field`, `ez_is_field_empty`... could be improved to allow for those errors. They could warn that there is an error instead of throwing a fatal error.

Repository

Changes to content types could be stored by the repository so that the repository's developer experience is made smoother. For instance, when a field is renamed, both the old and new name would remain usable. That way, templates would not have to be changed immediately, and the impact on production would be leveraged.

Field type

A custom field type could be also be an option: when a field is renamed, a renamed_field field definition is added, related to the new name. It acts as a proxy to the new name, and warns that the field has been renamed.

As one of the problems is that existing content items are updated progressively, the repository could use that renamed field from the content type to either pick the new or old value, depending on the renaming state.