[6.x] Small PHP CP performance improvements and UTF-8 fix by jasonvarga · Pull Request #15254 · statamic/cms

jasonvarga · 2026-08-24T16:57:30Z

Split out of #15158.

Skip encoding detection when the relationship config is already UTF-8

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. Checking mb_check_encoding() first skips it in the normal case.

It's also a bug fix. That detection list could misdetect valid UTF-8 as some other encoding and mangle it, so a config whose only multibyte content was emoji came back as Cyrillic mojibake — {"display":"😀👍"} became {"display":"ЁЯШАЁЯСН"}. Taking the fast path leaves it alone. The original conversion stays as the fallback for genuinely non-UTF-8 input (#566).

Avoid resolving fields twice in `Fields::newInstance()`

setItems() resolves every item into a Field object, and the very next call in the chain, setFields(), immediately discarded that work. Assigning the items directly skips it.

Memoize relationship item lookups

getItemData() looked each id up twice, once in authorizeItemData() and again in toItemArray(). Caching the found item on the instance halves that. Roughly 24% off getItemData() for a 50-item relationship field.

The cache is reset in __clone(), because the fieldtype repository hands out clones of a single instance per handle. Without that, the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected: the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. That's ~9.6us per request, and it can misdetect perfectly valid UTF-8 as another encoding and corrupt it — a config containing only emoji came back as Cyrillic mojibake. Checking mb_check_encoding() first skips the detection entirely for valid UTF-8, which is the normal case, and leaves the existing conversion in place as the fallback for genuinely non-UTF-8 input.

setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

getItemData() looked each id up twice — once in authorizeItemData() to check the user can view it, and again in toItemArray() to build the response. Caching the found item on the instance halves the lookups. The cache is reset in __clone(), since the fieldtype repository hands out clones of a single instance per handle. Without it the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected — the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

Assigning the collection directly left both instances sharing one collection object, where setItems() would have given the new instance its own. Nothing in core mutates it in place, but addons can subclass Fields and reach it through items(), and a clone costs one allocation against the resolveFields() call we're skipping. Note this is shallow, matching what setItems() did — items can contain validation rule objects, and those stay shared either way.

jasonvarga · 2026-08-24T16:57:30Z

Split out of #15158.

Skip encoding detection when the relationship config is already UTF-8

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. Checking mb_check_encoding() first skips it in the normal case.

It's also a bug fix. That detection list could misdetect valid UTF-8 as some other encoding and mangle it, so a config whose only multibyte content was emoji came back as Cyrillic mojibake — {"display":"😀👍"} became {"display":"ЁЯШАЁЯСН"}. Taking the fast path leaves it alone. The original conversion stays as the fallback for genuinely non-UTF-8 input (#566).

Avoid resolving fields twice in `Fields::newInstance()`

setItems() resolves every item into a Field object, and the very next call in the chain, setFields(), immediately discarded that work. Assigning the items directly skips it.

Memoize relationship item lookups

getItemData() looked each id up twice, once in authorizeItemData() and again in toItemArray(). Caching the found item on the instance halves that. Roughly 24% off getItemData() for a 50-item relationship field.

The cache is reset in __clone(), because the fieldtype repository hands out clones of a single instance per handle. Without that, the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected: the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. That's ~9.6us per request, and it can misdetect perfectly valid UTF-8 as another encoding and corrupt it — a config containing only emoji came back as Cyrillic mojibake. Checking mb_check_encoding() first skips the detection entirely for valid UTF-8, which is the normal case, and leaves the existing conversion in place as the fallback for genuinely non-UTF-8 input.

setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

getItemData() looked each id up twice — once in authorizeItemData() to check the user can view it, and again in toItemArray() to build the response. Caching the found item on the instance halves the lookups. The cache is reset in __clone(), since the fieldtype repository hands out clones of a single instance per handle. Without it the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected — the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

Assigning the collection directly left both instances sharing one collection object, where setItems() would have given the new instance its own. Nothing in core mutates it in place, but addons can subclass Fields and reach it through items(), and a clone costs one allocation against the resolveFields() call we're skipping. Note this is shallow, matching what setItems() did — items can contain validation rule objects, and those stay shared either way.

jasonvarga · 2026-08-24T16:57:30Z

Split out of #15158.

Skip encoding detection when the relationship config is already UTF-8

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. Checking mb_check_encoding() first skips it in the normal case.

It's also a bug fix. That detection list could misdetect valid UTF-8 as some other encoding and mangle it, so a config whose only multibyte content was emoji came back as Cyrillic mojibake — {"display":"😀👍"} became {"display":"ЁЯШАЁЯСН"}. Taking the fast path leaves it alone. The original conversion stays as the fallback for genuinely non-UTF-8 input (#566).

Avoid resolving fields twice in `Fields::newInstance()`

setItems() resolves every item into a Field object, and the very next call in the chain, setFields(), immediately discarded that work. Assigning the items directly skips it.

Memoize relationship item lookups

getItemData() looked each id up twice, once in authorizeItemData() and again in toItemArray(). Caching the found item on the instance halves that. Roughly 24% off getItemData() for a 50-item relationship field.

The cache is reset in __clone(), because the fieldtype repository hands out clones of a single instance per handle. Without that, the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected: the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. That's ~9.6us per request, and it can misdetect perfectly valid UTF-8 as another encoding and corrupt it — a config containing only emoji came back as Cyrillic mojibake. Checking mb_check_encoding() first skips the detection entirely for valid UTF-8, which is the normal case, and leaves the existing conversion in place as the fallback for genuinely non-UTF-8 input.

setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

getItemData() looked each id up twice — once in authorizeItemData() to check the user can view it, and again in toItemArray() to build the response. Caching the found item on the instance halves the lookups. The cache is reset in __clone(), since the fieldtype repository hands out clones of a single instance per handle. Without it the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected — the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

Assigning the collection directly left both instances sharing one collection object, where setItems() would have given the new instance its own. Nothing in core mutates it in place, but addons can subclass Fields and reach it through items(), and a clone costs one allocation against the resolveFields() call we're skipping. Note this is shallow, matching what setItems() did — items can contain validation rule objects, and those stay shared either way.

jasonvarga · 2026-08-24T16:57:30Z

Split out of #15158.

Skip encoding detection when the relationship config is already UTF-8

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. Checking mb_check_encoding() first skips it in the normal case.

It's also a bug fix. That detection list could misdetect valid UTF-8 as some other encoding and mangle it, so a config whose only multibyte content was emoji came back as Cyrillic mojibake — {"display":"😀👍"} became {"display":"ЁЯШАЁЯСН"}. Taking the fast path leaves it alone. The original conversion stays as the fallback for genuinely non-UTF-8 input (#566).

Avoid resolving fields twice in `Fields::newInstance()`

setItems() resolves every item into a Field object, and the very next call in the chain, setFields(), immediately discarded that work. Assigning the items directly skips it.

Memoize relationship item lookups

getItemData() looked each id up twice, once in authorizeItemData() and again in toItemArray(). Caching the found item on the instance halves that. Roughly 24% off getItemData() for a 50-item relationship field.

The cache is reset in __clone(), because the fieldtype repository hands out clones of a single instance per handle. Without that, the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected: the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. That's ~9.6us per request, and it can misdetect perfectly valid UTF-8 as another encoding and corrupt it — a config containing only emoji came back as Cyrillic mojibake. Checking mb_check_encoding() first skips the detection entirely for valid UTF-8, which is the normal case, and leaves the existing conversion in place as the fallback for genuinely non-UTF-8 input.

setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

getItemData() looked each id up twice — once in authorizeItemData() to check the user can view it, and again in toItemArray() to build the response. Caching the found item on the instance halves the lookups. The cache is reset in __clone(), since the fieldtype repository hands out clones of a single instance per handle. Without it the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected — the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

Assigning the collection directly left both instances sharing one collection object, where setItems() would have given the new instance its own. Nothing in core mutates it in place, but addons can subclass Fields and reach it through items(), and a clone costs one allocation against the resolveFields() call we're skipping. Note this is shallow, matching what setItems() did — items can contain validation rule objects, and those stay shared either way.

jasonvarga · 2026-08-24T16:57:30Z

Split out of #15158.

Skip encoding detection when the relationship config is already UTF-8

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. Checking mb_check_encoding() first skips it in the normal case.

It's also a bug fix. That detection list could misdetect valid UTF-8 as some other encoding and mangle it, so a config whose only multibyte content was emoji came back as Cyrillic mojibake — {"display":"😀👍"} became {"display":"ЁЯШАЁЯСН"}. Taking the fast path leaves it alone. The original conversion stays as the fallback for genuinely non-UTF-8 input (#566).

Avoid resolving fields twice in `Fields::newInstance()`

setItems() resolves every item into a Field object, and the very next call in the chain, setFields(), immediately discarded that work. Assigning the items directly skips it.

Memoize relationship item lookups

getItemData() looked each id up twice, once in authorizeItemData() and again in toItemArray(). Caching the found item on the instance halves that. Roughly 24% off getItemData() for a 50-item relationship field.

The cache is reset in __clone(), because the fieldtype repository hands out clones of a single instance per handle. Without that, the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected: the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. That's ~9.6us per request, and it can misdetect perfectly valid UTF-8 as another encoding and corrupt it — a config containing only emoji came back as Cyrillic mojibake. Checking mb_check_encoding() first skips the detection entirely for valid UTF-8, which is the normal case, and leaves the existing conversion in place as the fallback for genuinely non-UTF-8 input.

setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

getItemData() looked each id up twice — once in authorizeItemData() to check the user can view it, and again in toItemArray() to build the response. Caching the found item on the instance halves the lookups. The cache is reset in __clone(), since the fieldtype repository hands out clones of a single instance per handle. Without it the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected — the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

Assigning the collection directly left both instances sharing one collection object, where setItems() would have given the new instance its own. Nothing in core mutates it in place, but addons can subclass Fields and reach it through items(), and a clone costs one allocation against the resolveFields() call we're skipping. Note this is shallow, matching what setItems() did — items can contain validation rule objects, and those stay shared either way.

jasonvarga · 2026-08-24T16:57:30Z

Split out of #15158.

Skip encoding detection when the relationship config is already UTF-8

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. Checking mb_check_encoding() first skips it in the normal case.

It's also a bug fix. That detection list could misdetect valid UTF-8 as some other encoding and mangle it, so a config whose only multibyte content was emoji came back as Cyrillic mojibake — {"display":"😀👍"} became {"display":"ЁЯШАЁЯСН"}. Taking the fast path leaves it alone. The original conversion stays as the fallback for genuinely non-UTF-8 input (#566).

Avoid resolving fields twice in `Fields::newInstance()`

setItems() resolves every item into a Field object, and the very next call in the chain, setFields(), immediately discarded that work. Assigning the items directly skips it.

Memoize relationship item lookups

getItemData() looked each id up twice, once in authorizeItemData() and again in toItemArray(). Caching the found item on the instance halves that. Roughly 24% off getItemData() for a 50-item relationship field.

The cache is reset in __clone(), because the fieldtype repository hands out clones of a single instance per handle. Without that, the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected: the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. That's ~9.6us per request, and it can misdetect perfectly valid UTF-8 as another encoding and corrupt it — a config containing only emoji came back as Cyrillic mojibake. Checking mb_check_encoding() first skips the detection entirely for valid UTF-8, which is the normal case, and leaves the existing conversion in place as the fallback for genuinely non-UTF-8 input.

setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

getItemData() looked each id up twice — once in authorizeItemData() to check the user can view it, and again in toItemArray() to build the response. Caching the found item on the instance halves the lookups. The cache is reset in __clone(), since the fieldtype repository hands out clones of a single instance per handle. Without it the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected — the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

Assigning the collection directly left both instances sharing one collection object, where setItems() would have given the new instance its own. Nothing in core mutates it in place, but addons can subclass Fields and reach it through items(), and a clone costs one allocation against the resolveFields() call we're skipping. Note this is shallow, matching what setItems() did — items can contain validation rule objects, and those stay shared either way.

jasonvarga · 2026-08-24T16:57:30Z

Split out of #15158.

Skip encoding detection when the relationship config is already UTF-8

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. Checking mb_check_encoding() first skips it in the normal case.

It's also a bug fix. That detection list could misdetect valid UTF-8 as some other encoding and mangle it, so a config whose only multibyte content was emoji came back as Cyrillic mojibake — {"display":"😀👍"} became {"display":"ЁЯШАЁЯСН"}. Taking the fast path leaves it alone. The original conversion stays as the fallback for genuinely non-UTF-8 input (#566).

Avoid resolving fields twice in `Fields::newInstance()`

setItems() resolves every item into a Field object, and the very next call in the chain, setFields(), immediately discarded that work. Assigning the items directly skips it.

Memoize relationship item lookups

getItemData() looked each id up twice, once in authorizeItemData() and again in toItemArray(). Caching the found item on the instance halves that. Roughly 24% off getItemData() for a 50-item relationship field.

The cache is reset in __clone(), because the fieldtype repository hands out clones of a single instance per handle. Without that, the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected: the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. That's ~9.6us per request, and it can misdetect perfectly valid UTF-8 as another encoding and corrupt it — a config containing only emoji came back as Cyrillic mojibake. Checking mb_check_encoding() first skips the detection entirely for valid UTF-8, which is the normal case, and leaves the existing conversion in place as the fallback for genuinely non-UTF-8 input.

setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

getItemData() looked each id up twice — once in authorizeItemData() to check the user can view it, and again in toItemArray() to build the response. Caching the found item on the instance halves the lookups. The cache is reset in __clone(), since the fieldtype repository hands out clones of a single instance per handle. Without it the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected — the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

Assigning the collection directly left both instances sharing one collection object, where setItems() would have given the new instance its own. Nothing in core mutates it in place, but addons can subclass Fields and reach it through items(), and a clone costs one allocation against the resolveFields() call we're skipping. Note this is shallow, matching what setItems() did — items can contain validation rule objects, and those stay shared either way.

jasonvarga · 2026-08-24T16:57:30Z

Split out of #15158.

Skip encoding detection when the relationship config is already UTF-8

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. Checking mb_check_encoding() first skips it in the normal case.

It's also a bug fix. That detection list could misdetect valid UTF-8 as some other encoding and mangle it, so a config whose only multibyte content was emoji came back as Cyrillic mojibake — {"display":"😀👍"} became {"display":"ЁЯШАЁЯСН"}. Taking the fast path leaves it alone. The original conversion stays as the fallback for genuinely non-UTF-8 input (#566).

Avoid resolving fields twice in `Fields::newInstance()`

setItems() resolves every item into a Field object, and the very next call in the chain, setFields(), immediately discarded that work. Assigning the items directly skips it.

Memoize relationship item lookups

getItemData() looked each id up twice, once in authorizeItemData() and again in toItemArray(). Caching the found item on the instance halves that. Roughly 24% off getItemData() for a 50-item relationship field.

The cache is reset in __clone(), because the fieldtype repository hands out clones of a single instance per handle. Without that, the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected: the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

The base64-encoded fieldtype config was always run through mb_convert_encoding() with the full mb_list_encodings() detection list. That's ~9.6us per request, and it can misdetect perfectly valid UTF-8 as another encoding and corrupt it — a config containing only emoji came back as Cyrillic mojibake. Checking mb_check_encoding() first skips the detection entirely for valid UTF-8, which is the normal case, and leaves the existing conversion in place as the fallback for genuinely non-UTF-8 input.

setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

getItemData() looked each id up twice — once in authorizeItemData() to check the user can view it, and again in toItemArray() to build the response. Caching the found item on the instance halves the lookups. The cache is reset in __clone(), since the fieldtype repository hands out clones of a single instance per handle. Without it the first consumer's lookups get baked into the shared instance and inherited by every unrelated field of the same type. Authorization is unaffected — the cache holds the item, not a decision, so authorizeViewable() still runs on every call.

Assigning the collection directly left both instances sharing one collection object, where setItems() would have given the new instance its own. Nothing in core mutates it in place, but addons can subclass Fields and reach it through items(), and a clone costs one allocation against the resolveFields() call we're skipping. Note this is shallow, matching what setItems() did — items can contain validation rule objects, and those stay shared either way.

jasonvarga added 4 commits August 24, 2026 12:41

Avoid resolving fields twice in Fields::newInstance()
d99e9a5
setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

jasonvarga merged commit 30e0aaf into 6.xAug 24, 2026
64 checks passed

jasonvarga deleted the cp-php-perf branch August 24, 2026 18:00

jasonvarga added 4 commits August 24, 2026 12:41

Avoid resolving fields twice in Fields::newInstance()
d99e9a5
setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

jasonvarga merged commit 30e0aaf into 6.xAug 24, 2026
64 checks passed

jasonvarga deleted the cp-php-perf branch August 24, 2026 18:00

jasonvarga added 4 commits August 24, 2026 12:41

Avoid resolving fields twice in Fields::newInstance()
d99e9a5
setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

jasonvarga merged commit 30e0aaf into 6.xAug 24, 2026
64 checks passed

jasonvarga deleted the cp-php-perf branch August 24, 2026 18:00

jasonvarga added 4 commits August 24, 2026 12:41

Avoid resolving fields twice in Fields::newInstance()
d99e9a5
setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

jasonvarga merged commit 30e0aaf into 6.xAug 24, 2026
64 checks passed

jasonvarga deleted the cp-php-perf branch August 24, 2026 18:00

jasonvarga added 4 commits August 24, 2026 12:41

Avoid resolving fields twice in Fields::newInstance()
d99e9a5
setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

jasonvarga merged commit 30e0aaf into 6.xAug 24, 2026
64 checks passed

jasonvarga deleted the cp-php-perf branch August 24, 2026 18:00

jasonvarga added 4 commits August 24, 2026 12:41

Avoid resolving fields twice in Fields::newInstance()
d99e9a5
setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

jasonvarga merged commit 30e0aaf into 6.xAug 24, 2026
64 checks passed

jasonvarga deleted the cp-php-perf branch August 24, 2026 18:00

jasonvarga added 4 commits August 24, 2026 12:41

Avoid resolving fields twice in Fields::newInstance()
d99e9a5
setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

jasonvarga merged commit 30e0aaf into 6.xAug 24, 2026
64 checks passed

jasonvarga deleted the cp-php-perf branch August 24, 2026 18:00

jasonvarga added 4 commits August 24, 2026 12:41

Avoid resolving fields twice in Fields::newInstance()
d99e9a5
setItems() resolves every field into a Field object, and the very next call in the chain, setFields(), immediately threw that work away. Assigning the items directly skips the wasted resolution.

jasonvarga merged commit 30e0aaf into 6.xAug 24, 2026
64 checks passed

jasonvarga deleted the cp-php-perf branch August 24, 2026 18:00

Uh oh!

Uh oh!

Conversation

jasonvarga commented Aug 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Skip encoding detection when the relationship config is already UTF-8

Avoid resolving fields twice in Fields::newInstance()

Memoize relationship item lookups

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

jasonvarga commented Aug 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Skip encoding detection when the relationship config is already UTF-8

Avoid resolving fields twice in Fields::newInstance()

Memoize relationship item lookups

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

jasonvarga commented Aug 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Skip encoding detection when the relationship config is already UTF-8

Avoid resolving fields twice in Fields::newInstance()

Memoize relationship item lookups

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

jasonvarga commented Aug 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Skip encoding detection when the relationship config is already UTF-8

Avoid resolving fields twice in Fields::newInstance()

Memoize relationship item lookups

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

jasonvarga commented Aug 24, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Skip encoding detection when the relationship config is already UTF-8

Avoid resolving fields twice in Fields::newInstance()

Memoize relationship item lookups

jasonvarga commented Aug 24, 2026•
edited
Loading

Avoid resolving fields twice in `Fields::newInstance()`

jasonvarga commented Aug 24, 2026•
edited
Loading

Avoid resolving fields twice in `Fields::newInstance()`

jasonvarga commented Aug 24, 2026•
edited
Loading

Avoid resolving fields twice in `Fields::newInstance()`

jasonvarga commented Aug 24, 2026•
edited
Loading

Avoid resolving fields twice in `Fields::newInstance()`

jasonvarga commented Aug 24, 2026•
edited
Loading

Avoid resolving fields twice in `Fields::newInstance()`

jasonvarga commented Aug 24, 2026•
edited
Loading

Avoid resolving fields twice in `Fields::newInstance()`

jasonvarga commented Aug 24, 2026•
edited
Loading

Avoid resolving fields twice in `Fields::newInstance()`