The field is required from a content perspective (and is correctly required on the page type) - without it, the page renders incorrectly.
It should be noted that this is UI validation-only. It isn't a database level required because linked content items are represented as a JSON array of identifiers pointing to other content items. There are no database-level constraints on this type of JSON data.
This is relevant when considering that the linked content item can be deleted and the linking item won't be updated. However, the marketer will be notified that the item being deleted is in use and deleting it could have unintended effects.
However, this dialog is optional - editors can dismiss it and publish the parent page anyway, leaving the linked image unpublished
Yes, and this dialog should be optional. Deciding to publish linked items is a marketing strategy decision, not a platform behavior one. Consider these scenarios.
- A new version of the linked image is created, with a new product image file, alt text, and tags. The new version will be published next week with updates to other products, but in the meantime the product web page needs its changes published now.
- The web page image field allows linking to multiple images and the linked images are in various states of publishing - new draft, existing but unpublished draft, and published. The cascade publish dialog for a web page will show the new draft and existing but unpublished draft items can be published along with the web page. Maybe the marketing team wants to publish the web page, which will show the linked items that are published but won't display the unpublished new draft or unpublished changes of the existing images. If no images are selected or in a published state, a system fallback image is displayed instead.
- One of the linked images isn't deleted, but it is temporarily unpublished while the marketing team quickly fixes some of the messaging that is confusing customers.
I'm sure there are other scenarios where multiple content types various combinations of validation but the team expects different rendering behavior when linked items are missing or are unpublished.
We're currently handling this defensively in the frontend (graceful null handling)
This is the correct approach. Because developers are not in control of content and content models often need to be flexible to handle content in various states of editing and publishing, modeling content could be missing in code is a good way to represent reality.