We'd like Graphql equivalent of #2626924: Include processed text in normalizations: "text" field type's "processed" computed property should be non-internal and carry cacheability metadata because we can't expect calling system to recreate Drupal filter pipeline.
Comments
Comment #2
fubhy commentedI've re-added the "renderedOutput" field for entities also with the option to use a view mode. Are you suggesting we should process every text field and run it through the filter or do you want to do that for all string properties in general?
Comment #3
wim leersYes. Well, not filter, but text format. (And I'm assuming you mean
\Drupal\text\Plugin\Field\FieldType\TextItem.)No, that wouldn't make any sense. The whole reason we need this, is because text formats. You can't let JS run text formats. Or you'd have to have JS reimplement all text format logic.
So: yes for
\Drupal\text\Plugin\Field\FieldType\TextItem, no for\Drupal\Core\Field\Plugin\Field\FieldType\StringItem.Comment #4
fubhy commentedRight, after checking the patch from the other issue that makes sense. I was thinkin in terms of string sanitization and couldn't check the patch because I was on the train. Yes, text formats make sense indeed.
Comment #5
wim leersThe patch at #2626924: Include processed text in normalizations: "text" field type's "processed" computed property should be non-internal and carry cacheability metadata is tantalizingly close to RTBC atm. Just needs dawehner's +1. So hopefully you'll soon have a reference implementation.
Comment #6
wim leersLet's just block this on #262924: which order to install modules? — that patch is very close at this point too :)
Comment #7
fubhy commentedWe just added a bunch of submodules that bring back automatic schema generation. Also includes rendered fields and is configurable.