Error when check upgrading from 3.3.0.15 to 3.3.0.17 (PKPLocale.inc.php:292)

I was trying to upgrade from OJS 3.3.0.15 to 3.3.0.17 following instructions on https://docs.pkp.sfu.ca/dev/upgrade-guide/en/, but when I run the command php tools/upgrade.php check, I get the error

PHP Fatal error:  Uncaught Error: Call to undefined function putenv() in /var/www/revista/ojs/lib/pkp/classes/i18n/PKPLocale.inc.php:292
Stack trace:
#0 /var/www/revista/ojs/lib/pkp/classes/cliTool/CliTool.inc.php(64): PKPLocale::initialize()
#1 /var/www/revista/ojs/lib/pkp/classes/cliTool/UpgradeTool.inc.php(36): CommandLineTool->__construct()
#2 /var/www/revista/ojs/tools/upgrade.php(21): UpgradeTool->__construct()
#3 {main}
  thrown in /var/www/revista/ojs/lib/pkp/classes/i18n/PKPLocale.inc.php on line 292

It’s installed and running in an Ubuntu 22.04 webserver (Apache 2.4, MySQL 8.0, PHP 8.0), in Brazilian Portuguese (pt_BR) language (pt_PT and es_ES languages also installed on OJS). I tried changing the language to English before the upgrade, but got the same error.

I tried this same upgrade before, in a sandbox server “almost” like this one (same Ubuntu, Apache, MySQL and PHP versions), with the same languages installed on OJS (and running in pt_BR), and it worked just fine.

The main differences between the OJS in the sandbox server and the one on the production server (where the upgrade failed) is that on the production’s OJS salt, smtp, and recaptcha are enabled and configured (and working). I disabled them and tried to upgrade, but got the same error.

The PHP on the production server has more modules enabled and configured than the sandbox (apcu, imagick, memcached, redis, JIT and opcache).

Other difference is that the production server has much more users and content on OJS.

(Note: I tried to run php tools/upgrade.php check on the current version of OJS (3.3.0.15), and got the same error).

Edit this file: PKPLocale.inc.php (lib/pkp/classes/i18n/PKPLocale.inc.php)

find this line
AppLocale::registerLocaleFile($locale, “lib/pkp/locale/$locale/common.po”);
after this line add this code
if ($locale == ‘pt_BR’) setlocale(LC_CTYPE, ‘en_US’);
if ($locale == ‘es_ES’) setlocale(LC_CTYPE, ‘en_US’);

try again.

Hi, thanks for your response!
Actually I was able to solve this problem doing this:

  1. Through command line, accessed the directory where OJS was installed (in my case /var/www/revista/ojs) using:
cd /var/www/revista/ojs
  1. Locate the php.ini file in use for the command line, using:
php --ini

The response was:

(...)
Loaded Configuration File:         /etc/php/8.1/cli/php.ini
(...)
  1. Opened this file for edition using:
sudo nano /etc/php/8.1/cli/php.ini
  1. Locate the funcion putenv in the disable_functions = line, and removed it, so the line:
disable_functions = posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,pcntl_exec,**putenv**,system,exec,shell_exec,passthru,proc_open,popen,dl,proc_close

became:

disable_functions = posix_getpwuid,posix_setpgid,posix_setsid,posix_setuid,pcntl_exec,system,exec,shell_exec,passthru,proc_open,popen,dl,proc_close
  1. Saved (with <Ctrl>+S) and closed (<Ctrl>+X) the file, and restarted my PHP-FPM with:
sudo systemctl restart php8.1-fpm.service

What happened to me is that I have several virtual hosts on the same server, using different versions of PHP. Since OJS was on the virtual host using PHP 8.0, I had already made this change on the php.ini file of this version (PHP 8.0), but it didn’t work because the CLI (command line) was running the PHP 8.1 version…

Thanks for the attention!

1 Like