Describe the issue or problem
the tools/rebuildSearchIndex.php crashes on line 38, PHP Fatal error: Uncaught Error: Call to a member function getData() on null in /usr/local/ojs/classes/search/ArticleSearchIndex.inc.php:38
and I found this related post
I did the select to find out if I have any submissions without publications and I did find one. It belongs to a journal that is not active anymore.
The result of select: submission_id: 53 context_id: 4 date_submitted: 2007-01-15 17:51:44 last_modified: 2007-12-16 13:40:54 status: 3 submission_progress: 0 stage_id: 4 current_publication_id: 51 date_last_activity: 2007-12-16 13:40:54 work_type: 0 locale: en_US
Can the whole journal + contents be deleted to just get rid of it? Or will we have to enable the journal to be able to try and remove the submission in the web interface?
Itâs entirely up to you whether you delete the entire journal, or just the submissions without publications. If the journal has an important scholarly record to preserve, then I would suggest deleting just the problem submissions.
The quickest/easiest way to do that, if you have access to the command line, is probably to use tools/deleteSubmissions.php. I havenât tried it specifically on submissions without publications, but thatâs where Iâd start.
Make a backup before you start taking drastic actions like deleting journals or submissions en masse!
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks @asmecher, I had forgotten about the deleteSubmissions.php script. The journal that created the submission without publication has migrated to another installation and to make it even more secure, Iâm doing this on a copy of the production right now.
I wanted to see if I was able to rebuild the search index, as we decided we want to truncate the three index tables to speed up our next upgrade.
deleteSubmissions.php for one submission_id (the one found by the select above) failed with
PHP Fatal error: Uncaught Error: Call to a member function getStatus() on null in /usr/local/ojs/lib/pkp/classes/submission/reviewRound/ReviewRoundDAO.inc.php:238
Hmm, it looks like thatâs caused by additional missing data â in this case, review rounds.
If the journal has already been migrated elsewhere, then I would lean towards removing the journal entirely. But if you have a journal with partial data in it, you might run into problems with that too, where even the deletion process expects the data to have a level of integrity.
The good news is that upgrading to 3.4 and 3.5 will add referential integrity checks so that this kind of partial data wonât be possible in the future. The process of upgrading will clean up data where thatâs possible to do without any particular knowledge of the journal, but OJS will stop short of deleting entire submissions and in all likelihood youâll be prompted to do some cleanup when you try to run the upgrade script.
Long story short, an eventual plan to upgrade will help clean up your data, but you might be in a situation already where some manual actions in the database will be necessary. I would start (after taking a good backup!) by removing the entries in submissions and journals related to the journal thatâs been migrated. Itâs entirely possible that just doing that will resolve the problem with the search index rebuild, and I believe the upgrade process to 3.4 and above (when youâre ready to tackle it) will take that as sufficient cause to remove anything left related to the missing submissions.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher, thanks for your reply. It is great that there are more integrity checks in the newer versions.
I did some steps, (backup first)
removed all submissions that belonged to the migrated journal
truncated the search index tables again
ran the rebuildSearchIndex script
Unfortunately it crashed on the same line, and itâs trying to index a journal that is enabled. Line 38 in our OJS version of classes/search/ArticleSearchIndex.inc.php is
foreach ($publication->getData(âauthorsâ) as $author) {
and I guess there is something wrong with the authors table then?
PHP Fatal error: Uncaught Error: Call to a member function getData() on null in /usr/local/ojs/classes/search/ArticleSearchIndex.inc.php:38
Stack trace: #0 /usr/local/ojs/classes/search/ArticleSearchIndex.inc.php(280): ArticleSearchIndex->submissionMetadataChanged()
Finally I did a new test to rebuild the index where I disabled the journal where the error occurred to see if it would skip it, but it failed in the same place on the same journal.
I might not be understanding the db design, but if I turn around the search for submissions/publications to
select p.* from publications p left join submissions s on (s.current_publication_id = p.publication_id) where s.current_publication_id IS
NULL;
I get 1048 rows where the submission_id in publications donât exist in submissions.
Edited to add: I was just reminded that the journal that crashes the rebuild search index had a lot of content imported. Are there any scripts to check if a certain journalâs data is âcorrectâ?
I suspect failed imports have a lot to with this. An entry in submissions that doesnât have a corresponding entry in publications (via current_publication_id) wonât be worth much â it wonât have a title, abstract, set of contributors, etc.
Again, after taking a backup, Iâd recommend removing any entries in submissions that donât have matching entries in publications.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks again, @asmecher , and thanks for all these replies, it helped.
We found a few imported submissions in the problematic journal where current_publication_id pointed to a real publication row â but one that belonged to a different submission (eg current_publication_id = 1). These submissions had no publications of their own, no metadata, no authors, but were marked as complete.
I have removed those submissions and now the rebuild search index script does not fail on that journal anymore. So it will feel better to truncate the search index tables, knowing that I now can rebuild their content.
Very strange â Iâve never seen that situation before! Please let me know if youâre able to determine the conditions that caused it â I would guess itâs something to do with the import. Nonetheless, Iâm glad to hear itâs resolved.
Thanks,
Alec Smecher
Public Knowledge Project Team
It is an old installation we have, where the latest created journal is number 89. The import for the journal with the problems was made already in 2023, so I donât think Iâll try and find out.
