“Suddenly” I am unable to view installed plugins (although I can view available plugins), I just get a spinning loading circle of death. When trying to view plugins I get the following error for all journals when clicking Settings->Website:
Warning: Cannot modify header information - headers already sent by (output started at /customers/9/2/7/c3lqi88hb/webroots/yyyy/plugins/blocks/keywordCloud/KeywordCloudBlockPlugin.inc.php:1) in /customers/9/2/7/c3lqi88hb/webroots/yyyy/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 917 Warning: Cannot modify header information - headers already sent by (output started at /customers/9/2/7/c3lqi88hb/webroots/yyyy/plugins/blocks/keywordCloud/KeywordCloudBlockPlugin.inc.php:1) in /customers/9/2/7/c3lqi88hb/webroots/yyyy/lib/pkp/classes/template/PKPTemplateManager.inc.php on line 918
Where do I start?
Need to add that this used to work, and I have done nothing to the installation or the server. As it is now I cannot add the DOI plugin which was the last step of publishing this year’s last journal.
It sounds like there might be a blank line or an empty space at the top of the KeywordCloudBlockPlugin.inc.php file now, and it’s breaking the returned JSON needed to populate the plugin grid.
As a test, try chmodding to 000 the plugins/block/keywordCloud directory to see if the problem goes away. If it does, you’ll need to probably reinstall the keyword cloud plugin or at least figure out why there is blank space there now.
Ok. Will need to get hold of my hosting provider to look at that file then because my SSH login is no longer working.
Trying to update the keywordCloud gave me the following error: Tar command not available. Configure correctly in «config.inc.php».
I guess I’ll have to get my hosting provider for that as well? What is needed server side to allow Tar to run for installing updating plugins?
I constantly have the feeling that OJS is just a sneeze away from breaking down in some way or another. Now I need to get it running before I can consider updating to the latest build. Still dreaming of a big shiny “update to latest build” button.
There’s a configuration option in the config.inc.php file that should point to your tar binary on the server. It’s usually in /bin/tar or /usr/bin/tar. If it used to work but no longer does, it’s possible your hosting provider entire changed where the binary is, or else maybe turned on safe mode and it is no longer available to you.
The upgrade process will become substantially easier (and more robust) beginning in 3.4.
Tried switching to php8.0 from 8.2. But that changed nothing. So I set it back to 8.2 and now nothing works. I get “Fatal error: Cannot declare class XMLParser, because the name is already in use in /r000000/lib/pkp/classes/xml/XMLParser.inc.php on line 28”. So can switching back and fort between php versions break PJS or is my ISP moving things around without informing us?
We are trying to upgrade to 18.104.22.168 from 22.214.171.124. New version of OJS has been uploaded. But it failed when upgrading the database.
At the moment we are struggling to re-import an sql dump of our “old” 3.2 database to the new server. The new server is running MariaDB 10.6.x while the old one was at 10.3.x.
It only uploads 130 tables. After some finiggling it imports 142 tables. Is the sql dump incomplete or does if fail during import? How do I know?
Ran upgrade because we couldn’t get any further. Gave us this ERROR:
ERROR: Upgrade failed: DB: SQLSTATE: Syntax error or access violation: 1091 Can’t DROP INDEX review_round_files_pkey; check that it exists (SQL: alter table review_round_files drop index review_round_files_pkey).
I am assuming that this is because there are tables missing.
Tried finding the correct number of tables for the OJS 3 db online but had no luck. At least we’d know it was complete before trying anything else.
There isn’t really a great way to identify a database that’s the result of a failed upgrade because the upgrade could fail in a variety of ways. What you may want to do is run another mysqldump but use a --no-data option so you only get the database structure. Then dump the structure for a fresh install of 3.3 and perhaps compare the two files with a diff -u (unified diff) statement to see where things are different. You could also do the same and compare to a fresh installation of 3.2.1.
Finally managed to upgrade the database. Turns out our initial sql database backup was incomplete, and then the db upgrade failed, leaving us with one incomplete dump and a broken db. Our host had to recover a copy of the database from december.
Also had to convert all myisam tables to innodb as per another thread.
Now everything seems to be back in place, except we cannot upload files when creating new articles. Started a new thread for this issue.