Page MenuHomePhabricator
Search Advanced Search
    • Task
    Showing an image preview to the left of a Wikipedia article in the search results of Special:Search would enhance the user experience.
    • Task
    **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.
    • Task
    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}
    • Task
    **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}
    • Task
    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}
    • Task
    **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; ```
    • Task
    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
    • Task
    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. * …?
    • Task
    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).
    • Task
    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
    • Task
    **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.
    • Task
    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).
    • Task
    **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.
    • Task
    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.
    • Task
    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)
    • Task
    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}
    • Task
    When logged into fawiki and looking at Special:Search I see this warning in the browser console: ``` This page is using the deprecated ResourceLoader module "mediawiki.ui". Please use OOUI instead. ``` Unfortunately, clicking on the line number next to it does not take me to where this module is used, but to where the warning above is generated. This doesn't happen on article pages. I made sure this account does not have any Gadgets or user scripts enabled. It is a brand new account. Searching for `mediawiki.ui` in the MediaWiki namespace on fawiki [[ https://fa.wikipedia.org/w/index.php?sort=relevance&search=insource%3A%2Fmediawiki.ui%2F&title=%D9%88%DB%8C%DA%98%D9%87:%D8%AC%D8%B3%D8%AA%D8%AC%D9%88&profile=advanced&fulltext=1&advancedSearch-current=%7B%7D&ns8=1 | returns no results ]]. I am unable to find the root cause of the problem.
    • Task
    {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?)
    • Task
    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> ```
    • Task
    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
    • Task
    **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.
    • Task
    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?
    • Task
    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}
    • Task
    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.
    • Task
    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.
    • Task
    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. ```
    • Task
    **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
    • Task
    ==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.
    • Task
    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} ```
    • Task
    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.
    • Task
    Currently there is no way to change the default number of hits appearing in search results (i.e. 20). It would be a good idea if this was configurable on admin and/or user level.
    • Task
    On [[Special:Search]] focus is always set on the search input field. This is useful when making a new search. But when showing results from a previous search you want to be able to scroll down without having to unfocus first. Exepcted behaviour: * visiting [[Special:Search]] without search results: *# focus is on search input *# you can start typing your search * visiting [[Special:Search/Some search]] displaying search results: *# focus it is not on input *# (not having to unfocus) start scrolling using PageDown/PageUp or arrow keys This was fixed for earlier versions of search (then used by Wikipedia) in T11939 and T78637, but is now broken again (#regression).
    • 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.
    • Task
    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.
    • Task
    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"?
    • Task
    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
    • Task
    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.
    • Task
    @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.
    • Task
    **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?
    • Task
    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.
    • Task
    [[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).
    • Task
    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";
    • Task
    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.
    • Task
    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 ]]
    • Task
    Deselected article namespace does not result in the vanishing of the "no article exists" hint {F11069072}
    • Task
    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.
    • Task
    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
    • Task
    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}
    • Task
    **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.)
    • Task
    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.
    • Task
    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.
    • Task
    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.
    • Task
    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.
    • Task
    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.
    • Task
    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 ?
    • Task
    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.
    • Task
    `{{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
    • Task
    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}
    • Task
    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
    • Task
    **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.
    • Task
    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
    • Task
    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
    • Task
    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
    • Task
    I have done some edits on dewiki and than search for a word of the edit summary and found a user page with contains: > {{Special:Recentchanges/100}} The snippet was the expanded special page: > (-32)‎ . . ‎Umherirrender (Diskussion | Beiträge)‎ (Standard-ID nutzen - editnotice-ns-3 -> mw-editnotice-3) It seems useless to add transcluded special pages to the search index, because such pages will expiry very fast.
    • Task
    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).
    • Task
    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.
    • Task
    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.
    • Task
    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 - [ ] ...?
    • Task
    On Wikidata, **whenever** I type "something" in the search box and then hit ENTER I get this error: ```lang=json { "errorMessage": "TypeError: context is undefined", "url": "https://www.wikidata.org/static/1.26wmf13/resources/src/mediawiki/mediawiki.searchSuggest.js", "lineNumber": 255, "columnNumber": 5, "errorObject": {} } ``` https://github.com/wikimedia/mediawiki/blob/16ff17c7e9f39b53b9177fb0fec83b76cddd500c/resources/src/mediawiki/mediawiki.searchSuggest.js#L84 Originally seen using Firefox 39.0 on Linux, and still reproducible on MediaWiki 1.28.0-wmf.17 using Firefox 48.
    • Task
    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.
    • Task
    Apparently WIkimedia wikis' search does not ignore soft hyphens (U+00AD, &shy; ), 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.
    • Task
    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.
    • Task
    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.
    • Task
    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.
    • Task
    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
    • Task
    For example https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=insource%3A%2F\\reals%2F&fulltext=Search should render the math tags in the result list.
    • Task
    We installed the opensearchxml extension onto our mediawiki version 1.19.2 hoping we could return search query results in rss/atom format to be used by other organisations who need them in thins format. This appears to be a fundamental aspect of Open Search that is missing from the extension. Is there any way around this?
    • Task
    The English Wikipedia doesn't have the article "Arun Ganesh". When I search for it, I get the following message on top of the results: You may create the page "Arun Ganesh", but consider checking the search results below to see whether the topic is already covered. ("Arun Ganesh" is a red link.) This is technically correct, but a bit too immediate. Experienced users know that clicking the red link will take them to creating the new article. But the inexperienced users don't quite understand what happened. The current message doesn't seem to be very good neither at clarifying that an article with this title doesn't exist nor at inviting a user to create an article. It does say "You may create the page", but from observing inexperienced users for years my impression that it they don't understand this message. Also, this appears after 29 checkboxes for namespace selection, which seems to me to complicate things much further. Here are some proposed solutions: - Clarify that an article with this title wasn't found and the results further down (if there are any) are articles in which the search query was found. - Clarify that the user can create a new article if no results are relevant. (Yes, the current message says this already, but as I said, my impression is that it's far from perfect.) - Redesign the namespace selector in a way that will take into account that most Wikipedia don't need any namespaces except the main one, but experienced users and especially editors do need it. - [ Shameless plug for a product that I am developing: ] Something like the "New contributions" button from the ContentTranslation extension can be here. This is just a start of a proposal. The implementation will require professional design and user testing. The goals are supposed to be: - Helping the readers to get to the article - more clickthrough to results would be a success. - Converting readers to editors - more articles are created by new users and not speedily deleted would be a success. (See T91973 for a somewhat related issue in the Android app.)
    • Task
    $wgNamespacesToBeSearchedDefault defines which namespaces are searched by default. It is also uses as NS array for the "content pages" tab. That's misleading. In $wgNamespacesToBeSearchedDefault I define content namespaces (text) and other useful ns like FILE and TALK. Under the "content pages" tab I expect $wgContentNamespaces. Also the tab has at least 3 different names in the code (content, dfeault, articles). Best might be to * In the code rename "articles" and "default" for the "Content pages" tab to "content" > Use $wgContentNamespaces * Add a new tab "Default" > Use $wgNamespacesToBeSearchedDefault
    • Task
    ``` // @todo FIXME: This should prolly be a hook or something // instead of hardcoding the name of the Cite extension if ( \ExtensionRegistry::getInstance()->isLoaded( 'Cite' ) ) { $spat .= '|(<ref>)'; // references via cite extension $endPatterns[4] = '/(<ref>)|(<\/ref>)/'; } ```
    • Task
    Allow ApiQuerySearch searching title AND text together so the 2 queries result it 1 list.
    • Task
    Searching for Sapulpa-Beggs should find "U.S. Route 75 Alternate (Beggs–Sapulpa, Oklahoma)". Without splitting words on dashes it has no chance.
    • Task
    [Intitle: lama](//id.wikipedia.org/w/index.php?title=Istimewa%3APencarian&profile=advanced&search=intitle%3Alama&fulltext=Search&ns0=1&profile=advanced) returns nothing. Yet [a Search for "lama" on the same idwiki](//id.wikipedia.org/w/index.php?search=Lama&title=Istimewa%3APencarian&fulltext=1) will show that //there are a hundreds pages with the term lama in the title//. The problem seems to be * only the `intitle` search parameter, but not others: [incategory: lama](https://id.wikipedia.org/w/index.php?title=Istimewa:Pencarian&profile=default&search=incategory:+lama&fulltext=Search) * only the term `lama`, but not others: [intitle: "lama tibet"](//id.wikipedia.org/w/index.php?title=Istimewa:Pencarian&profile=default&search=intitle:+"lama+tibet"&fulltext=Search), [intitle: tibet prefix:lama](https://id.wikipedia.org/w/index.php?title=Istimewa:Pencarian&profile=default&search=intitle:+tibet+prefix:lama&fulltext=Search), [intitle: aceh prefix:lama](https://id.wikipedia.org/w/index.php?title=Istimewa:Pencarian&profile=default&search=intitle:+aceh+prefix:lama&fulltext=Search) * only on idwiki, but not others: [intitle:lama on mswiki](//ms.wikipedia.org/w/index.php?search=intitle:lama&title=Khas:Cari&go=Pergi), [intitle:lama on enwiki](//en.wikipedia.org/w/index.php?title=Special:Search&profile=default&search=intitle:lama&fulltext=Search) In Indonesian language, "lama" means "old", so it's definitely not a stopword. I've tried several different URLs, and several different pages. The following eight titles from [prefix:Lama](//id.wikipedia.org/w/index.php?title=Istimewa:Pencarian&limit=100&offset=0&profile=default&search=prefix:lama): * Lama Tuha, Kuala Batee, **Aceh **Barat Daya * ([intitle: aceh prefix:lama](https://id.wikipedia.org/w/index.php?title=Istimewa:Pencarian&profile=default&search=intitle:+aceh+prefix:lama&fulltext=Search)) * Lama **Mocogno** * Lama (**Tibet**) * Lama, Pancur Batu, Deli **Serdang** * Lama Tuha, Kuala Batee, **Aceh **Barat Daya * Lama, Sei Lepan, **Langkat** * Lama Baru, Sei Lepan, **Langkat** * Lama **parkir**
    • Task
    Could we leverage search referer queries as metadata on pages as a way of improving natural language queries on our own site? compare https://www.google.com/?gws_rd=ssl#q=who+is+albert+einstein to https://en.wikipedia.org/w/index.php?search=who+is+albert+einstein%3F&title=Special%3ASearch&go=Go If "who is albert einstein?" as metadata could be stored on the article for albert einstein so that it that natural language search query would result in albert einstein being the top result.
    • Task
    The query for "us car production" nor "us auto production" does not result this page as expected: http://en.wikipedia.org/wiki/U.S._Automobile_Production_Figures Exact queries (from URL): https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=us+auto+production&fulltext=Search https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=us+car+production&fulltext=Search Ticket was prompted by Tweet (https://twitter.com/asymco/status/551788812888965120)
    • Task
    As of [0] it is possible to apply post-filtering on $titleMatches/textMatches (using the SpecialSearchResults hook) but unfortunately after the [1] hook is called the "textMatchesNum", "numTextMatches", "titleMatchesNum", "numTitleMatches", and "num" aren't adjusted and therefore can lead to misinterpretation of the result display (e.g. prevnext is displayed even though the post filter has removed all matches from $titleMatches/textMatches or some SearchResult has been removed during the hook call therefore the total count number no longer add up etc.). [0] https://github.com/wikimedia/mediawiki/commit/421a7f1175dda6f75ec4efba44e320c49e94d117 [1] https://github.com/wikimedia/mediawiki/blob/96dd55fde17f13f61060c5786ef4076742af9272/includes/specials/SpecialSearch.php#L368
    • Task
    On <https://commons.wikimedia.org/w/index.php?search=File%3A&title=Special%3ASearch&fulltext=1>, "Results 1 - 20 of 23,135,741" is shown, though the 20 results that are supposed to be on the page are not there. It turns out that SpecialSearch does the following check: ``` $filePrefix = $wgContLang->getFormattedNsText( NS_FILE ) . ':'; if ( trim( $term ) === '' || $filePrefix === trim( $term ) ) { // Empty query -- straight view of search form return; } ``` The `$filePrefix` part of this was added in <https://www.mediawiki.org/wiki/Special:Code/MediaWiki/44252>, though it's unclear why. However, it is not present in the SearchEngine classes, and SpecialSearch performs the "search" even when it is not going to show the results.
    • Task
    At the Vietnamese Wiktionary, searching for “[trường hộp](https://vi.wiktionary.org/wiki/Special:Search/trường_hộp)” redirects to “[trường hợp](https://vi.wiktionary.org/wiki/trường_hợp)”, which is incorrect and potentially confusing to readers (because they might not notice the circumflex being replaced by a horn). At Vietnamese wikis, the search engine should perform case folding only for search suggestions, results, and Did You Mean; it should never redirect the user to a page that only matches due to case-folding. (There is one case where this behavior is useful: things like “xóa” and “xoá” are interchangeable. But we already have redirect pages for all these cases.) The impact on Vietnamese wikis is high because most words have completely unrelated lookalikes when ignoring diacritics.
    • Task
    SpecialAllPages could use a hook, similar to ChangesListInitRows, to allow extensions doing customized formatting in the Linker hooks (onLinkBegin) to do prefetched lookups before rendering each link. this would be helpful, for example, for formatting Wikibase titles with labels instead of ids (Q42 or whatnot).
    • Task
    The original specific description is below, but the required solution is much more general: we would need to find a way to upgrade the [HebMorph](https://github.com/synhershko/HebMorph) dictionary to a newer version of [Hspell](http://hspell.ivrix.org.il/) and/or be able to add custom entries to the dictionary. _____ In the Hebrew language the prepositions and the conjunctions are usually prefixed to the beginning of the word. For example, "טריפלקס" means "triplex" and "וטריפלקס" means "and triplex". The letter "ו" was added in the beginning. Ideally, the search engine should be smart enough to know about morphology and understand that "טריפלקס" should also yield results with "וטריפלקס". The situation with Arabic is very similar, and possibly there are more such languages.
    • Task
    "bar" should suggest * Foo Bar * Extension:Bars * Help:Foo baring -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Once the multiple namesspaces are enabled from T26214, it would be good if namespaces could be priorized. Example: On my wiki categories are more important as articles. So I'd like to give categories a higher prio on the suggestions. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    We have some langues such as Arabic, Persian, Urdu, Kurdish,... which uses common characters and they have similar geliphs with different Unicode number for example: for ک (Kaf) ك Arabic U+0643 ڪ Urdu U+06AA ﻙ Pushtu U+FED9 ﻚ Uyghur U+FEDA ک Persian U+06A9 for ی (ya) ی Persian U+06CC ي Arabic U+064A ى Urdu U+0649 ۍ Pushtu U+06CD ې Uyghur U+06D0 for ه (heh) ہ Pushtu U+06C1 ە Kurdish U+06D5 ه Persian U+0647 we have these characters which have different Unicode number and different keyboard. Now many users does not access to Persian keyboard or urdu keyboard by default in their OS (like windows xp, android (low versions), IOS ,...). so when they search for an article they can not find it in wikipedia searach box but it is existing in local characters. For example if you search at fa.wikipedia for article ويليام شكسپير (characters are in Arabic ي , ك) you can not find it and the article in Farsi is ویلیام شکسپیر (characters are in Persian ی , ک). for farsi please add a possibility for search tool to assume U+064A or U+0649 or U+06CD or U+06D0 or U+06CC > U+06CC U+0643 or U+06AA or U+FED9 or U+FEDA > U+06A9 U+06C1 or U+06D5 > U+0647 -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    **Author:** `KilliondudeWP` **Description:** To reproduce: 1) Go to meta.wikimedia.org 2) Type in "Meta:Speedy" into the search bar 3) Note that "Meta:Speedy Deletions" is suggested The suggested target page does not exist nor is there record of it having existed. See screenshots: http://imgur.com/a/irWIg -------------------------- **Version**: 1.24rc **Severity**: minor
    • Task
    **Author:** `asokratis` **Description:** searching on the wiki with characters such as ")" or "(" (maybe there are more?) will show a page with the following: Database Error. A database query error has occurred. This may indicate a bug in the software. Examples of Search: test) test( If a ticket for this has already been open, please close this ticket and refer to me where the issue so I can be monitoring it. -------------------------- **Version**: 1.23.1 **Severity**: normal
    • Task
    Adding new attributes to SearchResult and subclasses is a royal pain in the ass. Special:Search has to be screwed around with to handle this metadata in some UI way. So this bug is two things. Clean up SearchResult to have a useful way of returning $randomMetadata and a way to display it. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    **Author:** `atlantonius` **Description:** in 1.22, if a filename begins with a capital letter, searching fails if your search criteria includes the capital letter. If you omit the first character, it works fine. I found this to be because of the following line in /includes/special/SpecialListfiles.php, Line 138: $conds[] = 'LOWER(' . $prefix . '_name)' . If this is changed to the following, you can now search using a capital letter: $conds[] = 'CONVERT(' . $prefix . '_name USING latin1)' . Originally found by Fereal in a previous version, I simply adopted their solution for the new function in 1.22. Link to that discussion below: http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Search_function_in_File_list_doesn't_work_properly -------------------------- **Version**: 1.22.0 **Severity**: normal **OS**: Linux **URL**: http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Search_function_in_File_list_doesn't_work_properly
    • Task
    The request is for Special:PrefixIndex to return a count of the number of pages it finds and is able to return that number through the API and the magic word... The special page should show "Showing results 1-50 of 115" so people can see how many (sub-)pages there are with this prefix. This would allow for something like: {{#ifexpr:{{Special:PrefixIndex/Wikipedia:Requests for adminship/User:Example|count=yes}}>1|[{{fullurl:Special:PrefixIndex|prefix=Requests+for+adminship%2FUser:Example&namespace=4}} RfAs]}} to only show the link if there are actually results. So, this number should be available to access through the magic word and the API as well. -------------------------- **Version**: unspecified **Severity**: enhancement