View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006342||OXID eShop (all versions)||2.3. Extensions (modules, themes)||public||2016-03-01 13:33||2016-04-06 08:58|
|Priority||normal||Severity||tweak||Reproducibility||have not tried|
|Target Version||6.0.0-beta.1||Fixed in Version||6.0.0-beta.1|
|Summary||0006342: shop expects module to be in a folder named like the moduleid|
|Description||At some places in the module logic it is expects that modules are installed in a folder named like the module id.|
There are some modules out there including the NOT using the moduleid defined in the metadata.php as directory name e.g. the bundled paymorrow module.
This causes some effects when updating modules where extensions have changed since the last version. The shop is then not able to recognize that the old extensions belonging to the specific module. Which may cause a corrupted extension configuration and so may cause bad side effects.
|Additional Information||found that type of code ("$sModuleId .") in |
- oxmoduleinstaller method _filterModuleArray
- oxmodulelist method getDeletedExtensions
not sure how bad this issue is but i guess most effects are temporary and can be solved by "module internals" or disabling and enabling that module again. But this issue could have bad side effects in automated deployments where people using tools like the Oxid Console fix:states command, that will not be able to fix this kind of problems because the oxid console itself reuses that core logic. Then i do not know if the shop may deactivate that module or other strange things may happen.
|Tags||No tags attached.|
|PHP Version||Not defined|
|Database Version||Not defined|
i fixed the most interesting place for me at oxmoduleinstaller in
pull request for oxid 6
pull request for oxid 5.3
||Accepted pull request to master.|