[#47536] - updating multiple extensions fail
- New
- Medium
- Build: 6.0, 6.1
- # 47536
There is a bug in ./libraries/src/Installer/InstallerAdapter.php method protected function setupScriptfile()
when you have eg. the following updates in the Joomla update manager:
- a plugin with < scriptfile> in manifest that triggeres a preflight which removes a directory
- a package which doesn't have < scriptfile>, but has a component with a < scriptfile>
the plugin installs correct and the directory is removed (and filled again with the correct files in the updated file)
but the package installs and executes the plugins preflight agian... leaving the plugin installation in a flux as the directory is removed again.
Debugging led me to the following bug in protected function setupScriptfile()
// When no script file, do nothing
if (!$manifestScript) {
return;
}
this just returns, but the script class for the plugin is still set in $this->parent->manifestClass and as such the preflight is executed.
this is the (confirmed fix) that avoids the 'bleeding' of the plugins scriptfile to the package:
// When no script file, reset any previously set manifestClass and do nothing
if (!$manifestScript) {
$this->parent->manifestClass = null;
return;
}
hope this helps, keep up the good work!
| Labels |
Removed:
?
|
||
joomla-cms-bot
- | Labels |
Added:
No Code Attached Yet
|
||
Thanks @jiteshkhatri11 most difficult part will be to try and reproduce as that involves having an update server and packages etc.
Solution provided works.
Good luck on doing a PR for this
Hi @laoneo,
Thanks for pointing this out!
I’ll test PR #47637 locally to verify whether it resolves the issue described here (especially the manifestClass “bleeding” between installations). I’ll try to simulate a similar update scenario with a plugin (with ) and a package (without but containing one internally).
I’ll report back with my findings shortly.
If it doesn’t fully address the issue, I can proceed with implementing and testing the proposed fix of resetting manifestClass to null when no script file is present.
Thanks!
Thanks
Hi @laoneo,
I tested PR #47637 and it does partially address the issue,
however the manifestClass "bleeding" still occurs in some scenarios.
The fix of resetting $this->parent->manifestClass = null when no
scriptfile is present (as proposed by @Ruud68) is still needed.
I have submitted PR #47652 with this fix. Please review when convenient.
Thanks!
Hi @laoneo,
I reviewed PR #47637. It addresses the manifest path compilation
issue for discover install scenarios.
However, the manifestClass "bleeding" issue described in this issue
(#47536) is a slightly different problem — it occurs during batch
updates in the update manager, not just discover install.
I have submitted PR #47652 which resets $this->parent->manifestClass
to null when no scriptfile is present, which directly fixes the
bleeding issue described here.
Both fixes may be needed to fully resolve related installer issues.
Thanks!
Hi @Ruud68, thanks for reporting and providing a detailed analysis!
I’d like to work on this issue and implement the proposed fix. I’ll try to reproduce the problem locally and verify the solution before creating a PR.
Please let me know if that’s okay.
Thanks!