[logmedia-openclaw]

Problem

Fixes #87 — ./bin/console dal:validate reports 8 errors in 4 entities on Shopware 6.7.14.

I reproduced each error against Shopware\Core\Framework\DataAbstractionLayer\DefinitionValidator (v6.7.14.0) and fixed all of them:

1. Primary key mismatch in entity werkl_blog_entry

ReferenceVersionField(cms_page_version_id) carried a PrimaryKey flag, but the table has PRIMARY KEY (id) only (the column was added later via ALTER TABLE and the PK was never extended). Removed the flag — same pattern as core's LandingPageDefinition (ReferenceVersionField(CmsPageDefinition) with Required + ApiAware only).

2. Field media in entity struct is missing in BlogEntryDefinition

Since the teaser image became translatable (1744229687), media_id lives in the translation table and BlogEntryEntity::$media is hydrated manually by BlogSubscriber::onBlogEntryLoaded() (which is why all storefront templates like entry.media.url keep working). The validator skips struct properties documented with @internal — that's exactly what this property is, so it is now documented that way instead of silently polluting the DAL field collection.

3. Missing reverse one-to-one association (cmsPage <-> CmsPageDefinition)

The reverse side is already provided by CmsPageExtension::blogEntries, which is a OneToManyAssociationField. OneToOne requires a OneToOne mirror, so the owning side was switched to ManyToOneAssociationField — the same direction core itself uses for product.cmsPage / landingPage.cmsPage. No schema change; the DAL read/write behaviour for a foreign-key-owned association is unchanged.

4. Setter setTags is nullable

to-many setters must not accept null (see OrderEntity::setTags()). Changed to setTags(TagCollection $tags). Nothing in the plugin passes null.

5. Missing reverse many-to-many association for BlogEntryDefinition.tags

• Added a TagExtension that mirrors core's own approach (TagDefinition declares a reverse ManyToManyAssociationField for every taggable entity, e.g. products, media, landingPages) — tag.blogEntries via werkl_blog_entry_tag with CascadeDelete.
• Additionally the tags association now references the already registered BlogEntryTagMappingDefinition class instead of the magic table-name string, consistent with the blogCategories association and core conventions (behaviour-identical, but statically checkable).

6–8. werkl_blog_entry_translation.title/slug and werkl_blog_category_translation.name are not nullable

Translated columns must be nullable so values can fall back through the language hierarchy (see core, e.g. category_translation.name is NULL although the definition field keeps its Required flag). Added migration Migration1789100000NullableTranslationColumns (MODIFY ... NULL); the Required flags on the definition fields stay as they are, matching core behaviour.

How tested

• Every check of DefinitionValidator involved in the 8 reported messages (validatePrimaryKeyConsistency, validateOneToOne, validateManyToMany, validateTranslatedColumnsAreNullable, findEntityNotices, validateSetterIsNotNull) was traced against the fix.
• Added tests/unit/Content/Blog/BlogEntryDefinitionTest.php covering all eight points (PK flags, association types/directions, mapping definition identity, reverse sides from both extensions, @internal media property, non-nullable setTags).
• CI (PHPUnit + shopware-cli extension validate) runs on this PR; local php -l and definition reflection checks pass.

Note for reviewers

The changelog entries are kept under a 5.3.1 heading; feel free to squash that into your next release version as usual.