fec0cac557
* Delivery API: Generate typed OpenAPI schemas per content type
* Honour Delivery API allow/deny list in typed OpenAPI schemas
ContentTypeSchemaTransformer now filters DocumentTypes through
DeliveryApiSettings.IsAllowedContentType so document types blocked
by AllowedContentTypeAliases / DisallowedContentTypeAliases no longer
leak into the polymorphic union or discriminator mapping.
* Stop registering media derived types in the JSON resolver
ContentJsonTypeResolverBase.GetDerivedTypes goes back to returning
empty. Previously it registered ApiMediaWithCrops and
ApiMediaWithCropsResponse as derived types of their interfaces, which
made every consumer of the resolver (the Delivery API and webhooks)
emit a $type discriminator on media payloads, even when the typed
schema feature was disabled.
The Delivery API still needs a base schema for the typed media
schemas to extend via allOf. Since the concrete media classes are
internal to Umbraco.Infrastructure and cannot be referenced from
[JsonDerivedType] in Core, ContentTypeSchemaTransformer now builds
that base from the interface's own properties when the interface has
no [JsonDerivedType] entries. Content/element interfaces are
unaffected and keep using their declared concrete derived types.
Snapshots regenerated.
* Drop default JsonDerivedType registrations from Delivery API interfaces
Removes the [JsonDerivedType] attributes from IApiContent,
IApiContentResponse, and IApiElement. Without them System.Text.Json
configures no polymorphism by default, so wire payloads stop carrying
$type fields and the OpenAPI spec stops emitting a discriminator on
the generic schemas - matching v17 Delivery API behaviour. Consumers
that need polymorphic serialization can still register derived types
via ContentJsonTypeResolverBase.
Snapshots regenerated.
* Allows nulls at property reference sites without mutating any shared component schema.
Avoid unnecessary re-get of the JsonTypeInfo for the default case.
* Updated expected contracts following code adjustments
* Drop additionalProperties: false from typed schemas
JSON Schema 2020-12 (mandated by OpenAPI 3.1) does not let additionalProperties look through allOf, so a strict validator rejects every inherited field on the composed *ResponseModel/*Model/*PropertiesModel schemas. Most code generators silently ignore it, but the document is technically invalid and the constraint would be a lie anyway since Umbraco can grow new properties in non-major releases.
Removed from all four schema construction sites (response, content type, properties, and the interface-based fallback) and regenerated the affected snapshots.
* Preserve casing of content type aliases in OpenAPI schema IDs
Replaces the legacy ModelsBuilder-style ToCleanString tokenizer with
ToFirstUpperInvariant. The tokenizer split aliases on case boundaries
and mangled capital-letter runs (e.g. "xMLSitemap" -> "XMlsitemap"),
making the typed schema names harder to read for OpenAPI consumers.
Since content type aliases are already valid identifiers, only the
first character needs uppercasing.
Also adds an "xMLSitemap" sample type to the integration tests to
cover the casing-preservation behavior.
* Qualify properties model schema IDs by item type
Document, element, and media types share the same alias namespace
across content/media (a doc-type and a media-type can use the same
alias), so a "{Schema}PropertiesModel" naming scheme could collide.
Properties model schemas now follow the same Content/Element/Media
suffix as their parent *Model schema:
- Document type: ArticlePageContentPropertiesModel
- Element type: TestElementElementPropertiesModel
- Media type: VideoMediaPropertiesModel
Composition references look up each composition's own IsElement so
that a doc-type composing an element-type (allowed in the UI) still
references the correct ElementPropertiesModel schema.
---------
Co-authored-by: Andy Butland <abutland73@gmail.com>
Umbraco CMS
Umbraco is a free and open source .NET content management system. Our mission is to help you deliver delightful digital experiences by making Umbraco friendly, simpler and social.
Learn more at umbraco.com
Looking to install Umbraco?
You can get started using the following commands on Windows, Linux and MacOS (after installing the .NET Runtime and SDK):
dotnet new install Umbraco.Templates
dotnet new umbraco --name MyProject
cd MyProject
dotnet run
Documentation
Our comprehensive documentation takes you from the fundamentals on how to start with Umbraco to deploying it to production.
Some important documentation links to get you started:
- Installing Umbraco CMS
- Getting to know Umbraco
- Tutorials for creating a basic website and customizing the editing experience
Backoffice Preview
Want to see the latest backoffice UI in action? Check out our live preview:
This preview is automatically deployed from the main branch and showcases the latest backoffice features and improvements. It runs from mock data and persistent edits are not supported.
Get help
If you need a bit of feedback while building your Umbraco projects, we are chatty on Discord. Our Discord server serves as a social space for all Umbracians. If you have any questions or need some help with a problem, head over to our dedicated forum where the Umbraco Community will be happy to help.
Looking to contribute back to Umbraco?
You came to the right place! Our GitHub repository is available for all kinds of contributions:
Umbraco is contribution-focused and community-driven. If you want to contribute back to the Umbraco source code, please check out our guide to contributing.