User Details
- User Since
- Oct 7 2014, 2:31 PM (492 w, 6 d)
- Availability
- Available
- LDAP User
- Umherirrender
- MediaWiki User
- Umherirrender [ Global Accounts ]
Yesterday
(It is possible this is a real issue with the extension, not sure how to find the different)
Phabricator adds backlinks on the change sets, which makes it harder to see a dependency between all these links get generated by random. A fix would be nice. Using the has to make it a number sounds good.
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ORES/+/1011172/1 was prepared to fix the signature, but the other patch set does the same
Sat, Mar 16
Fri, Mar 15
Wed, Mar 13
As the data stored in the database are from parsing a page (via SecondaryDataUpdates), the fixes for T355877: [CLIENT] Investigate potential references to wrong ParserOutput in WikibaseClient code could be fix this as well.
At least the unique mode seems fixable
Tue, Mar 12
I have upgraded codesniffer on wmf deployed extensions/skins and some libs where autofix changed something or manual fixes are needed. Even with libup these patch sets would need manual attention for review of the autofix.
For the remaining wmf-deployed repos only the bump in composer plus the allow-plugins-change is needed. It would be nice to get this by/leave this to libup as libup is allowed to self-submit these simple patch sets.
Mon, Mar 11
Sun, Mar 10
Also false positives when inline php tags are used - https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1009913/2..3/includes/installer/WebInstallerOutput.php and in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Collection/+/1009879 the autofix was looking strange for the inline php tags.
The update to the latest codesniffer does not work on Translate extension with this error, not sure if that is related to the phpstorm comments here, because it fails with plain composer from command line.
> parallel-lint . --exclude vendor --exclude node_modules --no-progress > phpcs -p -s --cache Script phpcs -p -s --cache handling the phpcs event returned with error code 3 Script @phpcs was called via test PHP 8.2.13 | 10 parallel jobs Checked 519 files in 46.5 seconds No syntax error found ERROR: Referenced sniff "Universal.Constants.LowercaseClassResolutionKeyword" does not exist
Should be fixed with cd3e80e969e8450e29a77586707277bc514d8a15
There seems some false positives, but I have not checked if there are already tasks or fixes upstream:
$rawResponse['createdPaymentOutput'] ['payment'] ['paymentOutput'] ['amountOfMoney'] = [ 'amount' => $donorTestData['amount'] * 100, 'currencyCode' => $donorTestData['currency'] ];
Squiz.ControlStructures.ControlSignature.NewlineAfterOpenBrace is now enabled to cover this case (d0b5fd3ff730e33a2d5ffd1fa3798a06a565695b)
The url is https://ru.wikipedia.org/w/index.php?title=%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D0%B8_%D0%B1%D0%B5%D0%B7_%D0%B8%D1%81%D1%82%D0%BE%D1%87%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2_(%D1%82%D0%B8%D0%BF:_%D1%87%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D0%BA%26&stableid=79331611#59;_%D1%80%D0%BE%D0%B4_%D0%B7%D0%B0%D0%BD%D1%8F%D1%82%D0%B8%D0%B9:_%D0%B1%D0%B8%D0%BE%D1%85%D0%B8%D0%BC%D0%B8%D0%BA)
Fri, Mar 8
Thu, Mar 7
It is now possible to create MediaWiki:Undelete-comment-dropdown or MediaWiki:Undelete-comment-dropdown-unsuppress system messages on a wiki to use the new feature after the new version is active there - see roadmap https://www.mediawiki.org/wiki/MediaWiki_1.42/Roadmap for 1.42.0-wmf.22
Wed, Mar 6
Could be related to the pagelinks schema migration T351237: Set beta and production to read new for pagelinks migration / T352010: Gradually drop old pagelinks columns
Tue, Mar 5
Special:Block is using a similiar reason dropdown via the HTMLSelectAndOtherField as part of a HTMLForm.
T359012: Migrate Special:Block to CodexHTMLForm looks a bit like a duplicate. Maybe merge and add the subtasks under T359015: Implement Codex versions of HTMLFormFields needed for Special:Block?
Mon, Mar 4
action=delete is using fields from the HTMLForm class, while Special:MovePage builds the html form directly from OOUI widgets, that makes the technical different in the code. These widgets does not take url parameter in to account by default.
I can understand your comment for factorConds, for small lists it is not a big improvement in the final sql and it is a new function to know about, but it is a bit older as the expression system.
Sun, Mar 3
This feature request would covers mostly composer packages.
This could also or additional use foreign-resources.yaml from core and the extensions as a source for the repos used on wmf wikis to also include npm package.
Maybe that is a new task or could be done here as well.
Sat, Mar 2
Parsoid was updated to codesniffer 43.0.0 with 51baccc8741108a9e3f763f2c19c6ce6eda55ac4
Fri, Mar 1
It is expected to allow the plugin in each composer.json. LibUp should be teached to do this while upgrading via T358911: LibUp has to allow the dealerdirect/phpcodesniffer-composer-installer plugin on codesniffer update
There are some information about the 401 status in T228292#7490101
There is also T206252: Spike of HTTP errors from SwiftFileBackend::doStoreInternal, which could be related, but other function
Thu, Feb 29
Wed, Feb 28
This task is not about a prodution schema change, it seems I have clicked the wrong project Schema-change-in-production on phabricator and does not spot that before saving, to use Schema-change.
Mon, Feb 26
The special pages now shows only a limited result and should not have timeouts as in this task.
If the page cannot be open with the default limit it is okay to set a ?limit=10 on the url to get less results, up to limit=1 and paginate through the result if needed.
Sat, Feb 24
The initalize of the OOUIHTMLForm triggers this, which also happen in the include modus of Special:PrefixIndex, b08b6a7785e5ff3f152fdaf8f7b7cc13023212b8 was a first try to fix this, but got reverted. Cross-linking T352592
Fri, Feb 23
Please run namespaceDupes.php on this wiki due to that config change to fix the pages.
That is the result of 3fc635dcb20add63d844dc6f313b41319d6dda30, which is in 1.42.0-wmf.16, not that long ago.
Thu, Feb 22
3a1c95e9 is the trigger for this, but not the cause in code
Looks like the fixed tasks for wmf.19
T357700: PHP Deprecated: Use of MediaWiki\Content\Renderer\ContentRenderer::getParserOutput with integer revision id was deprecated in MediaWiki 1.42. [Called from FRInclusionCache::{closure}]
T357687: PHP Deprecated: Use of MediaWiki\Content\Renderer\ContentRenderer::getParserOutput with integer revision id was deprecated in MediaWiki 1.42. [Called from MediaWiki\Extension\TemplateSandbox\Hooks::onAlternateEditPreview]
Wed, Feb 21
New code this week from 2f11c59344c33edadc3c2e2c135678a6df4557b2 / T343963
The users showing on Special:Contributions the message "User account "..." is not registered.", also Special:ListUsers does not list them. No accocunt exists to have a newusers log for.
Tue, Feb 20
The linked patch sets needs a new release of the equivset package, that could be happen in some months.
Flow holds a reference to an older UserGroupManager, maybe the TalkpageManager already created in an previous test.
Mon, Feb 19
Sun, Feb 18
Antispoof detects different scripts, not sure if Ꭿ needs a mapping for A in that case. It seems AbuseFilter does not have this feature.
AntiSpoof has a feature to detect mixed script styles and avoid that user names are created with mixed scripts.
It has a list of known scripts and the range 2000–206F "General Punctuation" is not known and gives this messages.