[6.x] Fix global variable references not resolving through the data repository

[lazerg]

Global variable references use a globals:: prefix, but only the singular global repository was registered, so the reference fell through and got tried against every repository including entries, which throws an invalid ID error on database drivers (for example when adding a set to a Replicator inside a global set). This registers the globals prefix against the global variables repository so the reference resolves correctly.

Fixesstatamic/eloquent-driver#537

[grantholle]

Is this all it needs 😭

I've been unable to upgrade to Laravel 13 because of this, since I haven't been able to upgrade to v6...

[lazerg]

Yep, that's the whole fix. @jasonvarga mind taking a look when you get a chance - would be great to get this in so folks aren't blocked on the v6 upgrade.

[edalzell]

you can always composer patch this in if you need it.

[lazerg]

Yes, but the problem still needs to be solved.

[edalzell]

Yes, but the problem still needs to be solved.

Yup, and it will be when it gets merged! In the meantime you can patch it in, so you can upgrade etc. The team gets to PRs when they can.

[jasonvarga]

Initially this seemed strange to me.

In statamic/eloquent-driver#537 (comment) Ryan suggested maybe changing globals to global. No, that would've made the GlobalSet resolve, not Variables.

I wondered by this has only come up recently. That's because the change was introduced in #13427 (6.0) and you need to use it only a Replicator field inside a Global. Not super common to put those inside Globals.

Nowhere else do we really call Data::find() passing in a global variables reference.

This PR also happens to fix an edge case issue where the field's "parent" reference was null. (When using the Stache only. When using Eloquent, you'd get the reported exception.)

[grantholle]

Thank you @jasonvarga and @lazerg! Very appreciated

[lazerg]

Global variable references use a globals:: prefix, but only the singular global repository was registered, so the reference fell through and got tried against every repository including entries, which throws an invalid ID error on database drivers (for example when adding a set to a Replicator inside a global set). This registers the globals prefix against the global variables repository so the reference resolves correctly.

Fixesstatamic/eloquent-driver#537

[grantholle]

Is this all it needs 😭

I've been unable to upgrade to Laravel 13 because of this, since I haven't been able to upgrade to v6...

[lazerg]

Yep, that's the whole fix. @jasonvarga mind taking a look when you get a chance - would be great to get this in so folks aren't blocked on the v6 upgrade.

[edalzell]

you can always composer patch this in if you need it.

[lazerg]

Yes, but the problem still needs to be solved.

[edalzell]

Yes, but the problem still needs to be solved.

Yup, and it will be when it gets merged! In the meantime you can patch it in, so you can upgrade etc. The team gets to PRs when they can.

[jasonvarga]

Initially this seemed strange to me.

In statamic/eloquent-driver#537 (comment) Ryan suggested maybe changing globals to global. No, that would've made the GlobalSet resolve, not Variables.

I wondered by this has only come up recently. That's because the change was introduced in #13427 (6.0) and you need to use it only a Replicator field inside a Global. Not super common to put those inside Globals.

Nowhere else do we really call Data::find() passing in a global variables reference.

This PR also happens to fix an edge case issue where the field's "parent" reference was null. (When using the Stache only. When using Eloquent, you'd get the reported exception.)

[grantholle]

Thank you @jasonvarga and @lazerg! Very appreciated

[lazerg]

Global variable references use a globals:: prefix, but only the singular global repository was registered, so the reference fell through and got tried against every repository including entries, which throws an invalid ID error on database drivers (for example when adding a set to a Replicator inside a global set). This registers the globals prefix against the global variables repository so the reference resolves correctly.

Fixesstatamic/eloquent-driver#537

[grantholle]

Is this all it needs 😭

I've been unable to upgrade to Laravel 13 because of this, since I haven't been able to upgrade to v6...

[lazerg]

Yep, that's the whole fix. @jasonvarga mind taking a look when you get a chance - would be great to get this in so folks aren't blocked on the v6 upgrade.

[edalzell]

you can always composer patch this in if you need it.

[lazerg]

Yes, but the problem still needs to be solved.

[edalzell]

Yes, but the problem still needs to be solved.

Yup, and it will be when it gets merged! In the meantime you can patch it in, so you can upgrade etc. The team gets to PRs when they can.

[jasonvarga]

Initially this seemed strange to me.

In statamic/eloquent-driver#537 (comment) Ryan suggested maybe changing globals to global. No, that would've made the GlobalSet resolve, not Variables.

I wondered by this has only come up recently. That's because the change was introduced in #13427 (6.0) and you need to use it only a Replicator field inside a Global. Not super common to put those inside Globals.

Nowhere else do we really call Data::find() passing in a global variables reference.

This PR also happens to fix an edge case issue where the field's "parent" reference was null. (When using the Stache only. When using Eloquent, you'd get the reported exception.)

[grantholle]

Thank you @jasonvarga and @lazerg! Very appreciated

[lazerg]

Global variable references use a globals:: prefix, but only the singular global repository was registered, so the reference fell through and got tried against every repository including entries, which throws an invalid ID error on database drivers (for example when adding a set to a Replicator inside a global set). This registers the globals prefix against the global variables repository so the reference resolves correctly.

Fixesstatamic/eloquent-driver#537

[grantholle]

Is this all it needs 😭

I've been unable to upgrade to Laravel 13 because of this, since I haven't been able to upgrade to v6...

[lazerg]

Yep, that's the whole fix. @jasonvarga mind taking a look when you get a chance - would be great to get this in so folks aren't blocked on the v6 upgrade.

[edalzell]

you can always composer patch this in if you need it.

[lazerg]

Yes, but the problem still needs to be solved.

[edalzell]

Yes, but the problem still needs to be solved.

Yup, and it will be when it gets merged! In the meantime you can patch it in, so you can upgrade etc. The team gets to PRs when they can.

[jasonvarga]

Initially this seemed strange to me.

In statamic/eloquent-driver#537 (comment) Ryan suggested maybe changing globals to global. No, that would've made the GlobalSet resolve, not Variables.

I wondered by this has only come up recently. That's because the change was introduced in #13427 (6.0) and you need to use it only a Replicator field inside a Global. Not super common to put those inside Globals.

Nowhere else do we really call Data::find() passing in a global variables reference.

This PR also happens to fix an edge case issue where the field's "parent" reference was null. (When using the Stache only. When using Eloquent, you'd get the reported exception.)

[grantholle]

Thank you @jasonvarga and @lazerg! Very appreciated

[lazerg]

Global variable references use a globals:: prefix, but only the singular global repository was registered, so the reference fell through and got tried against every repository including entries, which throws an invalid ID error on database drivers (for example when adding a set to a Replicator inside a global set). This registers the globals prefix against the global variables repository so the reference resolves correctly.

Fixesstatamic/eloquent-driver#537

[grantholle]

Is this all it needs 😭

I've been unable to upgrade to Laravel 13 because of this, since I haven't been able to upgrade to v6...

[lazerg]

Yep, that's the whole fix. @jasonvarga mind taking a look when you get a chance - would be great to get this in so folks aren't blocked on the v6 upgrade.

[edalzell]

you can always composer patch this in if you need it.

[lazerg]

Yes, but the problem still needs to be solved.

[edalzell]

Yes, but the problem still needs to be solved.

Yup, and it will be when it gets merged! In the meantime you can patch it in, so you can upgrade etc. The team gets to PRs when they can.

[jasonvarga]

Initially this seemed strange to me.

In statamic/eloquent-driver#537 (comment) Ryan suggested maybe changing globals to global. No, that would've made the GlobalSet resolve, not Variables.

I wondered by this has only come up recently. That's because the change was introduced in #13427 (6.0) and you need to use it only a Replicator field inside a Global. Not super common to put those inside Globals.

Nowhere else do we really call Data::find() passing in a global variables reference.

This PR also happens to fix an edge case issue where the field's "parent" reference was null. (When using the Stache only. When using Eloquent, you'd get the reported exception.)

[grantholle]

Thank you @jasonvarga and @lazerg! Very appreciated

[lazerg]

Global variable references use a globals:: prefix, but only the singular global repository was registered, so the reference fell through and got tried against every repository including entries, which throws an invalid ID error on database drivers (for example when adding a set to a Replicator inside a global set). This registers the globals prefix against the global variables repository so the reference resolves correctly.

Fixesstatamic/eloquent-driver#537

[grantholle]

Is this all it needs 😭

I've been unable to upgrade to Laravel 13 because of this, since I haven't been able to upgrade to v6...

[lazerg]

Yep, that's the whole fix. @jasonvarga mind taking a look when you get a chance - would be great to get this in so folks aren't blocked on the v6 upgrade.

[edalzell]

you can always composer patch this in if you need it.

[lazerg]

Yes, but the problem still needs to be solved.

[edalzell]

Yes, but the problem still needs to be solved.

Yup, and it will be when it gets merged! In the meantime you can patch it in, so you can upgrade etc. The team gets to PRs when they can.

[jasonvarga]

Initially this seemed strange to me.

In statamic/eloquent-driver#537 (comment) Ryan suggested maybe changing globals to global. No, that would've made the GlobalSet resolve, not Variables.

I wondered by this has only come up recently. That's because the change was introduced in #13427 (6.0) and you need to use it only a Replicator field inside a Global. Not super common to put those inside Globals.

Nowhere else do we really call Data::find() passing in a global variables reference.

This PR also happens to fix an edge case issue where the field's "parent" reference was null. (When using the Stache only. When using Eloquent, you'd get the reported exception.)

[grantholle]

Thank you @jasonvarga and @lazerg! Very appreciated

[lazerg]

Global variable references use a globals:: prefix, but only the singular global repository was registered, so the reference fell through and got tried against every repository including entries, which throws an invalid ID error on database drivers (for example when adding a set to a Replicator inside a global set). This registers the globals prefix against the global variables repository so the reference resolves correctly.

Fixesstatamic/eloquent-driver#537

[grantholle]

Is this all it needs 😭

I've been unable to upgrade to Laravel 13 because of this, since I haven't been able to upgrade to v6...

[lazerg]

Yep, that's the whole fix. @jasonvarga mind taking a look when you get a chance - would be great to get this in so folks aren't blocked on the v6 upgrade.

[edalzell]

you can always composer patch this in if you need it.

[lazerg]

Yes, but the problem still needs to be solved.

[edalzell]

Yes, but the problem still needs to be solved.

Yup, and it will be when it gets merged! In the meantime you can patch it in, so you can upgrade etc. The team gets to PRs when they can.

[jasonvarga]

Initially this seemed strange to me.

In statamic/eloquent-driver#537 (comment) Ryan suggested maybe changing globals to global. No, that would've made the GlobalSet resolve, not Variables.

I wondered by this has only come up recently. That's because the change was introduced in #13427 (6.0) and you need to use it only a Replicator field inside a Global. Not super common to put those inside Globals.

Nowhere else do we really call Data::find() passing in a global variables reference.

This PR also happens to fix an edge case issue where the field's "parent" reference was null. (When using the Stache only. When using Eloquent, you'd get the reported exception.)

[grantholle]

Thank you @jasonvarga and @lazerg! Very appreciated

[lazerg]

Global variable references use a globals:: prefix, but only the singular global repository was registered, so the reference fell through and got tried against every repository including entries, which throws an invalid ID error on database drivers (for example when adding a set to a Replicator inside a global set). This registers the globals prefix against the global variables repository so the reference resolves correctly.

Fixesstatamic/eloquent-driver#537

[grantholle]

Is this all it needs 😭

I've been unable to upgrade to Laravel 13 because of this, since I haven't been able to upgrade to v6...

[lazerg]

Yep, that's the whole fix. @jasonvarga mind taking a look when you get a chance - would be great to get this in so folks aren't blocked on the v6 upgrade.

[edalzell]

you can always composer patch this in if you need it.

[lazerg]

Yes, but the problem still needs to be solved.

[edalzell]

Yes, but the problem still needs to be solved.

Yup, and it will be when it gets merged! In the meantime you can patch it in, so you can upgrade etc. The team gets to PRs when they can.

[jasonvarga]

Initially this seemed strange to me.

In statamic/eloquent-driver#537 (comment) Ryan suggested maybe changing globals to global. No, that would've made the GlobalSet resolve, not Variables.

I wondered by this has only come up recently. That's because the change was introduced in #13427 (6.0) and you need to use it only a Replicator field inside a Global. Not super common to put those inside Globals.

Nowhere else do we really call Data::find() passing in a global variables reference.

This PR also happens to fix an edge case issue where the field's "parent" reference was null. (When using the Stache only. When using Eloquent, you'd get the reported exception.)

[grantholle]

Thank you @jasonvarga and @lazerg! Very appreciated