[5.x]: Inconsistent results per field type with @parseRefs directive in GraphQL (need @noParseRefs for ckeditor)

[humandevs]

What happened?

Description

When querying GraphQL, some field types require the @parseRefs directive while others (ckeditor) automatically parseRefs.

This causes problems when ReferenceTags need to be available to the front end application for additional logic handling such as scoped or conditional values.

I've also created an issue in the ckeditor plugin if avoiding automatically running parseRefs is better handled by the ckeditor plugin. craftcms/ckeditor#329

Steps to reproduce

1. Add a ReferenceTag to a text field and a ckeditor field, query them both via GraphQL without the @parseRefs directive
2. Note that the text field has not had the ReferenceTag parsed, while the ckeditor field has

Expected behavior

If parseRefs is going to be implicitly called on some field types and not others, there should be a @noParseRefs directive

Actual behavior

Some fields implictly parseRefs and others do not

Craft CMS version

5.5.4

PHP version

8.2

Operating system and version

Linux 6.8.0-48-generic

Database type and version

MySQL 8.0.40

Image driver and version

Imagick 3.7.0 (ImageMagick 6.9.12-98)

Installed plugins and versions

Amazon S3 2.2.1
Amazon SES 3.1.0
AsyncQueue 4.0.0
CKEditor 4.4.0
CP Field Inspect 2.0.2
Element API 4.1.0
Preparse 3.0.0-alpha.2
Scout 5.0.2

[brandonkelly]

CKEditor and Redactor are the only field types (that I know of) which use reference tags internally when storing data, which is why they also are automatically parsing their reference tags on retrieval.

It wouldn’t be possible to implement a @noParseRefs directive in Craft CMS, because the reference tags would have already been lost by the time the directive was invoked. That said, we should be able to address this specifically for CKEditor. I’ll follow up @ craftcms/ckeditor#329 on that.