User Details
- User Since
- Oct 27 2014, 6:03 PM (571 w, 1 d)
- Availability
- Available
- IRC Nick
- edsanders
- LDAP User
- Esanders
- MediaWiki User
- ESanders (WMF) [ Global Accounts ]
Today
Instead of not showing, uou could also open source editor in the last known section, as by very strong convention this is where all the category links are.
Yesterday
I've verified all the rev_content in enwiktionary is stored externally (starts with DB://) so we should be good to just run a query to append ,external to anything that doesn't have it:
UPDATE flow_revision SET rev_flags = CONCAT(rev_flags, ",external") WHERE rev_user_wiki="enwiktionary" AND rev_flags NOT LIKE "%external%"
I think I have it solved - the rev_flags row on the updated rows is missing the external flag, which is required for the ExternalStorage lookup to happen. Here's a sample of random rows:
+------------------------+------------------------------------------+ | rev_content | rev_flags | +------------------------+------------------------------------------+ | DB://cluster31/4045076 | utf-8,gzip,html | | DB://cluster31/4045072 | utf-8,gzip,html | | DB://cluster31/4062748 | utf-8,gzip,html,external | | DB://cluster30/4044111 | utf-8,gzip,html | | DB://cluster30/4044110 | utf-8,gzip,html | | DB://cluster31/4062749 | utf-8,gzip,html,external |
Task for border colour consistency: T406563
Mon, Oct 6
@Krinkle Could we allow the skin to specify a default scroll-padding-top and then render that really early (e.g. an inline <style> tag in the <head>)?
Looks like the issues mentioned here have since been resolved.
Fri, Oct 3
Disabling this for GE sounds reasonable. Ideally we would provide an API for this, but if that's not feasible we can special case GE.
Is the edit apply_patch code handled differently than the install code?
Thu, Oct 2
These changes are for consistency with the existing bottom sheet cards (e.g. link inspector). If we need to diverge we should have a reason. If we want to change both we should do that in a separate task.
There are already some similar workarounds in place in the codebase, e.g. where we get a Node but need an Element:
const // Type declaration needed because of https://github.com/Microsoft/TypeScript/issues/3734#issuecomment-118934518 userLinksDropdownClone = /** @type {Element} */( userLinksDropdown.cloneNode( true ) ), userLinksDropdownStickyElementsWithIds = userLinksDropdownClone.querySelectorAll( '[ id ], [ data-event-name ]' );
I've implemented most of the above, while also trying to keep it aligned with our other context cards (e.g. link contexnt):
| Link context | Paste check | Tone check | Add reference (pre-save with footer) |
 |  |  |  |
Wed, Oct 1
DT doesn't actually do scrolling for the hash-linked comments, it's done natively. We could do a delayed non-native scroll after the vector hook runs to fixup the problem.
I believe scroll-padding-top is what makes this work, but in Vector-2022 the sticky header seemingly isn't ready when the DT code runs. If you focus the address bar and press enter you'll notice it works the second time.
We'll proceed with the other pages for now, staus update here:
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:ESanders_(WMF)/lqtarchives
Tue, Sep 30
There a couple of recently-active user talk pages on hu.wiki that have orphaned LQT topics pointing at them:
- User:Andrew69.
- User:Bennó
- User:Glanthor Reviol, manually archived at Glanthor Reviol/Archív 6, can be deleted
- User:Módis_Ágnes_Vadszederke
- User:Nyiffi (only 1 thread)
- User:Xia (Threads are User:Teemeah)
This is the result of some more general decsision:
- To store check results as expanding fragments. This means that if a check identifies a range, and that range is added to, the added content is still highlighted. This makes more sense if you type one word into the middle of a pasted paragraph.
- The expanding fragments expand at their boundaries, i.e. if you type at the end of pasted paragraph it is still highlighted. As far as expanding fragments are concerned, there is no difference between adding text to the end of a paragraph and adding a new paragraph, e.g. <p>pasted text</p> -> <p>pasted text new text</p> --vs-- <p>pasted text</p><p>new paragraph</p>
Mon, Sep 29
However, the social process of changing a style like this top-down tends to be slow and tiresome.
@Pppery Thanks for this investigation. Given the content is still recoverable in some for let's do that and see if the caches expire...
Edited
Possibly. What's also interesting is that in some topics, certain posts appear to have been rebuilt, as evidenced by the fact that their templates are now rendering correctly, while others are blanked:
I'm not sure having a such a significant divergence from https://www.mediawiki.org/wiki/Manual:Coding_conventions/JavaScript for just a handful of repos is a good idea. It makes code less portable and searchable, and has added a lot of noise to the revision history (as a non-whitespace change). There is a reason we try to keep code style consistent across projects. This task is also lacking any rationale for such a significant change.
Before we ran the import we didn't run FlowCreateTemplates.php, this means there are bunch of red-linked templates in the converted content. I have since run FlowCreateTemplates.php on enwikisource.
Thanks, fixed Afc0703.
Sat, Sep 27
Including the site name (Wikipedia) in the message adds complexity that we like to avoid.
Fri, Sep 26
I wouldn't want to limit it to only message keys, since then you give up the ability for these label messages to take parameters, but maybe we can allow either a message key or a MessageSpecifier and optimize the simple case.
Looks like there are a few hundred replacements that would need to be done: https://global-search.toolforge.org/?q=%5C%3C%2Fce%5C%3E%5B%5E%3C%5D®ex=1&namespaces=&title=
Thu, Sep 25
Without gadgets, the Edit button can blend in a but too well with the category listing, especially if the alignment is just so:
This can be fixed by passing a UA to the client:
$client = new \Phabricator\Client\Curl\CurlClient(); $client->setOption( CURLOPT_USERAGENT, 'User-Agent: PatchDemo/0.0 (https://patchdemo.wmcloud.org/)' ); $api = new \Phabricator\Phabricator( $config['phabricatorUrl'], $config['conduitApiKey'], $client );
There is a bug in the Phabricator PHP API that means this option doesn't get set. It was fixed in the master branch, but the repo was abandoned before it was released. I've made a fork of the repo and created a new release (2.0.3) with all the merged changes since 2.0.2:
https://github.com/wikimedia/Phabricator-PHP-API/releases/tag/2.0.3
Wed, Sep 24
The script ran successfully on one talk page after patching.
Mon, Sep 22
I ran the script a second time with some actualy board header content to verify the header was importing correctly and it is. It failed at the same place (importing threads):
https://en.wiktionary.org/wiki/User_talk:ESanders_(WMF)/lqt_test2
We ran the script targetting a test page https://en.wiktionary.org/wiki/User_talk:ESanders_(WMF)/lqt_test .
It moved the LQT page to /LQT Archive 1 and created a Flow board, but failed to import the threads.
esanders@deploy1003:~$ mwscript-k8s --comment="T405080" -f -- Flow:convertLqtPageOnLocalWiki.php --wiki=enwiktionary --srcpage="User_talk:ESanders_(WMF)/lqt_test" --logfile=/dev/null --ignoreflowreadonly
⏳ Starting Flow:convertLqtPageOnLocalWiki.php on Kubernetes as job mw-script.eqiad.zqzkpyq2 ...
🚀 Job is running.
📜 Streaming logs:
[2025-09-22 13:35:16] Starting LQT conversion of page User_talk:ESanders_(WMF)/lqt_test
[2025-09-22 13:35:16] Archiving page from User talk:ESanders (WMF)/lqt test to User talk:ESanders (WMF)/lqt test/LQT Archive 1
[2025-09-22 13:35:18] Importing to User talk:ESanders (WMF)/lqt test
[2025-09-22 13:35:19] Importing header
[2025-09-22 13:35:19] Imported 2 revisions for header
[2025-09-22 13:35:20] Importing new topic
[2025-09-22 13:35:20] Failed importing topic: topiclqt-api:local:thread_id:8601
[2025-09-22 13:35:20] Flow\Exception\DataModelException: Unable to locate root for post yzfzte0li84lz7t3 in /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Data/Index/PostRevisionTopicHistoryIndex.php:89
Stack trace:
#0 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Data/Index/PostRevisionTopicHistoryIndex.php(48): Flow\Data\Index\PostRevisionTopicHistoryIndex->findTopicId(Object(Flow\Model\PostRevision))
#1 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Data/ObjectManager.php(264): Flow\Data\Index\PostRevisionTopicHistoryIndex->onAfterInsert(Object(Flow\Model\PostRevision), Array, Array)
#2 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Data/ObjectManager.php(173): Flow\Data\ObjectManager->insert(Array, Array)
#3 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Data/ManagerGroup.php(98): Flow\Data\ObjectManager->multiPut(Array, Array)
#4 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Data/ManagerGroup.php(107): Flow\Data\ManagerGroup->multiMethod('multiPut', Array, Array)
#5 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Import/PageImportState.php(121): Flow\Data\ManagerGroup->multiPut(Array, Array)
#6 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Import/TalkpageImportOperation.php(305): Flow\Import\PageImportState->put(Array, Array)
#7 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Import/TalkpageImportOperation.php(247): Flow\Import\TalkpageImportOperation->createTopicState(Object(Flow\Import\PageImportState), Object(Flow\Import\LiquidThreadsApi\ImportTopic))
#8 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Import/TalkpageImportOperation.php(130): Flow\Import\TalkpageImportOperation->getTopicState(Object(Flow\Import\PageImportState), Object(Flow\Import\LiquidThreadsApi\ImportTopic))
#9 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Import/Importer.php(114): Flow\Import\TalkpageImportOperation->import(Object(Flow\Import\PageImportState))
#10 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Import/Converter.php(215): Flow\Import\Importer->import(Object(Flow\Import\LiquidThreadsApi\ImportSource), Object(MediaWiki\Title\Title), Object(MediaWiki\User\User), Object(Flow\Import\SourceStore\FileImportSourceStore))
#11 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Import/Converter.php(157): Flow\Import\Converter->doConversion(Object(MediaWiki\Title\Title), NULL)
#12 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/includes/Import/Converter.php(113): Flow\Import\Converter->convert(Object(MediaWiki\Title\Title), false, false)
#13 /srv/mediawiki/php-1.45.0-wmf.19/extensions/Flow/maintenance/convertLqtPageOnLocalWiki.php(101): Flow\Import\Converter->convertAll(Array, false, false)
#14 /srv/mediawiki/php-1.45.0-wmf.19/maintenance/includes/MaintenanceRunner.php(696): Flow\Maintenance\ConvertLqtPageOnLocalWiki->execute()
#15 /srv/mediawiki/php-1.45.0-wmf.19/maintenance/run.php(53): MediaWiki\Maintenance\MaintenanceRunner->run()
#16 /srv/mediawiki/multiversion/MWScript.php(221): require_once('/srv/mediawiki/...')
#17 {main}
[2025-09-22 13:35:20] Imported 1 items, failed 1
[2025-09-22 13:35:20] Failed to complete import to User talk:ESanders (WMF)/lqt test from User talk:ESanders (WMF)/lqt test/LQT Archive 1
[2025-09-22 13:35:20] Finished LQT conversion of page User_talk:ESanders_(WMF)/lqt_testSat, Sep 20
One thing we could do it have the OverflowMenuItem return message keys. Then we can implement the caching in CommentFormatter.
Copying my comment from code review:
this seems like complex setup to cache a message string, and I worry about having to copy this code to every new user of this hook. is there a way this could be provided by some DT class upstream?
Fri, Sep 19
This could be a performance bottleneck if there are many discussions per page with many replies.
Thu, Sep 18
Wed, Sep 17
Signatures now link to permlinks.
https://www.w3.org/TR/2011/WD-html5-20110525/urls.html#parsing-urls adds some chracters to RFC 3986, specifically listing U+005B .. U+005E, where 5B and 5D are the two square brackets, so it appears they are allowed.
Translate having its ext.translate.ve requiring ext.visualEditor.mwcore
I think we are happy the gutters are still working as before.
There is also the optional loader we added to DiscussionTools, which I suggested we upstream to core:
https://github.com/wikimedia/mediawiki-extensions-DiscussionTools/blob/master/includes/ResourceLoaderData.php#L115-L146
VE produces the following HTML:
<p><a href="./Wiktionary:Beer_parlour#[on_hold]_Temporary_accounts_will_be_rolled_out_soon" rel="mw:WikiLink">Wiktionary:Beer_parlour#[on_hold]_Temporary_accounts_will_be_rolled_out_soon</a></p>
which converts to
[[Wiktionary:Beer_parlour#[on_hold]_Temporary_accounts_will_be_rolled_out_soon]]
which converts back to
<p>[[Wiktionary:Beer_parlour#[on_hold]_Temporary_accounts_will_be_rolled_out_soon]]</p>
Tue, Sep 16
Actually a regression from 6 years ago: https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/512655
Mon, Sep 15
Thu, Sep 11
Wed, Sep 10
Tue, Sep 9
Closing as invalid - please re-open if you think we've missed something.
I don't think there's a bug here. Tone Check is not sentence based but paragraph based so you will get a different score when you append a violating sentence to the end of different paragraphs. If you paste on the end of a long paragraph that is not tone-violating then that will probably bring the score down below the threshold.
Add the same or a different tone violating sentence in the same paragraph or somewhere else in the article.
No errors since 2025-08-15
This broke some time between June 4 and July 2