Cant upgrade my ojs 3.0.2.0 to 3.2.1.1

I tried to upgrade my ojs from 3.0.2.0 to 3.2.1.1, but I could not and faced 500 error, I finally restore my backup and my site work fine with previous version (my current version still is 3.0.2.0).

is it possible to update my ojs from 3.0.2.0 to 3.2.1.1 directly?

It does not work for me because my 3.0.2.0 ojs website does not work with php 7 and above (my current php version is 5.6) and you know that the latest version of ojs works with php 7 and above so I cant directly install it from 3.0.2 to 3.2.1 because of php version , I should mention that I change my drive at confige.inc.php to mysqli and it does not work yet.

Hi @masoume_tm,

It should be possible to upgrade directly from 3.0.2-0 to 3.2.1-1. You can run the OJS 3.2.1-1 upgrade script using PHP7 and it’ll convert your database without needing PHP5.6. Can you check your PHP error log for specifics? The 500 error should result in details being recorded there.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

dear asmecher,
Finally, the current version of my ojs (3.0.2.0) worked with php version 7.2.
But when I tried to update it to the latest version, I got the following error.

I saw in other topics in forum that you wrote this error occurs when I had a failed upgrade before this upgrade. But I should mention that after a failed upgrade last month, I managed to restore the backup which I took before any upgrading. And after that my site worked properlytill now and today when I tried to upgrade my OJS site, I did not have any unsuccessful upgrade and it was my first attempt.

Stack trace:
#0 /home/IDname/public_html/jivr/lib/pkp/classes/db/DAO.inc.php(103): DAO->handleError(Object(ADODB_mysqli), ‘SELECT\t* FROM n…’)
#1 /home/IDname/public_html/jivr/lib/pkp/classes/navigationMenu/NavigationMenuItemDAO.inc.php(51): DAO->retrieve(‘SELECT\t* FROM n…’, Array)
#2 /home/IDname/public_html/my_journal/lib/pkp/classes/services/PKPNavigationMenuService.inc.php(638): NavigationMenuItemDAO->getByPath(1, ‘article/cite/32…’)
#3 /home/IDname/public_html/my_journal/lib/pkp/classes/plugins/HookRegistry.inc.php(107): PKP\Services\PKPNavigationMenuService->_callbackHandleCustomNavigationMenuItems(‘LoadHandler’, Array)
#4 /home/IDname/public_html/my_journal/lib/pkp/classes/core/PKPPageRouter.inc.php(187): HookRegistry::call(‘LoadHandler’, Array)
#5 /home/IDname in /home/IDname/public_html/my_journal/lib/pkp/classes/db/DAO.inc.php on line 703
[14-Nov-2020 13:32:00 UTC] Table ‘submission_galley_settings’ already exists

I should mention that there was no error on my error log till upgrading except this one.

Your cooperation will make me grateful.
regards,
Masoume

Hi @masoume_tm,

When you restored from backup, did you also DROP and then CREATE your database? If not, and you just re-loaded the dump over top of the existing database, then there are likely database tables left in place from the upgrade process. These will interfere.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Thanks,
no I didn’t drop and create new one.

What can I do now for upgrading my website successfuly?
Drop database, creat new one and export my previous database? but if my previous one contain that submission gallary ehat can I do?

Because my database in first attempt of upgrading show such error message.

How can I upgrade my website now?

Regards

Hi @masoume_tm,

Do you still have your 3.0.2-0 database dump? If so, you could check your database to see which tables are present in production that aren’t present in the dump. That should suggest which should be dropped (you can post the list here for a second opinion before dropping anything).

Regards,
Alec Smecher
Public Knowledge Project Team

Yes I have, my site version is 3.0.2.0, and unfortunately I do not have a clear backup of my database. My earliest backup is a database with tables that I list below as you asked:

access_keys

announcements

announcement_settings

announcement_types

announcement_type_settings

articles_migration

article_files_migration

article_galley_settings

article_supplementary_files

article_supp_file_settings

authors

author_settings

auth_sources

books_for_review

books_for_review_authors

books_for_review_settings

captchas

citations

citation_settings

comments

completed_payments

controlled_vocabs

controlled_vocab_entries

controlled_vocab_entry_settings

custom_issue_orders

custom_section_orders

dataverse_files

dataverse_studies

data_object_tombstones

data_object_tombstone_oai_set_objects

data_object_tombstone_settings

edit_assignments

edit_decisions

email_log

email_log_users

email_templates

email_templates_data

email_templates_default

email_templates_default_data

event_log

event_log_settings

external_feeds

external_feed_settings

filters

filter_groups

filter_settings

genres

genre_settings

gifts

groups

group_memberships

group_settings

institutional_subscriptions

institutional_subscription_ip

issues

issue_files

issue_galleys

issue_galley_settings

issue_settings

item_views

journals

journal_settings

library_files

library_file_settings

metadata_descriptions

metadata_description_settings

metrics

mutex

notes

notifications

notification_mail_list

notification_settings

notification_subscription_settings

oai_resumption_tokens

objects_for_review

object_for_review_assignments

object_for_review_persons

object_for_review_settings

paypal_transactions

pln_deposits

pln_deposit_objects

plugin_settings

processes

published_submissions

queries

query_participants

queued_payments

referrals

referral_settings

review_assignments

review_files

review_forms

review_form_elements

review_form_element_settings

review_form_responses

review_form_settings

review_object_metadata

review_object_metadata_settings

review_object_types

review_object_type_settings

review_rounds

review_round_files

roles

rt_contexts

rt_searches

rt_versions

scheduled_tasks

sections

section_editors

section_settings

sessions

signoffs

site

site_settings

stage_assignments

static_pages

static_page_settings

submissions

submissions_tmp

submission_artwork_files

submission_comments

submission_files

submission_file_settings

submission_galleys

submission_galley_settings

submission_html_galley_images

submission_search_keyword_list

submission_search_objects

submission_search_object_keywords

submission_settings

submission_supplementary_files

submission_tombstones

submission_xml_galleys

subscriptions

subscription_types

subscription_type_settings

temporary_files

theses

usage_stats_temporary_records

users

user_groups

user_group_settings

user_group_stage

user_interests

user_settings

user_user_groups

versions

Regards,

Hi @masoume_tm,

Unfortuantely I don’t have a database dump from OJS 3.0.2 to compare this against. One way to get that would be to make a fresh install of that version in a different database, then compare the two lists.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

then after compering, only droping tables which are not exist in that fresh install is enough?
regards,

Hi @masoume_tm,

That’s the idea – but I’d recommend checking back here to make sure. And of course please take good backups before doing any of this.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

I installed a new ojs 3.0.2 and I find below tables (112 table but I have 147 table on my database), But what was interesting to me is that the error I encounter when upgrading my journal site is Table ‘submission_galley_settings’ already exists, as you can see, this table also exists in the original database version 3.0.2.
What is the reason? And what should I do now? What is your suggestion?

access_keys
announcements
announcement_settings
announcement_types
announcement_type_settings
authors
author_settings
auth_sources
citations
citation_settings
completed_payments
controlled_vocabs
controlled_vocab_entries
controlled_vocab_entry_settings
custom_issue_orders
custom_section_orders
data_object_tombstones
data_object_tombstone_oai_set_objects
data_object_tombstone_settings
edit_decisions
email_log
email_log_users
email_templates
email_templates_data
email_templates_default
email_templates_default_data
event_log
event_log_settings
filters
filter_groups
filter_settings
genres
genre_settings
gifts
institutional_subscriptions
institutional_subscription_ip
issues
issue_files
issue_galleys
issue_galley_settings
issue_settings
item_views
journals
journal_settings
library_files
library_file_settings
metadata_descriptions
metadata_description_settings
metrics
mutex
notes
notifications
notification_mail_list
notification_settings
notification_subscription_settings
oai_resumption_tokens
paypal_transactions
plugin_settings
processes
published_submissions
queries
query_participants
queued_payments
review_assignments
review_files
review_forms
review_form_elements
review_form_element_settings
review_form_responses
review_form_settings
review_rounds
review_round_files
rt_contexts
rt_searches
rt_versions
scheduled_tasks
sections
section_editors
section_settings
sessions
site
site_settings
stage_assignments
static_pages
static_page_settings
submissions
submission_artwork_files
submission_comments
submission_files
submission_file_settings
submission_galleys
submission_galley_settings
submission_html_galley_images
submission_search_keyword_list
submission_search_objects
submission_search_object_keywords
submission_settings
submission_supplementary_files
submission_tombstones
subscriptions
subscription_types
subscription_type_settings
temporary_files
usage_stats_temporary_records
users
user_groups
user_group_settings
user_group_stage
user_interests
user_settings
user_user_groups
versions

Regards,

Hi @masoume_tm,

The problem with submission_galley_settings could be caused by the presence of another table that shouldn’t be there.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Hi, thanks.
Additional tables in my database compared to the main tables of the current versionof my ojs (3.0.2.0) are the following 35 tables, in your opinion, droping these 35 tables will solve the problem of updating the site? I will definitely make a backup before dropping the tables.

articles_migration
article_files_migration
article_galley_settings
article_supplementary_files
article_supp_file_settings
books_for_review
books_for_review_authors
books_for_review_settings
captchas
comments
dataverse_files
dataverse_studies
edit_assignments
external_feeds
external_feed_settings
groups
group_memberships
group_settings
objects_for_review
object_for_review_assignments
object_for_review_persons
object_for_review_settings
pln_deposits
pln_deposit_objects
referrals
referral_settings
review_object_metadata
review_object_metadata_settings
review_object_types
review_object_type_settings
roles
signoffs
submissions_tmp
submission_xml_galleys
theses

regards,
Masoume Tamasoki

Hi @masoume_tm,

These tables break into several categories:

  • Tables belonging to OJS 2.x plugins – these probably won’t cause problems:
    • books_for_review
    • books_for_review_authors
    • books_for_review_settings
    • dataverse_files
    • dataverse_studies
    • objects_for_review
    • object_for_review_assignments
    • object_for_review_persons
    • object_for_review_settings
    • pln_deposits
    • pln_deposit_objects
    • external_feeds
    • external_feed_settings
    • review_object_metadata
    • review_object_metadata_settings
    • review_object_types
    • review_object_type_settings
    • theses
    • submission_xml_galleys
    • referrals
    • referral_settings
  • Tables that appear to be from OJS 2.x and should be removed:
    • captchas
    • groups
    • group_memberships
    • group_settings
    • roles
    • signoffs
    • edit_assignments
    • article_galley_settings
    • comments
    • article_supplementary_files
    • article_supp_file_settings
  • Tables that appear to be left over from a failed upgrade – these should be removed:
    • articles_migration
    • article_files_migration
    • submissions_tmp

Please do keep a copy of anything that you remove, just in case.

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Thanks very much, I did this and was finally able to update the site but:

  1. The submission section of the site does not work and the following error is displayed in the php error Log:

[18-Nov-2020 17:03:11 UTC] PHP Fatal error: Uncaught Error: Call to a member function getData() on null in /home/public_html/jivr/lib/pkp/classes/submission/PKPSubmission.inc.php:54
Stack trace:
#0 /home/public_html/jivr/pages/article/ArticleHandler.inc.php(83): PKPSubmission->getBestId()
#1 /home/public_html/jivr/lib/pkp/classes/core/PKPRouter.inc.php(388): ArticleHandler->initialize(Object(Request), Array)
#2 /home/public_html/jivr/lib/pkp/classes/core/PKPPageRouter.inc.php(231): PKPRouter->_authorizeInitializeAndCallRequest(Array, Object(Request), Array, false)
#3 /home/public_html/jivr/lib/pkp/classes/core/Dispatcher.inc.php(143): PKPPageRouter->route(Object(Request))
#4 /home/public_html/jivr/lib/pkp/classes/core/PKPApplication.inc.php(279): Dispatcher->dispatch(Object(Request))
#5 /home/public_html/jivr/index.php(68): PKPApplication->execute()
#6 {main}
thrown in /home/public_html/jivr/lib/pkp/classes/submission/PKPSubmission.inc.php on line 54
[18-Nov-2020 17:04:48 UTC] ojs2: 404 Not Found

  1. In the site archive, only the title of the archive is included and there is no news of articles anywhere on the site
  2. Although the site has been updated to version 3.2.1.1, but in system info it shows the site version 3.0.2.0.

Regards

Hi @masoume_tm,

Looking at:

Fatal error: Uncaught Error: Call to a member function getData() on null in /home/public_html/jivr/lib/pkp/classes/submission/PKPSubmission.inc.php:54

…and…

Although the site has been updated to version 3.2.1.1, but in system info it shows the site version 3.0.2.0.

…and the presence of articles_migration, article_files_migration, submissions_tmp in your backup, I don’t think the upgrade process wasn’t completed successfully. When you ran the upgrade process, you either received a confirmation message that the upgrade was successful, or an error message indicating failure. The above details confirm that it was a failure. Do you know what the error message was?

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

hi, thanks for your response. this is my errors while upgrading to 3.2.1.2 (the latest version):

[19-Nov-2020 13:58:37 UTC] PHP Fatal error: Uncaught ArgumentCountError: Too few arguments to function Article::getCoverImage(), 0 passed in /home/mysite/public_html/myabbriviation/cache/t_compile/0baabeb3dec3fddc1143e5d555f59d15b6913999^%%17^178^1786CABF%%article_details.tpl.php on line 26 and exactly 1 expected in /home/mysite/public_html/myabbriviation/classes/article/Article.inc.php:243

Stack trace:

#0 /home/mysite/public_html/myabbriviation/cache/t_compile/0baabeb3dec3fddc1143e5d555f59d15b6913999^%%17^178^1786CABF%%article_details.tpl.php(26): Article->getCoverImage()

#1 /home/mysite/public_html/myabbriviation/lib/pkp/lib/vendor/smarty/smarty/libs/Smarty.class.php(1870): include(’/home/mysite/…’)

#2 /home/mysite/public_html/myabbriviation/lib/pkp/classes/template/PKPTemplateManager.inc.php(362): Smarty->_smarty_include(Array)

#3 /home/mysite/public_html/myabbriviation/cache/t_compile/0baabeb3dec3fddc1143e5d555f59d15b6913999^%%2D^2D7^2D7EC92F%%article.tpl.php(27): PKPTemplateManager->_smarty_include(Array)

#4 /home/mysite/public_html/myabbriviation/lib/pkp/lib/vendor/smarty/smarty/libs/Smarty.class. in /home/mysite/public_html/myabbriviation/classes/article/Article.inc.php on line 243

[19-Nov-2020 14:01:47 UTC] PHP Fatal error: Uncaught Error: Call to a member function getId() on null in /home/mysite/public_html/myabbriviation/classes/install/Upgrade.inc.php:2504

Hi @masoume_tm,

See: Problem upgrading from 3.0.2.0 to 3.1.2.1

Regards,
Alec Smecher
Public Knowledge Project Team


Hi, as you can see it does not have a key field.
Regards

Hi @masoume_tm,

Hmm, it looks like OJS 3.0.2-0 is too old to allow editing the key field through the user interface (it was added with this issue. If you’re handy with databases, the best thing to do might be to create the “HTML Stylesheet” component, if it doesn’t already exist, then manually edit the key field in the genres table for the new entry and set it to STYLE.

Regards,
Alec Smecher
Public Knowledge Project Team