The search on the public interface does not return some results, but as soon as I log into the dashboard results are returned. Why are the two approaches to the search different?
The most likely explanation is that some of the items are private, and so not returned by the search when you are not logged in.
All items are public. I will private message you.
Here is the collection:
http://library.gc.cuny.edu/legacy/
Because the PDF’s are copyrighted via their authors, I placed behind a proxy (that is why you cannot see them):
https://login.central.ezproxy.cuny.edu/login?url=http://library.gc.cuny.edu/legacy/collections/browse
but that should not matter.
For example, this problem appears when searching on '“Alterman” while I am signed into Omeka:
http://library.gc.cuny.edu/legacy/admin/items/show/11620
but does not appear when searching on the public side.
Record says:
Public: Yes Featured: No
Here is the public record:
http://library.gc.cuny.edu/legacy/items/show/11620
Do you want me to create an Omeka account for you so you can compare results? If, so i will create an account and email you credentials.
Is the difference occurring based on the side you’re searching from (public vs. admin), or on whether you’re currently logged in? In other words, if you’re logged in as an administrator and you conduct a search from the public side, are you getting the results you’re expecting?
If it’s changing based on whether the user is logged in, that would align with what Patrick suggested: it’s omitting results that are marked as “private.” This happens automatically for non-authenticated users.
If that’s the case, you’re saying there’s a mismatch between the items being actually public but not coming up in the results anyway. If you go and edit/re-save one of those public items that’s not appearing, does that fix the problem for that item? It could be a situation where the index is for whatever reason out of sync and you need to re-index.
Great question. I just tested and the difference is between being logged in and not being logged in.
Because all records were always marked public, I will reindex and see what happens.
Reindexing did not work
Wondering if I should turn everything private via:
UPDATE omeka_items
SET public=0
WHERE public=1;
than everything public via:
UPDATE omeka_items
SET public=1
WHERE public=0;
Since items are returned when logged in (not just in dashboard, but frontend too), and you imply that somehow these items are still set on private. I took your suggestion and reindexed, but that did not resolve the issue. So
In development:
I ran the following to turn all items private:
UPDATE omeka_items
SET public=0
WHERE public=1;
then ran the following to turn all items public via:
UPDATE omeka_items
SET public=1
WHERE public=0;
but this did not resolve the issue.
I than simply went into the ‘Alterman’ record that you sent me, via the GUI set it to private and then to public and the issue was finally resolved. Somehow the problem is only resolved via this GUI switch. Is there is something we are overlooking?
Hmmm… that seems odd.
If you’re looking at the database anyway, take a look at the search_texts table. Each item (and other searchable record) has a row here, with a separate public flag, and it’s this one that the search page uses when it decides what records to show.
That flag is supposed to get updated to align with the item’s public/private flag when the item gets saved, but it seems like it isn’t for some reason.
The “flag” I was talking about is the public column for that table. A row needs a value of 1 for that column to appear on the public side.
So I need some SQL to change to 1?
UPDATE omeka_search_texts
SET public=1
WHERE public=0;
Ideally we’d figure out why the public column isn’t getting set correctly, as a reindex or resave should pick that up without needing anything else.
But, manually changing them as you suggest should also work in a pinch, as long as you want the whole thing to be public.
I ran the SQL, because there are 13K records.
Are you suggesting that the records might be set to 0 again?