We have completed more or less successfully upgrade of our OJS from 3.0.2 to 3.1.0.1.
But faced with a strange problem with search. The only one result is displayed when searching “outside”, via public site header:
While the same query inside the system (among published articles) produces all the results:
I performed rebuildSearchIndex, but it did not change anything. What can cause such a strange behavior?
I confirm, that I have the same problem.
Jirka
Hm, so we are dealing with some kind of bug? Curious select top(1) for external search?
Yes, if I search different topic, different authors, the result is always correct, but it is only one.
I am seeing this with some words in at least one of our journals. With some words the results are the same, but for example with the word “child” I get over 40 hits in the submissions list but only 25 in the public search.
What is interesting here is that for example one title with the word “childbearing” is missing from the search, but if I actually do a search with the “childbearing” it appears in the public search. However, some titles with the word “childbearing” do come up in the public search also with the word “child”. So I am totally confused with the logic here.
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? 
No, we don’t use QuickSubmit, import, etc. Only regular submission process.
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:
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 
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.