[Studio] Register CoreShop field types in the class definition editor

[dpfaffenbauer]

Closes #3260

Root cause

Studio keeps two registries per DataObject field type. CoreShop registered all its CoreExtension types only in DynamicTypes/ObjectDataRegistry (object editor) and never in DynamicTypes/FieldDefinitionRegistry (class definition editor), so LayoutForm fell through to "Type not supported" and the "add field" dropdown, which is built from the same registry via tags, had no CoreShop entries.

Class editor types

Every one of the 31 field types (the 29 from the issue plus coreShopRelation / coreShopRelations) gets a DynamicTypeFieldDefinitionCoreShop<Name> next to its object data type and is registered in each bundle's main.ts (IndexBundle: modules/filters/module.ts) via registerCoreShopFieldDefinitionTypes([...]), inside the same try/catch that already guards the object data registry for the document editor iframe. The types appear under a new "CoreShop" group in the dropdown (registerDropdownGroupInfo, registered idempotently via getDropdownGroupInfos() because every bundle calls it).

Base classes and bundle boundaries

• PimcoreBundle/.../dynamic-types/field-definitions/: DynamicTypeFieldDefinitionCoreShopAbstract (group, default icon, hides "unique"), group registration, registerCoreShopFieldDefinitionTypes(), shared WidthFormItem / HeightFormItem / MinMaxFormItems. Lives here because MoneyBundle, PimcoreBundle and ProductQuantityPriceRulesBundle do not depend on ResourceBundle. Money and ProductQuantityPriceRules get @coreshop/pimcore as npm dependency.
• ResourceBundle/.../dynamic-types/field-definitions/: ...CoreShopSelect (width, allowEmpty), ...CoreShopMultiselect (width, height, maxItems, renderType), ...CoreShopRelation / ...CoreShopRelations extending Pimcore's DynamicTypeFieldDefinitionManyToOne / ManyToMany with the resource stack select (options from the existing resource config endpoint) and returnConcrete.
• Plain resource selects (store, currency, country, state, carrier, payment provider, tax rate/rule group, cart price rule, filter, product unit, address identifier and the multiselect variants) are one-liners on those bases. Own forms for coreShopMoney (defaultValue, min/max, nullable), coreShopMoneyCurrency and coreShopStoreValues (width, min/max), coreShopProductUnitDefinitions (width), the two price rule types (height), coreShopSerializedData (no settings panel) and the four DynamicDropdown variants (folderName, className from the class definition API, methodName, sortBy, recursive, onlyPublished).

Form field names match the public properties of the PHP CoreExtension classes, since the class editor saves the raw field definition.

Translations and docs

field-definition.<kebab-case id> plus the .with-prefix.add / .with-prefix.convert variants Pimcore uses when a type is promoted to the dropdown root, en and de, in every bundle. New labels use coreshop_field_definition_*. New docs page docs/03_Development/14_Studio/02_Base_Infrastructure/06_Dynamic_Types.md (registries, base classes, registration, translations, type overview), linked from the Studio index; changelog entry under 5.1.3; CLAUDE.md section.

Test

• tsc --noEmit per affected bundle (14 bundles) against @pimcore/studio-ui-bundle 2025.4.13: 0 errors.
• npm run build (rsbuild / module federation): all bundles built. Build archives are not part of this PR, the frontend build workflow commits them.
• Not tested in a running Studio; please check that the "CoreShop" group shows all types and that saving an existing class keeps the type-specific values (allowEmpty, stack, ...).

Not in this PR

The same change for 2026.x follows via the automated upmerge (the branch applies cleanly there; the 2026.x tree only differs in the two package.json files).

[sonarqubecloud]

Quality Gate passed

Issues
10 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud