Application Version - OJS 3.2.0.0.
I’m unable to install any plugins through the Website Settings tab
Greetings,
I recently installed a clean 3.2 version on a Windows server under Wamp (PHP 7.2.14). I’m currently trying to install a couple of plugins and consistently get the same error regardless of the way I do it. The error doesn’t persist in Submissions (I can upload docx, xml etc. just fine), only in plugins. I tried installing one from the Gallery and uploading manually (tried .zip, .tar and .gz). My errorlog shows this everytime I try uploading a plugin:
[20-Mar-2020 14:30:50 UTC] PHP Fatal error: Uncaught Error: Call to a member function getProductType() on string in E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\plugins\PluginHelper.inc.php:113
Stack trace: #0 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\controllers\grid\plugins\PluginGalleryGridHandler.inc.php(283): PluginHelper->installPlugin(NULL, ‘Files of this t…’) #1 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\core\PKPRouter.inc.php(391): PluginGalleryGridHandler->installPlugin(Array, Object(Request)) #2 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\core\PKPComponentRouter.inc.php(257): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array) #3 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\core\Dispatcher.inc.php(143): PKPComponentRouter->route(Object(Request)) #4 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\core\PKPApplication.inc.php(278): Dispatcher->dispatch(Object(Request)) #5 E:\wamp64\vhosts\pbs.xmlogos.com\index.php(68): PKPApplication->execute() #6 {main}
I checked the config (MIME is remarked), I have fileinfo extension enabled in PHP, my permissions seem allright (especially since the error is obviously thrown after the file is downloaded - a small plugin throws the exception immediately, a large one after some time (presumably after it’s downloaded).
Thanks in advance for your help :-).
EDIT: Just to test things I tried installing 3.1.4 and I get an almost identical error:
thrown in E:\wamp64\vhosts\pbs2.xmlogos.com\lib\pkp\classes\plugins\PluginHelper.inc.php on line 113
[20-Mar-2020 15:10:57 UTC] PHP Fatal error: Uncaught Error: Call to a member function getProductType() on string in E:\wamp64\vhosts\pbs2.xmlogos.com\lib\pkp\classes\plugins\PluginHelper.inc.php:113
Stack trace: #0 E:\wamp64\vhosts\pbs2.xmlogos.com\lib\pkp\controllers\grid\plugins\PluginGalleryGridHandler.inc.php(283): PluginHelper->installPlugin(NULL, ‘No file uploade…’) #1 E:\wamp64\vhosts\pbs2.xmlogos.com\lib\pkp\classes\core\PKPRouter.inc.php(390): PluginGalleryGridHandler->installPlugin(Array, Object(Request)) #2 E:\wamp64\vhosts\pbs2.xmlogos.com\lib\pkp\classes\core\PKPComponentRouter.inc.php(257): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array) #3 E:\wamp64\vhosts\pbs2.xmlogos.com\lib\pkp\classes\core\Dispatcher.inc.php(134): PKPComponentRouter->route(Object(Request)) #4 E:\wamp64\vhosts\pbs2.xmlogos.com\lib\pkp\classes\core\PKPApplication.inc.php(252): Dispatcher->dispatch(Object(Request)) #5 E:\wamp64\vhosts\pbs2.xmlogos.com\index.php(68): PKPApplication->execute()
Make sure you’re trying to upload the right kind of file. The plugin uploader only accepts .tar.gz files, and these must be packaged up the right way. You can’t e.g. upload a .zip download from GitHub’s “Download” button.
Make sure your tar configuration in the cli section of config.inc.php is correct. This is necessary for OJS to be able to unpack the plugin.
Regards,
Alec Smecher
Public Knowledge Project Team
I tried making a .tar.gz file with GnuWin, but get the same error. Also the error persists when I try installing a plugin from the Gallery. My cli section (excluding perl for the moment) looks fine. I did get a tar command error at first, but after changing the config to the right path the error disappeared.
I tried manually unpacking the plugins to the plugins/generic folder and one (Texture) shows as installed in gallery, can be checked under plugins, but doesn’t work anyway (I can’t edit the XML file I uploaded to a submission sent for production), the other one doesn’t show up on the list at all.
I tested both 3.2.0.0 and 3.1.2-4 just to make sure.
Are you trying to install a custom plugin, i.e. one you’ve written yourself, or one of the common plugins? I’d suggest trying to work with one of the common plugins, to avoid complicating what you’re trying to debug.
Regards,
Alec Smecher
Public Knowledge Project Team
One of the common plugins. However the issue is identical with both.
Is there any way to disable the file type check across the board perhaps? I don’t intend to use this as an exterior system anyway, it’s not going to be available from the outside.
I tried to install the first two directly from the gallery and the third by downloading it, uploading zip, unpacking, repacking to tar.gz and uploading that and then copying it manually to plugins/generic.
I get the same error on all plugins (no file or wrong file type) and when I copy them to plugins/generic some appear on the list, but turning them on doesn’t turn them on at all or don’t appear at all.
Rather than downoading the zip and repackaging it, just get the .tar.gz from the repository’s “Releases” area. Or better yet, just use the Plugin Gallery and let it get the right file from the same place.
When you use the Plugin Gallery, what specific messages do you get? What is your tar configuration in config.inc.php?
Regards,
Alec Smecher
Public Knowledge Project Team
Here’s the message I get when using the Plugin Gallery:
[24-Mar-2020 13:37:24 UTC] PHP Fatal error: Uncaught Error: Call to a member function getProductType() on string in E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\plugins\PluginHelper.inc.php:203
Stack trace:
#0 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\controllers\grid\plugins\PluginGalleryGridHandler.inc.php(287): PluginHelper->upgradePlugin('generic', 'texture', NULL, 'Files of this t...')
#1 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\controllers\grid\plugins\PluginGalleryGridHandler.inc.php(236): PluginGalleryGridHandler->installPlugin(Array, Object(Request), true)
#2 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\core\PKPRouter.inc.php(391): PluginGalleryGridHandler->upgradePlugin(Array, Object(Request))
#3 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\core\PKPComponentRouter.inc.php(257): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array)
#4 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\core\Dispatcher.inc.php(143): PKPComponentRouter->route(Object(Request))
#5 E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\core in E:\wamp64\vhosts\pbs.xmlogos.com\lib\pkp\classes\plugins\PluginHelper.inc.php on line 203
And here’s my tar portion of my config.inc.php:
; tar (used in backup plugin, translation packaging)
tar = "C:/Program Files (x86)/GnuWin32/bin/tar.exe"
If I remove the quotes, I get the missing tar command error.
When uploading the plugin directly, I get this error:
php_error.log doesn’t show anything though.
As far as my MIME settings go, I have the mime_database_path line remarked and the fileinfo extension enabled.
OK, the different error messages when quotes are used vs. not suggests to me that the quoted version is correct.
When OJS installs the plugin, it first unpacks it into a temporary area using the tar tool – I suspect this part is working. Then it inspects the plugin’s contents. Then it attempts to install the plugin into the OJS tree. This last part is what I suspect is broken. Is it possible that file permissions are set on your server such that OJS’s plugin installation code can’t create contents within the plugins directory – plugins/generic, in the specific case of jatsParser?
Regards,
Alec Smecher
Public Knowledge Project Team
I would say it’s highly unlikely. I’ve even tried setting permissions to “Everyone/Full control” on the plugins folder to make sure, but the error persists. I’ll try to fiddle around with the tar command just to make sure, but it doesn’t seem to be wrong, as running the exact path (after reversing the slashes) returns a proper tar response.
I copied tar and both connected dlls to the OJS installation folder just to make sure it’s not a case of Program Files permissions, but no success, the error persists.
I did however realise the path to tar can look like this:
tar = E:/wamp64/vhosts/pbs.xmlogos.com/bin/tar/
And it works properly (at least doesn’t throw an error in my face). So no tar.exe and no " around the path. I copied the exe and dlls to that folder.
I can confirm that you will need to specify tar.exe in the tar setting, not just the path where that file lives.
To debug this further you’ll need to work with the code. The related code is in lib/pkp/classes/plugins/PluginHelper.inc.php – in particular the extractPlugin function. If you’re handy with PHP, a few error_log calls in that code will help to establish what’s working and what’s not.
Regards,
Alec Smecher
Public Knowledge Project Team
Definitely not my area of expertise, however I did some programming back in my day. First thing I checked is the extraction process, which I replicated by running this in CMD:
tar -xzf jatsParser-2.0.1-1.tar.gz -C E:\wamp64\vhosts\pbs.xmlogos.com\plugins\generic
Which is how the command seems to be built. I does work and, which is big news, the plugin actually appeared in te list after extracting it there manually. I’m currently trying to force them to actually work.
This does suggest to me that the likeliest cause is file permissions; unfortunately I don’t know the Windows permission model at all, so can’t provide much specific guidance. You can use the is_writable PHP function to confirm directly whether PHP is able to create files/directories in a specified location.
Regards,
Alec Smecher
Public Knowledge Project Team
There is indeed some bug in plugins gallery, because for instance: QuickSubmit plugin installer shows path to hypothesis plugin, not to QuickSubmit !!!
Dear managers of journals. I had the same message problem: “Files of this type can not be uploaded”. We have two providers and the technicians were unable to help me with this. I studied a lot. I found out that there is a php configuration that the site works on. The correct version must be configured. However, the most important thing is to disable the “standard” php configuration bans. See disable_functions in the php selector. DELETE ALL AND INSTALL THE PLUGIN YOU WANT. Then you can restore to the default. Hope this helps.
I’m Estevão Keglevich, from Brazil, manager of scientific journals.
I think what you’re describing is a disable_functions setting in your PHP configuration that includes the exec function. The work-around you’re describing is to temporarily remove exec from disable_functions, install the plugin, then re-add exec to disable_functions again. That’ll work, but note that exec is also used for a few other features of OJS, including text extraction from PDF files for the built-in search engine.
Regards,
Alec Smecher
Public Knowledge Project Team
