There was a problem searching authors with a hyphen that brought no results.
I ran php tools/resbuildSearchIndex.php and it failed with the following Exception
PHP Fatal error: Uncaught PDOException: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value: ‘\xF0\x9D\x91\x81\xF0\x9D…’ for column submission_search_keyword_list
.keyword_text
at row in lib/pkp/lib/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:119
Now Search is completely broken.
My system is as below
|OS platform|Linux| Ubuntu 22.04 LTS
|—|—|
|PHP version|7.4.33|
|Apache version|Apache/2.4.52 (Ubuntu)|
|Database driver|mysql|
|Database server version|5.5.5-10.6.16-MariaDB-0ubuntu0.22.04.1|
Has anyone got any idea how I can fix this issue?
Thanks
abadan
July 2, 2024, 12:54pm
2
Hi Nason,
See if the solutions presented in the links below work for you?
Hy there
Might be interesting for you, Orlando_Alonzo , if you have not found a solution yet. In our case the problem was that the database character set (migrated from OJS 2.4 > ... > 3.2) had the wrong character set which caused problems migrating from 3.2 to 3.3.
What we have done
Changed the character set of the database and all tables. As we migrate the system to a new development machine, we started from scratch creating a new database with the correct character set and collation using:
…
opened 11:20AM - 27 Sep 22 UTC
closed 11:36PM - 27 Sep 22 UTC
**Describe the bug**
Publicating a recent issue of one of our journals leads to… a halt in the publication with some articles unpublished and the following error in the php log file:
`PHP Fatal error: Uncaught PDOException: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect string value: '\xF0\x9D\x90\xB9\xF0\x9D...' for column ojs.submission_search_keyword_list.keyword_text at row 1 in /var/www/html/lib/pkp/lib/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:115\nStack trace:\n#0 /var/www/html/lib/pkp/lib/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php(115): PDOStatement->execute(NULL)\n#1 /var/www/html/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Database/Connection.php(489): Doctrine\DBAL\Driver\PDOStatement->execute()\n#2 /var/www/html/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Database/Connection.php(664): Illuminate\Database\Connection->Illuminate\Database\{closure}('INSERT INTO sub...', Array)\n#3 /var/www/html/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Database/Connection.php(631): Illuminate\Database\Connection->runQueryCallback('INSERT INTO sub...', Array, Object(Closure))\n#4 /var/www/html/lib/pkp/lib/vendor/laravel/framework/src/Illum in /var/www/html/lib/pkp/lib/vendor/laravel/framework/src/Illuminate/Database/Connection.php on line 671, referer: https://www.xxx.de/index.php/xxx/manageIssues
`
**To Reproduce**
Steps to reproduce the behavior:
1. Go to issues
2. Click on publish
3. Publication process continues to run indefinitely
4. See error in php error.log file
**What application are you using?**
OJS version 3.3.0.8
**Additional information**
I think that this could be due to special characters in one of the PDF files that are not part of the utf8 specification but need utf8mb4 (see https://stackoverflow.com/questions/20411440/incorrect-string-value-xf0-x9f-x8e-xb6-xf0-x9f-mysql#20429481). While i.e. character_set_client and character_set_connection are utf8mb4 in our database, character_set_database is utf8.
I don't know if this is due to a local setting or defined by PKP? If the first is the case, can I simply change the encoding?
Your's
Felix
Thank you @abadan , I will give it a go and will update the thread.
Regards
Nason
Hi @abadan
I tried option 1 and it did not solve the problem. I instead took a leaf from Fatal error Invalid datetime format when rebuilding search index - #9 by lcmartinezru and added a try-catch to ignore the problem records for now which is not ideal.
Going forward and for future-proofing, I will look into option 2, however, before doing that, I would like to know if future OJS versions including 3.4.x which we will still work with a database still using utf8mb3.
Regards
Nason