Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix unusable shop after activation of a module with migrated metadata (v2) #663

Conversation

Projects
None yet
3 participants
@whefter
Copy link
Contributor

commented Aug 3, 2018

When a module that was previously activated with metadata v1 is activated after its metadata has been migrated to v2, the old extensions are currently not correctly purged from the database.

Due to the way ModuleExtensionsCleaner::getModuleExtensionsGarbage() is currently written, it cannot purge v1-style class references from the database (because it checks for v2-style class references). This results in v1-style extensions such as "vendor/modulename/application/models/modulename_oxconfig" being left in the database.

Additionally, the ModuleChainsGenerator now correctly handles special cases where two modules have extensions to oxconfig and one of them is not available anymore (e.g. because of migrated metadata).

ModuleChainsGenerator::handleSpecialCases() currently only checks if the direct parent class is oxconfig. This works fine as long as only one OXID module is extending oxconfig. When two extensions to oxconfig are present, the check will fail (because the class checked by handleSpecialCases() might be modulename_oxconfig and not oxconfig) and allow the modules chain generation to enter an infinite loop.

These two bugs together can cause a shop to become unusable when

  1. Two OXID modules are extending oxconfig
  2. One of these modules is second in the oxconfig chain
  3. That module is migrated from metadata v1 to metadata v2

When these conditions are met, the faulty ModuleExtensionsCleaner::getModuleExtensionsGarbage() will not purge the old-style extensions from the database, and the oxconfig chain generation will enter an infinite loop. Any attempt to load the shop will throw a PHP Fatal Error - Maximum Nesting Level reached that can only be solved by editing the values in the oxconfig database table directly (more likely, deleting them and re-activating all modules).

The provided OXID function in the "Installed shop modules" tab on the extensions page in the backend, which correctly alerts the admin to the fact that some legacy module extensions are present in the database, results in all module settings (including admin-set values etc.) being deleted from the database, which is not useful in the context of upgrading a module to metadata v2.

The proposed commit fixes both these issues.

Fix unusable shop after activation of a module with migrated metadata…
… (v2)

When a module that was previously activated with metadata v1 is activated after its metadata has been migrated to v2, the old extensions are now correctly purged from the database.

Additionally, the ModuleChainsGenerator now correctly handles special cases where two modules have extensions to oxconfig and one of them is not available anymore (e.g. because of migrated metadata).
@mtkoltan

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2018

Looks good from my point of view.

@Sieg

This comment has been minimized.

Copy link
Contributor

commented Dec 20, 2018

Thank you @whefter for the Pull request. It was merged to b-6.1.x recently, so should be available in next release. (3eb3eb8)

@Sieg Sieg closed this Dec 20, 2018

@Sieg Sieg removed the in progress label Dec 20, 2018

@Sieg Sieg self-assigned this Dec 20, 2018

@Sieg Sieg added the Ready to merge label Dec 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.