Problem with search after upgrading to OJS 3.1.0.1

ping @bozana and @asmecher, this is clearly an issue in the public search.

Hi all,

Hmmm… It seems like something went/goes wrong when indexing the articles…

Do you maybe have a possibility to rebuild the search index and try again?

Else, I will try to figure it out, to somehow reproduce it…

Best,
Bozana

The problem with indexing would be logical if we observed identical “internal” and “external” results. I just completed search index rebuilding (no errors, just PHP strict standards warnings) - search behavior has not changed, only one result during public search with any queries.

Hi @rkhalikov

The way that the search functions “internal” and “external” is different – the first is, I believe, just the JavaScript search of the articles and texts form that listing and the second is the search of the data indexed in the Databse. Thus, although they would probably need to return the same articles, because both do search in titles and authors, for example, they do not use the same source…

Best,
Bozana

I just did a rebuild like two weeks ago, so not sure if that is the problem.

Hi all,

Here is the search SQL: https://github.com/pkp/ojs/blob/master/classes/search/ArticleSearchDAO.inc.php#L28.
I.e. you could test it and run this SQL:

SELECT
o.submission_id,
MAX(s.context_id) AS journal_id,
MAX(i.date_published) AS i_pub,
MAX(ps.date_published) AS s_pub,
COUNT(*) AS count
FROM
submissions s,
published_submissions ps,
issues i,
submission_search_objects o NATURAL JOIN submission_search_object_keywords o0 NATURAL JOIN submission_search_keyword_list k0
WHERE
s.submission_id = o.submission_id AND
s.status = 3 AND
ps.submission_id = s.submission_id AND
i.issue_id = ps.issue_id AND
i.published = 1 AND k0.keyword_text = ? AND i.journal_id = ?
GROUP BY o.submission_id
ORDER BY count DESC
LIMIT 500

Just change the signs “?” with the appropriate keyword (e.g. ‘soil’ or ‘childbearing’) and journal ID.

Note also, that searching after ‘soil’ will only return those containing the word ‘soil’ and not those only containing the word ‘soils’. To find them too you would need to use
AND k0.keyword_text LIKE 'soil%'
in the SQL above.

Maybe first to check if the keywords are indexed correctly – this seems not to be right. For this you would need to take a look in the DB tables submission_search_*, where the keywords are indexed. You can e.g. see this with this SQL:

SELECT
o.submission_id
FROM
submission_search_objects o NATURAL JOIN submission_search_object_keywords o0 NATURAL JOIN submission_search_keyword_list k0
WHERE
k0.keyword_text = ?
GROUP BY o.submission_id

Again, please replace the sign “?” with the keyword (e.g. ‘soil’) or use LIKE 'soil%'.

If everything is all right in those DB tables (which I do not think is), then we can think/see further – i.e. we will have to go step by step to figure out what is the problem…

Best,
Bozana

Maybe one more question: is there maybe something different with those articles that are not found – are they maybe inserted/published differently, e.g. using QuickSubmit, import, or … ?
Thanks!

EDIT: Hmmm… this is probably not the problem – latest when the search index is rebuild it should be fixed…

OK, I tried the second query with ‘soil’ and received 21 submissions_ids. What does it mean? :wink:

No, we don’t use QuickSubmit, import, etc. Only regular submission process.

@rkhalikov

Could you also please run the first query, for that specific journal?

EDIT: and also investigate the difference i.e. if those first results are maybe unpublished or article from another journal (if you have other journals)…

Thanks!

OK, here is the result for the first query, 16 submissions_ids:

image

OK, that looks good, so the the indexing is fine… I’ll take a look in the code, what else then could be a problem that not all the results are not displayed and will then come back…
Thanks!

Hmm, submission_id = 51 is the only result that we get via public search! It has the largest count (117).

Hmmm… Now I see that the footer is not displayed on the search result page, thus maybe an error occurs… could you please take a look in your error log file during you make that public search @rkhalikov ?
It seems like the list is not completely displayed…
Did you maybe make any changes in the templates?
What theme do you use?

Apparently the error happens here: ojs/search.tpl at ojs-stable-3_1_0 · pkp/ojs · GitHub
i.e. in the template frontend/objects/article_summary.tpl.

Well, I see now that the footer is not displayed :frowning:

I found the only one error in logs during public search:
PHP Fatal error: Uncaught Error: Call to a member function getVolume() on null in /.../plugins/generic/coins/CoinsPlugin.inc.php:90, referer: https://biocomm.spbu.ru

We use Manuscript Default child theme 1.0.1. We made some minor changes in the article_details.tpl (i.e. addThis plugin location). But we have no changes in the article_summary.tpl.

Wow! I tried to disable COinS Plugin for this journal and made new “soil” search - ola-la, all 16 results and footer! But the only “top one” result when COinS Plugin is enabled.

I see, this plugin “likes” search very much… Found closed issue with COinS ( OJS 3.0.2 Journal Search function). Some kind of curse with this plugin…

Thanks, with disabled COinS also my search works well

Seems this is a workaround. But I suspect, @asmecher will have to dig this plugin again… :wink:

Hi all,

Try applying this patch to the COinS plugin and see if it gets both COinS (save to Zotero from the article view page) and search working as expected. If one or two of you are able to report back I’ll make sure the plugin gets an update.

Thanks!
Alec Smecher
Public Knowledge Project Team