Page MenuHomePhabricator
Search Open Tasks
    • Task
    Traceroute link in checkuser-toollinks is broken. From looking at the site it doesn't seem that the tool still exists so a replacement likely is needed. Alternatively the tool could be removed without re-addition.
    • Task
    The RBLs link in checkuser-toollinks is a broken link. This either needs to be fixed or a replacement site used.
    • Task
    The tool links in checkuser-toollinks and checkuser-userlinks-ip contain(ed) dead links, broken links and links to sites with ads. Community built open source alternatives, such as the ones in use on enwiki at https://en.wikipedia.org/wiki/MediaWiki:Checkuser-toollinks and https://en.wikipedia.org/wiki/MediaWiki:Checkuser-userlinks-ip contain links to enwiki CU approved and mostly community run tools. Some may be WMF specific, but using those which do not require login through OAuth (such as bullseye) will likely improve the usefulness of the tool links for non-WMF wikis.
    • Task
    Currently some messages such as `videojs-quality` and `videojs-more-information` can be translated via translatewiki. Other translations that live in [[https://github.com/wikimedia/mediawiki-extensions-TimedMediaHandler/tree/master/resources/videojs/lang|TimedMediaHandler's resources folder]] are copied from upstream repo. This makes things confusing and difficult for translators. I think all needed messages could be made translatable via translatewiki. This might be similar to how Leaflet messages are handled within Kartographer extension. Or, alternatively, if current approach is really desirable, then this should be documented in mediawiki.org for translators.
    • Task
    The WHOIS/RNDS link used in Special:CheckUser for IPs in 'Get users' and 'Get IP Addresses' is a broken link. The new format is https://www.robtex.com/ip-lookup/<IP> instead of https://www.robtex.com/whois/<IP>.html The tool does not seem broken, so unless objections for the continued use of this tool are raised, I think the link should just be fixed. Alternatively the tool https://whois-referral.toolforge.org/ could be used which is a community run tool without ads.
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Remove revision. * Visit revision in Minerva: https://pl.m.wikipedia.org/w/index.php?title=A&oldid=67400982 https://pl.m.wikipedia.org/w/index.php?title=A&oldid=67300680 **What happens?**: Shows message suggestion page was modified seconds ago. And some user name or ip. **What should have happened instead?**: That green bar don't seem to be useful. Not sure why it is show. When I disable JS correct date is shown. **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**: plwiki {F35274608} Actual change is weeks ago: {F35274610}
    • Task
    The CheckUser extension currently uses the requests IP address as the IP to store the edit under. This is most of the time correct, but for certain actions, such as creating a local account for a SUL user as part of Special:CreateLocalAccount or importing pages and AbuseFilter blocks the request IP isn't necessarily the correct IP to be stored. In these cases the software, and other extensions, should be able to customise / change the IP being stored.
    • Task
    See also non-public https://support.bitergia.com/support/tickets/455 Currently, "About > Contact" in the top bar on https://wikimedia.biterg.io/ links to https://gitlab.com/Bitergia/c/Wikimedia/support (or rather links to https://gitlab.com/users/sign_in when you are not already logged in there). And that soon needs to be changed anyway due to T310900. It's hard to find out currently who in Wikimedia is involved in https://wikimedia.biterg.io/ As https://wikimedia.biterg.io/ is a public instance, that "Support" link is likely only relevant to instance admins. Could that "Support" link target be changed to https://www.mediawiki.org/wiki/Community_metrics#Contact which seems more relevant for us?
    • Task
    **Affected wiki(s)**: en **Diff(s) (if applicable)**: https://en.wikipedia.org/w/index.php?title=Banco_Hipotecario&type=revision&diff=1094876027&oldid=1038697173 **What is happening?**: fails to completely remove `[...]` markup when converting a plain link to a cs1|2 template; fails to replace `{{in lang|...}}` template to `|language=...` parameter **What should happen instead?**: remove both open `[` and close `]` brackets; convert `{{in lang|...}}` template to `|language=...`
    • Task
    I'm doing the following: ``` ssh deployment.eqiad.wmnet cd /srv/deployment/airflow-dags/research scap deploy ``` And getting this error: ``` == DEFAULT == :* an-airflow1002.eqiad.wmnet 10:45:01 ['/usr/bin/scap', 'deploy-local', '-v', '--repo', 'airflow-dags/research', '-g', 'default', 'fetch', '--refresh-config'] (ran as analytics-research@an-airflow1002.eqiad.wmnet) returned [70]: Could not chdir to home directory /nonexistent: No such file or directory Fetch from: http://deploy1002.eqiad.wmnet/airflow-dags/research/.git Running ['git', 'remote', 'set-url', 'origin', 'http://deploy1002.eqiad.wmnet/airflow-dags/research/.git'] with {'cwd': '/srv/deployment/airflow-dags/research-cache/cache', 'stdout': -1, 'stderr': -1, 'universal_newlines': True, 'stdin': -3} Command exited with code 0 Running ['git', 'fetch', '--tags', '--jobs', '2', '--no-recurse-submodules'] with {'cwd': '/srv/deployment/airflow-dags/research-cache/cache', 'stdout': -1, 'stderr': -1, 'universal_newlines': True, 'stdin': -3} Command exited with code 1 Unhandled error: deploy-local failed: <FailedCommand> {'exitcode': 1, 'stdout': '', 'stderr': 'From http://deploy1002.eqiad.wmnet/airflow-dags/research/\n ! [rejected] scap/sync/2022-06-24/0021 -> scap/sync/2022-06-24/0021 (would clobber existing tag)\n * [new tag] scap/sync/2022-06-25/0006 -> scap/sync/2022-06-25/0006\n'} airflow-dags/research: fetch stage(s): 100% (in-flight: 0; ok: 0; fail: 1; left: 0) 10:45:01 1 targets had deploy errors 10:45:01 1 targets failed 10:45:01 1 of 1 default targets failed, exceeding limit ``` Is there a limit on the number of times I can deploy? Because of issues with kerberos and custom airflow instance, I'm resorting to developing/debugging my code via the deploy1002 and airflow1002 servers.
    • Task
    La infraestructura requiere mantenimiento rutinario, se divide en: [] juno [] jupiter [] minerva [] apollo [] mars [] ceres
    • Task
    @Dreamy_Jazz has been doing great work in the CheckUser extension lately, and I think we should give them +2 rights. They're also an admin, checkuser and oversighter on the English Wikipedia. (I think it's great that on-wiki users are contributing and hopefully maintaining the software they use and know best). To quote the Gerrit privilege policy, "+2 is a strong expression of trust, and trust is maintained through good judgement and careful action.". I trust Dreamy Jazz will apply good judgement and caution as applicable, I hope others agree with me. * [[https://gerrit.wikimedia.org/r/q/owner:dreamyjazzwikipedia%2540gmail.com+project:mediawiki/extensions/CheckUser|CheckUser patches]] * [+1s given in all repos](https://gerrit.wikimedia.org/r/q/label:Code-Review%253D%252B1%252Cuser%253Ddreamyjazzwikipedia+-owner:%2522dreamyjazzwikipedia%2522) * [-1s given in all repos](https://gerrit.wikimedia.org/r/q/label:Code-Review%253D-1%252Cuser%253Ddreamyjazzwikipedia+-owner:%2522dreamyjazzwikipedia%2522) * [comments given in all repos](https://gerrit.wikimedia.org/r/q/commentby:%2522dreamyjazzwikipedia%2522+-owner:%2522dreamyjazzwikipedia%2522)
    • Task
    Tanto galahad como ylucero perdieron sus claves de acceso. Si bien pueden acceder mediante la consola de DO, es recomendable hacerlo vía terminal. Requerido de ambos: [x] Clave ssh de galahad [] Clave ssh de ylucero
    • Task
    This script shows embeds on external ID statements such as YouTube videos, Spotify playlists, Twitter tweets, Genius lyrics, and more! This helps you validate the accuracy of external identifiers, provides an interface to explore further document the data present in embeds, and makes editing fun! The script is 100% stable and documented. https://www.wikidata.org/wiki/User:Lectrician1/embeds.js
    • Task
    My Team's Phabricator board, "Design-Systems-Sprint" (see [[ https://phabricator.wikimedia.org/project/view/5859/ | here ]]) , is organized into the following columns: "Committed", "Research", "Ready for Design", "In Design", "Design Review", "Ready for Development", "In Development", "Code Review", "Design Sign-Off", "Functional Testing", "Product Sign-Off", "Pending Release". I would like to be able to query statistics about these columns via the Bitergia dashboards, so as to understand where there are backups or slowdowns, how long issues stay in each column, how many issues are present in each column, etc. If using the Phabricator API, I can do this with: ``` $ echo '{ "queryKey": "open", "constraints": { "projects": [ "PHID-PROJ-7x2jagmev5l5dyco323o" ] }, "attachments": { "columns": "true", "projects": "true" } }' | arc call-conduit --conduit-uri https://phabricator.wikimedia.org/ --conduit-token $CONDUIT_TOKEN -- maniphest.search | jq '.response.data[].attachments.columns.boards."PHID-PROJ-7x2jagmev5l5dyco323o".columns[].name' ``` The result is something like: ``` "Design Sign-Off" "Code Review" "Committed" "Code Review" "Product Sign-Off" "Committed" "Research" "Committed" ... ``` That is to say, call `maniphest.search` specifying `{"attachments": {"columns": "true", "projects": "true"}}`, then retrieve the contents of `attachments.columns.boards`, and finally get the value associated with the key of the project you query, in this case "PHID-PROJ-7x2jagmev5l5dyco323o". Note that these are distinct from "statuses" (which you can get with `maniphest.status.search`, as in ```echo '{}' | arc call-conduit --conduit-uri https://phabricator.wikimedia.org/ --conduit-token $CONDUIT_TOKEN -- maniphest.status.search ``` these are more granular and vary per board. To get the full set of columns for a given project, you can do ``` echo '{ "constraints": { "projects": [ "PHID-PROJ-7x2jagmev5l5dyco323o" ] } }' | arc call-conduit --conduit-uri https://phabricator.wikimedia.org/ --conduit-token $CONDUIT_TOKEN -- project.column.search | jq '.response.data[].fields.name' ``` which yields a result such as : ``` "Functional Testing" "Pending Release" "Product Sign-Off" "Design Sign-Off" "Code Review" "In Development" "Ready for Development" "Design Review" "In Design" "Ready for Design" "Research" "Committed" ``` I have a custom script which queries for these, but I can't current integrate this into the Bitergia dashboard. I would love to have this ability, so as to integrate with other dashboards and visualizations. I'd imagine there are many other projects here that would benefit from this capability! (I should note that I do not see the ability to query `attachments.projects` in the current set of available properties - let me know if this is indeed present somewhere / possible to query!)
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Be an election admin on votewiki (or probably anywhere else with SecurePoll) * Click "Edit" by an editable poll **What happens?**: * The title reads "SecurePoll: Create poll" **What should have happened instead?**: * The title should read "SecurePoll: Edit poll"
    • Task
    From Znuny: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12232287 It seems like the bug is from the erasing - the app still reports objects taking up space. See ticket for video. `Ticket#2022061810006113 — Bug: Logged out with “saved articles” (from Syncing with WikiMedia account) apparently still on device, but app won’t erase them when I tell it to ` `The admittedly-long Subject line completely describes this bug in its entirety. Screen recording of this issue is attached (see below). A note: I’m not trying to delete the saved articles from my account. I synced with it to update its list of Saved articles, then logged out after that was completed, intending to remove the data downloaded during the Syncing operation in order to free up local storage space on my device. (A perfect analog is how Google Photos works.) `
    • Task
    "I was wondering if the same can be done for open tabs and opening new tabs. Sometimes I click on a link and "open in new tab" and it's already among a lot I want to and will read. Could there be an icon on the info pop-ups (when clicking a link) so you can keep track of tabs? "
    • Task
    **Feature summary** When someone posts on my talk page, I currently get TWO pings. Interesting implementation... that might actually be worth a separate ticket. And of course it displays the giant orange bar. Anyway, oftentimes my workflow is I go read the message (which marks the ping read). But then I go to my ping drawer and mark it as unread again so I don't forget to work on it. However marking it unread again brings back the orange bar. 1) Would be nice if marking a once read ping as unread would not bring back the orange bar. 2) Re-visiting the user talk page should not clear all user talk pings. Other ping pages don't work like this, it's unique to user talk. **Use case(s)** **Benefits** Improved ability to use pings as a "todo list". Improved differentiation between a new talk page message and an old talk page message. {F35272516}
    • Task
    **Feature summary** In [[Special:NewPagesFeed]] -> Set filters, suggest placing a green "Reset" button next to the green "Set filters" button. This would reset the filters to default. **Use case(s)** **Benefits** [[Special:NewPagesFeed]] remembers your old settings and sometimes the user just wants to go back to default settings or less customized settings. {F35272450}
    • Task
    As part of on-call this week, I have noticed systemd failures flapping on thanos-fe1001 (from the alerts on #wikimedia-operations). A quick look on Icinga confirms this: ``` Service Critical[2022-06-24 18:06:45] SERVICE ALERT: thanos-fe1001;Check systemd state;CRITICAL;HARD;3;CRITICAL - degraded: The following units failed: swift_dispersion_stats.service Service Critical[2022-06-24 18:04:21] SERVICE ALERT: thanos-fe1001;Check systemd state;CRITICAL;SOFT;2;CRITICAL - degraded: The following units failed: swift_dispersion_stats.service Service Critical[2022-06-24 18:02:01] SERVICE ALERT: thanos-fe1001;Check systemd state;CRITICAL;SOFT;1;CRITICAL - degraded: The following units failed: swift_dispersion_stats.service ``` ``` Service Critical[2022-06-24 17:31:21] SERVICE ALERT: thanos-fe1001;Check systemd state;CRITICAL;SOFT;1;CRITICAL - degraded: The following units failed: swift-account-stats_search:platform.service,swift_dispersion_stats.service ``` The failures seem to recover but I am just sharing this in case it was missed and/or might be a symptom of a larger issue as the systemd status seems to switch from CRITICAL to OK multiple times a day. Please feel free to ignore if this is not useful. Thank you!
    • Task
    **name** and **description** are //required// properties for a strictly valid `composer.json` file. However, many extensions do not include these properties. This makes them unsuitable for managing with Composer when otherwise they would be. (You don't get dependency resolution, version constraint matching, etc. and are forced to declare a 'package' repository for each extension that you want to manage with Composer. [ref](https://stackoverflow.com/questions/12954051/use-php-composer-to-clone-git-repo) **List of steps to reproduce** * Go to any extension directory using your terminal. * type `composer validate` **What happens?**: You get **publish** errors that describe how "name" and "description" are required properties for strict validation. ``` /var/www/html/extensions/CodeMirror# composer validate ./composer.json is valid for simple usage with Composer but has strict errors that make it unable to be published as a package See https://getcomposer.org/doc/04-schema.md for details on the schema # Publish errors - name : The property name is required - description : The property description is required # General warnings - No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license. ``` **What should have happened instead?**: **composer.json is valid** message ``` /var/www/html/extensions/AdminLinks# composer validate ./composer.json is valid, but with a few warnings See https://getcomposer.org/doc/04-schema.md for details on the schema # General warnings - require.composer/installers : unbound version constraints (>=1.0.1) should be avoided ``` **Positive example**: https://github.com/ProfessionalWiki/bootstrap/blob/master/composer.json ``` { "name": "mediawiki/bootstrap", "type": "mediawiki-extension", "description": "Provides the Bootstrap 4 web front-end framework to MediaWiki skins and extensions", "keywords": [ "wiki", "MediaWiki", "extension", "Twitter", "Bootstrap" ], "homepage": "https://www.mediawiki.org/wiki/Extension:Bootstrap", "readme": "README.md", "license": "GPL-3.0-or-later", "authors": [ { "name": "Stephan Gambke", "email": "s7eph4n@protonmail.com", "role": "Developer" }, { "name": "Professional.Wiki", "email": "info@professional.wiki", "homepage": "https://professional.wiki", "role": "Maintainer" } ], "support": { "issues": "https://github.com/cmln/mw-bootstrap/issues", "forum": "https://www.mediawiki.org/wiki/Extension_talk:Bootstrap", "wiki": "https://www.mediawiki.org/wiki/Extension:Bootstrap", "irc": "irc://libera.chat:6667/mediawiki", "source": "https://github.com/cmln/mw-bootstrap", "docs": "https://github.com/cmln/mw-bootstrap/tree/latest/docs", "rss": "https://github.com/cmln/mw-bootstrap/releases.atom" }, "require": { "php": ">=5.6", "composer/installers": "^2|^1.0.1", "mediawiki/scss": "~2.0" }, "require-dev": { "mediawiki/mediawiki-codesniffer": "39.0.0", "mediawiki/mediawiki-phan-config": "0.11.1", "php": ">=7.2" }, "autoload": { "psr-4": { "Bootstrap\\": "src/", "Bootstrap\\Tests\\" : "tests/phpunit/" } }, "scripts": { "test": [ "phpcs -p -s" ], "fix": "phpcbf" }, "extra": { "branch-alias": { "dev-master": "4.x-dev" } } } ``` **other information**: I can find extensions that **are valid** [in MediaWiki code search](https://codesearch.wmcloud.org/extensions/?q=%22name%22%3A&i=nope&files=%5Ecomposer.json%24&excludeFiles=&repos=) but I didn't work out the regex to be able to do a negative lookahead (perl-compatible regex is not supported) to generate a list of all the affected extensions. Additional projects without a 'tag' (there are many more affected extensions, this is just a partial list) # https://github.com/wikimedia/mediawiki-extensions-NoTitle/blob/master/composer.json # https://github.com/wikimedia/mediawiki-extensions-NumberFormat/blob/master/composer.json # https://github.com/wikimedia/mediawiki-extensions-RegexFun/blob/master/composer.json # https://github.com/wikimedia/mediawiki-extensions-UrlGetParameters/blob/master/composer.json **Recommended Fix**: Simply adding **"name":** and **"description":** properties to invalid `composer.json` files will fix the issue. **Important**: Extension names in MediaWiki are (almost?) always CamelCase, while the [name property](https://getcomposer.org/doc/04-schema.md#name) for `composer.json` MUST be lowercase. Simply insert a 'hyphen' (-) character before any capitalized letters in your extension name. If your extension name is `PdfHandler`, the composer name would be`mediawiki/pdf-handler` Example: copy/paste to **add** this to the top of your `composer.json` file, and revise as needed. ``` "name": "mediawiki/my-extension", "type": "mediawiki-extension", "description": "Does something great", "keywords": [ "wiki", "MediaWiki", "extension" ], "homepage": "https://www.mediawiki.org/wiki/Extension:MyExtension", "license": "GPL-3.0-or-later", ```
    • Task
    Three reports came via email that "recent searches" is missing after the latest update (2.7.50406-r-2022-06-14). Two reports were in English, and one was in Japanese. What it looks like: {F35272426}
    • Task
    Pixel caught an unexpected UI change in the languages sidebar: {F35272338} The sidebar heading has changed from languages to "In other language". We are loading modern templates inside the legacy Vector skin and have broken an integration point with ULS.
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Try to use Web2Cit to translate https://revistacontinente.com.br/edicoes/258/lino-arruda **What happens?**: An error is returned, as reported by @GiFontenelle **What should have happened instead?**: A translation should be returned instead This is also happening with #citoid, without Web2Cit.
    • Task
    As suggested by @GiFontenelle consider adding an edit icon next to "Web2Cit" (in "Powered by Zotero & Web2Cit"), maybe between parenthesis, to make it clear that a way to the editor (and not the documentation) will open when clicked. Ideally, we may show some text ("edit"), but that would require internationalization and translation of the user script.
    • Task
    These two classes are used in Vector as of https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/805232 and have similar meanings. While one (vector-sidebar-container-no-toc) is associated with the sidebar, the class .vector-toc is not. We should give this more thought so we understand it a little better. Question: [] IS this a class that belongs on the body tag? If so, how can we do that given table of contents state is not computed until Skin::getTemplateData [] Do they do the same thing or do they serve different purposes? Do these relate to modified versions of components (see http://getbem.com/naming/) or a state for the page? [] If we renamed the classes what would more meaningful classes be? **What happens?**: **What should have happened instead?**: **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
    • Task
    A community member notified us that the Bengali language was completely translated for Wikistats2. We should update production with this new language, and others that might have been translated recently.
    • Task
    My plan for now is to have a feature flag in the codebase for our new talk page feature, so that we can continue to merge new work into `main` but still have bug fix releases before the feature goes out. We can explore moving the flag to a remote config file later if we decide it's needed. We have a Staging version of the app that we used to deploy nightly along with our main build. Let's restore this and have it configured to show the new talk pages. 1. Undo the work done in [[ https://github.com/wikimedia/wikipedia-ios/pull/3925 | this PR ]] to get staging to deploy nightly again. 2. Set up a feature flag property that is true using the staging environment macro (could be something like this): ``` struct FeatureFlags { static var needsNewTalkPage: Bool { #if WMF_STAGING return true #else return false #endif } } ``` 3. Create a new blank view controller subclass that will eventually be the home of our new talk page. 4. Find all branches where talk pages are pushed on (you could look for wherever `TalkPageContainerViewController` is instantiated), check the feature flag and push your new empty view controller if it's true, otherwise push the `TalkPageContainerViewController` as before. To test this: Running the Staging scheme (black icon) in Xcode should show your blank view controller, running the main Wikipedia scheme (white icon) should show the old talk page as before. Every night both the black icon build and white icon build will be pushed, and QA can test against both. **Note:** Staging is set up to point to our [[ https://www.mediawiki.org/wiki/Beta_Cluster#:~:text=The%20Beta%20Cluster%20is%20a,of%20the%20Wikimedia%20test%20wikis. | beta cluster ]], which means the usual production accounts won't work on it. On this Staging scheme the endpoint URLs generated by the app should have the format `https://en.wikipedia.beta.wmflabs.org/w/api.php?action=discussiontoolspageinfo...`. Feel free to [[ https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special:CreateAccount&returnto=Main+Page | create a new account ]] (note the password warning) and log in with that account when testing the Staging app.
    • Task
    Currently `ServiceImageRecommendationProvider::processApiResponseData` iterates over all the image suggestions returned by the API and fetches metadata for each suggestion. Since we're currently only showing a single suggestion, iterating over all the suggestions is excessive. Instead, the function could return once we have a single valid suggestion or have reached the specified number of suggestions (in case we do need to support showing multiple suggestions). For better results, the suggestions should be sorted by confidence.
    • Task
    === Description In T310197 we moved the VE toolbar below the page toolbar. In T309398#8003719 @Esanders pointed out that the border between the toolbar and VE does not match the border below VE. The purpose of this task is to visually refine those borders so that they feel more harmonious with each other. To start off with here are two possibilities: 1) darken the border below the article toolbar to match the border below VE (#c8ccd1) 2) lighten the border below VE to match the border below the article toolbar (#eaecf0) | darken border below article toolbar | lighten border below VE | {F35271976} | {F35271983} in either case we can wait until the VE toolbar switches to `fixed` positioning in order to apply the box-shadow (note: in the videos above the box-shadow is still appearing while VE is loading, but then goes away until the toolbar becomes fixed).
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): On betacommons: ``` action globalpreferences format json change userjs-BawlTackOnEchoGlobal={"1656080881662_0":{"icon":"svgBawlBlackCopyIcon","user":"AJ","link":"","msg":"copy"}} token [redacted] ``` **What happens?**: ``` {"globalpreferences":"success"} [YrXKTcDtZadeuZa146t7CgAAAA0] /w/api.php Wikimedia\Rdbms\DBTransactionSizeError: Transaction spent {time}s in writes, exceeding the 3s limit Backtrace: from /srv/mediawiki/php-master/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1701) #0 /srv/mediawiki/php-master/includes/libs/rdbms/lbfactory/LBFactory.php(320): Wikimedia\Rdbms\LoadBalancer->approvePrimaryChanges(array, string) #1 /srv/mediawiki/php-master/includes/MediaWiki.php(679): Wikimedia\Rdbms\LBFactory->commitPrimaryChanges(string, array) #2 /srv/mediawiki/php-master/includes/api/ApiMain.php(901): MediaWiki::preOutputCommit(DerivativeContext) #3 /srv/mediawiki/php-master/includes/api/ApiMain.php(846): ApiMain->executeActionWithErrorHandling() #4 /srv/mediawiki/php-master/api.php(90): ApiMain->execute() #5 /srv/mediawiki/php-master/api.php(45): wfApiMain() #6 /srv/mediawiki/w/api.php(3): require(string) #7 { ``` **What should have happened instead?**: Just success.
    • Task
    In T309445, we are witnessing some strange behavior where the terms of an item aren’t properly updated after a merge. We want to find out whether the secondary data updates which are supposed to update the terms even take place, by adding some debug logging to `ItemHandler::getSecondaryDataUpdates()` and `ItemTermStoreWriterAdapter::saveTermsOfEntity()`. This should go to a separate channel (like e.g. the `DuplicateParse` channel), which would be configured to capture all debug messages. (By default, only messages at level ≥ info go to logstash.)
    • Task
    === Description See [[ https://phabricator.wikimedia.org/T311305 | parent task ]] for general information. Navigational menus usually consist of two parts: 1) the menu handle/trigger (i.e. the thing you click on to open the menu), 2) the menu links/items (i.e. the things inside of the menu). This task is specifically about //the styling of the menu handle/trigger//. {F35271818} **Native HTML references** The menu handle/trigger is a kind of button. Unfortunately there is no clear default styling for such an element in HTML (HTML provides a `<select>` menu, but no such navigational menu). Two HTML elements that function similarly to menu handle/triggers are: - the [[ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details | summary element ]] which is part of the details tag. This is an element that you click on in order to reveal additional information, much like a menu handle/trigger. - [[ https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input | input element ]], such as a checkbox or radio. These are clickable elements that function more as toggles rather than typical buttons. By default the summary element looks like this: {F35271804 width=90} Presumably the arrow next to the text indicates both that the element is clickable, and that when clicked it will reveal additional information. **Menu handles/triggers in Wikimedia interfaces** Currently there are a few different types of handles/triggers for our navigational menus: | dropdowns | icon button | quiet button | normal button (?) | input | {F35272737} | {F35271825} | {F35271890} | can't find a navigational menu w/ a normal button, but here is a select menu with one {F35271892} | {F35271832} === Challenge I think what's currently implemented in production works well when menu handles/triggers are icon buttons, normal buttons, or inputs. //I think the challenge comes when menu handles/triggers are quiet buttons// (which I think will be the most common case, in addition to icon buttons). Why is this a challenge? Because quiet buttons are styled very similarly to links, and in the case where there is a quiet button as a menu handle/trigger located next to other links, there is visual disharmony between the two very similar, yet slightly differently styled, elements. For example: {F35271904 width=900} For comparison: | {F35271913 width=435} | {F35271916 width=435} === Proposal - If the handle/trigger is a quiet button, the label should always include a `⌄` icon to indicate that it is clickable, and is a menu handle/trigger. - If the handle/trigger is a quiet button the label should be styled as `font-weight: normal` so that it is visually harmonious with surrounding link elements. - In order to achieve this in a systematic way we could either a) decide that all quiet buttons have `font-weight: normal` styling (which I think is a good choice, though recognize it's a bigger decision), or b) create a new component, or a variant of the quiet button component, for menu handle/triggers
    • Task
    === Description There are many navigational menus in the Wikimedia interfaces. Currently the way we style these menus is not consistent. Some of the most prominent navigational menus are: - language switching menu - search menu - user menu - main menu Navigational menus usually consist of two parts: 1) the menu handle/trigger (i.e. the thing you click on to open the menu), 2) the menu links/items (i.e. the things inside of the menu). This is the parent task for evaluating how we style menu handles/triggers, and menu links/items. (Note: select menus are a different type of menu) {F35271727 width=657}
    • Task
    update https://wikitech.wikimedia.org/wiki/Netbox#Puppet woith details of what and how we export data
    • Task
    When you edit a multipart transclusion in the VisualEditor TemplateDialog and delete all parts using the sidebar controls, you will end up with a placeholder page to search and add a new template. All fine with that. The controls in the sidebar behave a bit inconsistent in that situation though: The buttons to move parts up and down are disabled and greyed out. The button to delete a part is hidden. {F35271576} We might want to change that behavior to be more consistent. Also hiding that delete button is implemented in a way that feels a bit odd and could be cleaned-up.
    • Task
    This thread will operate as a place to document progress in creating AuthorBot: A bot that automatically adds and corrects author names (and eventually author pages?) to scientific articles on Wikidata. To see data regarding the most popular scientific databases on Wikidata, go here: https://github.com/feliciss/wasian/blob/main/wasian/wikidata-database-analysis/graphs/ Some graphs of note: {F35271388} {F35271389} {F35271387} {F35271386} Progress on AuthorBot: - [X] **Bot queries scientific articles with missing author information:** -- [X] Articles where P50 items are missing a P9687 or P9688 qualifier -- [X] Articles with no P2093 and P50 items -- **TO ATTEMPT LATER:** --- [] Articles with only P2093 items that //could// have author name strings replaced with authors --- [] Articles with P2093 items that have author initials that could be replaced by full author names (Articles with a PubMed ID good candidates for this) - [] **Bot is able to obtain and parse citations from a variety of academic databases:** -- [] PubMed ID (P698) -- [] PubMed Central ID (P932) -- [] Dimensions Publication ID (P6179) -- [] CJFD Journal ID (P6769) -- [X] ResearchGate ID (P5875) -- [X] ADS Bibcode (P819) -- Bonus Databases: --- [] DBLP Publication ID (P8978) --- [] arXiv ID --- [] OpenCitations Bibliographic Resource ID (P3181) --- [] JSTOR Article ID (P888) - [] **Bot is able to automatically add author names to articles from a variety of academic databases** -- [] PubMed ID (P698) -- [] PubMed Central ID (P932) -- [] Dimensions Publication ID (P6179) -- [] CJFD Journal ID (P6769) -- [X] ResearchGate ID (P5875) -- [X] ADS Bibcode (P819) -- Bonus Databases: --- [] DBLP Publication ID (P8978) --- [] arXiv ID --- [] OpenCitations Bibliographic Resource ID (P3181) --- [] JSTOR Article ID (P888) - [] **Bot is able to automatically detect if an author page exists on Wikidata and add it instead of an author name string to scientific article pages on Wikidata** - [] **Bot is able to automatically create author name pages from author name strings** Some thoughts: - Both PubMed IDs and CJFD IDs should be prioritised due to the sheer volume of articles with said IDs and capacity to parse Chinese names accurately, respectively. -- On this: unsure how to get CJFD IDs without manual parsing. Deal with this later.
    • Task
    For {T222310}, it will be easiest to create a new module ("PositiveReinforcement", or "ImpactV2") and provide a config flag to allow displaying the new module or the existing, non-Vue one. **Acceptance Criteria** # Have a configuration flag to allow for progressive rollout of the new module # Boilerplate PHP code and JavaScript (Vue-based) code #### Completion checklist **Functionality** [] The patches have been code reviewed and merged [] The task passes its acceptance criteria **Engineering** [] There are existing and passing unit/integration tests [] Tests for every involved patch should pass [] Coverage for every involved project should have improved or stayed the same **Design & QA** [] If the task is UX/Design related: it must be reviewed and approved by the UX/Design team [] Must be reviewed and approved by Quality Assurance. **Documentation** [] Related and updated documentation done where necessary - Internal technical changes: internal repository documentation must be updated (README.md, JSDoc, PHPDoc) - Infrastructure technical changes: technical changes that reflect on environment, infrastructure, endpoints or any other area of interest for technical contributors should be reflected on [[ https://www.mediawiki.org/wiki/Extension:GrowthExperiments | Extension:GrowthExperiments ]] or [[ https://www.mediawiki.org/wiki/Extension:GrowthExperiments/Technical_documentation | Extension:GrowthExperiments/Technical documentation ]] pages.
    • Task
    In the best case, if you open a story and let it play from beginning to end, the `story_frames_viewed` field is too small by 1. If you use the frame navigation and close the story from a earlier frame, the `story_frames_viewed` field is off by a lot. Basically, this field uses the currentFrame.index prop so it may have been right before the cover page and frame navigation but now it is wrong. We have to keep track of all the frames that have been viewed.
    • Task
    https://activity.toolforge.org/ loads third-party content from `d3js.org`. https://toolsadmin.wikimedia.org/tools/id/activity says "Outreachy round 15" (and lists @Shreya1771 as maintainer, but they might not be active anymore).
    • Task
    Currently, the visual editor template sidebar uses a highly customized OutlineControlsWidget. We add two buttons and wire in all sorts of new behaviors. Rewrite any behavior that depends on the outlineSelectWidget to decouple from that object. For example, `onOutlineChange` can be replaced by wiring that detects whether the selected sidebar item is a parameter or template-level item, and whether it's first and/or last in the list of top-level items. Then we can delete all of the "movable" / "removable" management to support the old function.
    • Task
    **List of steps to reproduce** * I'm editing a map, e.g. [[ https://de.wikipedia.org/wiki/Wairarapa_Fault | this one ]] * I preview the map. | wikitext | VE | | {F35271233} | {F35271232}| * I hit save **What happens?** * The map has "jumped up" a bit. * The little indicator of the map scale is gone. {F35271244}
    • Task
    I've done a quick test. ==== Keyboard navigation ==== Works reasonably, though we should probably have hotkeys to show/hide the sidebar. When you have a narrow screen, you can no longer tab to the search field as it is hidden. The element to unhide is is an <a> element which in some browsers (macOS) is not focusable by default (only actual buttons are). This is not an issue if users configure their Safari preferences with "Press tab to highlight each item on a page", but this is not the default. Adding role=button tabindex=0 to that element (like for the ToC button) might help here ? ==== VoiceOver ==== * Navigation is broken for the personal tools menu. * The new ToC button is labelless, which isn't good. * The landmarks have a few clear issues to me: 1. When the main menu is collapsed, the whole landmark for the main menu is gone, which makes it pretty hard to rediscover. Especially as it is also not in the header navigation mode. 2. The H1 is wrapped in a banner landmark.. I'm not entirely sure why (ah because its a <header> element) it seems a bit confusing to me (probably should get a label) 3. One of the landmarks is "Tools navigation", which isn't really helping explain WHICH tools. It also seems that the sidebar no longer features headings, which makes it a bit more difficult/slow to navigate the site navigation menu. The headings for Twinkle and Languages (which have not yet been updated to this new missing heading layout) now are before the H1, which is 'bad'.
    • Task
    Have an SSH login message (motd) on Toolforge that checks existence and completeness of a `toolinfo.json` file, nudges maintainers to please create that file, links to https://meta.wikimedia.org/wiki/Toolhub#Publish_a_toolinfo_file_and_register_it_with_Toolhub's_web_crawler and/or https://toolhub.wikimedia.org/add-or-remove-tools?tab=urls , explains why this is useful (finding source code and contribute changes or porting it to newer underlying library versions etc, being able to contact maintainers, being able to report issues that might get seen by maintainers, etc).
    • Task
    The TOR node checker, which was removed in T190542, may need to be replaced with another suitable tool. Some discussion occurred in that task, but as it's based around removal of the tool, I'm creating this parent task to potentially add a new tool.
    • Task
    From the commit message of [807625](https://gerrit.wikimedia.org/r/807625) > * Sort the suggestions based on confidence and timestamp (derived from UUID) — MvpImageRecommendationApiHandler uses the first valid suggestion returned from the API so this patch achieves parity in that regard Sorting based on confidence would be nice to have. We'll have to also deduplicate the entries based on timeuuid when we do the sorting.
    • Task
    Filling this for the future, as I don't plan to work more on this until it has proven to have some usefulness. == Intro == I 've worked a bit on puppetizing[1] and getting `prometheus-ipmi-exporter` functional in our infra. Many thanks to @jbond and #observability for reviews. We already have some [graphs](https://grafana-rw.wikimedia.org/d/f64mmDzMz/power-usage?orgId=1&viewPanel=110) showing Wattage and Amperage per cluster {F35271135} There a number of outstanding issues documented below: == Issues == * The [Debian bullseye package](https://packages.debian.org/bullseye/prometheus-ipmi-exporter) was used as is. This has a number of repercussions. ** Buster and Stretch aren't currently supported. Entire clusters aren't thus supported and we don't have any kind of ipmi data for them ** Packaged version is `1.2`. Built-in support for proper sudoed `ipmi*` command execution was added in `1.4.0`, see [Changelog](https://github.com/prometheus-community/ipmi_exporter/blob/master/CHANGELOG.md). That means that for now we are relying on an already deprecated hack to more securely run the exporter, namely a symlinked sudo wrapper under `/var/lib/prometheus` (see the puppetization for that). We also aren't using the created configuration file as it is not compatible. * [SEL](https://github.com/prometheus-community/ipmi_exporter/blob/master/docs/metrics.md#system-event-log-sel-info) events aren't yet fetched and metrics aren't populated. This is because that "module" of prometheus-ipmi-exporter is disabled by default and we haven't enabled it yet. * No rack/rackrow information is present currently in the metrics * We are using the local mode of the exporter and not the [remote](https://github.com/prometheus-community/ipmi_exporter/blob/master/docs/configuration.md#remote-metrics) one. That means that we only get data for machines `operations/puppet` runs on. That is production and WMCS machines currently, frack isn't included. == Notes == * Debian [sid](https://packages.debian.org/sid/prometheus-ipmi-exporter) has 1.6.1. We could just rebuild it for bullseye/buster/stretch and populate it via `apt.wikimedia.org` to our fleet. * Enabling SEL is a simple config change, but we currently don't use a configuration file at all, even though we ship one (cause the one we ship is compatible with version 1.4.0+) * The exporter supports querying remote IPMI endpoints (configuring username/password etc), so frack could be queryed without requiring much integration (aside from a frequently updated list of hosts). == Possible Future action items == [] Evaluate whether the data is indeed useful and whether keeping the exporter around makes sense. See [Metrics](https://github.com/prometheus-community/ipmi_exporter/blob/master/docs/metrics.md) for a list of metrics [] Depending on the above, evaluate whether backporting the exporter to buster/stretch or just waiting for the clusters to be migrated to bullseye makes more sense. [] Evaluate whether [SEL](https://github.com/prometheus-community/ipmi_exporter/blob/master/docs/metrics.md#system-event-log-sel-info) metrics would be useful and decide whether to add them or not. [] Evaluate whether adding frack to the mix (e.g. via the [remote](https://github.com/prometheus-community/ipmi_exporter/blob/master/docs/configuration.md#remote-metrics) mode of the exporter) makes sense or not [] Figure out how to get more granular data per rack/row. That might involved patching the exporter, changing the configuration of the scraper to apply extra labels, or just joining when querying on some other metric to get the required labels. [1]: https://gerrit.wikimedia.org/r/c/operations/puppet/+/807124 and https://gerrit.wikimedia.org/r/c/operations/puppet/+/807494
    • Task
    Resource usage from Ganeti needs to be collected to do capacity management and alerting. Data must be collected by Prometheus, to allow visualization in Grafana and alerting via AlertManager.
    • Task
    If API client makes a create statement POST request to /entities/items/{item_id}/statements, and `item_id` is an ID of an item that has been merged into another item, API will not create any statement. The API will not try to "pass" the request to the "target" item of the redirected item, etc API should respond with 409 Conflict HTTP response code. Response payload should contain (translatable) text "Item {item_id} has been merged into {other_id}."
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Navigate to https://en.wikisource.org/wiki/Special:LintErrors/html5-misnesting * Try to click table headings **What happens?**: The table headings display without the ability to sort the results displayed. **What should have happened instead?**: Previously it was possible to sort the individual results by selecting the table heading to sort the headings by page title, tag, or template through which the error was transcluded.
    • Task
    **Description/User Story** In the same way projects or tools used in the Wikimedia movement are Identified with a logo, we want to have a logo representing our new visual content format tool called the Wikistories that will be deployed to its first Wikipedia soon. Reasons we need a logo: - For Identity - To draw interest and curiosity amongst our pilot Wiki communities as the community representatives create awareness for the planned campaign. - Attract newcomers (Content curators and consumers) that will use the tool. The Wikistories team will use the ticket to update progress and sample designs for our logo.
    • Task
    [[ https://pixel.wmcloud.org/reports/desktop/index.html | Pixel flagged a UI regression ]] relating to the margin underneath the heading which was caused by moving mw-body-subheader under #bodyContent (https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/807232) {F35269375} Iring on the side of caution we should not change the margin unintentionally. **List of steps to reproduce** (step by step, including full links if applicable): * Set `$wgVectorTitleAboveTabs = false;` **What happens?**: {F35269363} **What should have happened instead?**: **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
    • Task
    `catch` should go on the same line as the preceding `}` from either `try` or an earlier `catch` See https://gerrit.wikimedia.org/r/q/topic:start-catch for manual fixes
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Using Vector-2022, press the [[https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey|accesskey]] for the watchlist ({key Alt Shift L} on Windows or Linux, {key Control Option L} on Mac) while on any page. **What happens?**: The watchlist button gains focus and a blue outline. **What should have happened instead?**: The browser should navigate to the watchlist. **Browser**: Firefox 101.0.1
    • Task
    [] Bump chromedriver from 93.0.1 to 103.0.0 [] Bump core-js from 3.18.0 to 3.23.2 [] Bump @vue/cli-plugin-babel from 4.5.13 to 5.0.6 [] Bump @vue/cli-plugin-router from 4.5.13 to 5.0.6 [] Bump @vue/cli-plugin-eslint from 4.5.13 to 4.5.18 [] Bump lint-staged from 11.2.3 to 13.0.2 [] Bump @vue/cli-plugin-vuex from 4.5.12 to 5.0.6 [] Bump @vue/cli-plugin-unit-jest from 4.5.13 to 5.0.6 [] Bump @vue/cli-plugin-e2e-webdriverio from 4.5.13 to 5.0.6 [] Bump eslint-plugin-vue from 7.18.0 to 9.1.1 [] Bump vue-router from 3.5.2 to 3.5.4 [] Bump axios from 0.21.4 to 0.27.2 [] Bump material-design-icons-iconfont from 6.1.0 to 6.7.0 [] Bump eslint-plugin-import from 2.24.2 to 2.26.0 [] Bump minimist from 1.2.5 to 1.2.6 [] Bump url-parse from 1.5.1 to 1.5.10 [] Bump node-sass from 6.0.1 to 7.0.1 [] Bump node-fetch from 2.6.1 to 2.6.7 [] Bump follow-redirects from 1.13.2 to 1.14.7 [] Bump shelljs from 0.8.4 to 0.8.5 [] Bump tar from 6.1.0 to 6.1.9 [] Bump path-parse from 1.0.6 to 1.0.7 [] Bump tmpl from 1.0.4 to 1.0.5 [] Bump @vue/cli-service from 4.5.12 to 4.5.15 Current plan is that each change should result in a newly deployed image if it touches production code. If it is only a test dependency this is not needed. The developer should check the tests pass, read the release notes and if anything looks "suspicious" test it manually (locally for example). If it does cause a regression a test should be added, the regression resolved and then it should be deployed. If this is tricky a followup ticket should be created to track the work
    • Task
    [] Bump actions/cache from 3.0.2 to 3.0.4 [] Bump actions/setup-node from 3.2.0 to 3.3.0 [] Bump actions/github-script from 5 to 6 Current plan is that each change should result in a newly deployed image if it touches production code. If it is only a test dependency this is not needed. The developer should check the tests pass, read the release notes and if anything looks "suspicious" test it manually (locally for example). If it does cause a regression a test should be added, the regression resolved and then it should be deployed. Review and merge the above PRs. If they look challenging and require additional changes to function then open a new ticket to track the work.
    • Task
    Problem currently the log event happens when the story finish running, with the new feature navigating the story, the log will happen in multiple times Solution Log Event only when user close the viewer or moving to the next story
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * While logged out, go to https://en.wikipedia.org/wiki/Russian_Soviet_Federative_Socialist_Republic?useskin=vector-2022 * Type "Russian Soviet" in the search bar at the top of the page. * See search results, complete with short descriptions. * Repeat the process without the "?useskin..." modifier. **What happens?**: On my screen at least, the short description is truncated at 59 characters in Vector 2022, followed by an ellipsis. Here's what the search looks like in the Vector 2022 skin, desktop version: https://commons.wikimedia.org/wiki/File:SD_search_in_vector_2022_skin.png Here's what the search looks like in the current default skin available to non-logged-in readers, mobile version: https://commons.wikimedia.org/wiki/File:SD_search_in_2022_default_skin.png **What should have happened instead?**: In most skins and apps and browsers, when the short description is shown in the search results, the search results provide at least two lines of text in the short description. This new, and presumably better, skin should show at least two lines of text. **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
    • Task
    Error received : o.w.query.rdf.tool.HttpClientUtils - HTTP request failed: java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Buffering capacity 2097152 exceeded Don't. see an option to increase the buffersize. Running an update with this command: /wdqs/runUpdate.sh -- -v -s 20220401170100 Unable to proceed after this point Some additional info: Running a local copy, its at the point after loading a DUMP file from about 1.5 months ago (it took over 1 month to import) Looking to run the updater now to get all data up to speed and refreshed
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Use the Vector 2022 skin * Have a large number of notifications (see below for a bit of Javascript if that's not already the case) * Set the browser's default font size in the settings to something larger, e.g. very large in Chrome-based browsers or 150% zoom with only the "only text" option selected in Firefox * or, set the interface language to Classical Chinese (some other languages which use their own numeral systems also have the same problem, although less prominently) **What happens?**: The notification icons overlap. **What should have happened instead?**: The notification icons should adjust to the size of the text and not overlap. **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**: A bit of Javascript to make the interface mimic having the maximum number of notifications: ```for (let e of document.querySelectorAll("#pt-notifications-alert a, #pt-notifications-notice a")) { e.dataset.counterText = mw.language.convertNumber("99+"); e.dataset.counterNum = "100"; e.classList.add("mw-echo-notifications-badge-long-label"); e.classList.remove("mw-echo-notifications-badge-all-read"); }``` Chrome-based browser using English and very large font sizes: {F35269158} Chrome-based browser using Classical Chinese and default font sizes: {F35269160} Firefox using English and default font sizes: {F35269176}
    • Task
    The Graph extension uses the old "static function" hook style. It should change to the new style, with an object which can hold the various service objects required for dependency injection.
    • Task
    The API retrieves image suggestions for a given production article ID. For non-production environment, this doesn't work since page ID is different than production so we need the ability to query the suggestions for a given page title. API Documentation: https://www.mediawiki.org/wiki/Platform_Engineering_Team/Data_Value_Stream/Data_Gateway#Image_Suggestions To achieve this with the new API: # Get the production page ID for the current title via title_cache endpoint (This is blocked by {T311220}) # Use the page ID from the previous step to query image suggestions via `/public/image_suggestions/suggestions/{wiki}/{page_id}` For local development, the current workaround is to use SubpageImageRecommendationProvider to mock the API response.
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Follow https://www.mediawiki.org/wiki/MediaWiki-Docker/Extension/Wikibase **What happens?**: The very last step fails. There is an error: > > mediawiki % docker-compose exec mediawiki php extensions/Wikibase/client/maintenance/populateInterwiki.php > PHP Fatal error: Uncaught Error: Call to a member function setDescription() on null in /var/www/html/w/maintenance/includes/Maintenance.php:317 > Stack trace: > #0 /var/www/html/w/extensions/Wikibase/client/maintenance/populateInterwiki.php(37): Maintenance->addDescription('This script wil...') > #1 /var/www/html/w/maintenance/includes/MaintenanceRunner.php(99): Wikibase\PopulateInterwiki->__construct() > #2 /var/www/html/w/maintenance/doMaintenance.php(60): MediaWiki\Maintenance\MaintenanceRunner->init('Wikibase\\Popula...') > #3 /var/www/html/w/extensions/Wikibase/client/maintenance/populateInterwiki.php(165): require_once('/var/www/html/w...') > #4 {main} > thrown in /var/www/html/w/maintenance/includes/Maintenance.php on line 317 **What should have happened instead?**: There should not be an error **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**: Most recent versions from git
    • Task
    ==== Error ==== * mwversion: `1.39.0-wmf.17` * reqId: `54588fb4-828b-428e-8f11-28b36874b7ef` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2022-06-22T20:14:10.000Z',to:'2022-06-23T20:18:18.339Z'))&_a=(query:(query_string:(query:'reqId:%2254588fb4-828b-428e-8f11-28b36874b7ef%22'))) | Find reqId in Logstash ]] ```name=normalized_message [{reqId}] {exception_url} PHP Warning: array_key_exists() expects parameter 2 to be array, float given ``` ```name=exception.trace,lines=10 from /srv/mediawiki/php-1.39.0-wmf.17/extensions/QuickSurveys/includes/SurveyFactory.php(77) #0 [internal function]: MWExceptionHandler::handleError(integer, string, string, integer, array) #1 /srv/mediawiki/php-1.39.0-wmf.17/extensions/QuickSurveys/includes/SurveyFactory.php(77): array_key_exists(string, double) #2 /srv/mediawiki/php-1.39.0-wmf.17/extensions/QuickSurveys/includes/SurveyFactory.php(41): QuickSurveys\SurveyFactory->validateUniqueName(array, array) #3 /srv/mediawiki/php-1.39.0-wmf.17/extensions/QuickSurveys/includes/ServiceWiring.php(29): QuickSurveys\SurveyFactory->parseSurveyConfig(array) #4 /srv/mediawiki/php-1.39.0-wmf.17/vendor/wikimedia/services/src/ServiceContainer.php(447): Wikimedia\Services\ServiceContainer::{closure}(MediaWiki\MediaWikiServices) #5 /srv/mediawiki/php-1.39.0-wmf.17/vendor/wikimedia/services/src/ServiceContainer.php(416): Wikimedia\Services\ServiceContainer->createService(string) #6 /srv/mediawiki/php-1.39.0-wmf.17/includes/MediaWikiServices.php(295): Wikimedia\Services\ServiceContainer->getService(string) #7 /srv/mediawiki/php-1.39.0-wmf.17/extensions/QuickSurveys/includes/Hooks.php(47): MediaWiki\MediaWikiServices->getService(string) #8 /srv/mediawiki/php-1.39.0-wmf.17/includes/HookContainer/HookContainer.php(338): QuickSurveys\Hooks::onBeforePageDisplay(OutputPage, MediaWiki\Skins\Vector\SkinVectorLegacy) #9 /srv/mediawiki/php-1.39.0-wmf.17/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array) #10 /srv/mediawiki/php-1.39.0-wmf.17/includes/HookContainer/HookRunner.php(943): MediaWiki\HookContainer\HookContainer->run(string, array, array) #11 /srv/mediawiki/php-1.39.0-wmf.17/includes/OutputPage.php(2837): MediaWiki\HookContainer\HookRunner->onBeforePageDisplay(OutputPage, MediaWiki\Skins\Vector\SkinVectorLegacy) #12 /srv/mediawiki/php-1.39.0-wmf.17/includes/MediaWiki.php(930): OutputPage->output(boolean) #13 /srv/mediawiki/php-1.39.0-wmf.17/includes/MediaWiki.php(943): MediaWiki::{closure}() #14 /srv/mediawiki/php-1.39.0-wmf.17/includes/MediaWiki.php(570): MediaWiki->main() #15 /srv/mediawiki/php-1.39.0-wmf.17/index.php(50): MediaWiki->run() #16 /srv/mediawiki/php-1.39.0-wmf.17/index.php(46): wfIndexMain() #17 /srv/mediawiki/w/index.php(3): require(string) #18 {main} ``` ==== Impact ==== ==== Notes ==== * Happened when we tried to roll out https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/808045
    • Task
    === Description See [[ https://phabricator.wikimedia.org/T311305 | parent task ]] for general information. Navigational menus usually consist of two parts: 1) the menu handle/trigger (i.e. the thing you click on to open the menu), 2) the menu links/items (i.e. the things inside of the menu). This task is specifically about //the styling of the menu links/items//. The links/items inside navigational menus are links (both from a user experience perspective, and from a technical perspective). Currently these links/items are sometimes styled in black, and sometimes styled in blue. For example: | blue menu links/items | black menu links/items | {F35269020} language menu | {F35269023} user menu | {F35269024} main menu | {F35269025} search menu === Proposal We should style navigational menu links/items as we style other links: in blue. The reasons are: - this sets clearer expectations for people using navigational menus - in the case of a navigational menu with headings it makes the links/items easier to distinguish from the headings - this simplified our interfaces from a design and code perspective by reducing the styling of links to one styling - this allows easier scanning of navigational menus in cases where the links/items have subtext (like the descriptions in the search menu) - this is aesthetically more aligned with our minimalist approach (i.e. less CSS) Prototype: https://di-visual-design-menus.web.app/Zebra (using the options panel in the bottom left corner you can toggle between option 1, which styles the navigational menu links/items in blue, and option 2, which styles them in black) === Examples Examples of different types of navigational menus, with the links/items styled in blue: | simple | with headings | with icons | with descriptions | with search input | {F35271640} | {F35271642} | {F35271645} | {F35271647} | {F35271651}
    • Task
    We should enable DiscussionTools visual enhancements on the beta cluster as a beta feature, to allow testing it ahead of the production deployments (T310960, T302547).
    • Task
    This task tracks migrating the *WebUIActionsTracking instruments to use the Metrics Platform. === TODO [] Implement parallel versions of the instruments using the Metrics Platform ** See https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/799353 === QA Steps
    • Task
    ===Background Currently, all input elements in Codex inherit an absolute height of 32px from their parent `cdx-text-input`. {F35262967} Using absolute units in this context becomes problematic, since they prevent the components from adjusting when the font size of the browser is increased (e.g. to "Very large" in Chrome, to "24" in Safari – which are default options provided by said browsers). The inputs become too narrow and, in the case of Safari, hardly usable. | TahS in Chrome's "Very large" font configuration | TahS in Safari's 24px font configuration| | {F35262972} | {F35262977}| ===Goal Inputs should scale to display correct proportions and proper spacing around their values. A good example of this would be the current vector 2022/WVUI TypeaheadSearch component: {F35262996} ===Considerations We might want to still specify 32px as a `min-height` instead. This way, inputs will be correctly resized thanks to the increase of their relative line height. Specifying a `min-height` will also ensure that Codex components maintain this base system size in contexts where font size is reduced (e.g. Monobook skin). ===ACs [] The height of Codex input components increases proportionally with font size
    • Task
    We're on jupyterhub 1.1.3 though 1.2 is out. Doesn't look like there are any breaking changes (https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/main/CHANGELOG.md) let's upgrade.
    • Task
    Codex's [[ https://gerrit.wikimedia.org/r/plugins/gitiles/design/codex/+/refs/heads/main/packages/codex/src/components/typeahead-search/TypeaheadSearch.vue#724 | TahS' footer ]] currently consumes the variable `@font-size-search-result-title`, which causes its font-size to be larger than that of MenuItems (it translates to around 18.2px instead of 16px in the demo site). {F35268773} This should be corrected: the footer should display a font-size that's consistent with that of the rest of the menu options.
    • Task
    SSH on cp5012.mgmt has a socket timeout and this has been happening for more than a week. I promised Willy I will file a task but I forgot so here's my attempt at fixing that! ``` #wikimedia-operations.log:13:10 <+icinga-wm> PROBLEM - SSH on cp5012.mgmt is CRITICAL: CRITICAL - Socket timeout after 10 seconds https://wikitech.wikimedia.org/wiki/Dc-operations/Hardware_Troubleshooting_Runbook ``` This is just on cp5012 in eqsin as far as I can tell. No other issues on the host, at least not on the non-mgmt side.
    • Task
    During the namenode outage a few weeks ago, and also during a failed namenode failover today, gobblin seems to have lost data without erroring about it. ``` hdfs dfs -ls /wmf/data/raw/eventlogging_legacy/eventlogging_ContentTranslationCTA/year=2022/month=06/day=23/hour=12/ Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8 Found 3 items -rw-r----- 3 analytics analytics-privatedata-users 0 2022-06-23 13:12 /wmf/data/raw/eventlogging_legacy/eventlogging_ContentTranslationCTA/year=2022/month=06/day=23/hour=12/_IMPORTED -rw-r----- 3 analytics analytics-privatedata-users 23154 2022-06-23 12:11 /wmf/data/raw/eventlogging_legacy/eventlogging_ContentTranslationCTA/year=2022/month=06/day=23/hour=12/part.task_eventlogging_legacy_1655986216453_179_1.txt.gz -rw-r----- 3 analytics analytics-privatedata-users 0 2022-06-23 13:31 /wmf/data/raw/eventlogging_legacy/eventlogging_ContentTranslationCTA/year=2022/month=06/day=23/hour=12/part.task_eventlogging_legacy_1655989815701_0_0.txt.gz\ ``` The file written by the Gobblin job that was launched at 13:10 wrote a 0 length .gz file. This 0 length .gz file is causing Unexpected end of input stream errors when Refine tries to decompress and ingest this file. This time around the failures arein 2022-06-23 hours 12 and 13 for the following legacy eventlogging topics: ``` # 'analytics' eventlogging_MobileWikiAppInstallReferrer eventlogging_MobileWikiAppWatchlist eventlogging_ContentTranslationCTA eventlogging_CentralAuth eventlogging_MobileWikiAppEdit eventlogging_ContentTranslationSuggestion # 'legacy' (migrated to Event Platform) eventlogging_ReferencePreviewsBaseline eventlogging_HelpPanel eventlogging_SuggestedTagsAction ``` Once we fix the gobblin data, the proper re-refine commands will be: ``` sudo -u analytics kerberos-run-command analytics refine_eventlogging_analytics --ignore_failure_flag=true --table_include_regex='mobilewikiappedit|contenttranslationsuggestion|centralauth|mobilewikiappinstallreferrer|contenttranslationcta|contenttranslationsuggestion|mobilewikiappwatchlist|centralauth' --since='2022-06-22T12:00:00.000Z' --until='2022-06-23T15:00:00.000Z' sudo -u analytics kerberos-run-command analytics refine_eventlogging_legacy --ignore_failure_flag=true --table_include_regex='helppanel|referencepreviewsbaseline|suggestedtagsaction' --since='2022-06-22T12:00:00.000Z' --until='2022-06-23T15:00:00.000Z' ``` Investigation into why gobblin failed and how to restore the data will go below in comments.
    • Task
    Found a couple of swift hosts (thanos-fe1001, ms-be2012) with failed prometheus-ipmi-exporter services today. looks like a race with swift-proxy which eventually binds 9290 as a source port. ```Jun 23 15:59:08 ms-fe2012 prometheus-ipmi-exporter[971859]: time="2022-06-23T15:59:08Z" level=fatal msg="listen tcp :9290: bind: address already in use" source="main.go:150" ``` ``` ms-fe2012:~# lsof -i | grep 9290 swift-pro 866 swift 66u IPv4 1836545862 0t0 TCP ms-fe2012.codfw.wmnet:9290->ms-fe2009.codfw.wmnet:11211 (ESTABLISHED) ```
    • Task
    === User Story Deploy the [[ https://meta.wikimedia.org/wiki/Community_Safety | Community Safety Survey ]] (Wave 2) to EN, ES, FA, FR, and PT wikis - estimated June 24th, 2022. === Notes - beta can be tested at higher coverage rates to ease QA (even at 1.0 coverage) - past experience shows that the coverage setting works well on the wikis. - This iteration of the survey will be testing whether T303740 works (pick up edit bucket count on impression - if we manage to get the edit bucket then we can resolve T303740 :)) === Design specs - T294363 - this ticket made the Quick Surveys end of survey message more tailored (nice!); however, **I would err on the side of caution and use the default message** (as we’d have to input the translations and test which could cause delays [but if someone really really wants to work on it, then I’m happy to provide the translations I have]). === Technical information - The survey should run on each wiki for a minimum of 1 week (7 days). After 1 week, each wiki's survey can safely be undeployed if the amount of responses has surpassed 450. EN.WIKI ``` 'enwiki' =>[ // T311079 'name' => 'internal-gdi-safety-survey-wave2', 'type' => 'internal', 'layout' => 'single-answer', 'question' => 'ext-quicksurveys-internal-gdi-safety-survey-question', 'privacyPolicy' => 'ext-quicksurveys-internal-gdi-safety-survey-privacy-policy', 'answers' => [ 'ext-quicksurveys-internal-gdi-safety-survey-answer-positive', 'ext-quicksurveys-internal-gdi-safety-survey-answer-negative', 'ext-quicksurveys-internal-gdi-safety-survey-answer-neutral', ], 'audience' => [ // T311079 'minEdits' => 5 ], 'enabled' => true, 'coverage' => 0.03, // T311079 'platforms' => [ 'desktop' => [ 'stable' ], 'mobile' => [ 'stable', 'beta' ], ], ], ``` – ES.WIKI ``` 'eswiki' =>[ // T311079 'name' => 'internal-gdi-safety-survey-wave2', 'type' => 'internal', 'layout' => 'single-answer', 'question' => 'ext-quicksurveys-internal-gdi-safety-survey-question', 'privacyPolicy' => 'ext-quicksurveys-internal-gdi-safety-survey-privacy-policy', 'answers' => [ 'ext-quicksurveys-internal-gdi-safety-survey-answer-positive', 'ext-quicksurveys-internal-gdi-safety-survey-answer-negative', 'ext-quicksurveys-internal-gdi-safety-survey-answer-neutral', ], 'audience' => [ // T311079 'minEdits' => 5 ], 'enabled' => true, 'coverage' => 0.1, // T311079 'platforms' => [ 'desktop' => [ 'stable' ], 'mobile' => [ 'stable', 'beta' ], ], ], ``` – FR.WIKI ``` 'frwiki' =>[ // T311079 'name' => 'internal-gdi-safety-survey-wave2', 'type' => 'internal', 'layout' => 'single-answer', 'question' => 'ext-quicksurveys-internal-gdi-safety-survey-question', 'privacyPolicy' => 'ext-quicksurveys-internal-gdi-safety-survey-privacy-policy', 'answers' => [ 'ext-quicksurveys-internal-gdi-safety-survey-answer-positive', 'ext-quicksurveys-internal-gdi-safety-survey-answer-negative', 'ext-quicksurveys-internal-gdi-safety-survey-answer-neutral', ], 'audience' => [ // T311079 'minEdits' => 5 ], 'enabled' => true, 'coverage' => 0.1, // T311079 'platforms' => [ 'desktop' => [ 'stable' ], 'mobile' => [ 'stable', 'beta' ], ], ], ``` – PT.WIKI ``` 'ptwiki' =>[ // T311079 'name' => 'internal-gdi-safety-survey-wave2', 'type' => 'internal', 'layout' => 'single-answer', 'question' => 'ext-quicksurveys-internal-gdi-safety-survey-question', 'privacyPolicy' => 'ext-quicksurveys-internal-gdi-safety-survey-privacy-policy', 'answers' => [ 'ext-quicksurveys-internal-gdi-safety-survey-answer-positive', 'ext-quicksurveys-internal-gdi-safety-survey-answer-negative', 'ext-quicksurveys-internal-gdi-safety-survey-answer-neutral', ], 'audience' => [ // T311079 'minEdits' => 5 ], 'enabled' => true, 'coverage' => 0.2, // T311079 'platforms' => [ 'desktop' => [ 'stable' ], 'mobile' => [ 'stable', 'beta' ], ], ], ``` – FA.WIKI ``` 'fawiki' =>[ // T311079 'name' => 'internal-gdi-safety-survey-wave2', 'type' => 'internal', 'layout' => 'single-answer', 'question' => 'ext-quicksurveys-internal-gdi-safety-survey-question', 'privacyPolicy' => 'ext-quicksurveys-internal-gdi-safety-survey-privacy-policy', 'answers' => [ 'ext-quicksurveys-internal-gdi-safety-survey-answer-positive', 'ext-quicksurveys-internal-gdi-safety-survey-answer-negative', 'ext-quicksurveys-internal-gdi-safety-survey-answer-neutral', ], 'audience' => [ // T311079 'minEdits' => 5 ], 'enabled' => true, 'coverage' => 0.2, // T311079 'platforms' => [ 'desktop' => [ 'stable' ], 'mobile' => [ 'stable', 'beta' ], ], ], ``` **Confirming coverage** EN: 0.03 (3%) ES: 0.1 (10%) FR: 0.1 (10%) PT: 0.2 (20%) FA: 0.2 (20%) All wikis should target logged in editors with a minimum of 5 edits. === Testing and QA steps - Open to TST for QA input (likely confirm on beta first, as well as confirming edit count bucket upon impression is working?) === Acceptance Criteria [] Survey is deployed on enwiki, eswiki, fawiki, frwiki and ptwiki, estimated June 24th, to run for a minimum of 7 days.
    • Task
    For the purpose of this task we’re going to focus on //Special:Preferences/User Profile// but those specs also apply to the remaining settings. The suggested changes follow after the completion of {T310897}. # State of the art 1 - Open https://en.wikipedia.org/wiki/Special:Preferences on a mobile device or emulator {F35271158} # Desired design We are moving away from tabs, in favor of modals. For more details, or to better understand what happens when settings move into a modal please refer to {T310272}. **Full image (PDF) detailing changes and specifications https://commons.wikimedia.org/wiki/File:Desing-specs-mobile-web-preferences.pdf. ** Summary of changes: A - Section titles get a border bottom for stronger separation B - Labels loose the colon “:” at the end C - Buttons become links D - Links stay as links E - Information (non-interactive) texts are set to grey F - Helper texts move into the modal G - Options are separated by a grey line H - Sections are more distant from each other I - Descriptions move into the modal J - Dropdown options move into the modal and the selected option is displayed as a link K - In-page options move into a modal L - Single checkboxes turn into toggle switch M - Input fields content become a link and inputs move into the modal ## Detailed suggestions ### A - Section titles get a border bottom for stronger separation In order to enable editors to easily scan the content of a page a solid black border will signify the beginning of each settings section. {F35271192} ### B - Labels loose the colon “:” at the end The colon is needed as a separator when the content is displayed on the same line. In this instance, we're going to rely on the line break to create a clear distinction between the label and the call to action (or text) below. {F35271193} ### C - Buttons become links In order to simplify the visual design of the page, all call to actions will share the same visual style. If we would use buttons for some instance, and links for some other, the instances set as buttons will be visually prioritized. While with this approach all instances share the same priority. {F35271198} ### D - Links stay as links As above. {F35271199} ### E - Information (non-internactive) texts are set to grey For content and is non-interactive, and only informational, we can de-prioritize it by setting the text color to grey. {F35271194} ### F - Helper texts move into the modal In order to reduce the amount of content (and noise) on the page we will move helper texts into the specific settings modal. In this way we will display at first only the necessary information to enable editors to make a decision ("Is this the setting that am I looking for?") and only then we will display additional information (in this case the helper text) in order to enable them to make a conscious and informed decision. Moreover by reducing the amount of content displayed upfront we will reduce the height of the page, hence reducing the scroll necessary to scan the content of the page. {F35271204} ### G - Options are separated by a grey line To emphasize the distinction between an option and another we will add a grey separator line. These separators, together with the section separators, will give a stronger structure to the content of the page, hence improving the scannability of the content. {F35271215} ### H - Sections are more distant from each other To improve the scannability, and to enable editors to quickly scroll the page, and find the section that they need, we will increase the space between each main section. {F35271220} ### I - Descriptions move into the modal Same rationale as helper texts, point F above. {F35271227} ### J - Dropdown options move into the modal and the selected option is displayed as a link Same rationale as point C and F. {F35271236} ### K - In-page options move into a modal Same reason as above, see point F, {F35271238} ### L - Single checkboxes turn into toggle switch For ON/OFF (or binary) options we will opt for a commonly used mobile component, the toggle switch. This will also support the suggested (auto) saving mechanism proposed in {T310344}. {F35271252} ### M - Input fields content become a link and inputs move into the modal Same rationale as point C and F. {F35271241}
    • Task
    === Background With all the new cases for the TOC added under T306660, the styles for the TOC have gotten even more complex. This is exacerbated by the no-js approach taken in T307900, which reuses and overrides the existing TOC element and it's styles, greatly increasing the chance for regressions across variations in viewport, user selected TOC collapsed state, and sticky header state. Visual regression teset will help us maintain these different cases. === AC [] Add cases for when the collapsed TOC is open in the page title on all viewports (including larger viewports where the "hide" button is clicked first) [] Add cases for when the collapsed TOC is open in the page title with the sidebar open on all viewports [] Add case for when the collapsed TOC is open in the sticky header [] Update tags on relevant cases to include a "collapsed toc" tag for easier searching
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Create a wikistory * Select an image * On the screen to add text, replace any image and check the image license information **What happens?**: The attribution information shown belongs to the previous image. **What should have happened instead?**: The attribution information should have been updated to that of the new image used. **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**: Observed on local and on Beta. | {F35268286} | {F35268287} |
    • Task
    In the Calendar widget in Campaign Events, when clicking on a date that is in the following month (example, it is the June monthly calendar, but clicking on July 1 at the end of the month), the calendar will incorrectly select one extra month in advance. For example, clicking on July 1st in the June calendar, will currently select August 1st instead. see attached video: {F35268280} I am not sure where to put this ticket - @Mooeypoo recommended OOUI. notes from @matmarex: in mw.widgets.datetime.CalendarWidget.prototype.onDayClick, calling setFocusedDate "advances" the calendar by a month and the next call to setSelected uses the wrong month because of that
    • Task
    Currently, when there are misses or errors in the GitHub actions caching infrastructure, build assets aren't properly created, which causes the whole [test-and-demo](https://github.com/wmde/wikit/blob/master/.github/workflows/test-and-demo.yaml) workflow to fail. This can be potentially mitigated by conditionally running the "install" and "build" commands in each job in the workflow whenever there is a cache miss, which will make the workflow more resilient to failures. Acceptance Criteria: - [ ] Jobs in `test-and-demo` do not fail the process on cache misses / errors
    • Task
    Hi! I use following MW: MediaWiki 1.38.1 PHP 7.3.32 (cgi-fcgi) MySQL 5.7.34 I would suggest to the development team to improve the outlay of Mobile version of new Vector 2022 skin. I have svg logo uploaded and as you can see that the search button is very close to the logo (Google Chrome from iPhone 11): {F35268275} I would line the buttons with margins as it shown like on the image below: {F35268277}
    • Task
    Currently, the GitHub actions [test-and-demo](https://github.com/wmde/wikit/blob/master/.github/workflows/test-and-demo.yaml) workflow, utilizes artifact caching to cache build assets and speed up the build process. However, there seems to be an issue with generating the cache key, since it always evaluates to "Linux-". This problem results in us never really caching the actual build artifacts, and potentially slowing CI down. Acceptance Criteria: - [ ] Cache key is calculated correctly so that build artifacts are cached - [ ] Built assets are restored in each step where necessary
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): In 2020, I started to use the address list generator [[ https://wikilovesdownloads.toolforge.org/ | WikiLovesDownloads ]] which, entering a category of data used in Wikimedia, would collect their addresses to download them. As I remember (March 2021), a .zip archive was provided containing one or multiple .txt files with the urls suitable for download e.g., with wget2. By today, the service on https://wikilovesdownloads.toolforge.org/ still shows up with varying background images around the input mask. After less than 10 seconds, however, an additional page is shown (https://wikilovesdownloads.toolforge.org/src/initial.php) which is blank and stays blank regardless of the input provided earlier. The example input suggested to get familiar with the tool (category «Birds at Weltvogelpark Walsrode») and selecting 2 lists to write (in case there were many illustrations) does not work, nor the category «Category:Steinerne Linsen, Guttaring», «Steinerne Linsen, Guttaring», or «Steinerne_Linsen,_Guttaring» (all input without the guillemets). There is no progress monitor, nor visible advancement though there are no javascript blockers in the web browser (Firefox) used (separate user account in Linux Xubuntu). Questions: + is this hindered because there is a temporary problem (e.g., move of infrastructure the typical user isn't exposed)? + is the address list generator still maintained (the GitHub project https://github.com/wmde/WikiLovesDownloads does not feature an option to file for an issue report) + if no longer in service, may you recommend a tool to collect the download addresses for data from Wikimedia based on their assigned category? Preference were given to Python3 and bash for Linux Xubuntu/Linux Debian. **What happens?**: **What should have happened instead?**: **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**:
    • Task
    At least the `apiserver_request_latencies_summary` metric has been turned off with k8s 1.17. We should take the chance to revisit the need for the recording rules in modules/profile/files/prometheus/rules_k8s.yml and migrate the `monitoring::check_prometheus` alerts from `profile::kubernetes::master` to prometheus alerting rules.
    • Task
    **List of steps to reproduce** (step by step, including full links if applicable): * Go to www.wikipedia.org * Open browser's dev tools to observe network requests * Use the search language dropdown menu to choose a language other than English * Search for something **What happens?**: The search URL contains duplicate 'language' parameters. For example, selecting 'de' and searching for 'ipad', I observe a request to this URL: https://www.wikipedia.org/search-redirect.php?family=Wikipedia&language=en&search=ipad&language=de&go=Go **What should have happened instead?**: This currently works as intended because PHP parameter parsing lets the lattermost occurrence 'win', but this behavior is not well-defined and may break in the future. In the future we may sort query parameters lexicographically in the edge cache layer which could cause this to break.
    • Task
    Create a beta feature to control the inclusion on stories on article pages Title: Wikistories Text: A tool that lets you select images & highlight facts from an article to create short, visual, and reliable knowledge from Wikipedia for quick consumption. Enable it to do the following: - Discover stories attached to an article. - Click/Tap on the [+] icon below the article title to create a new story. Images: {F35271669} {F35271670} Info link: https://www.mediawiki.org/wiki/Wikistories Discussion link: https://www.mediawiki.org/wiki/Talk:Wikistories
    • Task
    T310408 identified an issue in the TextInput component (and, therefore, TypeaheadSearch) where the icons were 1px off from being centered within the input padding because we were positioning the icons relative to the inside of the input, rather than the outside of the input's border, which is where they actually get positioned from. This was fixed for TextInput in [[ https://gerrit.wikimedia.org/r/c/design/codex/+/806277/ | this patch ]]. We should review the other components that use this mixin to see if this issue exists elsewhere. If so, we could either: - Do what we did for TextInput and account for the border's width in the component implementing the mixin - Account for the border width in the mixin itself, allowing components to pass in the border width (since it might vary)
    • Task
    ==== Error ==== * mwversion: `1.39.0-wmf.17` * [[ https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-mediawiki-2022.06.23?id=KloXkYEBWxwKN7UdW39r | Find reqId in Logstash ]] ```name=normalized_message Elastica\Exception\Bulk\ResponseException","message":"Error in one or more bulk request actions: update: /commonswiki_file_1647920262/_doc/91579864 caused [commonswiki_file_1647920262][11] primary shard is not active Timeout: [1ms], request: [BulkShardRequest [[commonswiki_file_1647920262][11]] containing [update {[commonswiki_file][_doc][91579864], doc_as_upsert[false], script[Script{type=inline, lang="super_detect_noop", idOrCode="super_detect_noop", options={}, params={_index=, _retry_on_conflict=5, handlers={incoming_links=within 20%, version=documentVersion, descriptions=equals, labels=equals}, _type=, _id=91579864, source=... ``` ==== Notes ==== * Notice these are happening with more frequency since 2022-05-31 * https://logstash.wikimedia.org/goto/aae684f9c54a8562715933f9415db40a * related to T306168 as the messages are hard to parse and find in Logstash
    • Task
    Name of the project tag: Product-Infrastructure-Orphaned Type of project: Component Description (read the best practices and include a sentence understandable to the public and without "This project is for tracking work related to..." noise, plus a link to further information!): Component to keep track of tickets related to projects that product infrastructure used to maintain but now don't have clear ownership. Canonical code repository URL of the project (if this project has a code base): No codebase View policy of the project itself: Public (default)
    • Task
    Getting started with Codex development already requires learning skills that aren't required for MediaWiki development, or at least haven't been required in the past (TypeScript, Vue 3/composition API, etc.). We should consider how we can lower the burden for new contributors. One requirement we could drop is the requirement of building component demos in VitePress. VitePress is not widely used and our setup is mostly custom, so it requires some explanation and will be new to all new contributors. Instead, we could allow demos to be created in separate tasks, and suggest that developers use the sandbox that comes with Vite in the Codex package. This would require: - Updating the contributing code docs to remove the requirement of VitePress demos and, instead, state that they can either be created during component development or separately by another developer. - Clean up the sandbox, which is getting to be disorganized and unwieldy since it is a single file containing all components (see T311243) --- ### Acceptance criteria - [] Discuss with the team if we want to pursue this solution and what it would mean for our processes - [] If we decide to pursue it, update the docs accordingly
    • Task
    One of the ways developers can work on components locally is within the sandbox provided by Vite. This simple local dev environment is fast and no-frills, meaning component development can be done quickly and in an isolated environment (i.e. there are no styles potentially polluting the components, like in VitePress). However, the sandbox could use some work: - It's a single file containing all components, which is becoming unwieldy and disorganized - It's being used to demo components in MediaWiki in the [[ https://gitlab.wikimedia.org/egardner/mediawiki-extensions-vuetest/-/blob/main/resources/components/App.vue | VueTest extension ]] (it was manually copied there, but we might automate this in the future), which means the only thing being tested in a MediaWiki context is what we put in the Sandbox. We may want to consider what kinds of test cases should be included in the Sandbox to lead to adequate testing in MediaWiki. - In general, there are no standards as far as whether a component must be included in the Sandbox, how it should be included, and how many examples should be included --- ### Acceptance criteria - [] Decide on and document standards for the sandbox during component development. These should be as lightweight as possible, and adding a full suite of test cases (if that's what we want) could happen in a subsequent task done by another developer, to ease the burden on the main developer - [] Clean up and organize the sandbox according to those standards Future work: automate pulling the sandbox contents into Special:VueTest so it's kept up to date
    • Task
    ==== Error ==== * mwversion: `1.39.0-wmf.16` * reqId: `4c3beabd-c57d-422c-8e48-507d745fd770` * [[ https://logstash.wikimedia.org/app/dashboards#/view/AXFV7JE83bOlOASGccsT?_g=(time:(from:'2022-06-22T14:48:36.000Z',to:'2022-06-23T15:11:10.467Z'))&_a=(query:(query_string:(query:'reqId:%224c3beabd-c57d-422c-8e48-507d745fd770%22'))) | Find reqId in Logstash ]] ```name=normalized_message [{reqId}] {exception_url} TypeError: Return value of Kartographer\ApiQueryMapData::getParserOutput() must be an instance of ParserOutput, boolean returned ``` ```name=exception.trace,lines=10 from /srv/mediawiki/php-1.39.0-wmf.16/extensions/Kartographer/includes/ApiQueryMapData.php(224) #0 /srv/mediawiki/php-1.39.0-wmf.16/extensions/Kartographer/includes/ApiQueryMapData.php(76): Kartographer\ApiQueryMapData->getParserOutput(Title, integer) #1 /srv/mediawiki/php-1.39.0-wmf.16/includes/api/ApiQuery.php(657): Kartographer\ApiQueryMapData->execute() #2 /srv/mediawiki/php-1.39.0-wmf.16/includes/api/ApiMain.php(1901): ApiQuery->execute() #3 /srv/mediawiki/php-1.39.0-wmf.16/includes/api/ApiMain.php(875): ApiMain->executeAction() #4 /srv/mediawiki/php-1.39.0-wmf.16/includes/api/ApiMain.php(846): ApiMain->executeActionWithErrorHandling() #5 /srv/mediawiki/php-1.39.0-wmf.16/api.php(90): ApiMain->execute() #6 /srv/mediawiki/php-1.39.0-wmf.16/api.php(45): wfApiMain() #7 /srv/mediawiki/w/api.php(3): require(string) #8 {main} ``` ==== Impact ==== Unclear. ==== Notes ==== Seeing a handful of these in 1.39.0-wmf.16.
    • Task
    With the new network setup on Trusted Runners for buildkitd ([791655](https://gerrit.wikimedia.org/r/c/operations/puppet/+/791655)) CI jobs have networking issues now. One example job for a Trusted Runner: https://gitlab.wikimedia.org/repos/releng/gitlab-runner-test/-/jobs/21405 Failed with: ``` fatal: unable to access 'https://gitlab.wikimedia.org/repos/releng/gitlab-runner-test.git/': Could not resolve host: gitlab.wikimedia.org ``` I guess the new bridge network needs some more configuration to allow outgoing traffic (http, dns, ...).
    • Task
    The mobile presentation layer for production wikimedia projects has quite a few moving parts # [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/43a821496787e1690cace145bd097632c5705346 | Core ]] generates much of the markup for most pages # [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/MinervaNeue/+/3109d9aa8fe82ed69c999a7999bb44f160838653/ | MinervaNeue skin ]] provides a responsive interface with limited features # [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MobileFrontend/ | MobileFrontend extension ]] provides mobile device detection to automatically switch to the MinervaNeue skin for mobile users. It also provides additional functionality for making mobile-specific experiences Changing the mobile experience may require modifying all 3 code bases, so I've been experimenting with how to modify each, using Special:Preferences as my starting point, since it is of particular interest to us per {T309288} **JS/CSS only** - [[ https://gerrit.wikimedia.org/r/c/mediawiki/skins/MinervaNeue/+/803952 | 803952 ]] load custom css on Special:Preferences page in the minerva theme. - [[ https://gerrit.wikimedia.org/r/c/mediawiki/core/+/806293 | 806293 ]] Add custom JS to Special:Preferences in core. This one replaces the tab panel layout with a booklet layout based on `mw.config.get('skin') === 'minerva'`. Combined, these two changes will replace the Special:Preferences tab panel with a booklet after page load for the minerva skin only. Click the image below to see it in action {F35272064} **WIP** - [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/803991 | 803991 (WIP) ]] create custom Mobile Preferences page by extending Special:Preferences. This allows us to creating our own OOUI form class so that we can avoid tab panels all together.
    • Task
    === How many times were you able to reproduce it? Every time === Steps to reproduce # Go to an article # Tap the share toolbar button # Tap "Add to reading list" # Choose a reading list to add it to (or create one) # Back out of article, Go to Saved articles tab === Expected results Article you just saved is listed under "All articles" tab and the particular reading list screen in the "Reading lists" tab === Actual results Article is only shown under that particular reading list === Screenshots === Environments observed **App version: ** 6.9.2 (1932) **OS versions:** 15.5 **Device model:** iPad mini (6th generation) **Device language:** EN
    • Task
    To find a total count of matches via the API, it looks like one would need to iterate over the returned file matches (as each file could have multiple matches?) Consider adding a total match count to the stats (`?stats=true`) ```lang=json "Stats": { "FilesOpened":40, "Duration":78 } ``` [[ https://codesearch.wmcloud.org/core/api/v1/search?stats=fosho&repos=*&q=HACK&files=&i=nope | example API call ]]
    • Task
    The U2F API is no longer supported in Chrome and related browsers.
    • Task
    Before enabling webauthn we should update CAS to the latest version 6.5.
    • Task
    Extend the [[ https://phabricator.wikimedia.org/diffusion/EPHN/browse/master/includes/Engine/EngineInterface.php | EngineInterface ]] (similar to the [[ https://phabricator.wikimedia.org/diffusion/EPHN/browse/master/includes/Engine/EspeakEngine.php | espeak demo ]]) to send API requests to Larynx - **Endpoint**: https://larynx-tts.wmcloud.org/api - **Method**: `POST` or `GET` - **Docs**: https://larynx.theresnotime.io/openapi (swagger) --- ```lang=xml, name=Accepted SSML format <?xml version="1.0"?> <speak xmlns="http://www.w3.org/2001/10/synthesis" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.1" xsi:schemaLocation="http://www.w3.org/2001/10/synthesis http://www.w3.org/TR/speech-synthesis11/synthesis.xsd" xml:lang="en-US"> <lexicon xml:id="ipaInput" alphabet="ipa"> <lexeme> <grapheme>{word}</grapheme> <phoneme>{ipa}</phoneme> </lexeme> </lexicon> <lookup ref="ipaInput"> <w>{word}</w> </lookup> </speak> ```
    • Task
    Extend the [[ https://phabricator.wikimedia.org/diffusion/EPHN/browse/master/includes/Engine/EngineInterface.php | EngineInterface ]] (similar to the [[ https://phabricator.wikimedia.org/diffusion/EPHN/browse/master/includes/Engine/EspeakEngine.php | espeak demo ]]) to send API requests to Google - **Endpoint**: https://texttospeech.googleapis.com/v1 (`/text:synthesize`) - **Method**: `POST` - **Docs**: https://cloud.google.com/text-to-speech/docs/reference/rest/v1/text/synthesize --- ```lang=xml, name=Accepted SSML format <?xml version="1.0"?> <speak> <lang xml:lang="{lang}"> <phoneme alphabet="ipa" ph="{ipa}">{word}</phoneme> </lang> </speak> ```