@rijvirajib - that sounds like a totally different error. What version of Page Forms are you running?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 14 2022
14:48:02 <taavi> this incident probably deserves a post-mortem for our response, I don't think the time it took us to respond is acceptable nor is the fact that the patch authors aren't available and I don't know who to escalate this to
Also on a MW 1.35 instance with REL_135 checked out.
Error with $this-> in getInitialPageText which should be using wfMessage
Additional user report via Znuny: https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=12063191
@Inductiveload , yes I agree.
The above patch is reverts of 682aad7557ebb09c2aefa84d2c0c1f6c87ea5b76 87d8ccbd3e5280582a1bd60771b821ee5bbc95a7 1aecb692f64b3166cbaf1a7de9d85790ebc8759f d3b2b800678e91fd1a6177d80fde790c9006d423 squashed into one.
Change 754046 had a related patch set uploaded (by Legoktm; author: Legoktm):
[mediawiki/core@wmf/1.38.0-wmf.17] Revert \"LinksUpdate refactor\" and follow-ups
Some quick thoughts on eyeballing the code:
- The issue is presumably coming from LinksTable::getFromConds() line 353: return [ $this->getFromField() => $this->getSourcePageId() ];
- LinksTable::getSourcePageId() line 276 returns the getId() of the private PageIdentity $sourcePage
- LinksTable::injectBaseDependencies() is meant to set $sourcePage, and is meant to be called by the factory on instantiation.
- But the call to PageIdentity::getId() in practice will be routed to a Title::getArticleID()
- Title::getArticleID() line 2871 calls Title::getFieldFromPageStore() without any special flags, and casts its return to an instantiation
- Title::getFieldFromPageStore() line 4113 returns false if the page doesn't exist, which will include when it's just been deleted?
This seems to work on the backend, though. I.e. if I run this through the API, http://localhost:8080/w/api.php?action=wikilambda_function_call&format=json&wikilambda_function_call_zobject=%7B%0A%09%22Z1K1%22%3A%20%22Z7%22%2C%0A%09%22Z7K1%22%3A%20%22Z801%22%2C%0A%09%22Z801K1%22%3A%20%22Z10112%22%0A%7D%0A - I get a good answer.
All done and the APK with updated changes is ready for download.
In T295607#7621819, @SimoneThisDot wrote:The BLUE is set to indicate that the item is currently on focus not that it is selected.
The reason why they worked differently is that the first few dropdown are "preselecting" the first item as the Default, but the last one actually has a value of "reference" set..
So to summarise, the first few values show ALL as the default, while the last one has the actual value "Reference" set. Happy to change if you want them aligned, but I wanted you guys to know the main difference for this
I agree - "All" option is not actually selected, so then the blue font is probably not needed. I asked only to verify that we ok with the current design.
So we don't currently have a fix for T299244 but we also aren't comfortable reverting the branch at this point due to several complex changes that landed this week. The people who wrote the code aren't around and neither are any release engineers (I have to leave shortly)
elastic2051 came up fine after the new re-image
Re-image is complete
Thanks! Addressing some of these dated dependencies in a patch for eslint* and one for mediawiki-wdio (and one for stylelint-config-wikimedia that's waiting on getting a new release out).
Cookbook cookbooks.sre.hosts.reimage started by ryankemper@cumin2002 for host elastic2051.codfw.wmnet with OS stretch completed:
- elastic2051 (WARN)
- Downtimed on Icinga
- Disabled Puppet
- Removed from Puppet and PuppetDB if present
- Deleted any existing Puppet certificate
- Removed from Debmonitor if present
- Forced PXE for next reboot
- Host rebooted via IPMI
- Host up (Debian installer)
- Host up (new fresh stretch OS)
- Generated Puppet certificate
- Signed new Puppet certificate
- Run Puppet in NOOP mode to populate exported resources in PuppetDB
- Found Nagios_host resource for this host in PuppetDB
- Downtimed the new host on Icinga
- First Puppet run completed and logged in /var/log/spicerack/sre/hosts/reimage/202201142226_ryankemper_2294794_elastic2051.out
- Checked BIOS boot parameters are back to normal
- Rebooted
- Automatic Puppet run was successful
- Forced a re-check of all Icinga services for the host
- Icinga status is not optimal, downtime not removed
- Updated Netbox data from PuppetDB
Change 754044 had a related patch set uploaded (by Jforrester; author: Jforrester):
[mediawiki/extensions/WikiLambda@master] build: Upgrade eslint-config-wikimedia to 0.21.0 and make pass
The LinksUpdate lost the page id to work on:
I just noticed that SDAW-MediaSearch rolls its own initialization of videojs ...
https://github.com/wikimedia/mediawiki-extensions-MediaSearch/blob/766df4ed1ea586d98ff7b9838c3c7e78e62ebdb6/resources/components/base/Player.vue#L48
Banned elastic2035 and elastic2051 (which was already broken) via the following commands:
@kzimmerman Here are the changes Ive done after the last update:
- Have a standalone filter for the time range
- Section on the top with an Overview of the dashboard. With a statement that the dashboard filter and that it applies to all the charts in the dashboard
- Update “This dashboard is maintained by Maya Kampurath, Product Analytics. If you have questions or feedback please email @wikimedia.org or product-analytics@wikimedia.org”
- Change the default start to "Last July 1st"
- Remove any titles in charts that specify fiscal years
Change 754043 had a related patch set uploaded (by Andrew Bogott; author: Andrew Bogott):
[operations/puppet@production] cloud-vps nfsclient: switch to using the VM-hosted scratch NFS server
Looks like removing and re-assigning access did the trick. This can be closed.
I can reproduce this locally, git bisect says this is caused by the linksupdate refactor (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/743278). The patch doesn't seem to revert cleanly on master. I'm not really sure how to debug this component, sticking var_dump( 'here' ); die();s to functions that seem relevant seems to have no effect.
The update of the category table (for the counters) and also the deletion from categorylinks is not done.
Re-opening this task for investigation.
This latest patch at least isn't broken on the old/working hosts. We're reimaging elastic2051 to make sure it works on a fresh host.
I believe simple Unicode hieroglyphs already display on Windows browsers because Windows has a hieroglyph font.
Cookbook cookbooks.sre.hosts.reimage was started by ryankemper@cumin2002 for host elastic2051.codfw.wmnet with OS stretch
FWIW Pootymalooty is a locked LTA, who's phab account has been disabled.
This is still happening: https://en.wikipedia.org/w/index.php?title=Deerfield_Society_of_Arts_and_Crafts&type=revision&diff=1065432958&oldid=996235356 (13 January 2022)
@Pootymalooty34 You can request personal wikis at https://miraheze.org/ by the way.
Change 754042 merged by Ryan Kemper:
[operations/puppet@production] cirrus: Fetch java before elastic plugins
This is likely the same issue as reported at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Problems_with_speedy_deletion_category_counts
Still won't be as annoying as having to make an API call to get the timezone.
Untagging MediaWiki-extensions-Semantic-Rating, since the question seems to have to do with editing ratings, which is not a feature of that extension. It only displays ratings.
These are edits to Wikidata erroring. They might be edits to regular wiki pages. The damage and item quality models were made to assess edits to entities (items, properties) so it errors when trying to process wikitext.
Right ... quit ping-spamming, and make sure to give a support vote after 2022-01-28: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Wikidata/Do_not_follow_sitelink_redirects_when_redirect_badge_is_used#VALIDREDIRECT
The problem of wrong category member counts comes up time and again (currently on enwiki at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Problems_with_speedy_deletion_category_counts ). It would be really helpful to have some workarounds for the next time. If there are performance issues, just restrict the "force recount" action to admins or similar.
Change 753594 merged by jenkins-bot:
[mediawiki/extensions/WikimediaEvents@master] Add support for Vector2022 skin option to VectorPrefDiffInstrumentation