**Steps to replicate the issue** (include links if applicable):
* Search for any string with a # (hash symbol) in it, on a current mediawiki instance.
* The string is truncated at the hash, and only the substring before it is used to try automatically redirecting to an existing page
* If no page is found, the warning message that no such page exists only shows the search string up to the #
* This is noticeable when trying to find phrases that contain a hash symbol. For instance: try searching for **"#nofilter"**, this will look for a page whose title is a single doublequote. Search for **We are #1** and it will look for a page titled //We are//
**What happens?**:
* Search for **"#nofilter"**
* If on a wiki that has a page at that title (such as some large wikipedias), you are taken directly to the page about the doublequote character.
* If there is no such page, results page leads with the following warning:
> //Create the page "**"**" on this wiki! See also the search results found.//
* The search results shown match properly against the full search string.
**What should have happened instead?**:
* Just show the search results, don't interpret the # symbol as the start of a fragment identifier. [unless a search string classifier suggests that's what it is?]
**Feature summary** (what you would like to be able to do and where):
I would like to be able to use Command-K (or Control-K on Windows/Linux) to immediately open the search field. There are plenty of apps and websites that use Command/Control-K to open their search fields and I would like the same for Wikipedia/MediaWiki.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
I tried using Command-K to open the search field in Wikipedia, and it didn't open.
**Benefits** (why should this be implemented?):
Just as merely convenience/for power users that use keyboard shortcuts daily.
**Feature summary**: The disambiguation page for a search term should be on the top of the result list and the suggested list
**Use case(s)**: If I type a search term, the shortest string is usually the most general and will lead to an disambiguation page.
E.g. if I look for something or someone call "Goethe", the algorithm suggests "Johann Wolfgang von Goethe" on top, which makes sense. But "Goethe (disambiguation)" doesn't even make the top ten, so it is never shown on the mobile page, where there is no result page.
There might be the "Template:Redirect" as a workaround like in this case, but not in all cases. It's not reliable and not a good user experience.
**Benefits**: Especially casual and mobile users will have a better search experience with more successful search results
**Feature summary** (what you would like to be able to do and where):
In special:prefixindex need to toggle the namespace prefix on and off in the displayed page list
In this example from English Wikisource the generated list would allow a presentation form that prepends the namespace to the generated list, eg. Page: ns
https://en.wikisource.org/wiki/Special:PrefixIndex/Page:Houghton_Mifflin
```
Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/1
Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/2
Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/3
etc.
```
desired output
```
Page:Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/1
Page:Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/2
Page:Houghton Mifflin Co. v. Stackpole Sons (104 F.2d 306).pdf/3`
etc.
```
From my dim dark memory this sort of display used to be available though has disappeared with other iterations
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
I want to be able to easily generate a list of pages for maintenance purposes including the namespace name, and to have that ability to toggle on and off that display component
PrefixIndex only displays as
* {{{PAGENAME}}
desire the ability for additional option
* {{NS}}:{{PAGENAME}}
The addition of another toggle option would be my wish
**Benefits** (why should this be implemented?):
The Wikisources have Page: ns pages that align with the File: and Index: ns version file of the same name, and moves of these files/pages generates large amounts of redirects and other type of maintenance, and this the best source to generate a clean list.
At the moment for a book with 500 pages, that means that I have to add the prefix to 500 lines from a system generated list ¯\_(ツ)_/¯
WikiTextStructure uses the `cirrussearch-ignored-headings` i18n message from #cirrussearch, which won't exist if the extension isn't installed
```lang=php
/**
* Gets a list of heading to ignore.
* @return string[]
*/
private function getIgnoredHeadings() {
static $ignoredHeadings = null;
if ( $ignoredHeadings === null ) {
$ignoredHeadings = [];
$source = wfMessage( 'search-ignored-headings' )->inContentLanguage();
if ( $source->isBlank() ) {
// Try the old version too, just in case
$source = wfMessage( 'cirrussearch-ignored-headings' )->inContentLanguage();
}
if ( !$source->isDisabled() ) {
$lines = self::parseSettingsInMessage( $source->plain() );
// Now we just have headings!
$ignoredHeadings = $lines;
}
}
return $ignoredHeadings;
}
```
I suspect we can just remove that "fallback...
**Steps to replicate the issue** (include links if applicable):
On my system there are 218 occurrences of the word "regular". When I searched it the search result shows 1 – 27 of 27 only. If i click next 20 there are more results..
**What happens?**:
The search result total count is not correct.
**What should have happened instead?**:
The search result should give me the correct result. In my case the search of the word "regular" should return 218
**Software version** (skip for WMF-hosted wikis like Wikipedia):
MediaWiki 1.39.3
PHP 8.0.29 (fpm-fcgi)
ICU 72.1
Postgres 15.2
Pygments 2.11.2
Lua 5.1.5
**Other information** (browser name/version, screenshots, etc.):
The result of searching the word "regular"
{F37156332}
The total search result is corrected when click the "500"
{F37156334}
{F37156336}
This wiki was upgraded from 1.26-> 1.35 ->1.39. Previously I was on SphinxSearch but I decided to drop it since the project is not being maintained.
I've also tested this at mediawiki 1.40 and the problem still exist.
I recently opened up Special:Search on enwiki, set some things, then clicked search. This was the resulting URL:
https://en.wikipedia.org/w/index.php?search=bundle+-intitle%3Abundle+subpageof%3A%22Articles+for+deletion%22&title=Special:Search&profile=advanced&fulltext=1&advancedSearch-current=%7B%22fields%22%3A%7B%22subpageof%22%3A%22Articles+for+deletion%22%7D%7D&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns118=1&ns119=1&ns710=1&ns711=1&ns828=1&ns829=1&ns2300=1&ns2301=1&ns2302=1&ns2303=1
`&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns118=1&ns119=1&ns710=1&ns711=1&ns828=1&ns829=1&ns2300=1&ns2301=1&ns2302=1&ns2303=1` sticks out to my eye as too verbose. There's opportunity for improvement here.
I propose the following improvements:
* add URL support for...
* [ ] ?ns1=1&ns2=1 should be consolidated into ?ns=1,2
* [ ] There should be a ?ns=all shortcut added for searches that should check every namespace
* change the default search URLs emitted from Special:Search to use the new format
* [ ] ?ns1=1&ns2=1 should be consolidated into ?ns=1,2
* [ ] Detect when the user has clicked the "All" checkbox or has selected every namespace, and emit ?ns=all instead of ?ns=1,2,3,4,5 etc.
* [ ] keep the old URL format for backwards compatibility I guess
**Feature summary** (what you would like to be able to do and where):
Add a hook to allow extensions exclude certain namespaces from title-only search queries and search autocomplete, just like SearchableNamespaces.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Some extensions use random strings in titles, eg. Topic: in StructuredDiscussions (currently searching is disabled), and CommentStreams: in CommentStreams (T276016). Those unreadable titles shouldn't be used in search queries and search autocomplete.
**Benefits** (why should this be implemented?):
Make users not confused when searching.
Link: [[ https://wikiapiary.com/w/index.php?search=Bookmarklet | search for bookmarklet ]]
Other searches do not end up with exceptions. They either produce a page of results or, in the case of too broad a search, a database timeout.
The error in the log is:
> Wikimedia\Assert\PreconditionException: Precondition failed: This Title instance does not represent a proper page, but merely a link target.
**Software version**
MW version: 1.39.2 (626d2da)
**Other information**
The trace from the exception is:
```
Wikimedia\Assert\PreconditionException: Precondition failed: This Title instance does not represent a proper page, but merely a link target.
#0 .../includes/Title.php(4190): Wikimedia\Assert\Assert::precondition()
#1 .../includes/Title.php(4171): Title->assertProperPage()
#2 .../includes/Revision/RevisionStore.php(1828): Title->getId()
#3 .../includes/Revision/RevisionStore.php(1733): MediaWiki\Revision\RevisionStore->ensureRevisionRowMatchesPage()
#4 .../includes/Revision/RevisionStore.php(1609): MediaWiki\Revision\RevisionStore->newRevisionFromRowAndSlots()
#5 .../includes/Revision/RevisionStore.php(2348): MediaWiki\Revision\RevisionStore->newRevisionFromRow()
#6 .../includes/Revision/RevisionStore.php(1286): MediaWiki\Revision\RevisionStore->loadRevisionFromConds()
#7 .../includes/search/RevisionSearchResultTrait.php(52): MediaWiki\Revision\RevisionStore->getRevisionByTitle()
#8 .../includes/search/RevisionSearchResult.php(16): RevisionSearchResult->initFromTitle()
#9 .../includes/search/SqlSearchResult.php(36): RevisionSearchResult->__construct()
#10 .../includes/search/SqlSearchResultSet.php(60): SqlSearchResult->__construct()
#11 .../includes/search/SearchResultSet.php(73): SqlSearchResultSet->extractResults()
#12 .../includes/search/SearchResultSet.php(184): SearchResultSet->count()
#13 .../includes/search/SearchEngine.php(201): SearchResultSet->shrink()
#14 .../includes/search/SearchEngine.php(157): SearchEngine->maybePaginate()
#15 .../includes/specials/SpecialSearch.php(447): SearchEngine->searchTitle()
#16 .../includes/specials/SpecialSearch.php(229): SpecialSearch->showResults()
#17 .../includes/specialpage/SpecialPage.php(701): SpecialSearch->execute()
#18 .../includes/specialpage/SpecialPageFactory.php(1428): SpecialPage->run()
#19 .../includes/MediaWiki.php(316): MediaWiki\SpecialPage\SpecialPageFactory->executePath()
#20 .../includes/MediaWiki.php(904): MediaWiki->performRequest()
#21 .../includes/MediaWiki.php(562): MediaWiki->main()
#22 .../index.php(50): MediaWiki->run()
#23 .../index.php(46): wfIndexMain()
#24 {main}
```
**Steps to replicate the issue** (include links if applicable):
* Search for book title "ꦥꦼꦥꦼꦛꦶꦏ꧀ꦏꦤ꧀ꦱꦏꦶꦁꦥꦿꦗꦚ꧀ꦗꦶꦪꦤ꧀ꦭꦩꦶ" in Commons works (the full title), found [[ https://commons.wikimedia.org/wiki/File:%EA%A6%A5%EA%A6%BC%EA%A6%A5%EA%A6%BC%EA%A6%9B%EA%A6%B6%EA%A6%8F%EA%A7%80%EA%A6%8F%EA%A6%A4%EA%A7%80%EA%A6%B1%EA%A6%8F%EA%A6%B6%EA%A6%81%EA%A6%A5%EA%A6%BF%EA%A6%97%EA%A6%9A%EA%A7%80%EA%A6%97%EA%A6%B6%EA%A6%AA%EA%A6%A4%EA%A7%80%EA%A6%AD%EA%A6%A9%EA%A6%B6.pdf | the PDF ]]
* Search partial "ꦥꦼꦥꦼꦛꦶꦏ꧀ꦏꦤ꧀ꦱꦏꦶꦁꦥꦿꦗꦚ꧀ꦗꦶꦪꦤ꧀" or "ꦥꦼꦥꦼꦛꦶꦏ꧀ꦏꦤ꧀ꦱꦏꦶꦁ" or "ꦥꦼꦥꦼꦛꦶꦏ꧀" or any parts of the full title won't work
**What happens?**:
* First identified 10 years ago, T46350, marked wont fix, since last time was during migration from Lucene to Cirrus Search.
* I identified there was a problem with scriptio continua nature of Javanese script (no word marker)
* T58505 Cirrus Search ticket was closed as solved
**What should have happened instead?**:
The Commons search et. al should be able to find parts of the full title.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
A bit background on the way the script is written:
* Scriptio continua is a hassle to display in web, because there's no obvious line break. Therefore, in projects such as Wikisource, if not handled properly, would break the page view of the transcribed documents. (become too wide)
* Using certain keyboards, including the way we handle the problem is, to automatically insert ZWS (zero-width space) after certain character (e.g. comma, period, etc. ) I can gave you the full list. Therefore, the line break would still works, except in very rare cases where there's no occurrences of those characters (thus the ZWS not auto-inserted). [the zws doesn't always equal to the Latin space]
* AFAIK ZWS is not supported in page titles, (e.g. when I upload books with Javanese script titles that contain ZWS), so none of the titles in jv wiki projects contain ZWS, and thus the cirrus search won't be able to know the word delimiter.
**Steps to replicate the issue** (include links if applicable):
* Go to https://en.wikipedia.org/wiki/?useskin=vector-2022
* Open the inspector. Go to the Network panel, and set the filter to "Doc"
* Type "Albert" in the search bar
* Click on the search result for "Albert Einstein"
* This takes you to the "Albert Einstein" article
* Type "Albert" in the search bar again
* Click "Search for pages containing Albert" at the bottom of the results
* This takes you to the search page for "Albert"
**What happens?**:
When clicking the Albert Einstein result:
* A request is made for https://en.wikipedia.org/w/index.php?title=Special:Search&search=Albert+Einstein&wprov=acrw1_1
* This returns a 302 redirect to https://en.wikipedia.org/w/index.php?search=Albert+Einstein&title=Special:Search&ns0=1
* That then returns a 302 redirect to https://en.wikipedia.org/wiki/Albert_Einstein
When clicking the "Search for pages containing Albert" result:
* A request is made for https://en.wikipedia.org/w/index.php?title=Special%3ASearch&fulltext=1&search=albert
* This returns a 302 redirect to https://en.wikipedia.org/w/index.php?fulltext=1&search=albert&title=Special%3ASearch&ns0=1
**What should have happened instead?**:
There should be only one redirect (in the first case), or ideally no redirect at all (in both cases).
**Software version** (skip for WMF-hosted wikis like Wikipedia): Current production (1.40.0-wmf.10)
**Other information** (browser name/version, screenshots, etc.):
On https://gerrit.wikimedia.org/r/c/integration/quibble/+/850175/ there are a six API tests failling for mediawiki/core `/search`. https://integration.wikimedia.org/ci/job/integration-quibble-fullrun-sqlite/152/consoleFull
Maybe it is related to SQLite?
```counterexample
6 failing
1) Search
GET /search/page?q={term}
should return array of pages when there is only a text match:
AssertionError: expected [] to have a length of 1 but got +0
+ expected - actual
-0
+1
at Context.<anonymous> (tests/api-testing/REST/Search.js:34:11)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
```
```counterexample
2) Search
GET /search/page?q={term}
should return array of pages when there is only title match:
AssertionError: expected [] to have a length of 1 but got +0
+ expected - actual
-0
+1
at Context.<anonymous> (tests/api-testing/REST/Search.js:54:11)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
```
```counterexample
3) Search
GET /search/page?q={term}
should return a single page when there is a title and text match on the same page:
AssertionError: expected [] to have a length of 1 but got +0
+ expected - actual
-0
+1
at Context.<anonymous> (tests/api-testing/REST/Search.js:66:11)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
```
```counterexample
4) Search
GET /search/page?q={term}
should return two pages when both pages match:
AssertionError: expected [] to have a length of 2 but got +0
+ expected - actual
-0
+2
at Context.<anonymous> (tests/api-testing/REST/Search.js:78:11)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
```
```counterexample
5) Search
GET /search/page?q={term}
should return only one page when two pages match but limit is 1:
AssertionError: expected [] to have a length of 1 but got +0
+ expected - actual
-0
+1
at Context.<anonymous> (tests/api-testing/REST/Search.js:85:11)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
```
```counterexample
6) Search
GET /search/page?q={term}
should ignore duplicate redirect source and target if both pages are a match:
AssertionError: expected [] to have a length of 1 but got +0
+ expected - actual
-0
+1
at Context.<anonymous> (tests/api-testing/REST/Search.js:113:11)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
```
I was thinking about the DOM in search in the context of {T320295} and I think there are maybe some other improvements besides the flex there.
Assuming a DOM as implemented there:
```lang=html
<ul class="mw-search-results">
<li class="mw-search-result mw-search-result-ns-0 searchResultImage">
...
<div class="searchResultImage-text">
<div class="mw-search-result-heading">
<a href="/wiki/Mecca" title="Mecca" data-serp-pos="0">Mecca</a>
</div>
...
<div class="mw-search-result-data">97 KB (10,753 words) - 09:06, 7 October 2022</div>
</div>
</li>
...
</ul>
```
Firstly, I think `<h*>` (`<h2>` maybe) should be used for the heading (`<div class="mw-search-result-heading">`). It's in the name of the class even.
Second, I think it could be argued that the `<div class="mw-search-result-data">` would be better as a `<p>`. So something like this ultimately:
```lang=html
<ul class="mw-search-results">
<li class="mw-search-result mw-search-result-ns-0 searchResultImage">
...
<div class="searchResultImage-text">
<h2 class="mw-search-result-heading">
<a href="/wiki/Mecca" title="Mecca" data-serp-pos="0">Mecca</a>
</h2>
...
<p class="mw-search-result-data">97 KB (10,753 words) - 09:06, 7 October 2022</p>
</div>
</li>
...
</ul>
```
This would probably lead naturally to some future where CSS grid is supported at grade C and then the `<ul><li>...</li></ul>` could also be removed in favor of grid, since the necessary accessibility markers (headings) would be available to move around the page.
**Steps to replicate the issue** (include links if applicable):
* [[https://en.wikipedia.org/w/index.php?title=Special:Search&search=insource%3A%2F%5C%3Cref%28+%5B%5E%5C%3E%5D%2A%29%3F%5C%3Ehttps%3F%3A%5C%2F%5C%2F%5B%5E+%5C%3C%5C%3E%5C%7B%5C%7D%5D%2B+%2A%5C%3C%5C%2Fref%2Fi&ns0=1&fulltext=Search | Make a search]]
**What happens?**:
Results are rendered with a DOM kind of like this:
```lang=html
<ul class="mw-search-results">
<li class="mw-search-result mw-search-result-ns-0">
<table class="searchResultImage">
<tbody>
<tr>
<td class="searchResultImage-thumbnail">
<a href="..." class="image">
<img alt="" src="..." decoding="async" data-file-width="1920" data-file-height="2400" width="96" height="120">
</a>
</td>
<td class="searchResultImage-text">
<div class="mw-search-result-heading">
<a href="/wiki/Mecca" title="Mecca" data-serp-pos="0">Mecca</a>
</div>
<div class="searchresult">
many tunnels.<span class="searchmatch"><ref>https://www.constructionweekonline.com/projects-tenders/article-22689-makkah-building-eight-tunnels-to-ease-congestion</ref</span>>
===Rapid...
</div>
<div class="mw-search-result-data">97 KB (10,753 words) - 09:06, 7 October 2022</div>
</td>
</tr>
</tbody>
</table>
</li>
...
</ul>
```
**What should have happened instead?**: CSS flex should be used. These are not HTML data tables; the tables are being used strictly for presentation. The DOM should look something like this:
```lang=html
<ul class="mw-search-results">
<li class="mw-search-result mw-search-result-ns-0 searchResultImage">
<div class="searchResultImage-thumbnail">
<a href="..." class="image">
<img alt="" src="..." decoding="async" data-file-width="1920" data-file-height="2400" width="96" height="120">
</a>
</div>
<div class="searchResultImage-text">
<div class="mw-search-result-heading">
<a href="/wiki/Mecca" title="Mecca" data-serp-pos="0">Mecca</a>
</div>
<div class="searchresult">
many tunnels.<span class="searchmatch"><ref>https://www.constructionweekonline.com/projects-tenders/article-22689-makkah-building-eight-tunnels-to-ease-congestion</ref</span>>
===Rapid...
</div>
<div class="mw-search-result-data">97 KB (10,753 words) - 09:06, 7 October 2022</div>
</div>
</li>
...
</ul>
```
with appropriate CSS flex styling.
**Steps to replicate the issue** (include links if applicable):
* Open any WMF-hosted wiki like https://zh.wikipedia.org;
* Search anything that included in the article.
**What happens?**:
Search results have text content line feeds that exceed the device screen width.
{F35526082}
**What should have happened instead?**:
The text content of the search results will not exceed the width of the device screen in line feed position.
**Software version** (skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
Can be reproduced at least on Internet Explorer 11 (simulate Windows Phone device on PC) and Chrome (including Chromium-based browser) 105.
This ticket is to remove the Message 3 mentioned in the ticket [[ https://phabricator.wikimedia.org/T307464 | T307464 ]] in the case mentioned below.
**Article exist message**
{F35201136}
**Problem: **The above message is excessive and the link is repetitive when the article mentioned is already the first result in the list. In cases when the user is searching in other namespaces, this message is useful in informing the user about the article that might have been missed otherwise. However when the user is looking at article namespace results it serves no purpose.
**Solution / Acceptance Criteria**
[] Remove this message when the user is searching in article namespace.
**List of steps to reproduce** (step by step, including full links if applicable):
* Go to https://meta.wikimedia.org
* Type `Special:Banner` in the search bar
**What happens?**:
Three special pages are displayed as suggestions:
* Special:BannerLoader
* Special:BannerRandom
* Special:BannerAllocation
**What should have happened instead?**:
Only Special:BannerAllocation should be shown.
Special:BannerLoader and Special:BannerRandom appear to be both behind the scenes parts of Central Notice, and shouldn't be visible. Visiting Special:BannerLoader outputs a raw error string (`mw.centralNotice.handleBannerLoaderError("MissingRequiredParamsException while loading banner: '(none provided)'");`), and visiting Special:BannerRandom shows the wikimedia error page with a 410 error.
Steps to reproduce:
# go to https://en.wikipedia.org/
# enter `1.2.3.4` in the search bar and press enter
Expected behavior: you see a search results page
Actual behavior: you are forwarded to `Special:Contributions/1.2.3.4`.
I don't think this behavior makes any sense.
See T306246.
Here's another cool feature for the WMF developers to ignore.
Icons.
Look at these ajax search results for "ana":
{F35053510}
Don't worry about the compression of the screenshot, it's nothing compared to the thumbnails. Anal sex shouldn't have a thumbnail (I blurred it for the screenshot). The thumbnail for anaphylaxis is okay. The thumbnail for Ana de Armas isn't great, but passable I guess. The thumbnails for analog-to-digital converter and analgesic are not terribly useful without a caption to provide context.
That's 1 good, 1 passable and 2 somewhere between neutral and passable.
That just leaves the thumbnails for analytic philosophy, anatomy, Anaheim, anabolic steroid, anatomical terms of location and Anatolia. 6 thumbnails that, in my eyes, don't rise above the "garbage" level.
If you want something visual (which is admittedly easier to take in than a wall of text), try using the category system and/or Wikidata (specifically "instance of") to pick a category icon that can be optimized for display in search results. Here's a mockup, it's ugly because I just scraped some random icons from Commons together:
{F35053561}
For attribution purposes:
https://commons.wikimedia.org/wiki/File:Gender_signs.svg
https://commons.wikimedia.org/wiki/File:P_politics_icon_redpurple.png
https://commons.wikimedia.org/wiki/File:Deus_geography.png
https://commons.wikimedia.org/wiki/File:Aes_staff_blue_C.svg
https://commons.wikimedia.org/wiki/File:Aspirin-skeletal.svg
https://commons.wikimedia.org/wiki/File:P_philosophy.png
https://commons.wikimedia.org/wiki/File:Noun_Project_Technology_icon_2034212.svg
https://commons.wikimedia.org/wiki/File:Clapperboard_icon.png
**Request Status:** New Request
**Request Type:** project support request
**Related APP Priority & OKRs:**
=== Details
- **Request Description:**
**List of steps to reproduce** (step by step, including full links if applicable):
* Go to https://en.wikipedia.org/wiki/Main_Page?useskin=minerva
* Enter "ana" in the search box, because we are interested in Anaheim, California
* [[ https://knowyourmeme.com/memes/im-twelve-years-old-and-what-is-this | I'm Twelve Years Old and What is This?]]
**What happens?**:
Here's a picture of a penis in an anus!
**What should have happened instead?**:
NOT a picture of a penis in an anus
Search needs to obey https://en.wikipedia.org/wiki/MediaWiki:Bad_image_list.
* Enter "genit" for a genital piercing.
* Enter "apad" for the evolved version of Prince Albert.
* Enter "autof" for a guy sucking his own cock. Let's hope the article on autofocus isn't too popular with children.
* Enter "clit" for various clitoris images. Let's hope the children who live in Clitheroe aren't too interested in reading about their town.
* Enter "christina p" for another clitoris image.
* Enter "dyd" for a cock piercing
* please don't ask me to look up more examples
In a nutshell: MediaWiki:Bad_image_list is essentially a subset of MediaWiki:Pageimages-denylist but isn't treated as such.
- **Indicate Priority Level:** Medium
- **Main Requestors:** @ovasileva
- **Ideal Delivery Date:**
- **Stakeholders:** Desktop Refresh, search users
**List of steps to reproduce** (step by step, including full links if applicable):
* Log out.
* Go to main page of the French Wikipedia: https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal
* Click the search box at the top of the page once.
**What happens?**:
The search box is focused, and you can type in it, but the IME selector (little keyboard icon) does not always appear. It seems to depend how quickly after loading the page you focus the search box.
If you click outside the search box and then click again inside the search box, the ime selector does appear.
**What should have happened instead?**:
The ime selector must appear the first time you click the search box.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
Tested on Chromium 111 and Firefox 111 on Ubuntu 22.10.
**Feature summary** (what you would like to be able to do and where):
As a mobile user, I would like to be able to easily search for help and community discussions.
As an editor, I would also like to search other namespaces like templates and user pages from within mobile view.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
* On mobile web, if I perform an empty search or visit Special:Search directly, the page is empty. T300451
* On mobile web (with or without AMC enabled), if I type a search string, then choose “Search within pages” in the drop-down, the search results page doesn't have any widgets to refine the search.
* I learned today from T294799 that there is a profile=advanced parameter but I have not found any affordance / access point for this.
**Benefits** (why should this be implemented?):
* May benefit new users who don't know about namespace prefixes, nor that they can type them in the search box. Hosts at w:en:WP:Teahouse often advise new users to search on Help://someword// as a technique for finding help documentation. Whereas Vector has a “Help” link in the left sidebar under //Contribute// (which on w:en: links to Help:Contents), Minerva does not have any Help link as far as I can see.
* Avoids having to hand-type the prefix.
* Typing the namespace prefix only searches for titles (or other pages mentioning the page title), it doesn't search for keywords in pages of the namespace. Adding the selectors would permit full-text search outside ns0.
* Allows experienced users to search across multiple namespaces without switching to desktop view.
**List of steps to reproduce** (step by step, including full links if applicable):
Scenario 1, empty search
# On mobile web, place the cursor in the search box.
# Tap “Search” or “Enter”on the keyboard (the label for the enter key changes on some touchscreen platforms like iOS).
Scenario 2, switch from desktop
# On desktop web, do an empty search.
# Arrive at Special:Search, notice that it has selectors for advanced searching and for searching other namespaces.
# Tap //Mobile view// at the bottom of the page.
Scenario 3, explicitly visit Special:Search
# In mobile web with AMC, open the burger menu
# Tap Special Pages
# Tap Search
**What happens?**:
I get an empty page with just the title “Search”.
E.g. https://en.m.wikipedia.org/w/index.php?search=&title=
https://en.m.wikipedia.org/wiki/Special:Search
**What should have happened instead?**:
I expect a page with a search box and additional selectors for namespaces, other advanced search options, and sort-by options. Or at least a message saying to switch to desktop view. Or, if I have arrived there from a null-search, a message saying “There were no results matching the query.”
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
Wikimedia wikis (tested on English Wikipedia). Safari/iOS, and Edgium/Windows. Similar behaviour is observed on desktop web with useskin=Minerva, except sometimes (?) I see the marching dots like it's starting to load the selector widgets.
**List of steps to reproduce** (step by step, including full links if applicable):
* Open https://en.wikipedia.org/wiki/Special:Search.
* Copy this (with a space at the end): `абвгдеёжзийклмнопрстуфхцчшщъыьэюя ` (it's the Russian alphabet).
* Paste into the search form as many times as you can.
**What happens?**:
At the 4th paste, you will bump into a length limit. But it's a wrong one – 129 characters, which is obviously 255 bytes (Cyrillic characters are 2 bytes each).
**What should have happened instead?**:
The real limit is 300 characters, see T107947 and [[https://en.wikipedia.org/w/index.php?title=Special:Search&search=абвгдеёжзийклмнопрстуфхцчшщъыьэюя+абвгдеёжзийклмнопрстуфхцчшщъыьэюя+абвгдеёжзийклмнопрстуфхцчшщъыьэюя+абвгдеёжзийклмнопрстуфхцчшщъыьэюя+абвгдеёжзийклмнопрстуфхцчшщъыьэюя+абвгдеёжзийклмнопрстуфхцчшщъыьэюя+абвгдеёжзийклмнопрстуфхцчшщъыьэюя+абвгдеёжзийклмнопрстуфхцчшщъыьэюя+абвгдеёжзийклмнопрстуфхцчшщъыьэюя&ns0=1|a 305 character query]]. Actually, you //will// be able to reach it if you type in the address bar, not the search bar.
**Other information**
I noticed `mw.widgets.TitleWidget` is used there with its 255 byte limit. So perhaps this limit is wrongly inherited by `mw.widgets.SearchInputWidget`.
Came across this bug when people [[https://ru.wikipedia.org/wiki/Template_talk:Cite_web#Упростить_штрафные_категории|started renaming long categories]] because their names don't fit in the search query.
Search results show the title of the redirect page, not the actual page. These should be resolved by the API
Opensearch for autocomplete applies to current-Vector not new-Vector. (Everything else about this ticket is perfectly accurate.)
Current-Vector runs this API query for search autocomplete: https://en.wikipedia.org/w/api.php?action=opensearch&format=jsonfm&formatversion=2&search=grand%20buda&namespace=0&limit=10
If it was changed to add the redirects=resolve parameter like so: https://en.wikipedia.org/w/api.php?action=opensearch&format=jsonfm&formatversion=2&search=grand%20buda&namespace=0&limit=10&redirects=resolve
| what I see | what I expect to see
| {F34789765} | {F34789767}
**List of steps to reproduce** (step by step, including full links if applicable):
* Open https://en.m.wikipedia.org/w/index.php?search=&title=Special%3ASearch&profile=advanced in responsive design mode (360x800px)
**What happens?**:
The box "Search in namespaces" is wider than the viewport and causes a horizontal scrollbar to appear.
**What should have happened instead?**:
No scrollbar or scrollbar only for the box "Search in namespaces".
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**:
{F34722858}
1. Firefox 90.0.2 on Fedora 34. Vector skin. `Lohit Telugu` font.
2. Go to https://te.wikipedia.org/wiki/మొదటి_పేజీ?safemode=1
3. Look at search field position being too low
{F34574518}
{F34574522}
**List of steps to reproduce** (step by step, including full links if applicable):
* Create a wiki page with non latin (Cyrillic, Arabic etc) text
* Try to search for Cyrllic or Arabic text on that page
**What happens?**: on my MediaWiki 1.36 with MySQL Version 5.7.2 when I search something in Cyrillic script, I get only headers, but no text in results.
{F34557925}
**What should have happened instead?**: I should have had also text patterns in result, including search key words in Cryillic script.
**Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc**:
I use a shared hosting with the following parameters
- MediaWiki 1.34
- MySQL Version 5.7.23(MySQL Ver 14.14 Distrib 5.7.23-24, for Linux (x86_64) using 6.0
- CentOS7;
- Nginx и Apache HTTP Server Version 2.4;
- PHP 7.4.14 (cgi-fcgi)
- Perl 5.10;
- Python 2.6-3.9
The problem resolves if you add
```
$wgAdvancedSearchHighlighting = true;
```
Create a wiki page with title "Test for search. Abcd" (assume no other pages exist in the wiki).
Try to search for "abcd" or "search" (without quotes).
The title will not be found, if the DB backend is PostgreSQL.
Why not?
Essentially, the problem is with postgres FTS tsvector:
```
wiki=# select page_id, page_title, titlevector from wiki.page where page_title ilike '%abcd%';
page_id | page_title | titlevector
---------+-----------------------+---------------------------
382 | Test_for_search._Abcd | 'search._abcd':3 'test':1
wiki=# SELECT * FROM ts_debug('pg_catalog.english', 'Test_for_search._Abcd');
alias | description | token | dictionaries | dictionary | lexemes
-----------+-------------------+--------------+----------------+--------------+----------------
asciiword | Word, all ASCII | Test | {english_stem} | english_stem | {test}
blank | Space symbols | _ | {} | |
asciiword | Word, all ASCII | for | {english_stem} | english_stem | {}
blank | Space symbols | _ | {} | |
file | File or path name | search._Abcd | {simple} | simple | {search._abcd}
```
Tsvector is created from title with underscores (not spaces), and postgres FTS parser recognizes the whole part "search._Abcd" as a filename/path.
Suggestion: construct tsvecor after replacing underscores to spaces/
MW 1.34.1, PHP 7.4.3 (fpm-fcgi), PostgreSQL 12.4
An OpenSearch or [PrefixSearch for "la"](https://de.wikipedia.beta.wmflabs.org/w/api.php?action=templatedata&format=json&includeMissingTitles=1&lang=en&generator=prefixsearch&gpssearch=la&gpsnamespace=10&gpslimit=1) doesn't find [the template that's literally called "Template:LA"](https://de.wikipedia.beta.wmflabs.org/wiki/Template:LA), even if that would be a perfect match. Instead, another template is found at the first position. In this case "Template:Lang".
The same [PrefixSearch for "LA"](https://de.wikipedia.beta.wmflabs.org/w/api.php?action=templatedata&format=json&includeMissingTitles=1&lang=en&generator=prefixsearch&gpssearch=la&gpsnamespace=10&gpslimit=1) does find "Template:LA".
Searching for "la" also finds "Template:LA", but at position 17.
This is obviously somewhat case-sensitive, but the behavior is not consistent.
# It depends on the search backend. The behavior is different when #cirrussearch is in charge vs. when core's default prefix search is. While #cirrussearch's behavior is generally case-insensitive, [core's PrefixSearch class](https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/search/PrefixSearch.php$275) performs `LIKE` queries on the `page_title` column. This column does not have a case-insensitive collation like `utf8_general_ci` assigned, i.e. it's behavior is generally case-sensitive. Searching for "la" never finds "LA".
# No matter which backend is used, the search result is always processed by the [SearchExactMatchRescorer](https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/search/SearchExactMatchRescorer.php$47). This code is in charge of exactly what this ticket is about: It makes sure an exact match is always at the top of the search results, either by moving it up or adding it if the backend missed it. However, searching for that exact match is done using `Title::newFromText()`, which is case-sensitive. Searching for "la" this way also doesn't find "LA".
Expected behavior:
* Users typically type lowercase. I think it's fair to assume that most users expect "la" to find the same results as "LA".
* When there is no "Template:La" but "Template:LA", I expect "Template:LA" at the first position, no matter if I search for "la" or "LA".
* When both "Template:La" and "Template:LA" exist (which is rare, but possible), I expect the two at position 1 and 2. When I type "la" I expect "Template:La" at the first position. When I type "LA" I expect "Template:LA" at the first position.
* I expect this behavior even if the pages are redirects.
Possible ways forward:
* Make the SQL query in the PrefixSearch class case-insensitive. Example code for this can be seen in [gerrit:700175](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/700175/1/includes/search/PrefixSearch.php#276).
* Add code to the default backend that performs an additional, case-insensitive search for an exact match (i.e. not a `LIKE` but a `=`). Example code for this can be seen in [gerrit:700175](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/700175/1/includes/search/PrefixSearch.php#287).
* Add code to the rescorer that's able to find all exact matches despite their capitalization. Incomplete example code for this can be seen in [gerrit:700172](https://gerrit.wikimedia.org/r/c/mediawiki/core/+/700172/1/includes/search/SearchExactMatchRescorer.php).
* Add an additional step to the rescorer that moves all exact matches to the top, despite their capitalization. Only then look for a (true) exact `Title` match. While this won't always solve the problem, it's cheap (no extra SQL) and will improve results like the "position 17" example from the top.
* …?
The hook ShowSearchHit is supposed to allow results to be hidden if the callback returns false. However, for titles which fail a 'read' permissions check, this does not work properly.
This occurs in FullSearchResultWidget::render(), and happens because the permissions check is done before the hook is called, and immediately returns a search result (without a fulltext preview) if the permissions check fails. I would think the appropriate behavior would be to either call the hook separately in the failed permissions case to see whether the result should be returned as just the title (i.e. the current behavior) or null (if the hook callback returns false).
Alternatively, it's not obvious to me why we wouldn't just want to return null if the permissions check fails (rather than show a link to a title that the user won't be able to access anyway).
This is related to the [[ https://gerrit.wikimedia.org/g/mediawiki/core/+/4d284420e4221caf9ffa8396b9948d5369c37306/resources/src/mediawiki.widgets/mw.widgets.SearchInputWidget.js | OOUI component ]] that wraps the central search bar on Special:Search: this component is what turns the plain html text input box for search into an autocomplete.
Seen on various search pages
https://logstash.wikimedia.org/app/dashboards#/doc/logstash-*/logstash-2021.04.20?id=t5c58HgBGiM4niWIb8GP
```name=message
Error: Widget not found
```
```name=trace
at OO.ui.Element.static.unsafeInfuse URL1:183:48
at OO.ui.Element.static.infuse URL1:182:545
at OO.ui.infuse URL1:179:29
at URL1:792:596
at mightThrow URL1:53:141
at resolve/</process< URL1:53:800
URL1: https://ro.wikipedia.org/w/load.php?lang=ro&modules=Spinner%2Cjquery%2Coojs%2Coojs-router%2Coojs-ui-core%2Coojs-ui-widgets%2Csite%7Cext.advancedSearch.elements%2Cinit%2Cstyles%7Cext.centralNotice.geoIP%7Cext.centralauth.centralautologin%7Cext.cirrus.serp%7Cext.cx.eventlogging.campaigns%7Cext.dismissableSiteNotice%2CeventLogging%2CnavigationTiming%2Cpopups%2CwikimediaEvents%7Cext.tmh.OgvJsSupport%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cjquery.client%2Ccookie%2CembedPlayer%2ChighlightText%2CloadingSpinner%2CmwEmbedUtil%2Csuggestions%2CtextSelection%2CtriggerQueueCallback%7Cjquery.uls.data%7Cmediawiki.String%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2Cexperiments%2CjqueryMsg%2Clanguage%2Crouter%2CsearchSuggest%2Cstorage%2Cuser%2Cutil%2Cwidgets%7Cmediawiki.editfont.styles%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.special.search%7Cmediawiki.widgets.SearchInputWidget%7Cmw.EmbedPlayer.loader%7Cmw.MediaWikiPlayer.loader%7Cmw.MwEmbedSupport%2CPopUpMediaTransform%7Cmw.MwEmbedSupport.style%7Cmw.PopUpMediaTransform.styles%7Cmw.TimedText.loader%7Coojs-ui-widgets.icons%7Coojs-ui.styles.icons-content%2Cicons-interactions%2Cicons-layout%7Cskins.vector.legacy.js%7Cuser.defaults&skin=vector&version=ieqv3
```
Not sure how to replicate. Perhaps the search uses OOUI server side rendering only on a small amount of page views?
It looks like 20-112 hits in the last day, so this doesn't seem to be coming up a lot
**Paste**, not type, the word "surveying" into the Wikipedia search box.
{F34183684}
You'll see at this point there is no way, no matter what you do with your mouse, to see any of the other possibilities, including "search pages containing this text."
At this point one needs to add a blank at the front to revive the matches.
Yes, "surveying" matches an existing page...
which is all what we get if we hit the magnifying glass.
Could [[ https://qrank.toolforge.org/ | QRank ]] be useful for ranking search results in Wikidata’s Special:Search? See [[ https://github.com/brawer/wikidata-qrank/blob/main/doc/design.md | design document ]] for background. Disclaimer: I wrote QRank; apologies for this shameless plug. Filing ticket [[ https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Query_Service_and_search#QRank | as suggested ]] by @dcausse. (Not sure if I’ve assigned the right tags to the ticket; feel free to change).
**User story:** As an unsophisticated search user, I don't want suggestions that include search syntax that I don't understand—especially if the suggestions is literally "the logical complement of what you searched for"—because it is confusing and clicking on such suggestions normally gives unwanted results.
When searching for //[[ https://en.wikipedia.org/w/index.php?search=xnxx&title=Special:Search&profile=default&fulltext=1 | xnxx ]]// on enwiki, I get the DYM suggestion //!xnxx,// which is "not xnxx".
@EBernhardson pointed out that //!xnxx// is a `complex_query` (see [[ https://en.wikipedia.org/w/index.php?search=!xnxx&fulltext=1title=Special:Search&go=Go&cirrusDumpQueryAST | query dump ]]) and that these are perhaps not currently being filtered from Glent.
We should make sure that other queries labelled `complex_query` are also unfit for Glent suggestions before filtering them.
Alternatively, it may be possible that these are leftovers from earlier Glent prep runs that allowed search syntax. I //thought// that the [[ https://phabricator.wikimedia.org/T262610#6492273 | latest fix ]] only allowed `simple_bag_of_words`, which should have excluded `!xnxx`.
**N.B.:** There are a small number of article titles, like //!Kung people// on enwiki an //-ish// on enwikt, that have search syntax in their titles. These exact-match titles could no longer be suggestions after this change.
**Acceptance Criteria:**
* An understanding of how `!xnxx` got into the list of candidate suggestions.
* A fix to remove similar queries from the existing pool of candidates and/or prevent new such queries from getting into the candidate pool.
**Setup**
- MediaWiki 1.35.1 (3ff1919) 01:03, 7 February 2021
- PHP 7.3.19-1~deb10u1 (apache2handler)
- MariaDB 10.3.27-MariaDB-0+deb10u1
- ICU 63.1
**Issue**
When tying to rebuild the full search index `php maintenance/rebuildtextindex.php` fails with:
```
php maintenance/rebuildtextindex.php
Clearing searchindex table...Done
Rebuilding index fields for 63073 pages...
500
1000
1500
2000
2500
3000
Wikimedia\Rdbms\DBQueryError from line 1699 of /../w/includes/libs/rdbms/database/Database.php: Error 1406: Data too long for column 'si_title' at row 1 (localhost:6363)
Function: SearchMySQL::update
Query: REPLACE INTO `searchindex` (si_page,si_title,si_text) VALUES ('3380','u8d0bcu8d0b0u8d180u8d0b8u8d0bdu8d0b0 u8d186u8d0b2u8d0b5u8d182u8d0b0u8d0b5u8d0b2u8d0b0 - u8d0bcu8d0bdu8d0b5 u8d0bdu8d180u8d0b0u8d0b2u8d0b8u8d182u8d181u8d18f u8d187u8d182u8d0be u8d0b2u8d18b u8d0b1u8d0beu8d0bbu8d18cu8d0bdu8d18b u8d0bdu8d0b5 u8d0bcu8d0bdu8d0beu8d0b9...',' pu800 tlu800 russian t1u800 u8d0bcu8d0bdu8d0b5 u8d0bdu8d180u8d0b0u8d0b2u8d0b8u8d182u8d181u8d18f u8d187u8d182u8d0be u8d0b2u8d18b u8d0b1u8d0beu8d0bbu8d18cu8d0bdu8d18b u8d0bdu8d0b5 u8d0bcu8d0bdu8d0beu8d0b9... t2u800 itu800 pleases meu800 that iu800 amu800 notu800 your hurt... uu800 itpleasesmethatiamnotyourhurt ru800 u8d0b8u8d180u8d0beu8d0bdu8d0b8u8d18f u8d181u8d183u8d0b4u8d18cu8d0b1u8d18b tag1 songs tag2 poems tag3 film songs tag4 tag5 tag6 lu800 4u800 vu800 lvmfy-ryhas mu800 u8d0bcu8d0bdu8d0b5 u8d0bdu8d180u8d0b0u8d0b2u8d0b8u8d182u8d181u8d18f u8d187u8d182u8d0be u8d0b2u8d18b u8d0b1u8d0beu8d0bbu8d18cu8d0bdu8d18b u8d0bdu8d0b5 u8d0bcu8d0bdu8d0beu8d0b9 u8d0bcu8d0bdu8d0b5 u8d0bdu8d180u8d0b0u8d0b2u8d0b8u8d182u8d181u8d18f u8d187u8d182u8d0be u8d18f u8d0b1u8d0beu8d0bbu8d18cu8d0bdu8d0b0 u8d0bdu8d0b5 u8d0b2u8d0b0u8d0bcu8d0b8 u8d187u8d182u8d0be u8d0bdu8d0b8u8d0bau8d0beu8d0b3u8d0b4u8d0b0 u8d182u8d18fu8d0b6u8d0b5u8d0bbu8d18bu8d0b9 u8d188u8d0b0u8d180 u8d0b7u8d0b5u8d0bcu8d0bdu8d0beu8d0b9 u8d0bdu8d0b5 u8d183u8d0bfu8d0bbu8d18bu8d0b2u8d0b5u8d182 u8d0bfu8d0beu8d0b4 u8d0bdu8d0b0u8d188u8d0b8u8d0bcu8d0b8 u8d0bdu8d0beu8d0b3u8d0b0u8d0bcu8d0b8. u8d0bcu8d0bdu8d0b5 u8d0bdu8d180u8d0b0u8d0b2u8d0b8u8d182u8d181u8d18f u8d187u8d182u8d0be u8d0bcu8d0beu8d0b6u8d0bdu8d0be u8d0b1u8d18bu8d182u8d18c u8d181u8d0bcu8d0b5u8d188u8d0bdu8d0beu8d0b9 u8e28093 u8d180u8d0b0u8d181u8d0bfu8d183u8d189u8d0b5u8d0bdu8d0bdu8d0beu8d0b9 - u8d0b8 u8d0bdu8d0b5 u8d0b8u8d0b3u8d180u8d0b0u8d182u8d18c u8d181u8d0bbu8d0beu8d0b2u8d0b0u8d0bcu8d0b8 u8d0b8 u8d0bdu8d0b5 u8d0bau8d180u8d0b0u8d181u8d0bdu8d0b5u8d182u8d18c u8d183u8d0b4u8d183u8d188u8d0bbu8d0b8u8d0b2u8d0beu8d0b9 u8d0b2u8d0beu8d0bbu8d0bdu8d0beu8d0b9 u8d181u8d0bbu8d0b5u8d0b3u8d0bau8d0b0 u8d181u8d0beu8d0bfu8d180u8d0b8u8d0bau8d0beu8d181u8d0bdu8d183u8d0b2u8d188u8d0b8u8d181u8d18c u8d180u8d183u8d0bau8d0b0u8d0b2u8d0b0u8d0bcu8d0b8. u8d0bcu8d0bdu8d0b5 u8d0bdu8d180u8d0b0u8d0b2u8d0b8u8d182u8d181u8d18f u8d0b5u8d189u8d0b5 u8d187u8d182u8d0be u8d0b2u8d18b u8d0bfu8d180u8d0b8 u8d0bcu8d0bdu8d0b5 u8d181u8d0bfu8d0beu8d0bau8d0beu8d0b9u8d0bdu8d0be u8d0beu8d0b1u8d0bdu8d0b8u8d0bcu8d0b0u8d0b5u8d182u8d0b5 u8d0b4u8d180u8d183u8d0b3u8d183u8d18e u8d0bdu8d0b5 u8d0bfu8d180u8d0beu8d187u8d0b8u8d182u8d0b5 u8d0bcu8d0bdu8d0b5 u8d0b2 u8d0b0u8d0b4u8d0beu8d0b2u8d0beu8d0bc u8d0beu8d0b3u8d0bdu8d0b5 u8d0b3u8d0beu8d180u8d0b5u8d182u8d18c u8d0b7u8d0b0 u8d182u8d0be u8d187u8d182u8d0be u8d18f u8d0bdu8d0b5 u8d0b2u8d0b0u8d181 u8d186u8d0b5u8d0bbu8d183u8d18e. u8d187u8d182u8d0be u8d0b8u8d0bcu8d18f u8d0bdu8d0b5u8d0b6u8d0bdu8d0beu8d0b5 u8d0bcu8d0beu8d0b5 u8d0bcu8d0beu8d0b9 u8d0bdu8d0b5u8d0b6u8d0bdu8d18bu8d0b9 u8d0bdu8d0b5 u8d183u8d0bfu8d0beu8d0bcu8d0b8u8d0bdu8d0b0u8d0b5u8d182u8d0b5 u8d0bdu8d0b8 u8d0b4u8d0bdu8d0b5u8d0bc u8d0bdu8d0b8 u8d0bdu8d0beu8d187u8d18cu8d18e - u8d0b2u8d181u8d183u8d0b5u8e280a6 u8d187u8d182u8d0be u8d0bdu8d0b8u8d0bau8d0beu8d0b3u8d0b4u8d0b0 u8d0b2 u8d186u8d0b5u8d180u8d0bau8d0beu8d0b2u8d0bdu8d0beu8d0b9 u8d182u8d0b8u8d188u8d0b8u8d0bdu8d0b5 u8d0bdu8d0b5 u8d0bfu8d180u8d0beu8d0bfu8d0beu8d18eu8d182 u8d0bdu8d0b0u8d0b4 u8d0bdu8d0b0u8d0bcu8d0b8 u8d0b0u8d0bbu8d0bbu8d0b8u8d0bbu8d183u8d0b9u8d18f u8d181u8d0bfu8d0b0u8d181u8d0b8u8d0b1u8d0be u8d0b2u8d0b0u8d0bc u8d0b8 u8d181u8d0b5u8d180u8d0b4u8d186u8d0b5u8d0bc u8d0b8 u8d180u8d183u8d0bau8d0beu8d0b9 u8d0b7u8d0b0 u8d182u8d0be u8d187u8d182u8d0be u8d0b2u8d18b u8d0bcu8d0b5u8d0bdu8d18f - u8d0bdu8d0b5 u8d0b7u8d0bdu8d0b0u8d18f u8d181u8d0b0u8d0bcu8d0b8 u8e28093 u8d182u8d0b0u8d0ba u8d0bbu8d18eu8d0b1u8d0b8u8d182u8d0b5 u8d0b7u8d0b0 u8d0bcu8d0beu8d0b9 u8d0bdu8d0beu8d187u8d0bdu8d0beu8d0b9 u8d0bfu8d0beu8d0bau8d0beu8d0b9 u8d0b7u8d0b0 u8d180u8d0b5u8d0b4u8d0bau8d0beu8d181u8d182u8d18c u8d0b2u8d181u8d182u8d180u8d0b5u8d187 u8d0b7u8d0b0u8d0bau8d0b0u8d182u8d0bdu8d18bu8d0bcu8d0b8 u8d187u8d0b0u8d181u8d0b0u8d0bcu8d0b8 u8d0b7u8d0b0 u8d0bdu8d0b0u8d188u8d0b8 u8d0bdu8d0b5-u8d0b3u8d183u8d0bbu8d18fu8d0bdu8d18cu8d18f u8d0bfu8d0beu8d0b4 u8d0bbu8d183u8d0bdu8d0beu8d0b9 u8d0b7u8d0b0 u8d181u8d0beu8d0bbu8d0bdu8d186u8d0b5 u8d0bdu8d0b5 u8d183 u8d0bdu8d0b0u8d181 u8d0bdu8d0b0u8d0b4 u8d0b3u8d0beu8d0bbu8d0beu8d0b2u8d0b0u8d0bcu8d0b8 u8d0b7u8d0b0 u8d182u8d0be u8d187u8d182u8d0be u8d0b2u8d18b u8d0b1u8d0beu8d0bbu8d18cu8d0bdu8d18b - u8d183u8d0b2u8d18b - u8d0bdu8d0b5 u8d0bcu8d0bdu8d0beu8d0b9 u8d0b7u8d0b0 u8d182u8d0be u8d187u8d182u8d0be u8d18f u8d0b1u8d0beu8d0bbu8d18cu8d0bdu8d0b0 - u8d183u8d0b2u8d18b - u8d0bdu8d0b5 u8d0b2u8d0b0u8d0bcu8d0b8. itu800 pleases meu800 that iu800 amu800 notu800 your hurt itu800 pleases meu800 that youu800 areu800 notu800 myu800 illness that asu800 weu800 step upon theu800 heavy earth itsu800 solidness shall never drift beneath usu800. itu800 pleases meu800 that iu800 donu8e28099t have tou800 flirt that iu800 canu800 beu800 relaxed andu800 wordplay-needless inu800 suffocating blush notu800 feeling stirred byu800 accidental touch oru800 random glimpses. itu800 pleases meu800 asu800 well that when weu800 meet youu800 would embrace another oneu800 serenely that youu800 donu8e28099t fantasize ofu800 hellish heat consuming meu800 foru800 kissing someone keenly that myu800 sweet name will notu800 emerge myu800 sweet from your fair lips - inu800 vain - come dayu800 oru800 evening andu800 inu800 au800 silent temple brightly litu800 weu8e28099ll never wedu800 tou800 hallelujah singing. andu800 with myu800 heart andu800 hand comes thanking word; foru800 youu800 - without theu800 knowledge tou800 admit this u8e28093 sou800 fancy meu800; foru800 sleep sou800 undisturbed foru800 rareness ofu800 ouru800 dates inu800 twilight dimness foru800 walking-notu800 across au800 moonlit court foru800 rising sunu800 weu800 dou800 notu800 ever witness foru800 fact that iu800 - alas - amu800 notu800 your hurt foru800 fact that youu800 - alas - areu800 notu800 myu800 illness. u8d0b5u8d0b2u8d0b3u8d0b5u8d0bdu8d0b8u8d18f u8d181u8d0b0u8d180u8d0bau8d0b8u8d181u8d18cu8d18fu8d0bdu8d186 category u8d0b8u8d180u8d0beu8d0bdu8d0b8u8d18f u8d181u8d183u8d0b4u8d18cu8d0b1u8d18b category u8d186u8d0b2u8d0b5u8d182u8d0b0u8d0b5u8d0b2u8d0b0 u8d0bcu8d0b0u8d180u8d0b8u8d0bdu8d0b0 u8d0b8u8d0b2u8d0b0u8d0bdu8d0beu8d0b2u8d0bdu8d0b0 category u8d0b5u8d0b2u8d0b3u8d0b5u8d0bdu8d0b8u8d18f u8d181u8d0b0u8d180u8d0bau8d0b8u8d181u8d18cu8d18fu8d0bdu8d186 category u8d0bfu8d183u8d0b3u8d0b0u8d187u8d191u8d0b2u8d0b0 u8d0b0u8d0bbu8d0bbu8d0b0 u8d0b1u8d0beu8d180u8d0b8u8d181u8d0beu8d0b2u8d0bdu8d0b0 category u8d0b8u8d180u8d0b8u8d0bdu8d0b0 u8d0bau8d180u8d183u8d182u8d0beu8d0b2u8d0b0 category u8d182u8d0b0u8d180u8d0b8u8d0b2u8d0b5u8d180u8d0b4u8d0b8u8d0b5u8d0b2 u8d0bcu8d0b8u8d0bau8d0b0u8d18du8d0bb u8d0bbu8d0b5u8d0beu8d0bdu8d0beu8d0b2u8d0b8u8d187 ')
```
**Backtrace**
```
#0 /../w/includes/libs/rdbms/database/Database.php(1683): Wikimedia\Rdbms\Database->getQueryException('Data too long f...', 1406, 'REPLACE INTO `s...', 'SearchMySQL::up...')
#1 /../w/includes/libs/rdbms/database/Database.php(1658): Wikimedia\Rdbms\Database->getQueryExceptionAndLog('Data too long f...', 1406, 'REPLACE INTO `s...', 'SearchMySQL::up...')
#2 /../w/includes/libs/rdbms/database/Database.php(1227): Wikimedia\Rdbms\Database->reportQueryError('Data too long f...', 1406, 'REPLACE INTO `s...', 'SearchMySQL::up...', false)
#3 /../w/includes/libs/rdbms/database/DatabaseMysqlBase.php(1367): Wikimedia\Rdbms\Database->query('REPLACE INTO `s...', 'SearchMySQL::up...', 128)
#4 /../w/includes/libs/rdbms/database/Database.php(3240): Wikimedia\Rdbms\DatabaseMysqlBase->doReplace('searchindex', Array, Array, 'SearchMySQL::up...')
#5 /../w/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->replace('searchindex', Array, Array, 'SearchMySQL::up...')
#6 /../w/includes/libs/rdbms/database/DBConnRef.php(496): Wikimedia\Rdbms\DBConnRef->__call('replace', Array)
#7 /../w/includes/search/SearchMySQL.php(354): Wikimedia\Rdbms\DBConnRef->replace('searchindex', 'si_page', Array, 'SearchMySQL::up...')
#8 /../w/includes/deferred/SearchUpdate.php(106): SearchMySQL->update('3380', 'u8d0bcu8d0b0u8d...', ' pu800 tlu800 r...')
#9 /../w/maintenance/rebuildtextindex.php(114): SearchUpdate->doUpdate()
#10 /../w/maintenance/rebuildtextindex.php(68): RebuildTextIndex->populateSearchIndex()
#11 /../w/maintenance/doMaintenance.php(107): RebuildTextIndex->execute()
#12 /../w/maintenance/rebuildtextindex.php(162): require_once('/var/www/html/w...')
#13 {main}
```
Not sure why this is happening. If the title is too long I guess it should not be stored anyways. Hmm ....
Related to T274707? Same wiki.
Steps to Reproduce:
---
1. Go to https://en.wikipedia.org/wiki/Main_Page
2. Open the browser's developer console (hit `F12`) and select the network tab
3. Focus the search input
4. Type and repeat typing a single letter the fastest you can, just don't hold the key pressed, but actually press and release it repeatedly
Actual Results
---
A request is made to the server for **every single key press**, no matter how fast you type, causing an unreasonable load on the server that needs to complete each request. However, the user won't see the results of most of this requests, since the user keeps typing on the search input, and new requests are constantly being requested. This makes most of those request wasted.
Expected Results
---
A [[ https://css-tricks.com/debouncing-throttling-explained-examples/#debounce | debounce ]] system should be put in place, to send requests at fixed and reasonable intervals (maybe every second?) or when the user stops typing for a short period of time. This greatly reduces the amount of wasted requests to the server, reducing server load, while the user will still see suggestions at a sensible rate.
I made a [[https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017/Search/Preferences_settings_to_modify_crosswiki_search_results|request back in 2017]] as part of 2017 wishlist, but it didn't garner enough votes to be in the top 10. Then I realized that I don't have to depend solely on wishlists, do I? Rather than having only centralized settings of crosswiki search results, I think individual users should decide themselves which results to display and which results from any one of sister projects to display in various local projects, like Wikipedia. Furthermore, individual users can prioritize which results they want to first see in mind. I think adding the crosswiki search result settings in the "Search" tab would be best suitable. If not, then where else within the user preferences?
One thing for sure: we must set default settings for various projects in order to reflect and respect longstanding consensus from local communities, like English Wikipedia, who decided to have results from a couple or a few sister projects disabled (e.g. T163463, T171803, T185250)
Short descriptions (sometimes referred to as "taglines" or just "descriptions") are short few word snippets provided to give a reader an idea of what an article is about before reading it. English Wikipedia is aiming have a short description for each article. It would be helpful both as a reader and an editor to see the short descriptions in the search suggestion.
Prior art:
When generating the search suggestions, the skin MinervaNeue uses the "query" API action instead of the old/deprecated "opensearch" action. "query" returns all(?) of the information that "opensearch" provides and more including a description attribute. MinervaNeue uses that description to display the short description under the title.
{F32356195}
Let's face it: any non-English Wikipedia contains much fewer articles that the English one. As a consequence of this, searching a local Wikipedia often leads to [[ https://ru.wikipedia.org/w/index.php?title=%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%97%D0%B0%D1%8F%D0%B2%D0%BA%D0%B8_%D0%BD%D0%B0_%D1%81%D1%82%D0%B0%D1%82%D1%83%D1%81_%D0%B1%D0%BE%D1%82%D0%B0&diff=108961924&oldid=108961750 | "no results" ]]. What is a user's need at this point? They still need a result. Any result. Sometimes a user also posesses English and other (to them) foreign languages. I think that it would be a great opportunity to let them continue the search in another wiki with one click.
Maybe this click could happen in the interwiki section, where currently some settings are hidden (as for me, it's unexpected to see it there). Or maybe somewhere else, but it general, it should be near.
Another use case here is that, for example, my mother tongue is Russian so I usually lurk around the Russian Wikipedia. But sometimes I suddenly need to search for something in the English one.
Current path: click the main page, switch to English, search there. Not sure why, but I just don't like that path. Maybe because it's counter-intuitive: I need to search but I click somewhere else instead (to the main page).
I wish I could:
- click Search - enter term - specify other wikis where to search.
- or click Search - (if not already added as a saved setting) add English wiki in settings - enter a term.
{T250977} added mapping functionality to allow extensions to decouple `$wgSearchType`/`$wgSearchTypeAlternatives` from the underlying PHP class using ObjectFactory specification
However, it didn't give mappings for classes in MW core that are subclasses of `SearchDatabase` etc in core
Obviously this isn't a problem atm, but at some point `SearchMySQL` will be namespaced too, and we don't want to keep aliases around for ever, and similar to {T250812}, we don't want to have to have `$wgSearchType`/`$wgSearchTypeAlternatives` set to 'MediaWiki\Search\MySQL' etc (it's not exactly great in the current state in the API either - where you can end up being able to pass `srbackend=SearchMySQL`), so having mappings for something like 'mysql' => 'SearchMySQL' in the mix would make sense, and then being able to set `$wgSearchType`/`$wgSearchTypeAlternatives` to 'mysql' (and 'SearchMySQL' for back compat for some time?)
With using search API query for interwiki search (`&srinterwiki=1` option) we saw `pageid="0"` for all results from projects that are different from the initial one.
Steps to Reproduce:
As example, [[ https://en.wikipedia.org/w/api.php?action=query&list=search&format=xml&redirects=resolve&srlimit=1&srenablerewrites=1&&srprop=snippet&srinterwiki=1&srsearch=Tolstoy | requested from en-wikipedia]]:
```
https://en.wikipedia.org/w/api.php?action=query&list=search&format=xml&redirects=resolve&srlimit=1&srenablerewrites=1&&srprop=snippet&srinterwiki=1&srsearch=Tolstoy
```
Actual Results:
```lang=xml
<api batchcomplete="">
<continue sroffset="1" continue="-||"/>
<query>
<searchinfo totalhits="4331"/>
<search>
<p ns="0" title="Leo Tolstoy" pageid="18622119" snippet="Count Lev Nikolayevich <span class="searchmatch">Tolstoy</span> (/ˈtoʊlstɔɪ, ˈtɒl-/; Russian: Лев Николаевич Толстой, tr. Lev Nikoláyevich <span class="searchmatch">Tolstóy</span>; [lʲef nʲɪkɐˈlaɪvʲɪtɕ tɐlˈstoj] (listen);"/>
</search>
<interwikisearch>
<wikt>
<_v ns="0" title="Tolstoy" pageid="0" snippet="From Russian Толсто́й (Tolstój), from a stress variant of the ancestor of то́лстый (tólstyj, “stout”). <span class="searchmatch">Tolstoy</span> A surname." namespace="" url="https://en.wiktionary.org/wiki/Tolstoy"/>
</wikt>
<s>
<_v ns="0" title="A Confession (Tolstoy)" pageid="0" snippet="of Исповедь (A Confession) by Leo <span class="searchmatch">Tolstoy</span> 1996511English-language translations of Исповедь (A Confession)Leo <span class="searchmatch">Tolstoy</span> English-language translations of Исповедь" namespace="" url="https://en.wikisource.org/wiki/A_Confession_(Tolstoy)"/>
</s>
<q>
<_v ns="0" title="Leo Tolstoy" pageid="0" snippet="Lev Nikolayevitch <span class="searchmatch">Tolstoy</span> [Ле́в Никола́евич Толсто́й, usually rendered Leo <span class="searchmatch">Tolstoy</span>, or sometimes Tolstoi] (9 September 1828 – 20 November 1910) was a Russian" namespace="" url="https://en.wikiquote.org/wiki/Leo_Tolstoy"/>
</q>
<b>
<_v ns="0" title="Anarchist FAQ/What is Anarchism?/3.7" pageid="0" snippet="anarchist movement with the work of the famous Russian author Leo <span class="searchmatch">Tolstoy</span>. <span class="searchmatch">Tolstoy</span> took the message of the Bible seriously and came to consider that a" namespace="" url="https://en.wikibooks.org/wiki/Anarchist_FAQ/What_is_Anarchism%3F/3.7"/>
</b>
</interwikisearch>
<interwikisearchinfo totalhits="1855"/>
</query>
</api>
```
Expected Results:
```lang=xml
<api batchcomplete="">
<continue sroffset="1" continue="-||"/>
<query>
<searchinfo totalhits="4331"/>
<search>
<p ns="0" title="Leo Tolstoy" pageid="18622119" snippet="Count Lev Nikolayevich <span class="searchmatch">Tolstoy</span> (/ˈtoʊlstɔɪ, ˈtɒl-/; Russian: Лев Николаевич Толстой, tr. Lev Nikoláyevich <span class="searchmatch">Tolstóy</span>; [lʲef nʲɪkɐˈlaɪvʲɪtɕ tɐlˈstoj] (listen);"/>
</search>
<interwikisearch>
<wikt>
<_v ns="0" title="Tolstoy" pageid="6592235" snippet="From Russian Толсто́й (Tolstój), from a stress variant of the ancestor of то́лстый (tólstyj, “stout”). <span class="searchmatch">Tolstoy</span> A surname." namespace="" url="https://en.wiktionary.org/wiki/Tolstoy"/>
</wikt>
<s>
<_v ns="0" title="A Confession (Tolstoy)" pageid="1996511" snippet="of Исповедь (A Confession) by Leo <span class="searchmatch">Tolstoy</span> 1996511English-language translations of Исповедь (A Confession)Leo <span class="searchmatch">Tolstoy</span> English-language translations of Исповедь" namespace="" url="https://en.wikisource.org/wiki/A_Confession_(Tolstoy)"/>
</s>
<q>
<_v ns="0" title="Leo Tolstoy" pageid="143" snippet="Lev Nikolayevitch <span class="searchmatch">Tolstoy</span> [Ле́в Никола́евич Толсто́й, usually rendered Leo <span class="searchmatch">Tolstoy</span>, or sometimes Tolstoi] (9 September 1828 – 20 November 1910) was a Russian" namespace="" url="https://en.wikiquote.org/wiki/Leo_Tolstoy"/>
</q>
<b>
<_v ns="0" title="Anarchist FAQ/What is Anarchism?/3.7" pageid="219749" snippet="anarchist movement with the work of the famous Russian author Leo <span class="searchmatch">Tolstoy</span>. <span class="searchmatch">Tolstoy</span> took the message of the Bible seriously and came to consider that a" namespace="" url="https://en.wikibooks.org/wiki/Anarchist_FAQ/What_is_Anarchism%3F/3.7"/>
</b>
</interwikisearch>
<interwikisearchinfo totalhits="1855"/>
</query>
</api>
```
Reproduce:
1. Open a page (preferably an Wikibase entity page)
2. Refresh the page
3. Quickly put some text to Wikidata search box, like this: https://commons.wikimedia.org/wiki/File:Element_search_in_Wikidata_(Catalan).png, before the JavaScript is loaded (in entity pages, once JavaScript is loaded the edit statement buttons are shown)
Result:
The native OpenSearch suggestions is shown, overlapping the Wikibase search box.
Expected:
The native search box should be disabled.
Note:
T190454#4092077 proposed to integrate the Wikibase search box to the native search box.
Following up from {T172514}
It seems searchindex was never changed from a UNIQUE to a PRIMARY KEY
```lang=sql
--
-- When using the default MySQL search backend, page titles
-- and text are munged to strip markup, do Unicode case folding,
-- and prepare the result for MySQL's fulltext index.
--
-- This table must be MyISAM; InnoDB does not support the needed
-- fulltext index.
--
CREATE TABLE /*_*/searchindex (
-- Key to page_id
si_page int unsigned NOT NULL,
-- Munged version of title
si_title varchar(255) NOT NULL default '',
-- Munged version of body text
si_text mediumtext NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE UNIQUE INDEX /*i*/si_page ON /*_*/searchindex (si_page);
CREATE FULLTEXT INDEX /*i*/si_title ON /*_*/searchindex (si_title);
CREATE FULLTEXT INDEX /*i*/si_text ON /*_*/searchindex (si_text);
```
Should be a pretty easy fix
**Setup**
- MediaWiki 1.31.6 (c168a3f) 19. Dez. 2019, 14:28
- PHP 7.0.33-0+deb9u6 (apache2handler)
- MariaDB 10.1.41-MariaDB-0+deb9u1
- ICU 57.1
**Issue**
If you have things like «HelloWorld» or „HelloWorld“ on your wiki and try to search for HelloWorld you will get no search results at all. Only if you add «HelloWorld» or „HelloWorld“ including the quotation marks you get results. I expect nobody to add quotation marks to the search string. Moreover with mixed occurrences on the wiki «HelloWorld» or HelloWorld one would only get either results.
I believe it will be a great improvement to be able to also find quoted content.
I added "Discovery-Search" as a tag. Please change at your convenience if this is not the correct tag.
If you search a protected page using Special:Search and you're not a sysop, you won't see "This page doesn't exist, you can create it". That's not an isssue as long as the message isn't customized by the wiki.
For instance, Czech Wikipedia adds a link to Wiktionary, and also a link to whatlinkshere.
Maybe we should add a searchmenu-new-append message, empty by default, that would allow wiki owners to add always-displayed message, even if the page is protected? What do you think?
Hi,
I have found possible Information disclosure bug in the site (mediawiki-1.32.3)
Bug:[Information Disclosure leads to disclose the Database query and database name]
Steps to reproduce:
1.Open the mediawiki using the site https://wiki.mahara.org
2.go to the search bar and enter the single quote(') in that search box and search
3.You will get the database query error disclose the information about DB
4.I won't move further to get the database tables,I stopped there...
Vulnerable url with payload:https://wiki.mahara.org/index.php?search='
DB Error Information:
[XX8dCLpOheXeQVoKqPS3LgAAAAU] /index.php?search=%27+--%2B Wikimedia\Rdbms\DBQueryError from line 1506 of /usr/share/mediawiki-1.32.3/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: SELECT to_tsquery(''' & ! -+')
Function: Wikimedia\Rdbms\Database::query
Error: 42601 ERROR: syntax error in tsquery: "' & ! -+"{F30398268}
1.27
```
Targets
Occurrences of 'PrefixSearchBackend' in directory /Users/reedy/PhpstormProjects/mediawiki/extensions
Found Occurrences (5 usages found)
Usage in comments (2 usages found)
mediawiki (2 usages found)
extensions/SphinxSearch (1 usage found)
SphinxMWSearch.php (1 usage found)
67 * PrefixSearchBackend override for OpenSearch results
extensions/TitleKey/includes (1 usage found)
TitleKey.php (1 usage found)
67 // take over the PrefixSearchBackend hook without disabling the
Usage in string constants (3 usages found)
mediawiki (3 usages found)
extensions/SphinxSearch (2 usages found)
SphinxMWSearch.php (2 usages found)
46 $wgHooks[ 'PrefixSearchBackend' ][ ] = 'SphinxMWSearch::prefixSearch';
48 $wgHooks[ 'PrefixSearchBackend' ][ ] = 'SphinxMWSearch::infixSearch';
extensions/TitleKey/includes (1 usage found)
TitleKey.php (1 usage found)
71 $wgHooks['PrefixSearchBackend'][] = 'TitleKey::prefixSearchBackend';
```
Currently, many people might notice that the si_page column in the searchindex table is not always in numerical order in phpMyAdmin. We should add something there to ensure that the column is always in numerical order, perhaps an index or primary key.
An out-of-order si_page column may occur, for example, if a page has been deleted and then undeleted.
Hi, since upgrading to 1.33 we are seeing:
```
Query: REPLACE INTO `searchindex` (si_page,si_title,si_text) VALUES ('1042',' u8e6838a u8e4bca0 u8e5b7b2 u8e7bb8f u8e781ad u8e4baa1 u8e79a84 u8e5a4a7 u8e697a5 u8e69cac u8e5b89d u8e59bbd u8e58da0 u8e9a286 u8e58fb0 u8e6b9be u8efbc8c u8e5bc95 u8e58f91 u8e4b8a5 u8e9878d u8e79a84 u8e6ada6 u8e8a385 u8e8b5b7 u8e4b989 u8e586b2 u8e7aa81 u8efbc8c u8e980a0 u8e68890 u8e5a49a u8e5908d u8e690ad u8e982a3 u8e5989f u8e58aaa u8e98187 u8e5aeb3 ',' u8e4b893 u8e9a298 u8e68aa5 u8e5afbc u8e696b0 u8e997bb u8e697a5 u8e69c9f 2011 09u800 09u800 file scouts-guide-tou800-theu800-zombie-apocalypse-1u800-fullu82ejpgu800 450px u8e7bca9 u8e795a5 u8e59bbe u8e5b185 u8e4b8ad u8e4b8a7 u8e5b0b8 u8e69cab u8e697a5 u8e69da5 u8e4b8b4 u8e4b98b u8e697b6 u8efbc8c u8e4b88d u8e4bc9a u8e59ba0 u8e4b8ba u8e4bda0 u8e698af u8e5a5b3 u8e79a84 u8e5b0b1 u8e6af94 u8e8be83 u8e5aeb9 u8e69893 u8e6b4bb u8e591bd u8e59ca8 u8e5be88 u8e5a49a u8e4b8a7 u8e5b0b8 u8e9a298 u8e69d90 u8e79a84 u8e794b5 u8e5bdb1 u8e983bd u8e698af u8e794b7 u8e4baba u8e68bbf u8e79d80 u8e69eaa u8e69e9d u8e68896 u8e698af u8e58880 u8e696a7 u8e79083 u8e6a392 u8e59ca8 u8e4bf9d u8e68aa4 u8e99a8f u8e8a18c u8e79a84 u8e5a5b3 u8e680a7 u8efbc8c u8e4bd86 u8e698af u8e5a682 u8e69e9c u8e4b8a7 u8e5b0b8 u8e69cab u8e697a5 u8e79c9f u8e79a84 u8e69da5 u8e4b8b4 u8e4ba86 u8efbc8c u8e8808c u8e8baab u8e8beb9 u8e58faf u8e4be9d u8e8b596 u8e79a84 u8e794b7 u8e4baba u8e4b88d u8e698af u8e6adbb u8e58589 u8e4ba86 u8e5b0b1 u8e698af u8e4b99f u8e5bc82 u8e58f98 u8e68890 u8e4b8a7 u8e5b0b8 u8e8aea9 u8e4bda0 u8e7bb99 kou800 u8e4ba86 u8efbc8c u8e8bf99 u8e697b6 u8e69cab u8e697a5 u8e79a84 u8e5a5b3 u8e58a9b u8e5b0b1 u8e698af u8e58f91 u8e68ca5 u8e79a84 u8e697b6 u8e588bb u8efbc8c u8e5a682 u8e4bd95 u8e59ca8 u8e8bf99 u8e6b7b7 u8e4b9b1 u8e79a84 u8e5b180 u8e99da2 u8e4b88b u8e7be8e u8e7be8e u8e79a84 u8e4bf9d u8e4bd8f u8e887aa u8e5b7b1 u8e4b880 u8e69da1 u8e5b08f u8e591bd u8efbc9f * u8e59ba0 u8e4b8ba u8e5a5b3 u8e7949f u8e79a84 u8e5a4b4 u8e58f91 u8e995bf u8efbc8c u8e59ca8 u8e5be97 u8e4bf9d u8e68aa4 u8e887aa u8e5b7b1 u8e79a84 u8e697b6 u8e58099 u8efbc8c u8e69c80 u8e5a5bd u8e5b086 u8e5a4b4 u8e58f91 u8e7bb91 u8e68890 u8e8beab u8e5ad90 u8e69c80 u8e4b88d u8e4bc9a u8e695a3 u8e890bd u8e6b2be u8e588b0 u8e6b3a5 u8e59c9f u8e8a180 u8e6b1a1 u8e38082 file dfzz1fauyaeug0lu82ejpgu800 450px u8e7bca9 u8e795a5 u8e59bbe u8e5b185 u8e4b8ad u8e68980 u8e4bba5 u8e7bb91 u8e8beab u8e5ad90 u8e6898d u8e698af u8e78e8b u8e98193 * u8e983bd u8e5b7b2 u8e7bb8f u8e99da2 u8e4b8b4 u8e4b896 u8e7958c u8e69cab u8e697a5 u8e4ba86 u8efbc8c u8e68980 u8e4bba5 u8e4b99f u8e4b88d u8e4bc9a u8e69c89 u8e4bb80 u8e4b988 u8e58c96 u8e5a686 u8e59381 u8e68896 u8e981ae u8e79195 u8e8868f u8e58faf u8e4bba5 u8e981ae u8e4bd8f u8e683b3 u8e981ae u8e79195 u8e79a84 u8e983a8 u8e4bd8d u8efbc8c u8e68980 u8e4bba5 u8e8bf99 u8e697b6 u8e99a8f u8e4bebf u8e68bbf u8e4b8aa u8e6b3a5 u8e5b7b4 u8e68896 u8e698af u8e8a180 u8e6b88d u8e5b0b1 u8e5b086 u8e5b0b1 u8e4ba86 u8efbc8c u8e5bd93 u8e784b6 u8e6b682 u8e5be97 u8e5a4aa u8e5a49a u8e6909e u8e4b88d u8e5a5bd u8e4bc9a u8e8aea9 u8e585b6 u8e5ae83 u8e79a84 u8e7949f u8e8bf98 u8e88085 u8e8afaf u8e8aea4 u8e4b8ba u8e698af u8e4b8a7 u8e5b0b8 u8e38082 file 11af666aa1cu82ejpgu800 450px u8e7bca9 u8e795a5 u8e59bbe u8e5b185 u8e4b8ad u8e4b88d u8e8bf87 u8e8bf99 u8e5bca0 u8e59bbe u8e5a5bd u8e5838f u8e69186 u8e99499 u8e4ba86 u8efbc8c u8e59ba0 u8e4b8ba u8e4b88d u8e7aea1 u8e6808e u8e4b988 u8e79c8b u8e983bd u8e5838f u8e698af u8e4b8a7 u8e5b0b8 * u8e5a682 u8e69e9c u8e880b3 u8e78eaf u8e68e89 u8e4ba86 u8e4b880 u8e8beb9 u8e5b0b1 u8e8aea9 u8e5ae83 u8e68e89 u8e4ba86 u8e590a7 u8efbc8c u8e983bd u8e5b7b2 u8e7bb8f u8e698af u8e4b8a7 u8e5b0b8 u8e69cab u8e697a5 u8e4ba86 u8efbc8c u8e8b081 u8e8bf98 u8e7aea1 u8e4bda0 u8e688b4 u8e4b88d u8e688b4 u8e880b3 u8e78eaf u8e79a84 u8efbc9f u8e68896 u8e8aeb8 u8e58faa u8e688b4 u8e4b880 u8e8beb9 u8e79a84 u8e880b3 u8e78eaf u8e59ca8 u8e69cab u8e697a5 u8e697b6 u8e698af u8e4b880 u8e7a78d u8e697b6 u8e5b09a u8e6b581 u8e8a18c u8e38082 u8e4bd86 u8e698af u8e8bf98 u8e698af u8e5be97 u8e6b3a8 u8e6848f u8e79a84 u8e698af u8e5b0bd u8e9878f u8e588ab u8e688b4 u8e59e82 u8e5908a u8e4b88b u8e69da5 u8e79a84 u8e880b3 u8e78eaf u8efbc8c u8e59ba0 u8e4b8ba u8e5aeb9 u8e69893 u8e59ca8 u8e68898 u8e69697 u8e4b8ad u8e8a2ab u8e58bbe u8e689af u8e588b0 u8e38082 file p6crn6ozkkcbu82ejpgu800 450px u8e7bca9 u8e795a5 u8e59bbe u8e5b185 u8e4b8ad u8e8bf99 u8e7a78d u8e5a4b9 u8e59ca8 u8e880b3 u8e59e82 u8e4b88a u8e79a84 u8e880b3 u8e78eaf u8e4b99f u8e698af u8e4b88d u8e99499 u8e79a84 u8e98089 u8e68ba9 ')
Function: SearchMySQL::update
Error: 1406 Data too long for column 'si_title' at row 1 (xxx)
#0 /srv/mediawiki/w/includes/libs/rdbms/database/Database.php(1556): Wikimedia\Rdbms\Database->getQueryExceptionAndLog(string, integer, string, string)
#1 /srv/mediawiki/w/includes/libs/rdbms/database/Database.php(1274): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
#2 /srv/mediawiki/w/includes/libs/rdbms/database/Database.php(2927): Wikimedia\Rdbms\Database->query(string, string)
#3 /srv/mediawiki/w/includes/libs/rdbms/database/DatabaseMysqlBase.php(528): Wikimedia\Rdbms\Database->nativeReplace(string, array, string)
#4 /srv/mediawiki/w/includes/search/SearchMySQL.php(349): Wikimedia\Rdbms\DatabaseMysqlBase->replace(string, array, array, string)
#5 /srv/mediawiki/w/includes/deferred/SearchUpdate.php(108): SearchMySQL->update(integer, string, string)
#6 /srv/mediawiki/w/includes/deferred/DeferredUpdates.php(274): SearchUpdate->doUpdate()
#7 /srv/mediawiki/w/includes/deferred/DeferredUpdates.php(219): DeferredUpdates::runUpdate(SearchUpdate, Wikimedia\Rdbms\LBFactoryMulti, string, integer)
#8 /srv/mediawiki/w/includes/deferred/DeferredUpdates.php(143): DeferredUpdates::execute(array, string, integer)
#9 /srv/mediawiki/w/includes/MediaWiki.php(907): DeferredUpdates::doUpdates(string)
#10 /srv/mediawiki/w/includes/MediaWiki.php(731): MediaWiki->restInPeace(string, boolean)
#11 /srv/mediawiki/w/includes/MediaWiki.php(754): MediaWiki->{closure}()
#12 /srv/mediawiki/w/includes/MediaWiki.php(548): MediaWiki->doPostOutputShutdown(string)
#13 /srv/mediawiki/w/index.php(42): MediaWiki->run()
#14 {main}
```
In the logs.
We also run php 7.2.
Steps to reproduce:
Go to https://www.mediawiki.org/wiki/Special:PrefixIndex?prefix=Project%3ACurrent+issues%2F&namespace=90&hideredirects=1&stripprefix=1
Select the one link, to https://www.mediawiki.org/wiki/Thread:Project:Current_issues/User:MZMcBride_and_sysopping_of_User:Fram/reply_(61)
Expected result:
https://www.mediawiki.org/wiki/Thread:Project:Current_issues/User:MZMcBride_and_sysopping_of_User:Fram/reply_(61) displays something
Actual result:
```
No such thread
The thread you specified does not exist.
```
The search results display the date & time of the last edit in green under each search result (in green). With advanced search or the URL-parameters it's possible to change the order of the search results to be sorted by the date of article creation.
Users now might expect the date to show the date of article creation – since they asked for it to be the sorting criterion – but it's still the date of the last edit. This confuses users. ([[ https://www.mediawiki.org/wiki/Topic:V3o1yqxx101kpf2q | Report of a user ]])
{F29966023}
We should show the creation date in those cases or make it more visible that the date is the timestamp of the last edit.
**Setup**
- MediaWiki 1.31+
**References**
- [[ https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4115 | Semantic MediaWiki issue 4115 ]].
**Feature request**
This is a feature request for MediaWiki core though this will also help extensions. Earlier versions as indicated above do not have this feature either however I am just mentioning supported versions of MediaWiki here.
While it is possible to set namespace to be searched by default with `$wgNamespacesToBeSearchedDefault` it is not possible to set a default for the search tabs/sections to be shown by default. Thus having some method (e.g. hook) in [0] to set a default profile would made things easier for users and administrators and moreover also allow extension defined tabs to be set by default - not just MediaWiki core.
[0] https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialSearch.php#L206-L257
==Steps to reproduce
* Load https://www.mediawiki.org/wiki/Special:Search with a slow internet connection.
* Start typing a few characters into the big search field as soon as the search field is visible.
* Wait until the JavaScript is loaded and initialized.
* Current behavior: You have to enter a further character. Then the search suggestions gets loaded and the search suggestions box are shown.
* Expected behavior: The search suggestion engine loads the search suggestions of the already typed characters on initializing the JavaScript. The search suggestion box gets shown automatically as soon as the JavaScript and the search suggestions are loaded.
For module `jquery.suggestions` for the small search field this was implemented in T223422.
MediaWiki 1.32.0
PHP 7.2.15-0ubuntu0.18.04.2 (apache2handler)
MariaDB 10.1.34-MariaDB
```
A database query error has occurred. This may indicate a bug in the software.
[42cc5c670a243b95937180db] /w/index.php?title=Special%3ASearch&search=Binding+Coil+of+Bahamut+-+Turn+2&go=Go Wikimedia\Rdbms\DBQueryError from line 1496 of /var/www/<domain>/htdocs/w/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading?
Query: SELECT page_id,page_namespace,page_title FROM `ffxiv_mw_page`,`ffxiv_mw_searchindex` WHERE (page_id=si_page) AND ( MATCH(si_title) AGAINST('+binding +coil +ofu800 +bahamut +- +turn +2u800 ' IN BOOLEAN MODE) ) AND page_namespace IN ('0','200','800') ORDER BY MATCH(si_title) AGAINST('+binding +coil +ofu800 +bahamut +- +turn +2u800 ' IN NATURAL LANGUAGE MODE) DESC LIMIT 21
Function: SearchMySQL::searchInternal
Error: 1064 syntax error, unexpected '-' (<endpoint>.rds.amazonaws.com)
Backtrace:
#0 /var/www/<domain>/htdocs/w/includes/libs/rdbms/database/Database.php(1466): Wikimedia\Rdbms\Database->makeQueryException(string, integer, string, string)
#1 /var/www/<domain>/htdocs/w/includes/libs/rdbms/database/Database.php(1226): Wikimedia\Rdbms\Database->reportQueryError(string, integer, string, string, boolean)
#2 /var/www/<domain>/htdocs/w/includes/libs/rdbms/database/Database.php(1693): Wikimedia\Rdbms\Database->query(string, string)
#3 /var/www/<domain>/htdocs/w/includes/search/SearchMySQL.php(191): Wikimedia\Rdbms\Database->select(array, array, array, string, array, array)
#4 /var/www/<domain>/htdocs/w/includes/search/SearchMySQL.php(178): SearchMySQL->searchInternal(string, boolean)
#5 /var/www/<domain>/htdocs/w/includes/search/SearchDatabase.php(69): SearchMySQL->doSearchTitleInDB(string)
#6 /var/www/<domain>/htdocs/w/includes/search/SearchEngine.php(140): SearchDatabase->doSearchTitle(string)
#7 /var/www/<domain>/htdocs/w/includes/search/SearchEngine.php(169): SearchEngine->{closure}()
#8 /var/www/<domain>/htdocs/w/includes/search/SearchEngine.php(141): SearchEngine->maybePaginate(Closure)
#9 /var/www/<domain>/htdocs/w/includes/specials/SpecialSearch.php(341): SearchEngine->searchTitle(string)
#10 /var/www/<domain>/htdocs/w/includes/specials/SpecialSearch.php(190): SpecialSearch->showResults(string)
#11 /var/www/<domain>/htdocs/w/includes/specialpage/SpecialPage.php(569): SpecialSearch->execute(NULL)
#12 /var/www/<domain>/htdocs/w/includes/specialpage/SpecialPageFactory.php(568): SpecialPage->run(NULL)
#13 /var/www/<domain>/htdocs/w/includes/MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#14 /var/www/<domain>/htdocs/w/includes/MediaWiki.php(860): MediaWiki->performRequest()
#15 /var/www/<domain>/htdocs/w/includes/MediaWiki.php(517): MediaWiki->main()
#16 /var/www/<domain>/htdocs/w/index.php(42): MediaWiki->run()
#17 {main}
```
Postgres currently uses columns in specific tables (pagecontent.textvector and page.titlevector, both of type tsvector) to store search index information. Postgres also currently uses triggers/procedures to maintain these tables. It needs to be converted to use a searchindex table like MySQL.
This relates to MCR Schema Migration, because it prepares for when we want SearchMySQL and so on to handle more than just the main slot. By using a searchindex table, the changes to SearchPostgres will be similar rather than entirely different.
Details:
- add a searchindex table, similar to the MySQL one, but adapted to Postgres data types. Basically page.titlevector becomes searchindex.si_title and pagecontent.textvector becomes searchindex.si_text. searchindex.si_page works exactly like it does in MySQL.
- add related code to maintain this table. Per T164898, we don't want to keep using triggers for this. SearchPostgres::update() should do it, similar to what SearchMySQL::update() does. Same for ::updateTitle().
- add necessary documentation and install/update support for these db changes
- modify searchPostgres.php to use the new db changes
See T198341 for the discussion that led to this task.
Currently, there’s a difference in clicking on suggestions on Special:Search and in default search bar.
- Special:Search ones redirect you to another Special:Search page before you can go to the article,
- and the search bar redirects you to the article itself.
I have no doubt that this difference in UX is confusing for the most people who try to use autocomplete, so I suggest to bring it to one default behaviour (redirecting to articles, since there’s no way that autocomplete can contain non-existing articles). I’d think that this non-standard behaviour was brought somewhere from OOUI, but you never know.
This extension is barely 25 lines of PHP code. Wikimedia only uses it on Commons, where it has the configuration of `$wgSearchExtraNamespaces = [ NS_CATEGORY ];`. It's functionality should be available in MediaWiki core.
https://www.mediawiki.org/w/api.php?action=help&modules=query%2Bsearch
There's are example in the bottom of the page: api.php?action=query&list=search&srwhat=text&srsearch=meaning -- It lists "totalhits" for all entries and and "wordcount" for each entry.
Is there a URI to list the hits for "meaning" for each entry like "wordcount"?
Putting an interwiki title in Special:Search, like `:pl:Jakub Ćwiek`, will show `The page "pl:Jakub Cwiek Wikipedia" does not exist.` aka `(searchmenu-new-nocreate: pl:Jakub Ćwiek, 0)` message.
But the blue link in the message points to https://pl.wikipedia.org/wiki/Jakub_%C4%86wiek, an existing article on plwiki.
So in this case another message should be shown.
Direct link: https://en.wikipedia.org/w/index.php?search=%3Apl%3AJakub+%C4%86wiek&title=Special:Search&profile=default&fulltext=1
On Special:PrefixIndex, when the main namespace is selected (the default) and one types in a prefix that begins with a namespace prefix followed by a colon, the namespace box is no longer automatically changed to the actual namespace. For example, https://en.wikipedia.org/wiki/Special:PrefixIndex?prefix=User%3AA&namespace=0 shows "User:A" as the prefix and the main namespace as the namespace. The expected result is to show just "A" as the prefix and "User" as the namespace.
When typing in the search-field on Special:Search recommendations are shown matching the text that was entered. This by default searches in Main (article) namespace any only after entering a namespace with colon at the end (for example `wikipedia:` it searches in an other namespace.
When having selected other namespaces than the default one this is rather contra intuitive.
{F18489576}
[This was reported [[https://www.mediawiki.org/wiki/Topic:Ud6j4k0g3r9rnd85|here]] by user Nickps.]
@HappyDog (since you originally wrote the documentation I think) and others who may be knowledgeable about this.
Originally posted at https://www.mediawiki.org/w/index.php?title=Topic:Ucvujwwl2m3509du&topic_showPostId=ucvujwwmmshtgi2q#flow-post-ucvujwwmmshtgi2q
> For website visitors I'd like to forward searches to a different URL using Manual:$wgSearchForwardUrl but need to keep the standard MW search page for internal use. Unfortunately, setting $wgSearchForwardUrl to a different URL (which requires that $wgDisableTextSearch is set to true) also adds a redirect from Special:Search to the alternative URL. Is there any way the two approaches can live together?
Clarification: one could, for instance, use $wgSearchForwardUrl to send visitors straight to a search engine like Google or DuckDuckGo (pick your favourite here), or even a wiki page that embeds a search engine.
For internal use, however, in order that editors can find the right template or anything purposely hidden from web crawlers, you'd still need something like "the standard MW search page". That functionality seems gone once $wgSearchForwardUrl points to an alternative URL. Its impact is total: the "Search" option of the searchbox (as opposed to "Go" to send you straight to the wiki page), the Special:Search page and everything with ?search= appended share the same new target.
My best chance is probably to create a new extension, but I'm hoping there's an easier route. One possible avenue I have in mind is to forget about $wgSearchForwardUrl and to rebuild the searchbox so that the full-text search option ("Search" not "Go") takes you to a different URL. In other words, limit URL forwarding to a specific option in the searchbox, but I don't know if that's possible.
**MW Version: **1.30
**Scenario: **I need to search pages for a string which contains an embedded pipe.
**Request:** Treat embedded pipes in searches as string characters.
**Current: **In MediaWiki search, embedded pipes behave as boolean AND.
**Note: **This issue was discovered and validated through the MW API, not through MW search interface.
**Details:**
As implied in **[[ https://gunretort.xyz/api.php?action=help&modules=query%2Bsearch | this helpfile ]]**, srsearch param does not accept multiple values. Therefor, i assume an embedded pipe will be treated as part of the search string.
However, this call:
```
https://gunretort.xyz/api.php?action=query&list=search&**srsearch=NewTag|Anteater**&srwhat=text&srnamespace=0|3000
```
returns pages which contain:
no pipe, unrelated word in-between:
> NewTag
> x
> Anteater
no pipe, order is reversed, with an unrelated word in-between:
> Anteater banana
> NewTag
and (the desired):
> {{NewTag|Anteater}}
The apparent logic is "contains both words anyplace on the page." In other words, the pipe in srsearch is being interpreted as an AND.
Ie, multivalue entries ARE supported in srsearch (although helpfile suggests not), except they are interpreted as AND instead of the usual OR.
Is there any workaround, to treat embedded pipe as string?
We have [[ https://www.mediawiki.org/wiki/Manual:$wgNamespacesWithSubpages | namespaces with subpages ]], it should be pretty natural to add a simple way to look for subpages of pages in those namespaces from the toolbox.
There have been [[ https://stackoverflow.com/questions/28677871/how-do-i-add-specialprefixindex-fullpagename-to-the-toolbox-in-my-local-mediawi | questions about this ]] on Stackoverflow before, people [[ https://en.wikipedia.org/wiki/User:Ilmari_Karonen/prefixindex.js | have made scripts for this from 2007 ]]. I suggest that this would be more useful than stuff like Special:RelatedChangesLinked for people who edit templates and modules, for example, and there is little to none bloating in having this on MediaWiki level (since this would concern pages outside of main space in most projects).
This should act like `Special:PrefixIndex/{{FULLPAGENAME}}` and be called `View subpages`. There needs to be a discussion whether to have this link displayed on subpages themselves, but even without going into that I would guess that it would be an improvement.
[[https://www.mediawiki.org/wiki/Category:Search_extensions|Category:Search extensions]] says
> The Search extensions category contains articles on extensions that extend or modify the search behavior of MediaWiki. For guidance in writing and selecting search extensions, please see Manual:Search.
but then the page doesn't actually exist. It would be nice to have high-level documentation on this. Looking at CirrusSearch it seems like such extensions are supposed to a mix of hooks and subclassing, neither of which is easy to find or documented much even inline. Just having a list of the right hooks and classes with one-liner explanations of what they do would be a great improvement; having some examples would be even better.
It would be extra nice if the page also explained all the ways other extensions can interact with search (metadata in media handlers, content handlers etc).
When using a short URL setup (see https://www.mediawiki.org/wiki/Manual:Short_URL/Apache) a search for "abc" redirects to www.example.com/Main_page?search=abc and the searchmenu-new entry says: Create the page "abc" on this wiki! See also the search results found.
However "abc" links to www.example.com/Main_page?title=Abc&action=edit&redlink=1 which itself redirects to "Main_page" instead of calling the editor. The correct URL would be www.example.com/Abc?title=Abc&action=edit&redlink=1
Workaround is to use the edit-action as path-segment and not within the query-string: $wgActionPaths['edit'] = "$wgScriptPath/edit/$1";
When editing wikitext, I can copy any wikilink--the text in square brackets, without pipe text--into the searchbox to go to that article. It even works if the link has namespace or sisterproject components. However, template-transclusion has an implicit Template: namespace. If I copy the text from the curly-braces (without parameters) into the searchbox, I have to manually insert the "Template:" prefix, and do so if and only if there isn't some other namespace already given.
As a feature request, I would like the searchbox to treat "{{Foo" as "Template:Foo". That is, if the search-string begins with "{{", convert it to "Template:" if there is no namespace and then remove it regardless. For symmetry, a trailing "}}" should be ignored. For consistency of "copy-base of wikitext", leading "[[" and trailing "]]" should also be ignored.
APP versions:
Mediawiki 1.30.0 ( using sqlite database )
PHP Version 7.0.25
SQLite Library 3.14.2
Issues:
Search using profile=images, will get fatal error:
>
> Fatal error: Maximum execution time of 60 seconds exceeded in /home1/ed29/public_html/includes/libs/rdbms/database/DatabaseSqlite.php on line 312
But search with profile=default, all, advanced is ok, so, i think maybe it's a bug.
Here is a video log:
[[ http://ed29.com/bugReport-tmp-_2018_01_08_10_46_28_685.mp4 | video log ]]
Deselected article namespace does not result in the vanishing of the "no article exists" hint
{F11069072}
Currently Special:AllPages lists all pages on a wiki including translated pages.
There is a "Hide redirect" option. It would be good if there could also be a "Hide translations" option, since sometimes users don't want to see translations as well, just all pages.
It would improve the user experience to have a searchbox in the category pages of wiktionary, especially in those with several pages; therefore, you could quickly find the word 燦燦 in the following category page https://en.wiktionary.org/wiki/Category:Chinese_reduplications
On MediaWiki.org a drop down box appears below the search field when starting to type.
However, on my wiki's [[ https://evermeet.cx/wiki/Special:RandomInCategory | Special:RandomInCategory ]] page, no such box appears. I checked the response of the ajax call and it seems to be valid:
```
{"batchcomplete":"","query":{"pages":{"-1":{"ns":0,"title":"Category:Apache","missing":"","index":1,"contentmodel":"wikitext","pagelanguage":"en","pagelanguagehtmlcode":"en","pagelanguagedir":"ltr"},"-2":{"ns":0,"title":"Category:Article","missing":"","index":2,"contentmodel":"wikitext","pagelanguage":"en","pagelanguagehtmlcode":"en","pagelanguagedir":"ltr"}}}}
```
Above was the response after I typed the letter `a` in the search field. So I don't understand why there's no dropdown box below the search field.
I tried IRC, but maybe there were no devs on the channel today. I don't know what else to do. But I reckon that for someone with knowledge of the internals this should be easy to figure out.
{F10420647}
**Summary:** Autocomplete in the search box does nothing if you type a character that uses a [[ https://en.wikipedia.org/wiki/Dead_key | dead key ]] (a key that put an accent or other diacritic on the next letter you type), the Javascript "keypress" event listener doesn't get the message that anything has happened. This is true for Latin and Greek characters with dead keys. Using "onkeyup" may solve the problem.
It isn't clear what other UI elements are affected beside the search box, if any.
I'm not sure what projects this applies to, since it is a UI problem on an element used for search.
Earlier discussion from T75605:
@Xoristzatziki in T75605#3417714:
> A bug, which may be related, still exists for Greek terms (in ALL projects, even in en.wiktionary) . Typing in the search box anything that ends in accented letter does not provide any suggestions that include the last letter (even if they exist ex. καλά). Copying and pasting works. Also typing anything after (ex. a space) works. It seems (to user) like the search is not done by the really typed letters, and the code is "waiting" for something.
@TJones in T75605#3421129:
> ... the scope is much bigger than accented Greek characters. ... I'm pretty sure this is a Javascript issue.
>
> For my quick test, I'm on a Mac, using the American, French, and Greek keyboards, and I tested in Chrome, Safari, and Firefox. To my surprise, they all behave the same.
>
> If you use [[ https://en.wikipedia.org/wiki/Dead_key | dead keys ]] (keys that put an accent or other diacritic on the next letter you type), the Javascript "keypress" event listener doesn't get the message that anything has happened. I tested this with both Latin and Greek letters on the Mac keyboards.
>
> As I understand it, the Greek keyboard uses a dead key to add ´ and ¨ to vowels. Similarly in the Mac American keyboard has dead keys for several diacritics (I use ´ ¨ ˆ ` ˜ regularly). If I type //resumé// to search on English Wiktionary, I also don't get any more suggestions for the final é. (BTW, it happens for non-final letters, too, if you pause, but it's easy to miss if you keep typing).
>
> On the French keyboard, é has its own key, and when I type //resumé// using that keyboard, it behaves as expected.
>
> On the //Mac// Greek keyboard (so this probably does not apply to Windows or Linux), I can type ά by typing option+shift+α. If I type //καλά// this way it gets suggestions as expected. Similarly, you can use option+shift+<x> to type other accented vowels: 1/έ 2/ί 3/ή 4/ό 0/ύ ./ώ —I didn't see any precomposed versions with diaeresis (i.e, ϊ or ϋ ). These non-dead-key versions generate new suggestions.
>
> So, the problem isn't accented characters per se, but rather characters that have to be typed with dead keys, at least on a Mac keyboard. I'm not familiar with the UI code that's handling all this, so I have no idea how easy it would be to fix, but searching online shows a lot of people complaining about this, but no obvious solutions.
@Xoristzatziki in T75605#3651879:
> The problem is in the code for sure. The accent in dead keys in Greek keyboard are typed first so the last key pressed is a non dead key. onkeyup works in my tests.
(See link for attachments.)
It has become a sort of standard that the first tab links to the current subject, and for special pages this should be the page with options as currently set. Some special pages don't follow this pattern, and especially Special:Prefixindex is weird. In this case the tab links to the current page being investigated. For example, go to [[ https://no.wikipedia.org/wiki/Spesial:Lenker_hit/Mal:S%C3%B8ster | w:no:Spesial:Lenker_hit/Mal:Søster ]] (its the same as Special:Prefixindex/Template:Søster) and the first tab goes to the template itself. This breaks the user expectation and makes navigation harder than necessary.
I have not investigated the reason for this behavior, it could be that the reason is some underlaying default behavior that is counterintuitive.
In the sister project search results (at least on enwiki), hatnotes and various unnecessary text often displays instead of the actual content. For example, in a search for [[ https://en.wikipedia.org/w/index.php?search=Hong+Kong&title=Special:Search&profile=default&fulltext=1 | Hong Kong ]], the Wiktionary hatnote text appears instead of the content (and for some reason, the page "Hong-Kong" is displayed instead of the page "Hong Kong"). A search for [[ https://en.wikipedia.org/w/index.php?search=Singapore&title=Special:Search&profile=default&fulltext=1 | Singapore ]] returns text from Wiktionary including the sidebar containing Wikipedia links.
A fix would be to exclude hatnotes; sidebar text such as Wiktionary's {{[[ https://en.wiktionary.org/wiki/Template:wikipedia | wikipedia ]]}}; and header templates like Wikisource's {{[[ https://en.wikisource.org/wiki/Template:Disambiguation | disambiguation ]]}} from search results, like how enwiki excludes hatnotes.
In Special:PrefixIndex results, if we go to the "Next page (...)", there is no link to the "Previous page (...)" at the top.
This causes these problems:
* harder to navigate
* inconsistent with Special:AllPages
* sharing a link to results beyond the first page will be less useful
Example:
* At https://en.wikipedia.org/w/index.php?title=Special%3APrefixIndex&prefix=foo&namespace=0
* Click `Next page (....)` at the top
* There is no `Previous page (...)` link.
In contrast, Special:AllPages does have this useful function:
* At https://en.wikipedia.org/wiki/Special:AllPages?from=Foo&to=&namespace=0
* Click `Next page (....)`
* The expected link is there.
Obviously, we cannot have a `Previous page (...)` link on the //first// page of PrefixIndex results, because it is a limited listing. But we should have it on subsequent pages.
When reading through User Research by @dchen on gathering user feedback and insights if open (uncollapsed) or closed (collapsed) sections are preferred, there were comments like “I don’t want to see everything, i want to see what i’m looking for”.
That made me think if it is possible to show users who are coming with a referrer the related section initially opened. It's seems probable that a majority of search results are not 1:1 translatable to sections. Still, for the clear cases that options seems experience-wise useful to consider.
There are –without question– several technical hurdles, still I'd like to see if there has been evaluations of technical hurdles connected with the issue.
the following fields are added by CirrusSearch, for all content models:
* namespace
* namespace_text
* redirect
* source_text
* suggest
* timestamp
* title
* text
* text_bytes
handling for some of these in CirrusSearch is quite complex, but still think these should be exposed in some (simple) way in core.
Hi,
We discussed with one user on this topic : https://www.mediawiki.org/wiki/Topic:T309ediwdcwhm1nn, and we couldn't find how to do this :
When using Translate extension, we have the possibility to translate page title. But when you try to search for this title, you only have "Nom page/en" for instance for a page translated in English, instead of the page name.
Is it possible to have an option to display translated title in the search results ?
The ContentHandler base class extracts data for certain fields (text, source_text, text_bytes) but I don't see field definitions for these in getFieldsForSearchIndex.
`{{Special:PrefixIndex}}` and `{{Special:AllPages}}` transclusions currently set a hard maximum number of results: 345, usually presented as three columns of 115 results.
Currently, we silently truncate the results at a seemingly arbitrary number, as far as I can tell.
Some options:
* Add pagination links that can fetch more data with AJAX and load it in the same browser window
* Provide a link to the next set of results that would take the user to Special:PrefixIndex?offset= or similar
* Provide an error message of some kind or tracking category
Visit http://en.m.wikipedia.beta.wmflabs.org/wiki/Special:Search with JavaScript disabled, Opera mini browser and screen resolution of 240px {F3434145}
Seems to be an issue in the stylesheet for Special:Search - not MobileFrontend specific.
-----
**See Also:** {T109944}
Just upgrade to 1.26.0.
When the search returns page with results from title and text content, the columns are not correctly aligned.
(May be something wrong in my CSS alors ?)
As shown in the following screen capture
{F3029705}
More over, there si a \n display at the end of page.
{F3029737}
Correct link to see the result and may be say that the error comes from my CSS :
http://www.jouvinio.net/wiki/index.php?title=Sp%C3%A9cial:Recherche&limit=20&offset=40&profile=default&search=jenkins
Regards.
Etienne Jouvin
**Scenario:** You are searching for something. You type "Foo Bar Baz" into the search box at the top of the page. The reults returned aren't what you want. You wonder whether a different language might have the results you want. The typical process from there is:
# Guess which wiki you want
# Go to that wiki
# Re-type the search into the search box
# Re-do any adjustments you made to the search (number of results per page? namespace?)
(Alternate approach, for advanced users: Hand-edit the URL to switch the language. But if you're not coming from an English project, then even the name of the search page has to be hand-edited.)
**Suggestion:** Why not provide 'interlanguage links'? They could be in the sidebar, just like interlanguage links. When you click them, they would run exactly the same search that you have on screen.
Expected behaviour:
* https://commons.wikimedia.org/wiki/Special:Search/MediaWiki:Foo-bar-baz redirects to https://commons.wikimedia.org/wiki/MediaWiki:Foo-bar-baz only if MediaWiki:Foo-bar-baz exists as a page, or is a valid i18n message. (e.g. It should be the same check as the one that determines if [[MediaWiki:Foo-bar-baz]] shows up as a blue link or a red link)
Actual behaviour:
https://commons.wikimedia.org/wiki/Special:Search/MediaWiki:Foo-bar-baz always redirects
Dear Ladies and Gentlemen,
i found a bug in the search in mediawiki for postgresql.
When using a wilcard in the search like "example*" the generated SQL statment is wrong. The genereated SQL statement is:
```
SELECT page_id, page_namespace, page_title, ts_rank('textvector', to_tsquery('example*'), 2) AS score FROM page p, revision r, pagecontent c WHERE p.page_latest = r.rev_id AND r.rev_text_id = c.old_id AND textvector @@ to_tsquery('example*');
```
But the part "to_tsquery('example*')" should be "to_tsquery('example:*')".
It think the best solution is to change the behavior of the function "parseQuery" in the file searchPostgres.php. There should be added that a trailing "*" become ":*".
If you need any other information let me know.
Yours,
Erich Lerch
In {E50}, @ricordisamoa commented
> we need an API bucket at https://www.mediawiki.org/wiki/Special:Search
> so if someone searches for "recent changes" and selects API they find API:Recentchanges and RCStream
This seems a reasonable request. I think the only way to add a new search profile tab to Special:Search is by hooking the `SpecialSearchProfiles` event in PHP, e.g. in extensions/WikimediaMessages/WikimediaMessages.hooks.php, similar to its `onSkinCopyrightFooter()` hook.
The workaround is to click Advanced and uncheck the Main, Help, and possibly Manual namespaces
https://pt.wikipedia.org/wiki/Special:Search/Wikip%C3%A9dia:Revers%C3%A3o_e_Avisos
goes to the inexistent page
https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Revers%C3%A3o_e_Avisos
instead of the search results. If the same text is typed in the search field on top of the page, the inexistent page is also suggested as an existent page (in bold).
If I go to a random wiki and type a username in the search field, and that user migrated his user page to a global user page on Meta-wiki, I'll not be able to go directly to this page on the local wiki, because there will be no suggestion in the list.
As an example, I tried this on https://es.wikipedia.org, where my global user page is loaded (so, links to it appears in blue color, including the one in the personal portlet). The only item which appeared was "containing... user:he7d3r", but there should be a bold entry linking directly to it.
Newer versions of Mysql (5.6+) support full-text indexes on innodb tables. We should move the searchindex table that is used for core search support to innodb because innodb sucks less and to be more consistent to user's wishes.
The largest issue here, is doing it in a way that makes tables.sql backaward compat with old mysql.
Current:
{F193385}
Issues we're trying to solve:
- [ ] Redesign to OOUI
- [ ] Confusing buttons - Select all/none buttons are rendered as buttons, while the Search is custom styled. This leads to users hit one of those real buttons instead of the intended Search due to expectation blindness.
- [ ] The predefined sets do not let user know which namespaces are actually being searched -> the namespace selection is going to be always visible and checkboxes will change according to the selected predefined set
- [ ] Advanced search will be always present, collapsible, expanded by default. The entire section will contain presets as well as manual ns search by checkboxes
- [ ] Clicking on predefined set currently triggers the search -> will not, will just change the state of checkboxes to the relevant set
- [ ] Clicking on predefined set currently unexpectedly triggers the search with original search phrase, not with the changed one
- [ ] Confusing "Content namespaces" which is not always truth (there are two separate variables - wgContentNamespaces & wgNamespacesToBeSearchedDefault), because it is default search -> will be split to two presets
- [ ] Missing Subject namespaces / Talk namespaces selection
- [ ] Missing Invert the selection button
- [ ] Better column handling
- [x] The main (right top) search form input won't be prefilled as it is confusing - users check namespaces and then hit the search button there which submits different form
- [ ] ...?
I think we should consider auto-completing "insource:" and other magic prefixes when using search inputs. This might be similar to Gerrit's search behavior.
Apparently WIkimedia wikis' search does not ignore soft hyphens (U+00AD, ­ ), making it impossible to find occurences of words if they were written with the hyphen in them. I've been told this is a problem for Wikisources, as OCR applications often generate these hyphens.
Since MediaWiki version 1.24 when a search is performed for a quoted-phrase such as "more information" (using quotes to ensure only the entire phrase is matched rather than the separate words), the correct results are returned but no text snippets from the articles are rendered. The terms array in SearchMySQL::searchTerms that is passed to the SqlSearchResultSet object returned from SearchMySQL::searchInternal has split the quoted phrase at the spaces with the first and last item having a leading and trailing quote respectively, so the highlighter fails to find any matches and disregards the snippet.
Search settings were apparently moved out of the preferences and into the 'advanced' options of the search itself. Given that the average user will never actually go to the 'advanced' options and instead just click on the button for whatever they're actually searching for (content, multimedia, or just anything), this does not make the settings discoverable and leads the user to assume that there are no settings, and that, even if all they ever search for is under 'everything', they will simply need to click on 'everything' after an initial wrong-namespace search every single time they search, when this is simply not the case.
The search settings save option needs to be made more discoverable, perhaps by adding some access to or other indication of its existence from the other searches.
There's an article in the Hebrew Wikipedia called [[ https://he.wikipedia.org/wiki/%D7%A1%D7%A0%D7%93%D7%95%D7%9E%D7%99%D7%99%D7%96%27 | סנדומייז' ]] (it's about the Polish city of [[ https://en.wikipedia.org/wiki/Sandomierz | Sandomierz ]]).
If you search for it in the search box without the apostrophe, then the article doesn't come up as a result. In casual typing people quite often omit the apostrophe, so this is a practical problem. Sandomierz is just an example - there are many more article titles with an apostrophe in Hebrew and in some other languages.
It's just a simple and common punctuation mark, so the search engine should be smart enough to find the article.
This is comparable to T75862, but it should be much simpler, because this is just about punctuation and not morphology.
https://www.mediawiki.org/wiki/Thread:Help_talk:CirrusSearch/Incomplete_search_results_%282%29
When searching for insource:/\{\{Information.*\{\{Information/i we don't get a page with the information template twice, https://commons.wikimedia.org/wiki/File:YAMAHA_%28headquarters_1%29.jpg