PR #97 hoisted the getSchema call out of the per-item loop in sanitise() on the basis that getSchema is idempotent for a given schemaName. That holds for the base AbstractApiModule.getSchema but not for subclasses that override it to dispatch on the data argument — notably ContentModule.getSchema, which returns a different schema per content type / _component / enabled-plugin set.
With the hoisted call, ContentModule.getSchema receives the array as its data argument, can't extract _component/_id/_type, falls back to the base content schema, and drops all component-specific and extension fields when sanitising GET responses. Concretely, GET /api/content/<componentId> for a graphic component returns only base fields — _graphic, _vanilla, _pageLevelProgress etc. are stripped, so the editor shows no asset thumbnail on revisit even though the data is in the database.
PR #97 hoisted the
getSchemacall out of the per-item loop insanitise()on the basis thatgetSchemais idempotent for a givenschemaName. That holds for the baseAbstractApiModule.getSchemabut not for subclasses that override it to dispatch on the data argument — notablyContentModule.getSchema, which returns a different schema per content type /_component/ enabled-plugin set.With the hoisted call,
ContentModule.getSchemareceives the array as itsdataargument, can't extract_component/_id/_type, falls back to the basecontentschema, and drops all component-specific and extension fields when sanitising GET responses. Concretely,GET /api/content/<componentId>for a graphic component returns only base fields —_graphic,_vanilla,_pageLevelProgressetc. are stripped, so the editor shows no asset thumbnail on revisit even though the data is in the database.