Thanks for the patch!
We should check Logstash after this is deployed to confirm that the issue is fixed.
(Apparently you can't post the new topics on the demo, or view the page while you have topic subscriptions enabled – you'll get a fat red error. This is an unrelated problem, now filed as T287611. Sorry, I didn't notice that earlier.)
(just waiting for T282204, no other development needed)
Demo page with more ways to add a new topic than you thought possible: https://patchdemo.wmflabs.org/wikis/014e812f6d/wiki/Talk:New_section
Some interesting interactions that came up when I started testing it:
And now, let me talk about how do we actually take over the action=edit§ion=new URLs.
@Tacsipacsi Okay, you're correct again, I wrote my last comment quickly without thinking it through. So, right now I think that the new topic tool should only fall back to the normal wikitext editor if any of editintro, preload, preloadparams, preloadtitle is provided – and in a gadget like the warning.js one you linked, you could add &dtenable=0 to the query parameters to disable the new topic tool and fall back (this is what @DLynch proposed).
To clarify the relationship between this task and T282204: Handle URLs for starting new sections: the patch for T282204 will also resolve this task. Clicking a link to start a new topic on a different page will simply follow it, as it does now, and once the page loads, the new topic tool will open. If I understand correctly, we decided in the meeting yesterday that we are happy with that.
To clarify the relationship between this task and T282204: Handle URLs for starting new sections: the patch for T282204 would have also resolved this task, even if none of the patches here were written. However, if we did that, then following a link added by gadget/template would require the whole page to be reloaded. The patches here allow us to do it without reloading the page, which is faster.
@Krassotkin I think you would also benefit from re-reading the previous messages.
@DonSimon Please re-read the previous message.
Tue, Jul 27
Also, according to https://www.mediawiki.org/wiki/Help:Notifications#mute: "You will still receive notifications if a muted user writes or participates on your user talk page".
I can't reproduce, I don't get the notification for the comment by muted user.
You mentioned N'Ko language as well in the task, but the patch only implemented the other two. Does it also need a patch?
I haven't really proved that the above is exactly what happens, but I think at this point it's a better use of time to just try it and see if that fixes the problem. I couldn't reproduce it locally, but there might be other scenarios that are just harder to reproduce.
I think this can occur because:
- Tearing down and setting up the editor are both actually multi-step processes, with a few promises in the middle
- Other code may run after a promise is resolved but before the promise success callback runs
- We log the 'abort' event at the beginning of the teardown process; in contrast, we log 'ready' and 'loaded' at the end of the setup process.
We should check the logs after this is deployed everywhere next week.
Maybe we should just fall back to the existing editor when any URL parameters other than ?title=...&action=edit§ion=new are provided. Right now (in the limited solution implemented in T277371: Take over gadgets/templates which create additional links to "Add a new topic") we only fall back if any of editintro, preload, preloadparams, preloadtitle is provided, and other parameters are ignored.
(Also, it should say "editing toolbar" instead of "editing tools", for consistency.)
Updated logstash link in the description.
@Tacsipacsi What if we added "…in these features" (or something similar) instead? I think that should make it clear enough, given the context of the preferences page.
The button could open visual editor's "Languages" dialog (currently accessible only from the hamburger menu). This would be similar to how clicking the categories at the bottom of the page opens the "Categories" dialog.
Mon, Jul 26
Fixed by this change: https://github.com/MatmaRex/dtcheck/commit/38e6a36b3f21bf70310582aca9ad2b72a6fd4149
Actually this seems easy to fix, the recent changes data includes the ID of the previous revision at the time the edit was made, and we should be using that ID instead of the ID of the previous revision right now.
Sat, Jul 24
We noticed the issue in code review of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/704835. I think it's an unavoidable limitation of __call (per PHP documentation: "None of the arguments of these magic methods can be passed by reference."), but @DannyS712 asked me to file a bug.
Funnily enough, the following works in PHP 5.3, but it is a syntax error in all later versions where call-time pass-by-reference has been removed:
$a->func( &$b );
It will be everyone who visits such a page (or almost everyone, depending on their user preferences), not just those who visited them before.
Only the most recent comment gets highlighted in blue.
Only the most recent comment gets marked as read in the bundle.
Thu, Jul 22
Our [subscribe] and [reply] links are stored in the parser cache as part of the page contents, so if someone previously viewed the page and it has been cached, they will only disappear when either the page is manually purged (as @Quiddity described), or when the page is edited, or after a few weeks. Sorry, I probably should have thought about that and noted it.
Defining qualifying edit:
Any edit that adds a talk page comment, according to our talk page parser, using the same algorithm as for generating notifications. It's somewhat complicated (and still changing as we make improvements to the notifications), but hopefully intuitively obvious? Latest version of the code for reference: EventDispatcher.php.
Wed, Jul 21
It looks like you're viewing the page through Google Translate, that's probably the cause of the problem.
Will be fixed by the patch above.
a potential scenario where people would need to create (read: start a conversation on) their own user talk page.
Scheduled for later today: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20210721T1800
Tue, Jul 20
@Tacsipacsi Thanks, good points (particularly about user renames, I did not think about that).
This is a bug in the patch for T277371: Take over gadgets/templates which create additional links to "Add a new topic".
Mon, Jul 19
Musing about implementation details:
A few things are not completely clear to me:
Here's one idea for how to rephrase it:
Currently it uses ?redirect=no, because otherwise using the page tabs (history, edit, etc.) would affect the redirect target page instead of the page you just saved.
Thu, Jul 15
I searched for insource:/\<\/font size=3\>/ in the 'Template' namespace to find them: https://tr.wikipedia.org/w/index.php?search=insource%3A%2F%5C<%5C%2Ffont+size%3D3%5C>%2F&title=Özel:Ara&profile=advanced&fulltext=1&ns10=1
This diff found in dtcheck is caused by the same scenario: https://en.wikipedia.org/?diff=1029083485
THanks for preparing these, scheduled: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20210715T1800
I'll backport it today, this bug is causing some pages to be impossible to edit (e.g. the entire 'Schema' namespace on meta.wikimedia.org).
I can't reproduce this.