Issues after update to ojs-3.0.2 (file upload, new submission not working)

Software Support
1

Even after two days of constant efforts and exhaustive use of all options available on forums, I had no option than to turn to forum support now.

Context: Switching to Linux from Windows…both accounts are running now (one with temporary url)…we have two sets of backup files and databases (one from myphpadmin and other from automatic backup on Windows panel)…Previous version of OJS is 2.4.5 which is perfectly running on Windows server…Updated OJS 3.0.2 tar.gz file download (not GitHub)…php version: 5.6…Uploaded many times trying both type of backups but the problems outlined below persist.

Issues: In new account on Linux everything seems to be working except (at least so far):

(i) I can’t load files (logo, CSS stylesheet, homepage image, etc.) on website setting (Message: no file uploaded or invalid file type!)…All options were used up available on forum (e.g. file permissions, modifying CSS files, changing image file format, commenting out the mime_database_path variable in config.inc.php, etc.). I could see the files on Temp folder on the server but not on ‘public’ directory (as Alec Smecher in your team indicated in one of the forums that OJS moves files to public folder after some check on Temp folder, which probably not functioning in my case, to my understanding at least).

(ii) New submission is not working completely (nothing appears under Start, Upload Submission, Enter Metadata, …). The same problem persists even after activating ‘Make a Submission’ Block plugin…Can’t even install QuickSubmit plugin from plugin gallery.

(iii) TinyMCE doesn’t load anything in Chrome but works in other browsers (maybe it is the browser problem which I believe can be resolved)

These issues are bugging me now but maybe more on the go…

Thanks for your support in advance.

Dave

2

Hi @bdpaudel,

Let’s start with file permissions. Can you describe how you have these set, and what user account your server runs PHP scripts under?

Regards,
Alec Smecher
Public Knowledge Project Team

3

Thank you for your prompt response.

As to file permission, I tried with both 755 and 777. I used both of them one by one on public and all folders therein.

So far as the user account for PHP script in my server, unfortunately I wasn’t able to figure it out. I searched the web all around for information on how to find it but with no definite solution. I think I need to run the php script which I think I can do with Shell acess in my account but I don’t have that priveledge. Would you want me to ask the host?

4

Hi @bdpaudel,

You’ll need to know what user your PHP scripts run under in order to determine how file permissions should be. That’ll determine what file ownership needs to be. Just considering numeric permissions isn’t enough – see e.g. How should file permissions be set? for details.

Regards,
Alec Smecher
Public Knowledge Project Team

5

Hi Alec,

It took me a while to get back and meantime I did talk to my host and they say that permission issues are fine and they shouldn’t be any problem. Meantime, I did some workaround and installed a fresh OJS 3.0.2, hoping that it could solve the problem. I do see some improvements (such as new submission is working fine, tinyMCE is functioning, etc.) but the file loading problem is intact (including installation of QuickSubmit plugin). I have provided below the error log which might give you some clue:

For QuickSubmit plugin install:

I enabled the php configuration ‘allow_url_fopen=0’ but without any success. I don’t know what to do with other errors.

[04-Apr-2017 15:07:44 UTC] PHP Strict Standards: Declaration of PluginGalleryGridHandler::authorize() should be compatible with GridHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/…/public_html/journal-newsite/lib/pkp/controllers/grid/plugins/PluginGalleryGridHandler.inc.php on line 0
[04-Apr-2017 15:07:44 UTC] PHP Strict Standards: Declaration of PluginGalleryGridHandler::initialize() should be compatible with GridHandler::initialize($request, $args = NULL) in /home/…/public_html/journal-newsite/lib/pkp/controllers/grid/plugins/PluginGalleryGridHandler.inc.php on line 0
[04-Apr-2017 15:07:44 UTC] PHP Strict Standards: Declaration of PluginGalleryGridHandler::renderFilter() should be compatible with GridHandler::renderFilter($request, $filterData = Array) in /home/…/public_html/journal-newsite/lib/pkp/controllers/grid/plugins/PluginGalleryGridHandler.inc.php on line 0
[04-Apr-2017 15:07:44 UTC] PHP Warning: copy(): https:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /home/…/public_html/journal-newsite/lib/pkp/classes/file/FileManager.inc.php on line 159
[04-Apr-2017 15:07:44 UTC] PHP Warning: copy(https://github.com/pkp/quickSubmit/releases/download/ojs-3_0_2-0/quickSubmit-ojs-3_0_2-0.tar.gz): failed to open stream: no suitable wrapper could be found in /home/…/public_html/journal-newsite/lib/pkp/classes/file/FileManager.inc.php on line 159
[04-Apr-2017 15:07:44 UTC] ojs2: Incorrect MD5 checksum!

For file upload:

[04-Apr-2017 15:37:28 UTC] PHP Strict Standards: Declaration of SettingsTabHandler::initialize() should be compatible with PKPHandler::initialize($request, $args = NULL) in /home/…/public_html/journal-newsite/lib/pkp/classes/controllers/tab/settings/SettingsTabHandler.inc.php on line 20
[04-Apr-2017 15:37:28 UTC] PHP Strict Standards: Declaration of ManagerSettingsTabHandler::authorize() should be compatible with PKPHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/…/public_html/journal-newsite/lib/pkp/controllers/tab/settings/ManagerSettingsTabHandler.inc.php on line 20
[04-Apr-2017 15:37:28 UTC] PHP Strict Standards: Declaration of ValidatorUrl::getRegexp() should be compatible with ValidatorUri::getRegexp($allowedSchemes = NULL) in /home/…/public_html/journal-newsite/lib/pkp/classes/validation/ValidatorUrl.inc.php on line 19
[04-Apr-2017 15:37:28 UTC] PHP Strict Standards: Declaration of SettingsFileUploadForm::fetch() should be compatible with Form::fetch($request, $template = NULL, $display = false) in /home/…/public_html/journal-newsite/lib/pkp/controllers/tab/settings/form/SettingsFileUploadForm.inc.php on line 18
[04-Apr-2017 15:37:28 UTC] PHP Strict Standards: Declaration of NewContextImageFileForm::fetch() should be compatible with SettingsFileUploadForm::fetch($request, $params = NULL) in /home/…/public_html/journal-newsite/lib/pkp/controllers/tab/settings/appearance/form/NewContextImageFileForm.inc.php on line 18
[04-Apr-2017 15:37:28 UTC] PHP Strict Standards: Declaration of NewContextImageFileForm::initData() should be compatible with Form::initData() in /home/…/public_html/journal-newsite/lib/pkp/controllers/tab/settings/appearance/form/NewContextImageFileForm.inc.php on line 18
[04-Apr-2017 15:37:28 UTC] PHP Strict Standards: Declaration of NewContextImageFileForm::execute() should be compatible with Form::execute($object = NULL) in /home/…/public_html/journal-newsite/lib/pkp/controllers/tab/settings/appearance/form/NewContextImageFileForm.inc.php on line 18
[04-Apr-2017 15:37:28 UTC] PHP Deprecated: Non-static method PKPRequest::getUserVar() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/form/Form.inc.php on line 370
[04-Apr-2017 15:37:28 UTC] PHP Deprecated: Non-static method PKPRequest::_checkThis() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/core/PKPRequest.inc.php on line 582
[04-Apr-2017 15:37:28 UTC] PHP Deprecated: Non-static method PKPRequest::getUserVar() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/form/Form.inc.php on line 370
[04-Apr-2017 15:37:28 UTC] PHP Deprecated: Non-static method PKPRequest::_checkThis() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/core/PKPRequest.inc.php on line 582
[04-Apr-2017 15:37:28 UTC] PHP Strict Standards: Only variables should be assigned by reference in /home/…/public_html/journal-newsite/lib/pkp/classes/file/TemporaryFileDAO.inc.php on line 43
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::checkFrequency() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/plugins/generic/acron/PKPAcronPlugin.inc.php on line 315
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::_isInRange() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/scheduledTask/ScheduledTaskHelper.inc.php on line 114
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::checkFrequency() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/plugins/generic/acron/PKPAcronPlugin.inc.php on line 315
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::_isInRange() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/scheduledTask/ScheduledTaskHelper.inc.php on line 114
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::checkFrequency() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/plugins/generic/acron/PKPAcronPlugin.inc.php on line 315
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::_isInRange() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/scheduledTask/ScheduledTaskHelper.inc.php on line 114
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::checkFrequency() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/plugins/generic/acron/PKPAcronPlugin.inc.php on line 315
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::_isInRange() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/scheduledTask/ScheduledTaskHelper.inc.php on line 114
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::checkFrequency() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/plugins/generic/acron/PKPAcronPlugin.inc.php on line 315
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method ScheduledTaskHelper::_isInRange() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/scheduledTask/ScheduledTaskHelper.inc.php on line 114
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method Request::getContext() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/plugins/ThemePlugin.inc.php on line 409
[04-Apr-2017 15:37:30 UTC] PHP Deprecated: Non-static method PKPRequest::_checkThis() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/classes/core/Request.inc.php on line 68

6

Hi @bdpaudel,

There’s nothing relevant in the logs. Do I understand correctly that file uploading is still failing? The causes there are almost certain to be either file upload size limits (PHP and Apache configuration, see the FAQ) or file permissions (there’s a FAQ entry on this too). I do wonder whether your host’s assurances are accurate – I’m not sure they’ll know OJS’s requirements unless they’ve read the README document.

Regards,
Alec Smecher
Public Knowledge Project Team

7

Yes file uploading is still failing.

I will again get in touch with my host to make sure about permission issues and also attach the README document for them to have a look.

Meantime, I am trying every ways possible throughout the day today and the files are eventually uploaded on Temp folder after hitting upload button and you said in another topic that they would eventually go to ‘public’ folder after some check in Temp folder. These files in temporary folder have 644 permissions, even though the Temp folder has 755 permission. I think these are system generated permissions but just wonder if this could be the problem to get files transferred into ‘public’ folder.

Also, in my updated version of my installation from 2.4.5 to 3.0.2, I could see that ‘public’ folder contains my earlier uploaded files (which it should as I copied it from my old system during installation) but they are not displayed in my homepage (no logo, no homepage image, etc.).

Besides, I have created my folder for journal upload files outside of Public_html folder. Would this be a potential cause?

Thanks.

8

Moving the files directory outside of webroot is a best practice. It is possible, however, that PHP may be configured to only access files within the webroot via the open_basedir directive. It is also possible that SELinux extensions may block Apache’s access outside of webroot. I would expect either of these cases to result in a message within the PHP error log.

The difference between 644 (for files) and 755 (for directories) is expected. Directories require the “execute” bit to be set for the “stat” permission, which allows a user/group/world to be able to traverse the directory.

9

The thing is going even more mysterious. What I did lately is I created two instances of installations in my new Linux account - my old OJS (2.4.5) and the new OJS 3.0.2 and I placed both installations inside the same Public_html folder. I created two folders separately outside of Public_html folder to upload files for both of them. The interesting thingis the old installation OJS (2.4.5) works perfectly - I can upload files and that appears in ‘public’ folder eventually (I uploaded home page image and it is in there rightaway both in cpanel and in my website). When I do it in my new OJS, the upload keeps failing and I don’t see any file in ‘public’ folder. The permissions are exactly the same for both installations.

All this,to my understanding at least, doesn’t indicate any problem relating to file permissions. Within the same environment, how could everything, including the file upload, is going through in one installation and they are not in the other installation. What I can guess now is that problem could be associated with the new installation of OJS.

While I can keep going with my old OJS installation in my new Linux account but I am really interested to go with new OJS and I hope I get the solution on it.

10

Hi @bdpaudel,

The file type detection is somewhat different between OJS 2.x and 3.x – OJS 3.x prioritizes the fileinfo suite of functions for MIME type detection, where OJS 2.x prioritizes mime_content_type. What have you configured for mime_database_path in config.inc.php? (It’s generally safe to leave this line of configuration commented out, as that’ll cause the fileinfo tools to use a built-in database.)

Regards,
Alec Smecher
Public Knowledge Project Team

11

This doesn’t works out either. I had tried this option before too based your response in other threads but with no luck.

12

Hi @bdpaudel,

The function that detects MIME types for uploads, which is the most likely thing to be causing you trouble, is implemented here. I’d suggest investigating your server’s support for the functions used there – the fileinfo suite of functions, and the mime_content_type function.

Regards,
Alec Smecher
Public Knowledge Project Team

13

Hi Alec,

Thanks for your guidance all through, first of all. The upload problem is now resolved! Following your advice, I talked to my host telling them all you said and they said they deployed the fix and it is working perfectly.

Meantime, I am now stumbled with ‘QuickSubmit’ plugin. I can see this plugin in my Plugin Gallery. When I click Install, I am directed to the page to make sure if I want to install the plugin, and then when I click OK, nothing happens. The lines below are reported in my error log. Thanks.

[11-Apr-2017 23:50:20 UTC] PHP Strict Standards: Declaration of PluginGalleryGridHandler::authorize() should be compatible with GridHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/…/public_html/journal-newsite/lib/pkp/controllers/grid/plugins/PluginGalleryGridHandler.inc.php on line 0
[11-Apr-2017 23:50:20 UTC] PHP Strict Standards: Declaration of PluginGalleryGridHandler::initialize() should be compatible with GridHandler::initialize($request, $args = NULL) in /home/…/public_html/journal-newsite/lib/pkp/controllers/grid/plugins/PluginGalleryGridHandler.inc.php on line 0
[11-Apr-2017 23:50:20 UTC] PHP Strict Standards: Declaration of PluginGalleryGridHandler::renderFilter() should be compatible with GridHandler::renderFilter($request, $filterData = Array) in /home/…/public_html/journal-newsite/lib/pkp/controllers/grid/plugins/PluginGalleryGridHandler.inc.php on line 0
[11-Apr-2017 23:50:20 UTC] PHP Warning: copy(): https:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /home/…/public_html/journal-newsite/lib/pkp/classes/file/FileManager.inc.php on line 159
[11-Apr-2017 23:50:20 UTC] PHP Warning: copy(https://github.com/pkp/quickSubmit/releases/download/ojs-3_0_2-0/quickSubmit-ojs-3_0_2-0.tar.gz): failed to open stream: no suitable wrapper could be found in /home/…/public_html/journal-newsite/lib/pkp/classes/file/FileManager.inc.php on line 159
[11-Apr-2017 23:50:20 UTC] ojs2: Incorrect MD5 checksum!

14

What is your current setting for allow_url_fopen in PHP? Earlier, you mention:

I enabled the php configuration ‘allow_url_fopen=0’

This will actually disable the fetching of remote file contents via URL.

http://stackoverflow.com/questions/6551379/file-get-contents-error

15

This is indeed ‘enabled’, both in my home directory and in my domain locations. My apology… that should be my typo - I think I wrote ‘allow_url_fopen=0’ mistakenly for ‘allow_url_fopen’. I double checked in my PHP configuration and it has been set as enabled.

16

It may be that PHP doesn’t have support for https installed:

17

I talked to my host and I was told that HTTPS stream wrappers should not be an issue and pointed out there should be some sort of bug in QuickSubmit plugin. The error log they reported to me was:

17-Apr-2017 04:33:02 UTC] PHP Fatal error: Call to a member function getProductType() on string in /home/…/public_html/journal-newsite/lib/pkp/classes/plugins/PluginHelper.inc.php on line 107

Would you have any advice in this situation?

Thank you.

18

Can you turn on show_stacktrace in config.inc.php and try the install again? This will generate additional information immediately after that error in your log which will help identify the problem.

19

I turned that on but I don’t see any additional information after that error. The same error appears at the end line of the error log. All errors I see is:

[18-Apr-2017 17:03:29 UTC] PHP Warning: escapeshellarg() has been disabled for security reasons in /home/…/public_html/journal-newsite/lib/pkp/classes/plugins/PluginHelper.inc.php on line 64
[18-Apr-2017 17:03:29 UTC] PHP Warning: escapeshellarg() has been disabled for security reasons in /home/…/public_html/journal-newsite/lib/pkp/classes/plugins/PluginHelper.inc.php on line 64
[18-Apr-2017 17:03:29 UTC] PHP Warning: exec() has been disabled for security reasons in /home/…/public_html/journal-newsite/lib/pkp/classes/plugins/PluginHelper.inc.php on line 64
[18-Apr-2017 17:03:29 UTC] PHP Deprecated: Non-static method VersionCheck::getValidPluginVersionInfo() should not be called statically, assuming $this from incompatible context in /home/…/public_html/journal-newsite/lib/pkp/classes/plugins/PluginHelper.inc.php on line 103
[18-Apr-2017 17:03:29 UTC] PHP Fatal error: Call to a member function getProductType() on string in /home/…/public_html/journal-newsite/lib/pkp/classes/plugins/PluginHelper.inc.php on line 107

20

Ah, your server configuration disables escapeshellarg() and exec(), both of which are needed in the current code to extract the plugin from the downloaded file. Unless your provider is willing to relax this restriction, you will not be able to use the Plugin Gallery to install plugins (or some other application features, like the PKP PLN).

You can still install plugins manually by downloading and extracting them to the appropriate subdirectory under the plugins directory yourself. (You may need to subsequently re-run the upgrade script.)