OJS 3.1.1-4/3.2.1-1 Configuration Questions

My organization is transitioning from a system running OJS v3.1.1-4 to a system running v3.2.1-1. With that in mind, my configuration questions are…

  1. If the OJS configuration details don’t match, what kind of breakage, if any, can we expect to see when we import our data from the old system into the new system?
  2. Is there a way to query, print, or otherwise extract the configuration info for an OJS install?
  3. Is there any documentation that describes each of the fields in OJS’s Command Line Interface configuration process?
  4. Are there any documented ways to script an OJS CLI configuration process?

Hi @cbirmingham,

Have you reviewed the upgrade documentation? See docs/UPGRADE.md in your OJS package.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi Alec,

To clarify, what I’m doing is standing up a brand new system running the latest version of OJS and importing XML data from a existing system with a slightly older OJS version. While we have the data export from that existing system, we have no access to the system itself, so we can’t really see how OJS is configured on that system. Having said that, I’ve looked over the UPGRADE.md documentation, and also revisited the README.md file and the IMPORTEXPORT doc just in case they contained the information I need.

In this case, what I’m really after is more clarity on the CLI configuration process that kicks off from the command “php tools/install.php”. Is there any documentation that goes into detail on this process & each of the entries for it? Do the responses in this section get stored in config.inc.php? If I enter a database name (or repository identifier) that differs from what’s used in the current instance, and try to import data from that one to this new instance, will that cause any issue?

The following is a run-through of some trial entries and what I got as a result:

  • Primary Locale : en_US
  • Additional Locales : None
  • Client Character set: utf-8
  • Connection Character set : None
  • File Settings
    • Directory for uploads : /opt/ojs
  • Administrator Account
    • username : adminuser
    • password : adminpass
    • Repeat password : adminpass
    • Email : cbirmingham@fsu.edu
  • Database Settings
    • Database driver : mysql
    • Host : localhost
    • Username : fsuojs
    • Password : fsuojs
    • Database name : ojs
    • Create new database : Y
  • ##installer.miscSettings##
    • Repository Identifier : fsuojs
    • Provide a unique site ID and OAI base URL to PKP for statistics and security alert purposes only. : y
  • *** Install Open Journal Systems : y

PHP Fatal error: Uncaught Error: Call to undefined function mysql_connect() in /var/www/html/ojs/lib/pkp/lib/vendor/adodb/adodb-php/drivers/adodb-mysql.inc.php:461
Stack trace:
#0 /var/www/html/ojs/lib/pkp/lib/vendor/adodb/adodb-php/adodb.inc.php(683): ADODB_mysql->_connect(‘localhost’, ‘fsuojs’, ‘fsuojs’, ‘’)
#1 /var/www/html/ojs/lib/pkp/classes/db/DBConnection.inc.php(162): ADOConnection->Connect(‘localhost’, ‘fsuojs’, ‘fsuojs’, NULL, false)
#2 /var/www/html/ojs/lib/pkp/classes/db/DBConnection.inc.php(137): DBConnection->connect()
#3 /var/www/html/ojs/lib/pkp/classes/db/DBConnection.inc.php(124): DBConnection->initConn()
#4 /var/www/html/ojs/lib/pkp/classes/db/DBConnection.inc.php(56): DBConnection->initCustomDBConnection(‘mysql’, ‘localhost’, ‘fsuojs’, ‘fsuojs’, NULL, false, false)
#5 /var/www/html/ojs/lib/pkp/classes/install/PKPInstall.inc.php(77): DBConnection->__construct(‘mysql’, ‘localhost’, ‘fsuojs’, ‘fsuojs’, NULL, false, false)
#6 /var/www/html/ojs/lib/pkp/classes/install/Installer.inc.php(178): PKPInstall->preInst in /var/www/html/ojs/lib/pkp/lib/vendor/adodb/adodb-php/drivers/adodb-mysql.inc.php on line 461

Hi,

You should try using MySQLi instead of MySQL. That should solve your problem.

Hi all,

Also, @cbirmingham, just in case – if those are your actual credentials, please make sure to change them ASAP now that they’re published on the public forum.

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks, Alec. Those were just speed-run credentials I used.

1 Like

Hi,

I’ll give that a try. Thanks.

@pheckler, I tried using mysqli and got a similar error. I suspect that there might be a missing package causing this, so I’m going to try some usual suspects.

I figured that installing php-mysql might clear up the error I’m seeing here, but to no avail. It might be that there is something else I’ve mis-configured, or just plain missed, that’s causing this.

Hi @cbirmingham,

When you try the MySQLi driver, what is the exact message you see in your PHP log? It’ll be different than the one quoted above.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

If memory serves for this one, the error message looked similar except that it referenced mysqli_connect() instead of mysql_connect(). At this point, from our other conversation (Issues installing OJS v3.2.1-1), I think we can move past the error and circle back to the initial questions regarding how a data import is likely to behave if the destination OJS config doesn’t match the source OJS config. For instance, are we likely to see any import problems if there is a difference in database name, or repository identifier?

Hi @cbirmingham,

I don’t recommend exporting from one OJS and importing into another to perform a migration/upgrade. The XML import/export format isn’t intended to be backwards-compatible, so you’ll have to adapt the XML to account for differences between the two versions. But more importantly, the import/export XML only accounts for published content, not e.g. journal setup, peer review data, etc. You’ll lose a lot doing thing this way.

Any reputable service provider should give you proper access to your data, including a database dump. If you’re able to install plugins from the Plugin Gallery and are running in a single-journal environment, you can even do it yourself by installing the backup plugin, if your server has been configured with tar and mysqldump tools.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

Well, we’re in sort of a non-standard situation when it comes to migrating from the current OJS system. We don’t have many details on how that system is set up, and contact with the personnel that oversee that system is not very reliable at this time.

We might be able to secure a DB dump, archive /var/www directory and whatever else we’d need, but that process will be equal parts delicate & fluid.

I’ve informed my team of your latest recommendation, so we’ll just have to see what we can manage in that regard.

Thanks,
C. Birmingham II