Change #951900 merged by jenkins-bot:

[mediawiki/core@master] WikiTextStructure: Drop message fallback to old cirrussearch message

https://gerrit.wikimedia.org/r/951900

Change #1057978 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/CirrusSearch@master] i18n: Drop 'cirrussearch-ignored-headings', now unused

https://gerrit.wikimedia.org/r/1057978

@MarkTraceur is this possibly for media search for your team?

Indeed, Rdbms is detecting this and reporting it. It's not causing it. It's not clear which component is causing it, but they seem to have Search as common referer, perhaps we can investigate from there to see what it is?

This has been rolling around in my head for a while and something related came up today, so I wanted to jot down some notes to my future self, or to anyone else who may work on this.

@Paladox It would be fantastic if you could continue your work.

@Jdlrobson "Search" is white in PROD and fail contrast while Test.Wiki was black (as seen in my previous test)

This is currently blocked on all our testcases relying on tables to be cloneable, but innoDB cannot create a TEMPORARY table of a table that has a FULLTEXT index.

Hey @Prototyperspective, these sound like reasonable ideas for how to improve the user experience here, so I want to bring this to the attention of the Structured Data team (who are the official maintainers of this feature AFAIK). @AUgolnikova-WMF or @Sannita may be able to move this task to the appropriate place for triaging. I will say that I think the team's current focus is on improving UploadWizard, so this might not be an immediate priority.

Thanks for CCing. @egardner Yes of course. The Media search is much better. However, there are several problems with it due to which in practice one often has to resort to the Special search. The better solution would be to improve Media search further so that Special search is not needed anymore at all (that would be separate issues). Two main problems with it are that Cat-a-lot (which is very useful especially on WMC) does not work in Media search and that it doesn't have this dropdown for search operators.

Hi @Prototyperspective – are you familiar with Special:MediaSearch on commons? Here's an example of it in action:

CC'ing more folks who were involved in this change to get another opinion in this ticket.

I already knew about this research and agree with the findings and what it means for Wikipedia. I don't think it applies here much or at all because these are search results. The user usually just glances over them, like their filetitles and thumbnails. The special search looks quite broken currently and there could at least be settings to make use full width (actually on Wikipedia there now seems to be a reading view setting for width so I guess the same could be used here).

the space should be used until a preview is shown there, just like with the modern not-broken wall-of-images-view Media search results (example) which use all available width until an item is clicked for preview

@Aklapper That only relates to what would be needed for this problem to be fixed – in specific that the default for WMC needs to be different than other Wikimedia sites, eg site-specific changes on top of the default page layout that makes it use a wider width.

The empty space is used for interwiki search results or previews in other cases. Page layout shouldn't differ across pages, thus empty space in this case when there are no interwiki search results or previews.

@Aklapper I don't think this should be closed and it seems way to quick to close it – I don't understand your explanation. When I click on a file in these search results the page is opened instead of a preview showing on the right. Whether or not it's intentional doesn't make it any better, if anything it would be a bigger problem and indicate that it would be easier to fix. And remains the case that the Special search UI is broken. Could you please clarify what you mean in the sense of why you think this is not a valid issue?

@Aklapper That is not true. It does work well here for example (which has been very useful to find files missing in the cat) and this category contains thousands of files.

The operator works but AFAIK negation is currently not supported.

Assuming the total width on the screenshot is between 1440px and 720px, mw-search-results-container intentionally defines to use 7/12 for content, 1/12 space, and 4/12 for interwiki results and search previews (which doesn't apply in the screenshot above, thus the emptiness in this special case) since https://gerrit.wikimedia.org/r/c/mediawiki/core/+/902677 . Rating consistency across wikis higher than this special case, I'm declining this request.

Removing tag as this is unrelated to the Advanced-Search interface not shown in the screenshot.

Looks good. Resolving.

Change #1050438 had a related patch set uploaded (by Jayden Bailey; author: Jayden Bailey):

[mediawiki/extensions/AdvancedSearch@master] Rework AdvancedSearch's explicit namespacing to use history.pushState instead of 302 redirects

https://gerrit.wikimedia.org/r/1050438

This is already possible with the hook SpecialSearchProfiles instead of a config parameter or a MediaWiki:Sidebar-like alternative, so it should be clearer here what is really wanted (I’m aware the original author probably does not follow this task, so the question is to people interested to this task).

Mentioned in SAL (#wikimedia-operations) [2024-06-26T20:50:34Z] <jdrewniak@deploy1002> Finished scap: Backport for [[gerrit:1049972|Enable user pages and select special pages in dark mode (1.43.0-wmf.11) (T366364 T366375 T367375 T367581 T367582 T367583)]] (duration: 08m 09s)

Mentioned in SAL (#wikimedia-operations) [2024-06-26T20:44:55Z] <jdrewniak@deploy1002> jdlrobson, jdrewniak: Backport for [[gerrit:1049972|Enable user pages and select special pages in dark mode (1.43.0-wmf.11) (T366364 T366375 T367375 T367581 T367582 T367583)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)