pkp / sword

Allow Journal Managers and (optionally) Authors to deposit articles via the SWORD protocol
GNU General Public License v3.0
1 stars 9 forks source link

Plugin can't find version.xml during upgrade #2

Open jnugent opened 5 years ago

jnugent commented 5 years ago

On a PKP|PS journal, the sword plugin is installed. However, during an upgrade from 3.1.1-2 to 3.1.1-4 I noticed that the CLI upgrade process was failing during the [code: Installer Installer::addPluginVersions] section, with:

You are trying to downgrade the product "" from version [3.1.1.2] to version [1.0.0.0]. Downgrades are not supported.

ojs2: You are trying to downgrade the product "" from version [3.1.1.2] to version [1.0.0.0]. Downgrades are not supported. It appears that the getPluginPath() method for Sword returns an empty string, which means that Installer::addPluginVersions() builds a path to the version.xml file that ends up being "/version.xml" `$versionFile = $plugin->getPluginPath() . '/version.xml';` Removing the sword plugin directory and removing the old entries from the versions table related to it allows the upgrade to proceed to completion.
asmecher commented 5 years ago

@jnugent, is the plugins/generic/sword directory present/populated in the ojs-stable-3_1_1 codebase for that install? It shouldn't be -- see https://github.com/pkp/ojs/tree/ojs-stable-3_1_1/plugins/generic. Or was it installed from this repo separately?

jnugent commented 5 years ago

@asmecher - it had been previously installed from the repository. Looking at the journal now, there's a .gitmodules file in the directory pointing to https://github.com/swordapp/swordappv2-php-library. The upgrade procedure would have been to bring the rest of the repository up to ojs-stable-3_1_1, update the sub modules, and then run the regular upgrade CLI command.

asmecher commented 5 years ago

Can you try to narrow down why getPluginPath would be returning a blank? I can't think of a good reason that would be happening.

kaitlinnewson commented 5 years ago

Hey @asmecher, wanted to let you know that we've also been running into this issue, and removing the sword plugin has allowed us to run the upgrade script successfully.

jnugent commented 5 years ago

Hey @kaitlinnewson - I'm trying to find some time to investigate this further, also.

nils-stefan-weiher commented 5 years ago

@jnugent @asmecher I still have this issue with OJS 3.1.2-1 upgrading from 3.1.1 The problem is the child SwordImportExportPlugin class, which the SwordPlugin registers through a callback triggered by PluginRegistry::loadCategory. The installer tries to load a version file for the SwordImportExportPlugin, because it was loaded by PluginRegistry::loadCategory.

The SwordImportExportPlugin class is missing the method for getPluginPath(), and so no path is returned, it should return the path of the parent method.

Will try to fix this and test locally and then open a PR.

asmecher commented 5 years ago

@isgrim, sounds like you've tracked down a tricky one!