[OJS 3.3.0-20] Archive and Back Issues no load after upgrading PHP 7.4 to PHP 8.1

juancure · May 13, 2025, 2:36am

Hi I am testing the docker image for ojs 3.3.0-20 which use PHP 8.1.27 and I have found the following error when try to load the archive and back issues pages:

[Tue May 13 01:57:41.043142 2025] [php:error] [pid 25:tid 25] [client 192.168.2.1:49912] PHP Fatal error:  Uncaught TypeError: Cannot access offset of type string on string in /var/www/html/lib/pkp/classes/core/DataObject.inc.php:133
Stack trace:
#0 /var/www/html/lib/pkp/classes/db/DAO.inc.php(501): DataObject->setData()
#1 /var/www/html/classes/issue/IssueDAO.inc.php(309): DAO->getDataObjectSettings()
#2 /var/www/html/lib/pkp/classes/db/DAOResultFactory.inc.php(100): IssueDAO->_fromRow()
#3 /var/www/html/lib/pkp/classes/db/DAOResultIterator.inc.php(62): DAOResultFactory->next()
#4 [internal function]: DAOResultIterator->next()
#5 /var/www/html/pages/issue/IssueHandler.inc.php(136): iterator_to_array()
#6 /var/www/html/lib/pkp/classes/core/PKPRouter.inc.php(397): IssueHandler->archive()
#7 /var/www/html/lib/pkp/classes/core/PKPPageRouter.inc.php(246): PKPRouter->_authorizeInitializeAndCallRequest()
#8 /var/www/html/lib/pkp/classes/core/Dispatcher.inc.php(144): PKPPageRouter->route()
#9 /var/www/html/lib/pkp/classes/core/PKPApplication.inc.php(360): Dispatcher->dispatch()
#10 /var/www/html/index.php(68): PKPApplication->execute()
#11 {main} thrown in /var/www/html/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: http://192.168.2.98:8081/index.php/tip/article/view/703

[Tue May 13 01:59:47.395788 2025] [php:error] [pid 18:tid 18] [client 192.168.2.1:49954] PHP Fatal error:  Uncaught TypeError: Cannot access offset of type string on string in /var/www/html/lib/pkp/classes/core/DataObject.inc.php:133
Stack trace:
#0 /var/www/html/lib/pkp/classes/db/DAO.inc.php(501): DataObject->setData()
#1 /var/www/html/classes/issue/IssueDAO.inc.php(309): DAO->getDataObjectSettings()
#2 /var/www/html/classes/issue/IssueDAO.inc.php(321): IssueDAO->_fromRow()
#3 /var/www/html/lib/pkp/classes/db/DAOResultFactory.inc.php(100): IssueDAO->_returnIssueFromRow()
#4 /var/www/html/lib/pkp/classes/db/DAOResultFactory.inc.php(191): DAOResultFactory->next()
#5 /var/www/html/lib/pkp/classes/controllers/grid/GridHandler.inc.php(349): DAOResultFactory->toAssociativeArray()
#6 /var/www/html/lib/pkp/classes/controllers/grid/GridHandler.inc.php(321): GridHandler->setGridDataElements()
#7 /var/www/html/lib/pkp/classes/controllers/grid/GridHandler.inc.php(1032): GridHandler->getGridDataElements()
#8 /var/www/html/lib/pkp/classes/controllers/grid/GridHandler.inc.php(923): GridHandler->renderGridBodyPartsInternally()
#9 /var/www/html/lib/pkp/classes/controllers/grid/GridHandler.inc.php(643): GridHandler->doSpecificFetchGridActions()
#10 /var/www/html/lib/pkp/classes/core/PKPRouter.inc.php(397): GridHandler->fetchGrid()
#11 /var/www/html/lib/pkp/classes/core/PKPComponentRouter.inc.php(257): PKPRouter->_authorizeInitializeAndCallRequest()
#12 /var/www/html/lib/pkp/classes/core/Dispatcher.inc.php(144): PKPComponentRouter->route()
#13 /var/www/html/lib/pkp/classes/core/PKPApplication.inc.php(360): Dispatcher->dispatch()
#14 /var/www/html/index.php(68): PKPApplication->execute()
#15 {main} thrown in /var/www/html/lib/pkp/classes/core/DataObject.inc.php on line 133, referer: http://192.168.2.98:8081/index.php/tip/manageIssues

However when I load the same OJS using PHP 7.4.33 the problem isn’t appeared. I have read in the forum that others had had the same trouble and the solution was cleaning some registers in the database which could have NULL or empty values on some columns. However those solutions hadn’t worked for me. Can someone help me to resolve this trouble? Thanks.

dagosalas · May 13, 2025, 2:41am

Hola Juan!!
¿Borraste el cache del OJS después de actualizar el PHP?

juancure · May 13, 2025, 5:04pm

Que tal @dagosalas no estoy utilizando el mismo código en mi ambiente con PHP 7.4.33 y con PHP 8.1.

Me explico con más detalle, originalmente este OJS 3.3.0-20 estaba instalado en un ambiente con Nginx, PHP 7.4, PHP-FPM y Mysql 8.0, todos estos paquetes instalados directamente en el host.

Estoy haciendo pruebas con la imagen de OJS 3.3.0-20 en Docker, así que en otra máquina diferente, donde tengo instalado docker y docker compose, he logrado levantar este mismo OJS en contenedores (La verdad fue mucho prueba y error, jejeje, pero al fin lo logré). Para levantar este OJS en contendores de Docker seguí las instrucciones que aparecen en pkpoficial/ojs. La imagen de OJS en Docker utiliza la versión PHP 8.1.

Estos fueron los elementos que copie en el ambiente dockerizado:

Directorio files_dir
Directorio public
Directorio plugins
Archivo config.inc.php original
El respaldo de la base de datos dump.sql

No copie nungun otro directorio, ni tampoco el directorio cache, me da la impresión que el problema son algunos registros en la base de datos que pudieran tener valores nulos, pero no se cuales o como encontrarlos?

juancure · May 13, 2025, 7:49pm

it seems that I found a posible solution for this error. Afterwards activating the debug variable on the config.inc.php file I could see in the Apache log errors the following message:

Database query\nSELECT * FROM issue_settings WHERE issue_id = ?\n[21], referer: http://192.168.2.98:8081/index.php/tip

So this gave me the idea of searching in the issue_settings table and specifically the issue_id = 21. I found some inconsistencies with the registries where setting_name equals to “excludeDoi” as shown below:

+----------+--------+--------------+---------------+--------------+
| issue_id | locale | setting_name | setting_value | setting_type |
+----------+--------+--------------+---------------+--------------+
|       21 |        | excludeDoi   | 1             | string       |
|       21 | es_ES  | excludeDoi   | 1             | int          |
+----------+--------+--------------+---------------+--------------+

So I proceed to delete the second registry, which has the locale es_ES, with the following query, notice that I added others issue_id’s which had the same behaviour.

DELETE FROM issue_settings 
WHERE setting_name = 'excludeDoi' AND locale IS NOT NULL AND locale <> '' AND issue_id IN (21,20,19,18,17,16);

So I noticed that the setting_type should be int instead of string for setting_name equals to excludeDoi. Using the query below:

UPDATE issue_settings SET setting_type = 'int'
WHERE setting_name = 'excludeDoi' AND (locale IS NULL OR locale = '') AND issue_id IN (21, 20,19,18,17,16);

After that I can see the archive page and back issues on the manage panel.