Installed plugins not loading

“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/ in /customers/9/2/7/c3lqi88hb/webroots/yyyy/lib/pkp/classes/template/ 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/ in /customers/9/2/7/c3lqi88hb/webroots/yyyy/lib/pkp/classes/template/ 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.

Hi @geirrosset

It sounds like there might be a blank line or an empty space at the top of the 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 «».

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 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.


Looking at our webserver it has been upgraded to php8 without notifying us. Could that be the culprit? read somewhere that v 8 is unsupported…

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/ on line 28”. So can switching back and fort between php versions break PJS or is my ISP moving things around without informing us?

Hi @geirrosset

What version of OJS are you using? OJS 3.3 is compatible with PHP8.0 (although there may be third party plugins that are not). I suspect that it may not be compatible with 8.2.


We are trying to upgrade to from 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[42000]: 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.

Hi @geirrosset

If you look at your SQL dump in a text editor, there’ll be a line right at the bottom that says something like:

-- Dump completed on 2022-12-02 9:22:14

And the very last table in the dump will generally always be the versions table.

This would explain some of your previous comments here, since OJS 3.2 is not compatible with PHP8.


The last line is:

(128, ‘’, ‘doaj::status’, 'markedRegistered

So I guess it did not export correctly.

How do we dump/export the database if phpMyadmin can’t do it properly?


Hi @geirrosset

at PKP Publishing Services we always use the mysqldump command line utility. The syntax is:

mysqldump -u yourUser -p yourDatabase --opt --default-character-set=utf8 --result-file=database.sql

which will prompt you for your password.


Any special way to import it?

Export using the finished successfully (apparently), and import seems to finish as it should, but upgrade (both CLI and GUI) quits with error:

  • A database error has occurred: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘url’ in ‘field list’ (SQL: select url, navigation_menu_item_id from navigation_menu_items where context_id = 2)

Apache 2.4.18
PHP 8.0.5
MySQL (MariaDb 10.6.11)
Ubuntu 16.4.7

Are you sure you’re working off a database that has never had an upgrade attempt before? There’s definitely supposed to be a url column in the navigation_menu_items table:

However, this column is ultimately dropped during the upgrade to 3.3.0, here:

So it sounds like your OJS 3.2.1 database backup was made after you previously tried to upgrade to 3.3, and it failed. You’d need a copy of the database from before any upgrade attempts were made.


I can’t remember trying to upgrade. Very strange. How can I identify a db that has had a failed upgrade?

The first hit for “navigation_menu_items” in the SQL dump is:

– Table structure for table navigation_menu_items

DROP TABLE IF EXISTS navigation_menu_items;
/*!40101 SET @saved_cs_client = @@character_set_client /;
!50503 SET character_set_client = utf8mb4 /;
CREATE TABLE navigation_menu_items (
navigation_menu_item_id bigint(20) NOT NULL AUTO_INCREMENT,
context_id bigint(20) NOT NULL,
path varchar(255) DEFAULT ‘’,
type varchar(255) DEFAULT ‘’,
PRIMARY KEY (navigation_menu_item_id)
!40101 SET character_set_client = @saved_cs_client */;

Hi @geirrosset

That’s definitely a table from OJS 3.3. Looking at another installation I have here, I have:

so I have no url column present.

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.