Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.At the moment the top of admin/config/search/settings contains options for reindexing content, and settings that apply to how content is stored in the index.
Of the default search pages, these apply to the content (node) search, but not to the user search. There is nothing in the user interface to explain that these settings apply only to the content search even indicate that the user search is not indexed.
Any solution needs to work with search pages provided by contrib modules. We do not know whether these search pages will be indexed or not.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | search-2178651-10.patch | 1.7 KB | ianthomas_uk |
| #3 | per-index-status.png | 45.83 KB | ianthomas_uk |
Comments
Comment #1
jhodgdonSo... All of these settings are part of the "Indexing Settings" section of the admin form. There is already some information text there that says:
All we probably need to do is add additional text to that that explains that these settings only apply to pages that use the Search module's search index, such as the Content search page type, but not the User search page type.
Comment #2
jhodgdonAs a note, there is also hook_help() text at the top of the admin/config/search/settings page that says:
That should almost certainly also be updated, and there is some text in the main module hook_help() page that is also not great; there is also a separate issue for generically updating the hook_help():
#2091359: Update hook_help for Search module
Comment #3
ianthomas_ukIf we're going to have some generic settings that only apply to some search pages, then the first thing we need to do is label which search pages they apply to. At the same time we can break down the index status per-index.
If we do this, then we can refer to indexed vs not indexed in our descriptions and help text. I'm open to suggestions on exact terminology, I avoided the word status because we already had a status column and I couldn't think what that could be renamed to.
Is this a good approach?
Comment #4
jhodgdonI very much like the idea in #3. Actually, I implemented something very similar in my contrib Search by Page module for 7, which broke down the indexing status for existing search modules and Search by Page "environments" (which are essentially like the Pages in 8). So I'm glad to see this idea resurfacing. :)
A few UI thoughts:
a) At the top of the page, it's called "indexing status" and in the table it is "indexing progress". Let's make them consistent, and I think "status" is probably better... Although there is also the previous column "status" in the table that is the page status... so maybe change both of them to be "progress?
b) When I built the Search by Page version, I decided that the absolute numbers were better to display in the table than percentages... I still think so. Maybe it could say "N of M items indexed" instead of a percentage? Or if that is too long, maybe just "N/M indexed" or "N of M indexed"? My reasoning is that since the indexing cron throttle is a number of items that is indexed per cron run, it seems like the absolute numbers are more relevant than the percentage.
c) I don't think I like "No index required". How about "Does not use index" or "Not indexed" or "Does not use index" or just "Not applicable"? Actually, I think "Not applicable" might be the best?
d) This does make the table wider. Does it make it less usable for Mobile?
Comment #5
ianthomas_uka) I think both should be progress, unless someone can come up with an alternative term for the existing status column.
b) I agree about absolute numbers, I just used percentages because that's what the UI already did.
c) "Not indexed" implies that you need to do something to make it indexed. "Not applicable" doesn't explain why it's not applicable. "Does not use index" would work though.
d) Several columns disappear below a certain screen size, this will increase that breakpoint, so more devices will see the mobile version. We could perhaps increase some or all of the other columns to RESPONSIVE_PRIORITY_MEDIUM.
Comment #6
jhodgdonOn (d), wow can we do that? That seems like a good idea. It seems to me that the priority order for the columns would be something like:
- Label / Status / Operations - essential
- Indexing progress - probably next, since it also tells you whether the page uses the index or not?
- URL - medium (seems useful)
- Type - less important (you probably know the type from the label you gave it?)
Comment #7
jhodgdonOh and I'd point out that the UI at the top gives you both a percentage and a number of items remaining. :)
Comment #8
jhodgdonWe should revive this issue. ianthomas_uk - I think your patch was 90% there. Do you want to make a new patch?
Comment #9
ianthomas_ukAfter a "short" delay, here's a patch with those changes.
a) Both are now "Indexing progress"
b) "x of y indexed"
c) "Does not used index"
d) I've increased status from low to always shown, and inserted progress as medium. Url and type remain low, while label, operations and now status are always shown.
Comment #10
ianthomas_ukThis is identical to #9 except the case of "Indexing progress" is now consistent between the two calls.
Comment #12
ianthomas_ukThe test failure on #9 is a test running out of memory on some bots, nothing to do with this change.
Comment #13
jhodgdonLove it! Thanks ianthomas_uk!
I've looked over the code in this very straightforward patch, and also tested it manually (including the responsive table). It looks perfect to me. The test bot is also happy... Let's do it!
I guess I'm only left wondering whether we should add a test...
We're currently testing indexing status in general in SearchMultilingualEntityTest, but we are not currently testing the UI for this at all (as also noted in #1288442-2: Add search index status to the Status Report page). So it seems like we need to the following UI checks to SearchMultilingualEntityTest:
a) If you visit the search settings page, you see the indexing progress displayed there.
b) If this issue goes in, you also see the indexing progress displayed on the NodeSearch page.
c) If the update to the status report issue goes in, you also see the indexing progress displayed in the Status Report page.
Both this issue and the Status Report issue are ready to go (aside from tests)... so what I think I'd like to do is go ahead and mark this one as RTBC, since that other issue is already at needs work / tagged "needs tests", and just add tests for all 3 UI pieces on that other issue. I hope that's an OK strategy. I'll make a note there.
Comment #14
alexpottSure add tests in the the other issue.
Committed e5d8fce and pushed to 8.x. Thanks!
Comment #16
jhodgdonGreat, thanks for the quick commit! I've now written tests on #1288442: Add search index status to the Status Report page (which could use a review, hint hint!).