Take 3.3.0.3 version
•add pkp/pkp-lib#6703 Fix web-based upgrade form by asmecher · Pull Request #6719 · pkp/pkp-lib · GitHub fix
•add ‘engine’ => ‘InnoDB’, after this line
pkp-lib/PKPApplication.inc.php at 88c9965b2f601b79e034ceaff59d8a809b72943d · pkp/pkp-lib · GitHub
Enjoy the update…
1 Like
If it’s still not working after all of those steps, I’m not sure. I’m sorry.
- I should say that I updated from 3.2.1.4 to 3.3.0.3. Maybe that made a difference.
- If you look at the database manually, make sure you’re using utf8 and not latin1 or some other character set. I kept deleting my database and building a new one then uploading my sql file and may have created it at some point with latin1_swedish, but I corrected that throughout the file.
DEFAULT CHARSET=utf8
I was just doing search latin1 and replace with utf8 in Dreamweaver.
3) The only other thing that I can think of was that I took the new default config.inc file and simply filled in these five lines rather than copy my old config file into the new OJS upload:
[database]
driver = mysqli
*host = *****
*username = *****
*password = *****
*name = *****
Good luck HCsaba.
EDIT: Sorry, you should edit far more of the config file than just the database. You should be able to update with the old config file.
1 Like
Thank you for your help
I have reanalyzed this
Add this to line 36:
Application::get()->initializeDatabaseConnection();
and there was a typo …
Thank for your help!
3.3.0.3 needs this fix it seems
Thanks!!!
PS i also had a problem that our server looks for utf8 and not utf-8 …
PHP Fatal error: Uncaught PDOException: SQLSTATE[42000]: Syntax error or access violation: 1115 Unknown character set: ‘utf-8’
i should have RFM (read the manual)
Now it woks!!!
Have a great day
3 Likes
Thank you very much for your help and the good documentation of the errors. I was almost a bit desperate.
Despite the fixes I got the same problem as @HCsaba and could not solve it. So now I went through the console and upgraded it with php tools/upgrade.php upgrade`. This worked without any problems. However, an update was still not possible via the web interface.
Need to make a correction to my last post. You have to fix more than the database section of the config file. Just using the old config file works on wampserver.
I’m actually having different problems on my production server, so I’ll have to figure that out. D’oh.
1 Like
So I just wrestled with my production server over this upgrade for a while tonight. I narrowed my problem down to the configuration file and whether I typed in utf8 vs utf-8 vs utf8_general_ci. The solution? Just do what it says in the config template and you’ll avoid stress.
; Localization Settings ;
; Default locale
locale = en_US
; Client output/input character set
client_charset = utf-8
; Database connection character set
connection_charset = utf8
; Database Settings ;
; Database collation
; collation = utf8_general_ci
If you’re careless like I was, you’ll type in utf8, utf-8, or utf_8_general_ci consistently in all three spots and then keep reading one of two types of errors in the php error log.
Here’s a concern that I still have even though the journal is updated and running.
I realized early on tonight that I have in fact been using latin1_swedish_ci for my collation (must’ve accidentally done that when I first setup the journal many years ago). I used phpMyAdmin to change that to utf8_general_ci early in the process:
- Open your OJS database
- Click Operations in the top menu
- Under Collation, choose utf8_general_ci (assuming anyone else is using something else)
- Check the boxes beneath the drop menu for
Change all table collations
Change all tables columns collations - Click Go.
I seriously hope this change of collation won’t have any consequences down the road. Hopefully someone can reassure me… The journal looks fine now, so I’m not too worried…
EDIT
I doubled back and just updated with my backup database using latin1_swedish_ci as my collation but utf8 is all over the config file. The site is updated and running, but I have no idea how that has never been an issue over the years. Maybe someone can clue me in on whether its safe to switch to utf8 as I described above or stay with latin1. Should I change the config file?
1 Like
Just wanted to note that I had the same problem upgrading between the same versions; I’ve come from an old MySQL 5 database that must have been created with tables using the MyISAM engine. Most tables were MyISAM (about 75% of them), with the remaining tables being InnoDB; I imagine the former were from OJS v2 and the latter were created during the migration to v3.
My migration to v3.3 had failed part way through so I ended up having to disable any steps involving ->references('submission_file_id') in order to proceed. After the remainder of the migration finished, I ran this SQL:
ALTER TABLE submission_files ENGINE = InnoDB;
ALTER TABLE review_round_files ADD CONSTRAINT review_round_files_submission_file_id_foreign2 FOREIGN KEY (submission_file_id) REFERENCES submission_files (submission_file_id);
ALTER TABLE review_files ADD CONSTRAINT review_files_submission_file_id_foreign FOREIGN KEY (submission_file_id) REFERENCES submission_files (submission_file_id);
ALTER TABLE submission_file_revisions ADD CONSTRAINT submission_file_revisions_submission_file_id_foreign FOREIGN KEY (submission_file_id) REFERENCES submission_files (submission_file_id);
ALTER TABLE publication_galleys ADD CONSTRAINT plublication_galleys_submission_file_id_foreign FOREIGN KEY (submission_file_id) REFERENCES submission_files (submission_file_id);
I also needed to grant my database user REFERENCES permission as well; this wasn’t previously needed for OJS migrations (GRANT REFERENCES ON ojs.* TO 'ojsuser'@'localhost';).
Everything else seems okay at this point with the exception of adding Announcements, logged as [OJS 3.3] Cannot create Announcements: General error: 1364 Field 'setting_type' doesn't have a default value · Issue #6748 · pkp/pkp-lib · GitHub.
Given that MyISAM is deprecated, I took the opportunity to change all my remaining tables over to InnoDB just to head off any future issues with FKs.
1 Like
I just did a new OJS install on my wampserver. I let OJS create the database for me, and the collations are showing up as latin1 on phpMyAdmin even though the installation process gives me the option of utf8 and the config file is edited by OJS to say UTF8. I’m not going to edit the database to be UTF8 manually or through phpMyAdmin. At this point, I doubt its safe.
Anyone creating a journal for the first time should create a blank database ahead of time using UTF8_general_ci as the collation.
Just an FYI, cheers.
Last post. My website has errors (warped text and some submitted files links are broken), so I’m backing up. I’ll wait for the next version.
Hi @SilverBoot,
Can you describe the problems you encountered (warped text and broken links) in a little more detail?
Thanks,
Alec Smecher
Public Knowledge Project Team
I’m getting characters like these:
—
’s
instead of dashes and apostrophes. For instance, the page number listings for an article are
1–2 instead of 1-2.
One other thing is that the Administration menu link doesn’t work though I can get to it through the dashboard.
[11-Feb-2021 16:47:16 UTC] PHP Notice: Undefined variable: latestVersionInfo in /home/redactedjournalname/public_html/ojs/lib/pkp/pages/admin/AdminHandler.inc.php on line 361
Hi @SilverBoot,
Garbled characters (e.g. —) result from mismatches in character encoding – the technical term for this is “mojibake”. See e.g. this older thread, which has some general discussion.
Regards,
Alec Smecher
Public Knowledge Project Team