I started testing updating from OJS 2.4.7.1 to 3.0. I copied the whole current OJS (over 30 GB with “files_dir”) and the copy was a base for testing the update. The copy of the OJS was moved to different base url, which was included in the config file. The update process initally outputs a series of the following warnings:
PHP Strict Standards: Only variables should be assigned by reference in /xxx/lib/pkp/classes/site/VersionDAO.inc.php on line 146, referer: xxx/index.php/index/install/installUpgrade
Strict Standards: Only variables should be passed by reference in /xxx/lib/pkp/lib/adodb/adodb-xmlschema.inc.php on line 268
PHP Warning: file_exists(): open_basedir restriction in effect. File(plugins/oaiMetadataFormats/README/READMEOaiMetadataFormatsPlugin.inc.php) is not within the allowed path(s): (/xxx) in /xxx/lib/pkp/classes/plugins/PluginRegistry.inc.php on line 233, referer: xxx/index.php/index/install/installUpgrade
PHP Deprecated: Non-static method Version::fromString() should not be called statically, assuming $this from incompatible context in /xxx/lib/pkp/classes/install/Installer.inc.php on line 243, referer: xxx/index.php/index/install/installUpgrade
and the updating process freezes for many hours, after which time, when I update via web browser, I end up with a message “The form was not submitted properly.”. Updating via cli just hangs up after showing many of the above-mentioned warnings. I have session_check_ip = Off. I also set config file to show errors but these are the same as shown above. I was trying to search something in the error logs of the server, but didn’t find aby particular entry. I am not sure where to investigate further?
The upgrade process may legitimately take a long time – it’s doing a lot of work. If you suspect it’s stuck, you could always try turning on the debug option in config.inc.php, which will dump all SQL queries to the user and will therefore show you whether something is happening or not. I would suggest working with the command-line upgrade tool.
Regards,
Alec Smecher
Public Knowledge Project Team
After a few tries the installation finally succeeded. From the first sight, I just noticed that some images are no longer visible, such as issues covers, journals logos, but home page images are present, as well as site logo. However, I’m happy to be able to finally test production version of the OJS 3.0.
Author Version files, which were deposited on the Review page, Editor Decision section in OJS 2. I suppose they should be on the Review tab now, Revisions section?
Review form contains “Array” word instead of original radio buttons labels (e.g., “Array” instead of “Yes”).
Review files on Review tab is empty, where I suppose should be placed Review Version file from the OJS2?
Would you be willing to provide me with a copy of your journal in order to do some testing? We’re aware of some of these issues (e.g. images) and are working on it, but others would be good to track down.
Thanks,
Alec Smecher
Public Knowledge Project Team
I would like to try to understand what is happening with the journal images after the upgrade. The images that were uploaded under “Title image” in Setup 5.1 and 5.3 are not used any more, thus they will not appear. But the images that were uploaded as “Journal Logo” and “Journal Thumbnail” in journal Setup 5.1 and 5.3 should be there after the upgrade as well. Could you please take a look and tell me what journal images did you have in OJS 2.4.x and if they are in the public folder after the migration (they have the following names: homeHeaderTitleImage…, homeHeaderLogoImage…, pageHeaderTitleImage…, pageHeaderLogoImage…, journalThumbnail…)?
In OJS 2 I used title images in step 5.1. and 5.3. (and homepage image
in 5.2. which I mentioned above), so, according to what you wrote, it is
ok they are not displayed. There is also favicon from step 5.3. which is
not displaying in OJS 3.
What I am concerned about more is that I cannot see issue covers
anymore, and their descriptions. Uploading new logos is not as time-
consuming as issue covers. And we used cover description to write
something about what is presented on the cover (biological structures
mostly often require some explanation and this is often practices in
journals), are these not used any more?
I copied the public folder before update, so it has the same files as in
OJS 2. I attach screen with a list of some of the files included.
In case you need some more details let me know.
Best,
Piotr
W dniu 22.10.2016 o 22:59 Bozana Bokan pisze:
bozana[1]
October 22
Hi @piotreba[2]
I would like to try to understand what is happening with the journal
images after the upgrade. The images that were uploaded under “Title
image” in Setup 5.1 and 5.3 are not used any more, thus they will not
appear. But the images that were uploaded as “Journal Logo” and
“Journal Thumbnail” in journal Setup 5.1 and 5.3 should be there after
the upgrade as well. Could you please take a look and tell me what
journal images did you have in OJS 2.4.x and if they are in the public
folder after the migration (they have the following names:
homeHeaderTitleImage…, homeHeaderLogoImage…,
pageHeaderTitleImage…, pageHeaderLogoImage…, journalThumbnail…)?
Thanks a lot!
Bozana
Visit Topic[3] or reply to this email to respond.
To stop receiving notifications for this particular topic, click
here[4].
To unsubscribe from these emails, change your user preferences[5].
If I remove the locale “en_US” and replace setting_name “fileName” with “coverImage” the cover shows up.The problem is that in some cases there are several cover images for different locales, but the current issue data form does not support locales for cover images anymore. On the bright side, at least on my installation everything using the “fileName” value in the issue_settings table seem to be issue covers.
So, I solved the problem with these queries (be sure to do a backup before running these):
UPDATE IGNORE issue_settings SET locale = ‘’ WHERE setting_name = ‘fileName’ AND setting_value != ‘’;
DELETE FROM issue_settings WHERE setting_name = ‘fileName’ AND setting_value = ‘’;
DELETE FROM issue_settings WHERE setting_name = ‘fileName’ AND locale != ‘’;
UPDATE issue_settings SET setting_name = ‘coverImage’ WHERE setting_name = ‘fileName’;
@asmecher, any problems with this solution I did not think of? Maybe this is something that could/should be fixed in the upgrade script?
