You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
dispatch('openModal') not working after upgrading to Livewire 4.0.1 #545
Using Wire-elements 3.0.3, as titled, dispatch('openModal') does not open any modal. Any idea what could be the cause? It was working with Wire 3.0.3 + Livewire 3.7.4.
After investigation, Livewire 4 introduces reserved parameter names for the dispatch() method that are silently extracted from the parameters array before being passed to event listeners.
The following parameter names are now reserved and will be removed from the event payload:
- component
- ref
- el
- self
- to
The upgrade tool for wire-elements/modal (WireElementsModalUpgrade.php) actually migrated users TO this now-broken syntax:
// The upgrade tool converted this (Livewire 2 style): $this->dispatch('openModal', 'edit-user', ['user' => 1]);
// To this (Livewire 3 style) - which is NOW BROKEN in Livewire 4: $this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]); -> This fail
// PHP - Named parameters $this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]); -> This fail
// Blade/Alpine - Object syntax $dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } }) -> This work
// JavaScript - Object syntax Livewire.dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } }) -> This work
Temporary Workaround
Until package are updated, use positional arguments: $this->dispatch('openModal', 'edit-user', ['user' => 1]);
This issue should be addressed by @PhiloNL to see what strategy he wants to adopt.
Edit:
But it's working fine in my projetcts, without having to change anything, so it's maybe not completely related to this..
Reacted by shokanshi, LukeCaaS, Nima HeydariNasab and Dave Roverts
After investigation, Livewire 4 introduces reserved parameter names for the dispatch() method that are silently extracted from the parameters array before being passed to event listeners.
The following parameter names are now reserved and will be removed from the event payload:
- component
- ref
- el
- self
- to
The upgrade tool for wire-elements/modal (WireElementsModalUpgrade.php) actually migrated users TO this now-broken syntax:
// The upgrade tool converted this (Livewire 2 style): $this->dispatch('openModal', 'edit-user', ['user' => 1]);
// To this (Livewire 3 style) - which is NOW BROKEN in Livewire 4: $this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]); -> This fail
// PHP - Named parameters $this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]); -> This fail
// Blade/Alpine - Object syntax $dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } }) -> This work
// JavaScript - Object syntax Livewire.dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } }) -> This work
Temporary Workaround Until package are updated, use positional arguments: $this->dispatch('openModal', 'edit-user', ['user' => 1]);
This issue should be addressed by @PhiloNL to see what strategy he wants to adopt.
Edit: But it's working fine in my projetcts, without having to change anything, so it's maybe not completely related to this..
Thank you for this, I was pulling my hair out wondering why none of my modals were opening anymore except the ones trigger by Alpine!
@yabdab Don't know if "it's safe", but following @bee-interactive's instructions I was able to upgrade a Livewire 3 + Volt project and make it work with Livewire 4 (with wire-elements, of course)
Like @bee-interactive wrote that the 'component' key is removed from the $params, should we escalate it to livewire/livewire since this package needs it?
im fine with ether
ps also discussing with caleb to prefix all internal event params with "_" so this won't be an issue, so this will be just a backup if we dont find a solution on livewire
im fine with ether ps also discussing with caleb to prefix all internal event params with "_" so this won't be an issue, so this will be just a backup if we dont find a solution on livewire
✅ Is this 1:1 discussion or ongoing thread that I can follow? 😄
im fine with ether ps also discussing with caleb to prefix all internal event params with "_" so this won't be an issue, so this will be just a backup if we dont find a solution on livewire
✅ Is this 1:1 discussion or ongoing thread that I can follow? 😄
was a 1:1; conclusion:
in livewire v5 this will be done better, for now we can just use a macro or have to deal with the reserved words.
so i would open a pr and would pick modal_component as target might be more confusing with wire:target
im fine with ether ps also discussing with caleb to prefix all internal event params with "_" so this won't be an issue, so this will be just a backup if we dont find a solution on livewire
✅ Is this 1:1 discussion or ongoing thread that I can follow? 😄
was a 1:1; conclusion: in livewire v5 this will be done better, for now we can just use a macro or have to deal with the reserved words.
so i would open a pr and would pick modal_component as target might be more confusing with wire:target
Thanks! ModalComponent it is, just tag me in the PR, thanks! 🙌
@PhiloNL Is this merged, and also applies to the PRO version? I'm still getting this error. I've tried to not use named arguments, but I get this error from time to time with that solution even though I don't see any way an int can end up in my code: Trying to access array offset on int.
Activity
bee-interactive commentedon Jan 16, 2026
Hi @shokanshi,
After investigation, Livewire 4 introduces reserved parameter names for the dispatch() method that are silently extracted from the parameters array before being passed to event listeners.
see change in the livewire/livewire repo here
The following parameter names are now reserved and will be removed from the event payload:
The upgrade tool for wire-elements/modal (WireElementsModalUpgrade.php) actually migrated users TO this now-broken syntax:
// The upgrade tool converted this (Livewire 2 style):
$this->dispatch('openModal', 'edit-user', ['user' => 1]);// To this (Livewire 3 style) - which is NOW BROKEN in Livewire 4:
$this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]);-> This fail// PHP - Named parameters
$this->dispatch('openModal', component: 'edit-user', arguments: ['user' => 1]);-> This fail// Blade/Alpine - Object syntax
$dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } })-> This work// JavaScript - Object syntax
Livewire.dispatch('openModal', { component: 'edit-user', arguments: { user: 1 } })-> This workTemporary Workaround
Until package are updated, use positional arguments:
$this->dispatch('openModal', 'edit-user', ['user' => 1]);This issue should be addressed by @PhiloNL to see what strategy he wants to adopt.
Edit:
But it's working fine in my projetcts, without having to change anything, so it's maybe not completely related to this..
shokanshi commentedon Jan 16, 2026
Thank you for the detailed explanation. I guess in the meantime I will have to use this workaround.
Edit: I am able to get it to work using the provided workaround so I suppose the bug is related to your investigation.
PhiloNL commentedon Jan 16, 2026
Thanks for sharing. I'll look into this, looks like we might have to use a different property name.
LukeCaaS commentedon Jan 28, 2026
Thank you for this, I was pulling my hair out wondering why none of my modals were opening anymore except the ones trigger by Alpine!
yabdab commentedon Feb 5, 2026
Is it safe to use Livewire 4 with modal yet?
eleftrik commentedon Feb 6, 2026
@yabdab Don't know if "it's safe", but following @bee-interactive's instructions I was able to upgrade a Livewire 3 + Volt project and make it work with Livewire 4 (with wire-elements, of course)
yabdab commentedon Feb 6, 2026
@eleftrik yea, was just hoping to hear from @PhiloNL on an official status on this.
PhiloNL commentedon Feb 6, 2026
@yabdab you can use it with Livewire 4, but you need to use the workaround mentioned above for now given the keyword is reserved.
theticraft commentedon Mar 25, 2026
Like @bee-interactive wrote that the
'component'key is removed from the$params, should we escalate it tolivewire/livewiresince this package needs it?nuernbergerA commentedon Apr 10, 2026
this is a real blocker for me @PhiloNL would you accept a PR where we replace
componentwithmodalComponent?bee-interactive commentedon Apr 10, 2026
@nuernbergerA +1 for me too
PhiloNL commentedon Apr 12, 2026
@nuernbergerA sure, debating between
modalComponentor justtarget, what do you think?nuernbergerA commentedon Apr 13, 2026
im fine with ether
ps also discussing with caleb to prefix all internal event params with "_" so this won't be an issue, so this will be just a backup if we dont find a solution on livewire
PhiloNL commentedon Apr 15, 2026
✅ Is this 1:1 discussion or ongoing thread that I can follow? 😄
nuernbergerA commentedon Apr 20, 2026
@PhiloNL
was a 1:1; conclusion:
in livewire v5 this will be done better, for now we can just use a macro or have to deal with the reserved words.
so i would open a pr and would pick
modal_componentastargetmight be more confusing withwire:targetPhiloNL commentedon Apr 21, 2026
Thanks!
ModalComponentit is, just tag me in the PR, thanks! 🙌seabasss commentedon May 14, 2026
@PhiloNL Is this merged, and also applies to the PRO version? I'm still getting this error. I've tried to not use named arguments, but I get this error from time to time with that solution even though I don't see any way an int can end up in my code:
Trying to access array offset on int.