Bug report
Opening an entry edit page in the CP throws Maximum recursive updates exceeded in Vue and floods the console, when the entry has a lot of nested relationship (terms/entries) fields.
Triggered reliably on an entry with a replicator or grid containing around 20 rows, where each row has a nested replicator/grid of around 5 more rows, and each inner row has a terms field. That works out to roughly 100 nested relationship pickers mounting simultaneously. The entry uses the standard terms fieldtype with taxonomies: [wheel_finishes] and max_items: 1.
Smaller entries of the same shape (around 20 total relationship instances) do not trigger it.
Trace
Every error bottoms out on the publish container's throttled value setter:
set @ vue.esm-bundler...:3984
(anonymous) @ ui-...:98336
throttled @ ui-...:98310
It then cascades through showField and the radix-vue TabsContent presence watcher for every tab. SEO Pro's value watcher also fires a POST /cp/seo-pro/preview on every cycle, which made it easy to spot in the Network panel.
Expected
Editing a large entry should not blow past Vue's per-tick reactive update limit on initial mount.
Workaround
Replaced the inner terms field with a custom lightweight fieldtype:
preload() returns the full list of taxonomy options once, shared via meta- Vue component renders a plain
<select> bound to meta.options
- No per-instance relationship component, no per-instance XHR to
/cp/fieldtypes/relationship
That immediately fixed it. Same data storage format ([$slug] array), same taxonomy source. Only the rendering layer changed.
Related
Looks similar in shape to #13591, which was closed via a tooltip consolidation fix. That fix did not cover this scenario.
Suggestion
When the terms, entries, users, or assets fieldtypes render inside a repeatable structure with many instances sharing the same configuration, options could be fetched once and shared across instances, or the relationship component could be virtualised or lazy mounted so they do not all subscribe to publish container reactivity on initial mount.
Environment
Laravel Version: 12.56.0
PHP Version: 8.4.19
Composer Version: 2.9.4
Environment: local
Debug Mode: ENABLED
Maintenance Mode: OFF
Timezone: Australia/Adelaide
Locale: en
Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED
Drivers
Broadcasting: log
Cache: redis
Database: mysql
Logs: stack / daily
Mail: ses
Queue: sync
Session: redis
Storage
public/storage: NOT LINKED
Livewire
Livewire: v4.2.4
Statamic
Addons: 5
Sites: 2 (xxx Australia, xxx New Zealand)
Stache Watcher: Enabled (auto)
Static Caching: Disabled
Version: 6.13.0 PRO
Statamic Addons
aerni/livewire-forms: 10.3.0
marcorieser/statamic-livewire: 5.3.0
mitydigital/sitemapamic: 3.5.0
statamic/eloquent-driver: 5.6.2
statamic/seo-pro: 7.5.0
Statamic Eloquent Driver
Addon Settings: file
Asset Containers: file
Assets: file
Blueprints: file
Collection Trees: file
Collections: file
Entries: eloquent
Fieldsets: file
Form Submissions: file
Forms: file
Global Sets: file
Global Variables: file
Navigation Trees: file
Navigations: file
Revisions: file
Sites: file
Taxonomies: file
Terms: file
Tokens: file
Bug report
Opening an entry edit page in the CP throws
Maximum recursive updates exceededin Vue and floods the console, when the entry has a lot of nested relationship (terms/entries) fields.Triggered reliably on an entry with a replicator or grid containing around 20 rows, where each row has a nested replicator/grid of around 5 more rows, and each inner row has a
termsfield. That works out to roughly 100 nested relationship pickers mounting simultaneously. The entry uses the standardtermsfieldtype withtaxonomies: [wheel_finishes]andmax_items: 1.Smaller entries of the same shape (around 20 total relationship instances) do not trigger it.
Trace
Every error bottoms out on the publish container's throttled value setter:
It then cascades through
showFieldand the radix-vueTabsContentpresence watcher for every tab. SEO Pro's value watcher also fires aPOST /cp/seo-pro/previewon every cycle, which made it easy to spot in the Network panel.Expected
Editing a large entry should not blow past Vue's per-tick reactive update limit on initial mount.
Workaround
Replaced the inner terms field with a custom lightweight fieldtype:
preload()returns the full list of taxonomy options once, shared viameta<select>bound tometa.options/cp/fieldtypes/relationshipThat immediately fixed it. Same data storage format (
[$slug]array), same taxonomy source. Only the rendering layer changed.Related
Looks similar in shape to #13591, which was closed via a tooltip consolidation fix. That fix did not cover this scenario.
Suggestion
When the
terms,entries,users, orassetsfieldtypes render inside a repeatable structure with many instances sharing the same configuration, options could be fetched once and shared across instances, or the relationship component could be virtualised or lazy mounted so they do not all subscribe to publish container reactivity on initial mount.Environment