Upgrade 9 y.o. OJS to OJS3


#37

I am stupid. It did complain again, but regarding another plugin. Will keep the fight.


#38

Just noticed this today, but with OJS 3.1 the sections on current submissions and website users appear as blank pages. In the log I just see PHP warnings, that seem like deprecations of some time.

Any idea what might be going on?


#39

Hi @ambs,

Have you checked for sure that there are no errors amongst the warnings?

Regards,
Alec Smecher
Public Knowledge Project Team


#40

I do not think so, in any case, as four eyes see better than two, I am sharing it.
I see there some errors getting js files. Can it be the culprit? I confirmed I do not have build.js in that path…


#41

Hi @ambs,

Is this an installation from github, or from the .tar.gz download?

Regards,
Alec Smecher
Public Knowledge Project Team


#42

Git hub. Let me guess, installed dependencies with Composer and npm are not exclusive. First for PHP, second for JS, correct? I just used Composer…


#43

Hi @ambs,

Yes, that’s correct; you’ll have to build the Node dependencies yourself. There are instructions in README.md. (Both Node and Composer dependencies are bundled in the .tar.gz distribution files, but won’t come with a git checkout.)

Regards,
Alec Smecher
Public Knowledge Project Team


#44

Yes, it was a problem of missing JS files. I am dumb. Still having issues with sidebar blocks, but I opened a different thread for that.


#45

Any idea why a png upload fails?

2018/04/10 17:56:23 [error] 9476#9476: *4576 FastCGI sent in stderr: "PHP message: PHP Warning:  Declaration of PKPUsageEventPlugin::getEnabled() should be compatible with LazyLoadPlugin::getEnabled($contextId = NULL) in /home/linguamatica/root/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 0
PHP message: PHP Warning:  Declaration of CustomBlockPlugin::getBlockContext() should be compatible with BlockPlugin::getBlockContext($contextId = NULL) in /home/linguamatica/root/plugins/generic/customBlockManager/CustomBlockPlugin.inc.php on line 0
PHP message: PHP Warning:  Declaration of CustomBlockPlugin::getEnabled() should be compatible with BlockPlugin::getEnabled($contextId = NULL) in /home/linguamatica/root/plugins/generic/customBlockManager/CustomBlockPlugin.inc.php on line 0
PHP message: PHP Warning:  Declaration of SettingsFileUploadForm::fetch($request, $params = NULL) should be compatible with Form::fetch($request, $template = NULL, $display = false) in /home/linguamatica/root/lib/pkp/controllers/tab/settings/form/SettingsFileUploadForm.inc.php on line 18
PHP message: PHP Warning:  Declaration of NewContextImageFileForm::fetch($request) should be compatible with SettingsFileUploadForm::fetch($request, $params = NULL) in /home/linguamatica/root/lib/pkp/controllers/tab/settings/appearance/form/NewContextImageFileForm.inc.php on line 18
PHP message: PHP Warning:  Declaration of NewContextImageFileForm::initData($request) should be compatible with Form::initData() in /home/linguamatica/root/lib/pkp/controllers/tab/settings/appearance/form/NewContextImageFileForm.inc.php on line 18
PHP message: PHP Warning:  Declaration of NewContextImageFileForm::execute($request) should be compatible with Form::execute() in /home/linguamatica/root/lib/pkp/controllers/tab/settings/appearance/form/NewContextImageFileForm.inc.php on line 18
PHP message: PHP Notice:  Only variables should be assigned by reference in /home/linguamatica/root/lib/pkp/classes/file/TemporaryFileDAO.inc.php on line 37" while readin

#46

Hi @ambs,

Those warnings aren’t relevant, I don’t think. Do you get a message through the UI when you try to upload a PNG?

Regards,
Alec Smecher
Public Knowledge Project Team


#47

Hi, @asmecher
Yep, it says it has an invalid format or that the field is empty (you have a screenshot above in the thread, although with the PT message).


#48

Hi @ambs,

Have a look through Error message on upload: "No file uploaded or invalid file type!".

Regards,
Alec Smecher
Public Knowledge Project Team


#49

Hi, @asmecher,
Sorry for taking so much time lately :wink:

Well, I tried a small script to test if I have finfo, and to detect what magic file to use. This is the script.

<?php
$finfo = new finfo(FILEINFO_MIME, "/usr/share/file/magic.mgc");
$filename = "/root/linguamatica.png";
echo $finfo->file($filename);
?>

Running it against the image, I get the expected image/png; charset=binary
I both tried commenting out the mime_database_path or to define it with that same magic file.
I had no luck.

So, it looks like an upload problem? Checked php.ini from php7.2-fpm and it has upload support. Will keep digging. Any idea, let me know. Thanks


#50

Hi @ambs,

If it’s an upload problem, then the usual cause is file permissions. To get a better sense of what OJS is doing rather than using external test scripts (which are useful but sometimes only approximate), you could use error_log statements in lib/pkp/classes/core/PKPString.inc.php in the mime_content_type function.

Regards,
Alec Smecher
Public Knowledge Project Team


#51

Good Morning, @asmecher,

Yesterday night tried debugging OJS as you suggested. My main problem is that, as I am running php-fpm with nginx, error messages get truncated at 1024 bytes. As I posted above, a lot of warnings from PHP 7.2 are taking up all the error space.

As my PHP is quite limited, would you be interested in showing me the needed changes to one of those functions (say CustomBlockPlugin:getBlockContext) and I would apply that to other warnings, and prepare a pull request later? It would both help me finding what is going on, and help the project with those fixes.

Cheers,


#52

Hi @ambs,

I think it would probably be useful to set up your server so that the PHP error log is useful. Rather than having nginx manage the PHP error log, use the error_log directive in php.ini to have it store the PHP errors separately (and without the 1024B limit).

We’re working to resolve the warnings, and I’ve already done some since the 3.1.1 release, but it’ll be a long battle to match PHP’s changed expectations in such a large codebase.

Regards,
Alec Smecher
Public Knowledge Project Team


#53

Hi, @asmecher, good point. No idea why I didn’t think of that earlier. Doing it now.

And yep, permissions on public folder :frowning:

Curiously, now the journal thumbnails do not appear, they are being looked in the public folder, instead of files…


#54

Gosh, I have no luck. Now is the TinyMCE upload that is failing. And no log either in the php log or in the TinyMCE window.


#55

Hi @ambs,

Remind me – are you upgrading to 3.1.0-1, or 3.1.1?

The TinyMCE-based upload is a bit of a special case, so I wouldn’t use it as a test case for debugging uploads in general.

Regards,
Alec Smecher
Public Knowledge Project Team


#56

Hi. I am running 3.1.1 now. The generic upload problem is solved. Now I was trying to configure the journal website, and trying TinyMCE to configure a personalized footer.