View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007113 | OXID eShop (all versions) | 2.3. Extensions (modules, themes) | public | 2020-04-08 22:07 | 2026-08-20 12:19 |
| Reporter | leofonic | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Product Version | 6.2.0 | ||||
| Summary | 0007113: Module information is not deleted completely | ||||
| Description | If a registered module is not present in modules directory, a question is displayed: Invalid modules were detected. Do you want to delete all registered module information and saved configurations? Answering "yes" does not update configuration file, so the message appears again and again. | ||||
| Tags | Module | ||||
| Theme | Not defined | ||||
| Browser | Not defined | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
|
|
Steps to reproduce: 1. Install 6.2.0 2. Activate PayPal 3. Deactivate PayPal 4. Check var/config/shops/1.yaml and search for oepaypal 5. remove the directory source/modules/oe/oepaypal 6. goto admin -> modules and see the message "Invalid modules were detected. ". 7. Click on yes, see that it appears again. 8. remove the entry oepaypal from var/config/shops/1.yaml by yourself 9. goto admin -> modules and see the message "Invalid modules were detected. ". 10. Click on yes, see that it not appears again. -MK |
|
|
@HR Re-tested on 7.5 as requested. Short answer: the reported symptom is gone, but the headline of this ticket still applies. Details below, including how the state can be produced now that module code is no longer copied into source/modules. Environment: OXID eShop CE dev-b-7.5.x (10b54a8), PHP 8.3, MySQL 8.4, apex theme, no other modules installed. Admin driven over HTTP with a cookie jar. 1) Is it reproducible in 7.5? No, not the reported behaviour. Clicking "yes" works: the affected module is deactivated and the warning stays away on every following page load. The original complaint was that the message "appears again and again" because the configuration file was never updated. That flow does not exist any more. In 6.x the state lived in var/config/shops/1.yaml; in 7.x it is var/configuration/shops/1/ with a per-module file and an "activated" flag, and the check only looks at active modules. 2) How can the state be produced at all, without copying code into source/modules? The warning is not tied to source/modules. It is raised when an extension class of an ACTIVE module cannot be resolved through the Composer autoloader. Two ways to get there: a) Install and activate a module, then remove or rename the directory that holds its class files, while its registration under var/configuration/shops/1/modules/ stays in place. b) Ship metadata whose "extend" points at a class that never existed. The core has a fixture for exactly this: tests/Codeception/Support/Data/modules/test-module-problems, used by tests/Codeception/Acceptance/Admin/ModuleSortListCest::moduleWithProblemsSortList. Both produce the same observable result, so the scenario is still testable in 7.5. Note the message now only lives in Admin > Extensions > Modules > tab "Installed Shop Modules" (module_sortlist.html.twig, language key MODULE_EXTENSIONISDELETED). Steps used for the re-test: 1. Install and activate a module with resolvable classes (core fixture testModule). Open the "Installed Shop Modules" tab: no warning, extension chain lists the class. 2. Rename the module's source directory so its classes are gone, registration untouched. Reload the tab: the warning appears, naming the module id and the class. 3. Submit the "yes" button (cl=module_sortlist, fnc=remove, yesButton). Result: the module's yaml is set to activated: false, and reloading the page shows no warning. Repeating the reload keeps it gone. 4. Re-activating the module from the console while the code is still missing brings the warning back, which is expected: the check runs against active modules. 5. Same procedure with the test-module-problems fixture: identical behaviour. 3) What is still true, and why we suggest keeping a smaller ticket open The title of this ticket is "Module information is not deleted completely", and that part still holds in 7.5. The "yes" action does not delete anything. It only deactivates: - the module configuration file under var/configuration/shops/1/modules/ remains, - the entry in var/configuration/shops/1/class_extension_chain.yaml remains. Code path: ModuleSortList::remove() calls ModuleList::cleanup() (source/Core/Module/ModuleList.php:54). cleanup() iterates getDeletedExtensions() and calls the module activation bridge's deactivate() for each id. Nothing removes the registration or the chain entry. getDeletedExtensions() / getInvalidExtensions() resolve extension classes through the Composer autoloader and only consider active modules, which is why deactivating alone makes the warning disappear. So there are two possible outcomes, and that is a product decision rather than a QA one: - If "deactivate and stop warning" is the intended semantics, the dialog wording is misleading, because it offers to "delete all registered module information and saved configurations" while it deactivates. Then this ticket can be closed and the wording fixed instead. - If the dialog is meant literally, the leftover module configuration and the stale class_extension_chain entry are the remaining defect, and the ticket should be reduced to that. No new exceptions appeared in source/log/oxideshop.log during any of the steps, and the admin pages of the affected module stayed reachable (HTTP 200) while its code was missing. |
