Improve the unsupported field guard

[nikosdion]

Currently, if there is any field of an unsupported field type in the category an article is in, the unsupported field guard prevents it from being published. The only option we're given is to go back, copy the text, and paste it manually into Joomla.

There is a fairly good reason for this. We do not communicate the values for unsupported field types which would make the Joomla API to delete their values. As far as I can tell, the Joomla Web Services API violates RFC 5789 by having PATCH act as a PUT. But I digress.

The way we handle it in Grafida is technically correct, but user-hostile. There are several use cases where this makes no sense.

It would make more sense to update the unsupported field guard to give the user an option:

• Cancel. Go back to the article editor to copy the text manually. Same as the current behavior.
• Publish Anyway. Ignore the unsupported fields, proceeding with publishing.

This is not an unconditional button addition, though. To make it valuable to the user, we need to make it conditional, as well as ensuring that we can convey existing fields' values.

For this to work properly, when creating a local draft from a live article we need to cache the values of all media fields including unsupported ones. This allows us to push those values to the site. Therefore, the Publish Anyway button can be implemented in this case.

For new articles which do not have any values for the unsupported fields we need to evaluate whether the unsupported fields are required (straight up required, or inside a subform field that's itself required). If they're required, we cannot offer the Publish Anyway option (gray it out) notifying the user that some of the unsupported fields are required, therefore Joomla would reject publishing the article.

Finally, we should fully expect an article Publish to fail because of a required field that's not part of what we have in Grafida. It could be that a field was added, renamed, or made required between us last updating the field metadata and the user hitting Publish in Grafida.

[nikosdion]

Implemented in d7ae8c8.

What was built

The guard now distinguishes two situations instead of one. FieldSupport::requiredUnsupported() splits the required fields of a type Grafida cannot edit by whether the draft holds a value for them:

• blocking — nothing we could send. PublishBlockedException with canForce() === false; the dialog offers Copy article HTML only, with Publish anyway rendered disabled (rather than omitted — an absent button reads as "this build cannot do it" instead of "not for this article"), and a line saying why.
• overridable — the draft carries the value read off the site. canForce() is true, and a retry (POST /api/drafts/{id}/publish with {"force": true}) sends those values back verbatim.

Editing a site article now imports its custom field values, unsupported types included. ArticleController::remoteFieldValues() reads them off the article resource — com_content's JsonapiView::prepareItem() puts each field on the item as a top-level attribute named after the field ($field->apivalue ?? $field->rawvalue), which is where they were all along; Grafida just was not looking. Holding them is what makes "Publish anyway" possible at all.

A rejected publish now explains itself. Joomla answering 400 gets its own dialog: the site's own message verbatim (it names the offending field — nothing else identifies it) plus a Reload metadata button.

Where this diverged from the description

1. "We do not communicate the values for unsupported field types which would make the Joomla API delete their values" — this turns out not to be true, and the design changed accordingly.

Verified against the 5.4 source. Two separate mechanisms, and they behave differently:

• plg_system_fields::onContentAfterSave() falls back to $field->rawvalue for any field name missing from $data['com_fields'], so the site keeps what it had. The blanking we were guarding against — $data->com_fields[$name] = false, which becomes null and deletes the value — lives in onContentNormaliseRequestData, and only FormController::save() fires that event. ApiController::save() never does.
• What does bite is validation: ApiController::save() runs $model->validate($form, $data), and FormField::validate() rejects a required field whose value is ''/null, including one simply absent from the posted data. plg_fields_*::onCustomFieldsPrepareDom() sets required="true" on the form node, so a required custom field is validated exactly like a core one. The PATCH backfill does not rescue it — save() backfills real #__content table columns, and com_fields is not one.

So the guard is justified precisely where it fires (required only), and the consequence for this issue is that only the required unsupported fields are ever carried on a forced publish. Sending the optional ones too would have been a regression, not a courtesy: leaving them out preserves the site's value, whereas sending them overwrites it with whatever snapshot we took when the article was imported.

2. Subform members needed no special case. The description asks to check whether an unsupported field is "straight up required, or inside a subform field that's itself required". The second half is already covered: subform is itself an unsupported type, so a required one is caught by the ordinary check, and its member fields are assigned -1 ("Only Use In Subform") and dropped by FieldCategoryScope before the guard ever sees them.

3. Multi-valued list fields are deliberately not imported. list/radio/checkboxes are the only plugins defining an apivalue, and it is a stored value → label map whose keys are what can be written back. checkboxes keeps them all, but list/radio render as a single select here — so a field the site reports more than one value for is skipped rather than truncated. An empty sidebar control is harmless (an omitted key leaves the site's value alone); keeping the first of several and saving would have silently dropped the rest.

4. The confirmation is not ceremony, and the wording says so. Grafida cannot render these values, so it cannot show that its copy has gone stale on the site since the article was imported. That is the stated reason in the dialog and in the documentation, and it is why this is a confirmed action rather than an automatic re-send.

Coverage

New: PublishServiceUnsupportedFieldsTest (6 cases — blocking vs. overridable, one blocking field poisoning an otherwise forceable publish, optional fields never sent, empty imported value not counting as a value) and FieldSupportTest (5, pinning the emptiness rule — '0' is a value, ''/null/[] are not). ArticleRoutingTest gained a case pinning the field-value import including the apivalue key handling. 386 unit + 138 feature + 115 JS tests pass, PHPStan clean.

Documentation updated in the same commit: docs/Editing-Articles.md (both the "custom fields Grafida cannot edit" section and the publishing section), CHANGELOG, CLAUDE.md, four .claude/rules/* files, all seven language catalogues and the six glossaries.