Page MenuHomePhabricator
Search Global Search

Global Search
Use Results
Hide Query

Use the application-specific Advanced Search for better results and additional search criteria: Tasks, Commits. (More information)
  • T416446: Extension:Disambiguator could show a warning list of links to disambiguation pages on page edit and page preview
    • Task
    **Feature summary**: - On page edit, a list of links to disambiguation pages within the section/page being edited could be displayed as a warning. - On page preview, the links to disambiguation pages could be checked again, and updated. (See {T394016}) ** Additonal thoughts ** - We might not want the warning message to get too long. Give details only if requested by the user as user preference? - There is potential here to present the user with options, e.g. if a link goes to `[[2 Bob]]`, then it could display a list of more suitable targets, e.g: `[[The Two Bobs]]`, `[[Two Bob]]`, `[[Florin (British coin)]]`, `[[2BOB]]` **Benefits**: This would assist editors in identifying links to disambiguation pages that need fixing, and check that they are then being fixed.
  • T415009: Disambiguator does not trigger when linking from Citoid
    • Task
    When filling out a citation, it is common (and often desirable) to link a source to its Wikipedia article, e.g. with `|work=[[Time (magazine)|Time]]`. Many publication names (e.g. //Life//, //Vox//, //Variety//, //Hindustan//, //Nature//, etc.) need to be disambiguated. However, editors often forget to check for this when linking, creating a link to a disambiguation page that must be cleaned up. The #mediawiki-extensions-disambiguator extension does not trigger within the Citoid form on source editor the way it does when editing in the body, and there is no provision for warning when linking to a disambiguation page within the TemplateData form fields that must be used to link sources within a citation in VisualEditor. This task captures the work around creating a solution so that editors linking sources when adding a citation do not accidentally link to disambiguation pages.
  • T401556: isDisambiguationPage causes unnecessary inclusion in "Templates used in this page" list
    • Task
    **Steps to replicate the issue**: * Search Wikipedia for a module that uses the isDisambiguationPage function. * Go to "What links here", and click there on a page in the main namespace. * Go to edit mode, and scroll down to the "Templates used in this page" list (screenshot attached). **What happens?**: In the list, besides the templates used in the page, pages from the main namespace that are not included in the page also appear. **What should have happened instead?**: Even if we want the cache on these pages to be purged frequently (through the templates used in page tables), we should ensure that the page list doesn't display these. Or find another solution other than inclusion in this table. **Other information**: The issue was reported on Hebrew Wikipedia, at [[ https://he.wikipedia.org/w/index.php?title=ויקיפדיה:תבנית/אולם_דיונים&oldid=41623395#דפים_ממרחב_הערכים_שמופיעים_ברשימת_התבניות_שבתחתית_עורך_קוד_מקור | this ]] link. After investigation, it was found that the issue also exists in all other Wikimedia wikis, for example English Wikipedia. {F65733735}
  • T397129: Bundle Extension:Disambiguator with MediaWiki
    • Task
    From https://www.mediawiki.org/wiki/Extension:Disambiguator > The Disambiguator extension is designed to make disambiguation pages easier to work with programmatically. It allows you to designate all disambiguation pages with the __DISAMBIG__ magic word (or an equivalent alias), which then marks them as such in the database. This allows other extensions to optionally handle disambiguation pages as a separate class of page, although they are still considered "normal" pages. This extension is important for any wiki which has disambiguation pages, which is most wikis. Wikis without disambiguation pages can't have a good data structure, which is why Wiktionary's data structure is so screwed up. And then: From: https://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_integrated#Disambiguator > Ship in tarball, not merge, when Special:Disambiguations is removed from core. --Moejoe000 (talk) 10:58, 14 January 2013 (UTC) > Core is better. --Nemo 12:13, 14 January 2013 (UTC) > I originally implemented it in core, but was told it should be built as an extension instead. Personally, I thought it would make more sense in core, but I was under the impression that consensus was otherwise, per https://bugzilla.wikimedia.org/show_bug.cgi?id=35981. Let's discuss further in the bug. Kaldari (talk) 23:20, 15 January 2013 (UTC) > I also think it makes more sense in core. Btw, some discussion has occurred on wikitech-l. --Waldir (talk) 15:52, 6 February 2013 (UTC) > Moved to "bundle" section because the functionality was removed from core and this will obviously not be reverted any time soon. --Nemo 07:07, 10 September 2013 (UTC) **Checklist** [ ] Passed discussion or already Wikimedia deployed [x] Passed security review or already Wikimedia deployed [ ] Voting CI structure tests [ ] Runs MediaWiki-CodeSniffer [ ] Runs phan [ ] Supports MySQL, SQLite, and Postgres (if there are schema changes) [x] GPL v2 or later compatible license [ ] Extension's default configuration provides optimal experience [ ] Tested with web installer [ ] Any relevant dependencies also bundled
  • T393751: Extension:Disambiguator should include magic word {{ISDISAMBIG}}
    • Task
    **Feature summary** Extension:Disambiguator should introduce a new magic word `{{ISDISAMBIG}}` which returns Boolean `true` if the page is a disambiguation page. **Benefits**: This would allow [[MediaWiki:Nstab-main]] https://en.wikipedia.org/wiki/MediaWiki:Nstab-main can include a switch to account for whether the page is a disambiguation page. As you can see, Wikipedia currently contradicts itself on disambiguation pages: {F59798897} It would also mean that `{{ISDISAMBIG:insert page name here}}` could be called on any other page or template.
  • T393750: Extension:Disambiguator should have special page to disambiguate
    • Task
    **Background** Extension:Disambiguator is a nice little extension that's needed for any wiki that has disambiguation pages. https://www.mediawiki.org/wiki/Extension:Disambiguator 🙏 Thanks to Ryan @Kaldari for writing this. This has a lot of functionality, but one thing it doesn't actually do is live up to its name of disambiguat**OR**, as in one who does something: https://en.wiktionary.org/wiki/-or#Suffix **What I wanna do...** OK, so let's randomly pick a disambiguation page. Wikipedia gave me https://en.wikipedia.org/wiki/Senator_Taft_(disambiguation) I want a special page at [[Special:Disambiguate/Senator_Taft_(disambiguation)]] for this that # Recognises [[Senator_Taft_(disambiguation)]] (via the presence of `__DISAMBIG__` # If (1) is true, shows me all incoming links to [[Senator Taft (disambiguation)]] (or the first `n` to avoid overload), and for each link: # The context (co-text) of the incoming link. # The ability to change the link's target to one of the outgoing links from [[Senator Taft (disambiguation)]], or leave it if I'm confused # A button to execute However, if we pick a random article page (Wikipedia gave me https://en.wikipedia.org/wiki/Umtshezi_Local_Municipality), then the special page should instead offer to change any links from [[Umtshezi_Local_Municipality)]] that link to disambiguation pages. Again, with contextual clues. **Benefits**: This would be a really useful feature for disambiguating. It would mean users wouldn't have to use external scripts to disambiguate pages, as it could all be done in-wiki. External scripts can be a bit fiddly. A link to `[[Special:Disambiguate/{{PAGENAME}}]]` could be incorporated into the template `{{Disambig}}` Thanks for reading and considering. 🙏
  • T393668: Extension to create magic word for bad redirects
    • Task
    Redirects come in a variety of types, but one that's a little problematic are what might be called "**bad redirects**." These are things like misspellings (e.g. https://en.wikipedia.org/wiki/Category:Redirects_from_misspellings), including incorrect use of punctuation marks. Maybe a wiki strongly prefers a technical term over a non-technical term that's otherwise common, but also wrong (a misnomer). A wiki doesn't want editors linking to these, but these redirects can, nevertheless, be useful. For example, if someone types the term into the search box, or there are links into it from the outside world; see https://meta.wikimedia.org/wiki/Don%27t_delete_redirects for an essay on this. Now, by adding a magic word, for example, `{{#badredirect}}` or `{{#badredir}}` to these pages, we could wrap them in a specific CSS marker which could then be recognised by gadgets, userscripts, etc. This would allow editors to link to the desired page instead. A special page at `Special:BadRedirects` would provide a maintenance report that listed any internal links to these pages. Note how this functionality is nearly identical to what Extension:Disambiguator does. Extension:Disambiguator can be used to mark pages as disambiguation pages with a magic word `__DISAMBIG__`. This is a 👍 great extension for any wikis that use disambiguation pages. 🙏 Thanks to Ryan @Kaldari for writing this. Because of the inherent similarity, most of the code for this already exists. It probably needs to be a separate extension, though, since it's conceivable that a wiki lacks disambiguation pages but still has these bad redirects. Or maybe it should go into core. It's also nearly identical to https://www.mediawiki.org/wiki/Extension:SoftRedirector -- just the magic word is different, I think. Thanks for reading.
  • T386110: Disambiguation categories should have mw-disambig class in list of categories
    • Task
    **Feature summary** (what you would like to be able to do and where): On a page like https://ru.wikipedia.org/?oldid=142972911 the category `Родившиеся в Пожеге` should have `mw-disambig` class so that it can be highlighted by CSS that highlights disambiguation pages. This should allow people to notice these issues easier and to fix the disambiguation categories on their pages. Disambiguation categories are a feature of many wikis and is a mechanism supported by gadgets like HotCat: - https://www.wikidata.org/wiki/Q8379318 - https://en.wikipedia.org/wiki/Category:Disambiguation_categories - https://ru.wikipedia.org/wiki/Категория:Неоднозначные_категории Example of existing page without the class: - https://ru.wikipedia.org/wiki/Капичун,_Александр_Валерьевич
  • T378138: Wikimedia\RequestTimeout\EmergencyTimeoutException: The critical section "Wikimedia\Rdbms\Database::executeQuery" timed out after {limit} seconds
    • Task
    ==== Error ==== * mwversion: 1.43.0-wmf.28 * reqId: `8bcde27e-e745-46b8-8b4e-62f7b74002bb` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2024-10-23T20:14:27.714Z',to:'2024-10-24T20:16:07.567Z'))&_a=(query:(query_string:(query:'reqId:%228bcde27e-e745-46b8-8b4e-62f7b74002bb%22'))) | Find reqId in Logstash ]] ```name=normalized_message,lines=10 [{reqId}] {exception_url} Wikimedia\RequestTimeout\EmergencyTimeoutException: The critical section "Wikimedia\Rdbms\Database::executeQuery" timed out after {limit} seconds ``` | Frame | Location | Call | -- | -- | -- | from | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/vendor/+/refs/heads/wmf/1.43.0-wmf.28/wikimedia/request-timeout/src/Detail/CriticalSection.php#31 | /srv/mediawiki/php-1.43.0-wmf.28/vendor/wikimedia/request-timeout/src/Detail/CriticalSection.php(31) ]] | | #0 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/libs/rdbms/database/DatabaseMySQL.php#670 | /srv/mediawiki/php-1.43.0-wmf.28/includes/libs/rdbms/database/DatabaseMySQL.php(670) ]] | Wikimedia\RequestTimeout\Detail\CriticalSection::Wikimedia\RequestTimeout\Detail\{closure}(int) | #1 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/libs/rdbms/database/Database.php#787 | /srv/mediawiki/php-1.43.0-wmf.28/includes/libs/rdbms/database/Database.php(787) ]] | Wikimedia\Rdbms\DatabaseMySQL->doSingleStatementQuery(string) | #2 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/libs/rdbms/database/Database.php#711 | /srv/mediawiki/php-1.43.0-wmf.28/includes/libs/rdbms/database/Database.php(711) ]] | Wikimedia\Rdbms\Database->attemptQuery(Wikimedia\Rdbms\Query, string, bool) | #3 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/libs/rdbms/database/Database.php#638 | /srv/mediawiki/php-1.43.0-wmf.28/includes/libs/rdbms/database/Database.php(638) ]] | Wikimedia\Rdbms\Database->executeQuery(Wikimedia\Rdbms\Query, string, int) | #4 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/libs/rdbms/database/Database.php#1345 | /srv/mediawiki/php-1.43.0-wmf.28/includes/libs/rdbms/database/Database.php(1345) ]] | Wikimedia\Rdbms\Database->query(Wikimedia\Rdbms\Query, string) | #5 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/libs/rdbms/database/DBConnRef.php#127 | /srv/mediawiki/php-1.43.0-wmf.28/includes/libs/rdbms/database/DBConnRef.php(127) ]] | Wikimedia\Rdbms\Database->select(array, array, array, string, array, array) | #6 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/libs/rdbms/database/DBConnRef.php#351 | /srv/mediawiki/php-1.43.0-wmf.28/includes/libs/rdbms/database/DBConnRef.php(351) ]] | Wikimedia\Rdbms\DBConnRef->__call(string, array) | #7 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php#745 | /srv/mediawiki/php-1.43.0-wmf.28/includes/libs/rdbms/querybuilder/SelectQueryBuilder.php(745) ]] | Wikimedia\Rdbms\DBConnRef->select(array, array, array, string, array, array) | #8 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Disambiguator/+/refs/heads/wmf/1.43.0-wmf.28/includes/Lookup.php#70 | /srv/mediawiki/php-1.43.0-wmf.28/extensions/Disambiguator/includes/Lookup.php(70) ]] | Wikimedia\Rdbms\SelectQueryBuilder->fetchResultSet() | #9 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Disambiguator/+/refs/heads/wmf/1.43.0-wmf.28/includes/Hooks.php#163 | /srv/mediawiki/php-1.43.0-wmf.28/extensions/Disambiguator/includes/Hooks.php(163) ]] | MediaWiki\Extension\Disambiguator\Lookup->filterDisambiguationPageIds(array) | #10 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/HookContainer/HookContainer.php#159 | /srv/mediawiki/php-1.43.0-wmf.28/includes/HookContainer/HookContainer.php(159) ]] | MediaWiki\Extension\Disambiguator\Hooks->onGetLinkColours(array, array, MediaWiki\Title\Title) | #11 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/HookContainer/HookRunner.php#1924 | /srv/mediawiki/php-1.43.0-wmf.28/includes/HookContainer/HookRunner.php(1924) ]] | MediaWiki\HookContainer\HookContainer->run(string, array) | #12 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/parser/LinkHolderArray.php#232 | /srv/mediawiki/php-1.43.0-wmf.28/includes/parser/LinkHolderArray.php(232) ]] | MediaWiki\HookContainer\HookRunner->onGetLinkColours(array, array, MediaWiki\Title\Title) | #13 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/parser/LinkHolderArray.php#155 | /srv/mediawiki/php-1.43.0-wmf.28/includes/parser/LinkHolderArray.php(155) ]] | MediaWiki\Parser\LinkHolderArray->replaceInternal(string) | #14 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/parser/Parser.php#5083 | /srv/mediawiki/php-1.43.0-wmf.28/includes/parser/Parser.php(5083) ]] | MediaWiki\Parser\LinkHolderArray->replace(string) | #15 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/parser/Parser.php#1701 | /srv/mediawiki/php-1.43.0-wmf.28/includes/parser/Parser.php(1701) ]] | MediaWiki\Parser\Parser->replaceLinkHoldersPrivate(string) | #16 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/parser/Parser.php#704 | /srv/mediawiki/php-1.43.0-wmf.28/includes/parser/Parser.php(704) ]] | MediaWiki\Parser\Parser->internalParseHalfParsed(string, bool, bool) | #17 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/language/MessageCache.php#1540 | /srv/mediawiki/php-1.43.0-wmf.28/includes/language/MessageCache.php(1540) ]] | MediaWiki\Parser\Parser->parse(string, MediaWiki\Title\Title, MediaWiki\Parser\ParserOptions, bool) | #18 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/Message/Message.php#1503 | /srv/mediawiki/php-1.43.0-wmf.28/includes/Message/Message.php(1503) ]] | MessageCache->parse(string, MediaWiki\Title\Title, bool, bool, LanguageEn) | #19 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/Message/Message.php#1072 | /srv/mediawiki/php-1.43.0-wmf.28/includes/Message/Message.php(1072) ]] | MediaWiki\Message\Message->parseText(string) | #20 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/Message/Message.php#1112 | /srv/mediawiki/php-1.43.0-wmf.28/includes/Message/Message.php(1112) ]] | MediaWiki\Message\Message->format(string) | #21 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/skins/components/SkinComponentCopyright.php#117 | /srv/mediawiki/php-1.43.0-wmf.28/includes/skins/components/SkinComponentCopyright.php(117) ]] | MediaWiki\Message\Message->parse() | #22 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/skins/components/SkinComponentCopyright.php#43 | /srv/mediawiki/php-1.43.0-wmf.28/includes/skins/components/SkinComponentCopyright.php(43) ]] | MediaWiki\Skin\SkinComponentCopyright->getCopyrightHTML() | #23 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/skins/Skin.php#214 | /srv/mediawiki/php-1.43.0-wmf.28/includes/skins/Skin.php(214) ]] | MediaWiki\Skin\SkinComponentCopyright->getTemplateData() | #24 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/skins/SkinTemplate.php#197 | /srv/mediawiki/php-1.43.0-wmf.28/includes/skins/SkinTemplate.php(197) ]] | Skin->getTemplateData() | #25 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/skins/SkinMustache.php#140 | /srv/mediawiki/php-1.43.0-wmf.28/includes/skins/SkinMustache.php(140) ]] | SkinTemplate->getTemplateData() | #26 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/+/refs/heads/wmf/1.43.0-wmf.28/includes/SkinVector22.php#328 | /srv/mediawiki/php-1.43.0-wmf.28/skins/Vector/includes/SkinVector22.php(328) ]] | SkinMustache->getTemplateData() | #27 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/skins/SkinMustache.php#93 | /srv/mediawiki/php-1.43.0-wmf.28/includes/skins/SkinMustache.php(93) ]] | MediaWiki\Skins\Vector\SkinVector22->getTemplateData() | #28 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/skins/SkinTemplate.php#190 | /srv/mediawiki/php-1.43.0-wmf.28/includes/skins/SkinTemplate.php(190) ]] | SkinMustache->generateHTML() | #29 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/Output/OutputPage.php#3193 | /srv/mediawiki/php-1.43.0-wmf.28/includes/Output/OutputPage.php(3193) ]] | SkinTemplate->outputPage() | #30 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/actions/ActionEntryPoint.php#163 | /srv/mediawiki/php-1.43.0-wmf.28/includes/actions/ActionEntryPoint.php(163) ]] | MediaWiki\Output\OutputPage->output(bool) | #31 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/includes/MediaWikiEntryPoint.php#200 | /srv/mediawiki/php-1.43.0-wmf.28/includes/MediaWikiEntryPoint.php(200) ]] | MediaWiki\Actions\ActionEntryPoint->execute() | #32 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/wmf/1.43.0-wmf.28/index.php#58 | /srv/mediawiki/php-1.43.0-wmf.28/index.php(58) ]] | MediaWiki\MediaWikiEntryPoint->run() | #33 | [[ https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/w/index.php#3 | /srv/mediawiki/w/index.php(3) ]] | require(string) | #34 | {main} | ==== Notes ==== * This seems to happen quite a bit, but couldn't find a task for it * Notable {T365655} was looking for a stack trace with `EmergencyTimeoutException` -- good news!
  • T375930: Intentional link to disambiguation page with "(disambiguation)" in title should not trigger dab warning popup
    • Task
    **Steps to replicate the issue** (include links if applicable): * While editing a page's source on en.wikipedia.org, * Type [[New Year (disambiguation)]] **What happens?**: A popup appears warning me that I'm linking to a disambiguation page **What should have happened instead?**: The popup should not appear **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): Popups to review disambiguation links review popup were added in T285508 When intentionally linking to a disambiguation page on en.wikipedia.org, it is best practice to link to "(disambiguation)", even if it is a redirect to the unqualified name.
  • T375929: Removing or fixing a new disambiguation link should also hide the link review popup
    • Task
    **Steps to replicate the issue** (include links if applicable): * While editing a page's source on en.wikipedia.org, * Type [[NY]] * Wait for the "review link" popup to appear * Backspace through [[NY]] or change it to [[New York City]] **What happens?**: Popup stays up (until dismissed manually) **What should have happened instead?**: Popup should disappear **Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia): **Other information** (browser name/version, screenshots, etc.): Popups to review disambiguation links review popup were added in T285508
  • T361244: Wikimedia\Assert\PreconditionException: Precondition failed: This Title instance does not represent a proper page, but merely a link target.
    • Task
    ==== Error ==== * service.version: 1.42.0-wmf.24 * trace.id: 31b42232-39b3-4b02-8457-d4e823dd2945 * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2024-03-26T20:39:51.298Z',to:'2024-03-28T15:13:08.597Z'))&_a=(query:(query_string:(query:'reqId:%2231b42232-39b3-4b02-8457-d4e823dd2945%22'))) | Find trace.id in Logstash ]] ```name=labels.normalized_message,lines=10 [{reqId}] {exception_url} Wikimedia\Assert\PreconditionException: Precondition failed: This Title instance does not represent a proper page, but merely a link target. ``` ```name=error.stack_trace,lines=10 from /srv/mediawiki/php-1.42.0-wmf.24/vendor/wikimedia/assert/src/Assert.php(49) #0 /srv/mediawiki/php-1.42.0-wmf.24/includes/title/Title.php(3891): Wikimedia\Assert\Assert::precondition(boolean, string) #1 /srv/mediawiki/php-1.42.0-wmf.24/includes/title/Title.php(3872): MediaWiki\Title\Title->assertProperPage() #2 /srv/mediawiki/php-1.42.0-wmf.24/extensions/Disambiguator/includes/Hooks.php(202): MediaWiki\Title\Title->getId() #3 [internal function]: MediaWiki\Extension\Disambiguator\Hooks::MediaWiki\Extension\Disambiguator\{closure}(MediaWiki\Title\Title) #4 /srv/mediawiki/php-1.42.0-wmf.24/extensions/Disambiguator/includes/Hooks.php(201): array_map(Closure, array) #5 /srv/mediawiki/php-1.42.0-wmf.24/includes/HookContainer/HookContainer.php(159): MediaWiki\Extension\Disambiguator\Hooks->onLinksUpdateComplete(MediaWiki\Deferred\LinksUpdate\LinksUpdate, integer) #6 /srv/mediawiki/php-1.42.0-wmf.24/includes/HookContainer/HookRunner.php(2348): MediaWiki\HookContainer\HookContainer->run(string, array) #7 /srv/mediawiki/php-1.42.0-wmf.24/includes/deferred/LinksUpdate/LinksUpdate.php(194): MediaWiki\HookContainer\HookRunner->onLinksUpdateComplete(MediaWiki\Deferred\LinksUpdate\LinksUpdate, integer) #8 /srv/mediawiki/php-1.42.0-wmf.24/includes/deferred/AutoCommitUpdate.php(47): MediaWiki\Deferred\LinksUpdate\LinksUpdate->MediaWiki\Deferred\LinksUpdate\{closure}(Wikimedia\Rdbms\DBConnRef, string) #9 /srv/mediawiki/php-1.42.0-wmf.24/includes/deferred/DeferredUpdates.php(486): MediaWiki\Deferred\AutoCommitUpdate->doUpdate() #10 /srv/mediawiki/php-1.42.0-wmf.24/includes/deferred/DeferredUpdates.php(198): MediaWiki\Deferred\DeferredUpdates::attemptUpdate(MediaWiki\Deferred\AutoCommitUpdate) #11 /srv/mediawiki/php-1.42.0-wmf.24/includes/deferred/DeferredUpdates.php(285): MediaWiki\Deferred\DeferredUpdates::run(MediaWiki\Deferred\AutoCommitUpdate) #12 /srv/mediawiki/php-1.42.0-wmf.24/includes/deferred/DeferredUpdatesScope.php(269): MediaWiki\Deferred\DeferredUpdates::MediaWiki\Deferred\{closure}(MediaWiki\Deferred\AutoCommitUpdate, integer) #13 /srv/mediawiki/php-1.42.0-wmf.24/includes/deferred/DeferredUpdatesScope.php(198): MediaWiki\Deferred\DeferredUpdatesScope->processStageQueue(integer, integer, Closure) #14 /srv/mediawiki/php-1.42.0-wmf.24/includes/deferred/DeferredUpdates.php(304): MediaWiki\Deferred\DeferredUpdatesScope->processUpdates(integer, Closure) #15 /srv/mediawiki/php-1.42.0-wmf.24/extensions/EventBus/includes/JobExecutor.php(110): MediaWiki\Deferred\DeferredUpdates::doUpdates() #16 /srv/mediawiki/rpc/RunSingleJob.php(60): MediaWiki\Extension\EventBus\JobExecutor->execute(array) #17 {main} ``` ==== Notes ==== * Started happening yesterday on zhwiktionary immediately following wmf.24 rollout * Only coming from jobrunners * Only from wikikube jobrunners
  • T352847: Disambiguation pages should be on top
    • Task
    **Feature summary**: The disambiguation page for a search term should be on the top of the result list and the suggested list **Use case(s)**: If I type a search term, the shortest string is usually the most general and will lead to an disambiguation page. E.g. if I look for something or someone call "Goethe", the algorithm suggests "Johann Wolfgang von Goethe" on top, which makes sense. But "Goethe (disambiguation)" doesn't even make the top ten, so it is never shown on the mobile page, where there is no result page. There might be the "Template:Redirect" as a workaround like in this case, but not in all cases. It's not reliable and not a good user experience. **Benefits**: Especially casual and mobile users will have a better search experience with more successful search results
  • T348691: $textarea is undefined
    • Task
    Seen on https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Polar_bear&action=edit&cm6enable=1 https://logstash.wikimedia.org/app/dashboards#/doc/logstash-*/logstash-default-1-7.0.0-1-2023.10.10?id=-NQ-G4sBt3kDdlqnJpry ``` stack_trace at bindTextareaListener https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector-2022 line 10 > eval:2:845 at disambiguator/ext.disambiguator.js/</< https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector-2022 line 10 > eval:3:538 at fire https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector-2022 line 10 > eval:4:699 at value https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=ext.CodeMirror.v6.WikiEditor%7Cjquery%2Coojs-ui-core%2Coojs-ui-widgets%2Cvue%7Cjquery.ui&skin=vector-2022&version=1w73y:282:181 at execute https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=ext.CodeMirror.v6.WikiEditor%7Cjquery%2Coojs-ui-core%2Coojs-ui-widgets%2Cvue%7Cjquery.ui&skin=vector-2022&version=1w73y:281:115 at doAction https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=ext.wikiEditor&skin=vector-2022&version=14ys9:28:874 at jquery.wikiEditor.toolbar.js/buildTool/< https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=ext.wikiEditor&skin=vector-2022&version=14ys9:30:882 at OO.EventEmitter.prototype.emit https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector-2022 line 10 > eval:8:344 at OO.ui.mixin.ButtonElement.prototype.onClick https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=ext.CodeMirror.v6.WikiEditor%7Cjquery%2Coojs-ui-core%2Coojs-ui-widgets%2Cvue%7Cjquery.ui&skin=vector-2022&version=1w73y:452:758 at dispatch https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=ext.CodeMirror.v6.WikiEditor%7Cjquery%2Coojs-ui-core%2Coojs-ui-widgets%2Cvue%7Cjquery.ui&skin=vector-2022&version=1w73y:348:932 at add/elemData.handle https://en.wikipedia.beta.wmflabs.org/w/load.php?lang=en&modules=ext.CodeMirror.v6.WikiEditor%7Cjquery%2Coojs-ui-core%2Coojs-ui-widgets%2Cvue%7Cjquery.ui&skin=vector-2022&version=1w73y:345:565 ```
  • T347123: Reduce database queries on parsercached logged-out page views (Sep 2023)
    • Task
    Capturing via verbose Logstash and Excimer UI in two (separate) profiles using WikimediaDebug after 1 warmup request that has neither of the options enabled, by viewing en.wikipedia.org's featured article at <https://en.wikipedia.org/wiki/Robert_Howard_Hodgkin> in private browsing (logged-out). Prior art: * {T302538} * {T322528} ## List of queries * Logs: <https://logstash.wikimedia.org/app/dashboards#/view/x-debug?_g=(time:(from:now-1h,mode:quick,to:now))&_a=(query:(query_string:(query:%27reqId:%22d15a6bb9-27ac-44ac-a1ed-9887c872fbe2%22%27)))> * Flame graph with **stack traces for each database query**: <https://performance.wikimedia.org/excimer/profile/9f93148c22caf7dc> I reduced the logs by using `message:SELECT` which yields **19 queries**, roughly in order: 1. `[0.001s] Wikimedia\Rdbms\Replication\MysqlReplicationReporter::fetchSecondsSinceHeartbeat SELECT … FROM heartbeat where shard = 's1' …` * Who: rdbms. * Why: Preflight required once for any new db connection, as requested by one or more later. 2. `[0.001s] WikiPage::pageData SELECT … FROM page WHERE page_namespace = 0 AND page_title = 'Robert_Howard_Hodgkin' LIMIT 1 ` * Who: MediaWiki.php. * Why: This single query feeds many consumers all in one efficient row fetch. E.g. to determine the rendered title (is it a redirect that we need to resolve first?), RequestContext (does the page exist?), ActionFactory (which ContentHandler and Action will hande this request?), Title and PageRecord (page ID), ViewAction/OutputPage/Skin (current revision ID etc.) 3. `[0.002s] MediaWiki\Output\OutputPage::addCategoryLinksToLBAndGetResult SELECT … FROM page LEFT JOIN page_props ON (pp_propname = 'hiddencat' AND (pp_page = page_id)) WHERE ((page_namespace = 14 AND page_title IN (…,'Featured_articles',…,'1877_births','1951_deaths',…,'British_historians',…) ))` * Who: OutputPage, on behalf of Skin. * Why: Show category links at the bottom of the page. Interestingly, there is no `categorylinks` table query, because that data is obtained from the ParserOutput from the ParserCache. Doing so saves a DB query but also ensure integrity and internal concistency with the rendered wikitext revision (i.e. you wouldn't want a category associated with a template like "citation needed", when it is no longer in the content or vice versa). This query is to help separate the "hidden" categories from the regular ones. This can change at any time through edits to category pages and rather than cache this in ParserCache and require refresh links to propagate on the entire site after (unprotected) Category edits, we instead query this at the last-minute. 4. `[0.001s] MediaWiki\Page\PageProps::getProperties SELECT pp_page,pp_propname,pp_value FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'notalk'` 5. `[0s] MediaWiki\Page\PageProps::getProperties SELECT pp_page,pp_propname,pp_value FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'newsectionlink'` 6. `[0s] MediaWiki\Page\PageProps::getProperties SELECT pp_page,pp_propname,pp_value FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'archivedtalk'` * Who: DiscussionTools extension. * Why: To determine whether this is a talk page, via `isAvailableForTitle()` from `DiscussionTools\PageHooks::onOutputPageBeforeHTML`. 7. `[0.001s] MediaWiki\Page\PageProps::getProperties SELECT pp_page,pp_propname,pp_value FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'templatedata'` * Who: TemplateData extension. * Why: To localise template documentation, in case this is a page view (which it might not be) for a Template page (which it might not be) with templatedata docs in the parser output (which it might not have). 8. `[0.001s] MediaWiki\Extension\PageTriage\QueueLookup::getByPageId SELECT ptrp_page_id,ptrp_reviewed,ptrp_created,ptrp_deleted,ptrp_tags_updated,ptrp_reviewed_updated,ptrp_last_reviewed_by FROM pagetriage_page WHERE ptrp_page_id = 54249587 LIMIT 1 ` * Who: PageTriage extension. * Why: To decide whether to add its user interface to the article, via `isPageUnreviewed()` from `PageTriage\Hooks::onArticleViewFooter`. 9. `[0s] MediaWiki\Extension\Disambiguator\Lookup::filterDisambiguationPageIds SELECT page_id,rd_from FROM redirect JOIN page ON ((rd_namespace=page_namespace) AND (rd_title=page_title)) WHERE rd_from = 54249587` 10. `[0s] MediaWiki\Extension\Disambiguator\Lookup::filterDisambiguationPageIds SELECT pp_page FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'disambiguation'` * Who: RelatedArticles extension. * Why: To decide whether to output a "related articles" below the article. Via `MediaWiki\Extension\Disambiguator\Hooks::isDisambiguationPage` from `RelatedArticles\Hooks::onSkinAfterContent`. 11. `[0.001s] PageImages\PageImages::fetchPageImage SELECT pp_value FROM page_props WHERE pp_page = 54249587 AND pp_propname IN ('page_image','page_image_free') ORDER BY pp_propname LIMIT 1 ` * Who: PageImages extension. * Why: To insert `<meta property="og:image">` into the HTML `<head>` 12. `[0.001s] LinkBatch::doQuery (for Skin::preloadExistence) SELECT … FROM page WHERE ((page_namespace = 1 AND page_title = 'Robert_Howard_Hodgkin') OR (page_namespace = 2 AND page_title = 'X.X.X.X/sandbox'))` * Who: Skin. * Why: For links in the skin interface sidebar, personal tools, page actions, etc. all batched together to decide whether they are blue or red. 13. `[0s] MediaWiki\User\TalkPageNotificationManager::dbCheckNewUserMessages SELECT user_ip FROM user_newtalk WHERE user_ip = 'X.X.X.X' LIMIT 1 ` * Who: Skin. * Why: "**[Orange bar of doom](https://meta.wikimedia.org/wiki/New_messages_notification)**", to say "You have new messages".. Note that this for any edit session, including for unregistered users for whom messages are left on a User_talk page based on their IP-address. 14. `[0.001s] MediaWiki\Page\PageStore::getPageByNameViaLinkCache SELECT … FROM page WHERE page_namespace = 12 AND page_title = 'Category' LIMIT 1` * Who: Skin. * Why: The `Help:Categories` link, labelled "Categories", for the category box at the bottom of article. 15. `[0.001s] MediaWiki\Extension\Disambiguator\Lookup::filterDisambiguationPageIds SELECT page_id,rd_from FROM redirect JOIN page ON ((rd_namespace=page_namespace) AND (rd_title=page_title)) WHERE rd_from = 54249587` 16. `[0s] MediaWiki\Extension\Disambiguator\Lookup::filterDisambiguationPageIds SELECT pp_page FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'disambiguation'` * Who: RelatedArticles extension. * Why: To decide whether the already decided on "related articles" below the article, should load its CSS/JS module as well. Via `MediaWiki\Extension\Disambiguator\Hooks::isDisambiguationPage` from `RelatedArticles\Hooks::onBeforePageDisplay`. 17. `[0.001s] Wikimedia\Rdbms\Replication\MysqlReplicationReporter::fetchSecondsSinceHeartbeat SELECT … FROM heartbeat.heartbeat WHERE shard = 's8' …` * Who: rdbms. * Why: Preflight for one or more Wikidata queries after this. 18. `[0.011s] Wikibase\Lib\Store\Sql\Terms\DatabaseTermInLangIdsResolver::resolveTermsViaJoin SELECT … FROM wbt_term_in_lang JOIN … WHERE wbtl_type_id = 2 AND wbxl_language = 'en' AND wbit_item_id = 30153087` * Who: Wikidata (WikibaseClient extension) * Why: To create the `<script type="application/ld+json">` metadata element and add it to the end of the HTML output stream for machine readable association between Wikipedia articles and Wikidata.org entities (e.g. for automated clients, bots, and crawlers). Via `Wikibase\Client\ClientHooks::onSkinAfterBottomScripts` hook. 19. `[0.002s] MediaWiki\Revision\RevisionStore::fetchRevisionRowFromConds SELECT … FROM revision … JOIN actor comment comment_rev_comment page ON … LEFT JOIN user ON … WHERE page_namespace = 0 AND page_title = 'Robert_Howard_Hodgkin' ORDER BY rev_timestamp ASC,rev_id ASC LIMIT 1` * Who: Wikidata (WikibaseClient extension) * Why: To compute the `datePublished` property within the `<script type="application/ld+json">` element. Via `RevisionStore::getFirstRevision` as indirectly caleld from the same `Wikibase\Client\ClientHooks::onSkinAfterBottomScripts` hook handler. ## Performance analysis > 4. `SELECT pp_page,pp_propname,pp_value FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'notalk'` > 5. `[0s] MediaWiki\Page\PageProps::getProperties SELECT pp_page,pp_propname,pp_value FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'newsectionlink'` > 6. `[0s] MediaWiki\Page\PageProps::getProperties SELECT pp_page,pp_propname,pp_value FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'archivedtalk'` > * Who: DiscussionTools extension. > * Why: To determine whether this is a talk page, via `isAvailableForTitle()` from `DiscussionTools\PageHooks::onOutputPageBeforeHTML`. At glance one would think that articles can be more cheaply ruled out as a potential talk page by other means before doing a page props query for `notalk`. However, I suspect that this is yet another victim of `wgExtraSignatureNamespaces` and how its thus inheritently expensive for DiscussionTools to determine what a "discussion" page is (ref T336020, T249293, T245890, T249036; for various prior art and trade offs). Looking more closely, one thing that looks odd to me is the inline cache in `DiscussionTools\HooksUtils::hasPagePropCached`. This is caching the result of MediaWiki core's `PageProps->getProperties` service, which already has an inline cache. But above all, if this is specific to page views (i.e. not when viewing action=edit, action=history, or action=info), then you can assume a ParserOutput object, which already has page props in it. Fetching them by page ID should not be needed at all. The PageProps service can't do that, since its contract is bound to the latest revision in the database, not the revision shown. However, perhaps DiscussionTools could make some of this hook decision via the `onOutputPageParserOutput` hook, which runs just before the `onOutputPageBeforeHTML` hook, and has access to the `ParserOutput` object and all its rich metadata. (NOTE) **ACTION (DiscussionTools)**: Consider if checks can work without database queries by using ParserOutput. > 6. `[0.001s] MediaWiki\Page\PageProps::getProperties SELECT pp_page,pp_propname,pp_value FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'templatedata'` > * Who: TemplateData extension. > * Why: To localise template documentation, […] This was introduced Nov 2022 last year as part of T316759 and seems to introduce a mechanism not unlike core's `<mw:editsection>` placeholder. But, because it hooks into OutputPage, this means these placeholders are leak outside the content layer and not taken care of until here in the Skin-level with OutputPage and its browser-facing hooks. In other words, Parsoid and other APIs likely still leak the placeholders through non-standard HTML. A more appropiate hook would be `onParserOutputPostCacheTransform` which happens inside `ParserOutput::getText` just like where `<mw:editsection>` happens. These was introduced in 2017 (T171797). Adopting this would have three major benefits: * Reverts the added database query above in favour of free access via the in-memory ParserOutput object, provided to this hook. * Avoids race conditions where template pages are missing localisation or needlessly running this code when page_props and ParserCache return a different revision ID (e.g. when under load via PoolCounter). * Avoids leaking non-standard HTML to APIs. (NOTE) **ACTION (TemplateData)**: Consider if checks can work without database queries by using ParserOutput. > 12. `[0.001s] LinkBatch::doQuery (for Skin::preloadExistence) SELECT … FROM page WHERE ((page_namespace = 1 AND page_title = 'Robert_Howard_Hodgkin') OR (page_namespace = 2 AND page_title = 'X.X.X.X/sandbox'))` > * Who: Skin. Seems fine as-is. This is batched and heavily optimised to a bare minimum. The Article/Talk button (page actions tabs) and user talk page (personal portlet link) need to have the correct URL (redlink=1), tooltip ("Page doesn't exist") and blue/red coloring as they are highly visible and relevant to editor worklflow and engagement. For speed it doesn't matter much whether we query 1 or 20 titles in a batch, but for what its worth, we did reduce the query size a lot here in the past through {T299099}. > 9. `[0s] MediaWiki\Extension\Disambiguator\Lookup::filterDisambiguationPageIds SELECT page_id,rd_from FROM redirect JOIN page ON ((rd_namespace=page_namespace) AND (rd_title=page_title)) WHERE rd_from = 54249587` > 10. `[0s] MediaWiki\Extension\Disambiguator\Lookup::filterDisambiguationPageIds SELECT pp_page FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'disambiguation'` > * Who: RelatedArticles extension. > * Why: To decide whether to output a "related articles" below the article. Via `MediaWiki\Extension\Disambiguator\Hooks::isDisambiguationPage` from `RelatedArticles\Hooks::onSkinAfterContent`. > 15. `[0.001s] MediaWiki\Extension\Disambiguator\Lookup::filterDisambiguationPageIds SELECT page_id,rd_from FROM redirect JOIN page ON ((rd_namespace=page_namespace) AND (rd_title=page_title)) WHERE rd_from = 54249587` > 16. `[0s] MediaWiki\Extension\Disambiguator\Lookup::filterDisambiguationPageIds SELECT pp_page FROM page_props WHERE pp_page = 54249587 AND pp_propname = 'disambiguation'` > * Who: RelatedArticles extension. > * Why: To decide whether the already decided on "related articles" below the article, should load its CSS/JS module as well. Via `MediaWiki\Extension\Disambiguator\Hooks::isDisambiguationPage` from `RelatedArticles\Hooks::onBeforePageDisplay`. There's a lot to unpack here. First of all, the RelatedArticles extension doesn't actually output anything outside the Minerva skin or MobileFrontend. That fact is realized about three method calls **after** two full database roundtrips through a static check on the skin name. Those checks need to be re-ordered and that will immediately **remove 21% of all databae queries on all page views** in production. (NOTE) **ACTION (RelatedArticles)**: Fix order of operations in `RelatedArticles\Hooks::hasRelatedArticles` to check skins before making database queries. Secondly, the RelatedArticles extension is performing two queries where 1 would suffice. It apparently calls the Disambiguator lookup service with `$includeRedirects = true`. I have no idea why this parameter exists or why it is true by default. There are only 3 calls across production codebases and it not one appears to intentionally follow redirects. This was introduced in the Disambiguator extension in T88305 as an unused parameter for a use case relating to `onGetLinkColours` where links to disambig pages and links to redirects to disambig pages get the same colours. That's fine, except this hook calls the underlying logic direclty and so doesn't even need to expose the `$includeRedirects` paremeter, much less set it to true by default, even less set it to true for the call from the RelatedArticles extension. (NOTE) **ACTION (RelatedArticles)**: Fix `RelatedArticles\Hooks::isDisambiguationPage` to set `$includeRedirects = false` to skip a pointless database query. (NOTE) **ACTION (Disambiguator)**: Consider changing `DisambiguatorLookup` service to remove or change default of the `$includeRedirects` parameter. Thirdly, the RelatedArticles extension is performing the exact same database queries twice on every single page view. Once to decide whether to insert an empty `<div>` element, and then the whole suite of database queries and computations a second time to decide whether to queue a CSS/JS module. (NOTE) **ACTION (RelatedArticles)**: Fix `RelatedArticles\Hooks` to either use a single hook for both purposes, or to let one re-use information from the other. For example, use onBeforePageDisplay to communicate with the Skin in a way that removes the need for a onSkinAfterContent hook, or that leaves information that the onSkinAfterContent can use. Or the other way around, let onBeforePageDisplay send a signal to OutputPage, for example `OutputPage::setProperty` which the onSkinAfterContent hook can and draw its separation concern to only base on that predetermined boolean signal instead of concerning itself with the full computation again from scratch and having to keep them in sync. ## Conclusion The situation in the RelatedArticles extension reminds us that it's important to periodically run your dev environment with `$wgDebugToolbar` and `$wgDebugDumpSql` enabled (see DevelopmentSettings.php for an example). The number of queries on plain MediaWiki core is around 9 by default. Small enough to become familiar with and remember, and more importantly, to stand out if it goes and stays up, for someone in your team to notice. Even if it goes up by only 1, that's a big deal. Given the scale of Wikipedia and our budget, the quota for a feature is generallys **0 database queries** added per (cached) page view. The fact that we have hundreds of extension deployed and yet only 10-15 database queries on page views means this is generally feasible with relatively little effort. It's not about how hard it is, it's about noticing it. The above 19 are exceptional features where there was no other way and a trade-off was made in consultation with SRE, or, where we budgeted for it by saving something else, or where it benefits multiple features through a single query (e.g. batched, or re-usable information), or.... it flew under the radar temporarily... which works if only 1 or 2 extension do so and if we notice and revert or pay back within a few months!
  • T332454: Return HTTP status code 300 for disambiguation pages
    • Task
    **Feature summary** (what you would like to be able to do and where): Per [[https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/300|MDN]], the `300 Multiple Choices` HTTP status code signifies that several pieces of content are available for one request. Disambiguation pages fit directly into this description; the main body content of a "request" in this case would be the title of an article. **Benefits** (why should this be implemented?): Makes responses more semantic and correct.
  • T321407: Disambiguator doesn't recognize redirect to a disambiguation page
    • Task
    **Problem ** When adding a new link on the Wikitext editor, the editor doesn’t notice if the link is to a redirect to a disambiguation page **What happens?**: The editor does NOT warn you that the link you added is a disambiguation page since it's a redirect. **What should have happened instead?**: The editor should warn you that you are adding a link to a disambiguation page. ––––– Thanks to @Danbloch for spotting this – and please feel free to add more information/edit the bug description as you see fit.
  • T315814: Disambiguator has no PHPUnit tests
    • Task
  • T314762: Removing a disambiguation template should mark article as unreviewed
    • Task
    **Feature summary** (what you would like to be able to do and where): Removing a disambiguation template should mark article as unreviewed. > I'm pleased to see that NPP catches [[WP:NPPREDIRECT|redirects converted to articles]]. Does any mechanism cover dabs converted to articles? For example, if I overwrite [[John Smith]] with a badly written bio of my non-notable friend John Smith, is there a system for picking that up? How about name lists such as [[Abdul Hamid]]? @Certes **Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution): **Benefits** (why should this be implemented?): * Close a loophole that undisclosed paid editors could exploit. Examples: ** https://en.wikipedia.org/w/index.php?title=888&diff=1103108865&oldid=1096833961&diffmode=source ** {{diff|Galactica|prev|1103019290|Galactica}} ** {{diff|Galactica|prev|1103050323|twice}} ** {{diff|Scaler|prev|1103067869|Scaler}} **Notes** * Another ticket talks about [[mw:Extension:Disambiguator]] which notes whether a page is a disambiguation page in SQL table `page_props`. Example query to see if a page is a disambiguation page: https://quarry.wmcloud.org/query/66497 * Could also do an edit page hook and look for the removal of something. Perhaps the category "Disambiguation pages" ** The "mark redirect-to-article as unreviewed" code lives in Hooks.php->onRevisionFromEditComplete(). That'd be a good spot for this. * Set index articles are basically a disambiguation page, but are not marked as such in page_props and would have to be detected a different way. Example: https://en.wikipedia.org/wiki/New_York_Proposition_1
  • T187116: In the "Page Settings" menu, "This is a disambiguation page" is not adequately explained to the user
    • Task
    Disambiguation pages are tagged with `__DISAMBIG__` so that they're easier to work with; for example, tagging a page allows the software to easily tell whether a page is a disambiguation page without having to parse the page, and have a consistent API to tell clients this information. Almost always, this tag is put into a disambiguation template, so even the most experienced of editors aren't aware that the tag exists because they never see it and never have to add it. Nevertheless, there is a button in the page settings box in the visual editor to add the tag. There is no tooltip or other explanation given to the user as to why it's there or what it does. There probably should be. {F13710249} Original report: > I'll admit 2 things: > one is that I have never used the magic word to create/tag a disambig page. Interestingly, my colleague from en.wp said the same thing, > The second is that I would have loved to figure out what the option actually did via the (I) icon, but there isn't one there, and I don't even know if you ever planned to have one in the first place. TY!
  • T175084: `DisambiguationPages` not being updated in querycache
    • Task
    On enwiki `DisambiguationPages` in the querycache hasn't been updated since `20130716141819`... Is this right? Shouldn't it have been updated? https://github.com/wikimedia/mediawiki-extensions-Disambiguator/blob/master/specials/SpecialDisambiguationPages.php Or are the rows under `DisambiguationPages` not from Disambiguator the extension? There are 1000 rows in the querycache table... There's thousands more available via https://en.wikipedia.org/w/index.php?title=Special:DisambiguationPages&limit=5000&offset=0 - Are they from the old MW implementation that was stripped out years ago? The page is marked as inexpensive - https://github.com/wikimedia/mediawiki-extensions-Disambiguator/blob/master/specials/SpecialDisambiguationPages.php#L20 which would presumably explain why it's not being cached? Notice when looking at T174513
  • T173528: Add a class to disambiguation pages' body tag
    • Task
    In order to apply special styling to disambiguation pages (in our particular case, we want the TOC flushed right), we need a way to identify them in CSS. Adding a class "mw-disambig-page" to the page's body tag would accomplish that. Thanks.
  • T161349: Provide a structured way to represent disambiguation pages and give API responses
    • Task
    Maybe its own ContentHandler type with its own special kind of editor?
  • T145622: When link suggestions contain a disambiguation page, also show pages linked on that page
    • Task
    When I try to add link to "Note" on de.wikipedia in VE, I get a list of suggestions with titles starting with "Note". The first entry is a disambiguation page. It would be nice to have (some of) the links from that page also in the suggestion list, as it isn't unlikely that I want to link one of these pages. Not all of them start with "Note", so they won't turn up on a normal prefix search.
  • T119644: Add option to exclude disambiguation pages from random/morelike (&others?) results.
    • Task
    For example, presently to show a single non-disambig random article we have to use one of the two following approaches: - add "pageprops" to the random query, run the query, check returned pageprops for "disambiguation" and if found keep re-requesting another random article until we get an article without "disambiguation" pageprop - make the random query fetch multiple random articles, say 5, and check for one without "disambiguation" pageprop, hoping that we didn't get 5 disambiguation articles What would be nice to have is a parameter to exclude disambig pages, so, in the case of random, we could just ask for a single non-disambig random article.
  • T88230: Disambiguator: Only register VisualEditor module if VisualEditor is installed
    • Task
    See T88227. ``` $wgResourceModules['ext.disambiguator.visualEditor'] = array( 'localBasePath' => __DIR__, 'remoteExtPath' => 'Disambiguator', 'scripts' => array( 'visualEditorIntegration.js' ), 'messages' => array( 'visualeditor-dialog-meta-settings-disambiguation-label' ), 'dependencies' => array( 'ext.visualEditor.mwmeta', 'ext.visualEditor.mediawiki' ), 'targets' => array( 'desktop', 'mobile' ) ); ``` ``` 22:00:57 There was 1 error: 22:00:57 22:00:57 1) ResourcesTest::testUnsatisfiableDependencies 22:00:57 Undefined index: ext.visualEditor.mediawiki 22:00:57 22:00:57 /srv/ssd/jenkins-slave/workspace/mwext-Disambiguator-testextension-zend/src/tests/phpunit/structure/ResourcesTest.php:94 22:00:57 /srv/ssd/jenkins-slave/workspace/mwext-Disambiguator-testextension-zend/src/tests/phpunit/MediaWikiTestCase.php:133 22:00:57 22:00:57 -- ```
  • T76198: Disambiguation pages should not be marked as "No citations"
    • Task
    From https://www.mediawiki.org/wiki/Thread:Talk:Page_Curation/Modifying_Page_Info_on_disambiguation_pages: Could the Page Curation toolbar be modified to prevent the "No citations" notice (under "Possible issues") from appearing on any page containing a disambiguation tag?
  • T73012: mw-disambig class should be added in special pages too
    • Task
    Now when I look at e.g. user's contributions, RC, etc. I cannot see disambigs (s)he edited highlighted while I can see it for redirects (I use simple css which changes background of links to disambigs or redirects). -------------------------- **Version**: unspecified **Severity**: normal
  • T53110: Provide a way to exclude certain links to disambiguation pages from [[Special:DisambiguationPageLinks]]
    • Task
    The page [[Special:DisambiguationPageLinks]] (currently) has the item "ASCII → ASCII (disambiguation)" but it is the code {{about|the character encoding}} from [[ASCII]] which (intentionally) creates the link to the disambiguation [[ASCII (disambiguation)]] (and there is no other link to the same page). For maintenance purposes, it would be great to have a way to exclude this kind of links from the special page. Maybe we could have some tag which could be used in the [[Template:about]] as in <validLinkToDisambiguationPage>[[the link]]</validLinkToDisambiguationPage> ? -------------------------- **Version**: unspecified **Severity**: enhancement
  • T41913: Exclude disambiguation pages in article count
    • Task
    **Feature summary** As of April 2025, English Wikipedia has 6,986,487 articles according to `{{NUMBEROFARTICLES}}`. But approximately 366,943 of these — about 5% — are disambiguation pages. Disambiguation pages are not articles. The real number would be 6,619,544. MediaWiki is overestimating the actual number of articles by about 6%. There's going to be huge fanfare soon about the "7 millionth article" -- and, well, yeah. https://www.mediawiki.org/wiki/Manual:Article_count explains the criteria used for "counting" these. Nothing is mentioned in https://meta.wikimedia.org/wiki/Article_counts_revisited which details some of the history of how this value is calculated. **What should have happened instead?**: If a page has the `__DISAMBIG__` magic word, it shouldn't be counted as an article. This feature should be added to [[Extension:Disambiguator]], which handles disambiguation issues.
  • T21184: makes Special:DisambiguationPageLinks output less ambiguous
    • Task
    Is this what you're trying to say? >-'disambiguations-text' => "The following pages link to a '''disambiguation page'''. >+'disambiguations-text' => "The following pages (on the left) link to a '''disambiguation page''' (on the right). (Same for other languages.) But looking at e.g., [[Special:Disambiguations]], we see "(disambiguation)" scattered on both left and right. Personally in LocalSettings.php I instead just avoid the issue, via ``` functionJidanniLessSpecialPages(&$list){ foreach(array('Disambiguations',...)as $i){ unset($list[$i]);} return true;} $wgHooks['SpecialPage_initList'][]='JidanniLessSpecialPages'; ``` -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://en.wikipedia.org/wiki/Special:Disambiguations
  • T18449: Show disambiguations page as such in search results
    • Task
    **Author:** `le.korrigan` **Description:** Currently, the improved Lucene Search on en.wikipedia indicates when results are redirects, or form a section of an another page. I think it would be useful if the results could indicate "(Disambiguation page)" when a page is a disambiguation, for example using the list of relevant templates from [[MediaWiki:Disambiguationspage]]. Thanks. -------------------------- **Version**: master **Severity**: enhancement
  • T11319: Optionally exclude disambiguation pages from Special:Allpages and Special:Prefixindex
    • Task
    **Author:** `lcarsdata` **Description:** It would be useful to have a check box to remove disambiguation pages from [[Special:Allpages]] and [[Special:Prefixindex]].
  • T9936: Distinguish disambiguation pages in [[Special:Allpages]]
    • Task
    **Author:** `dunc_harris` **Description:** I'm not sure this can be done without fixing T8754 first, but... [[special:allpages]] identifies redirect pages from all other pages. Redirects are in <i>italics</i>, whereas other pages are not. I want to split all other pages into article pages and disambiguation pages, so developing the theme, I think it would be good to put disambiguation pages in <b><i>bold italic</b></i>.
  • T9935: Distinguish disambiguation pages in [[special:whatlinkshere]]
    • Task
    **Author:** `dunc_harris` **Description:** I'm not sure this can be done without fixing http://bugzilla.wikipedia.org/show_bug.cgi?id=6754 first, but... [[special:whatlinkshere]] identifies redirect pages from all other pages. I want to split all other pages into article pages and disambiguation pages, so that you end up with summut like this: The following pages link to [[foobar]] * [[FOOBAR]] (redirect page) * [[tree (disambiguation)]] (disambiguation page) * [[turtle]] * etc -------------------------- **Version**: unspecified **Severity**: enhancement
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits