To directly answer your question, there's really no good reason except that I noticed there were a bunch of old tasks incorrectly tagged with Patch-For-Review; As you say though, it's really not a great use of time, so thanks for getting my attention about it -- I appreciate the advice! :)

Apologies, I won't continue if you object. Sorry to bother you.

In T386436#11991931, @stjn wrote:

A function like the above also enables SyntaxHighlight to make the link clickable similar to require(), mw.loadData() and mw.loadJsonData().

Although I agree with having a simpler way to add styles since it’s such a common thing, I should note that currently all of those aren’t links either.

Note that, if this were done, several of the current parser functions could be moved out into their respective extensions as well (ifexist is from Extension:ParserFunctions; lst, lstx, and lsth are from Extension:Labeled Section Transclusion; and invoke is from Extension:Scribunto).

I removed the note about the demo revealing your IP address since Temporary Accounts are a thing now.

This won't blow-up files beyond their original max resolution, so as long as non-free pics are kept small in terms of the actual file itself (which they are), there shouldn't be any problem.

In T419332#11923047, @ExE-Boss wrote:

Note that the MediaWiki Download ships with CodeEditor, but not CodeMirror, so that needs to be rectified for MediaWiki 1.46.

In T391926#11439114, @Mr._Starfleet_Command wrote:

Agree that this should be bundled, but wait till v6 is out of beta.

I've tested it, and it works: an image uploaded while the system message is non-empty (e.g. has its default content) gets the section header, while an image uploaded after the system message was blanked doesn't include a header at all. Yay! Now my patch just needs to get merged.

In T394964#11832542, @Bhsd wrote:

At the current stage (after the deployment next week), a user can customize the client-side linting rules like this:

mw.hook( 'ext.CodeMirror.ready' ).add( ( cm ) => {
    const { worker } = cm.langExtension;
    switch ( cm.mode ) {
        // WikiLint for Wikitext
        case 'mediawiki':
            worker.onload( async () => {
                const lintConfig = await worker.getLintConfig();
                $.extend( true, lintConfig, {
                    rules: {
                        ruleName: severity,
                        // e.g.
                        'tag-like': 0
                    }
                } );
                worker.setLintConfig( lintConfig );
            } );
            break;

        // ESLint for JavaScript
        case 'javascript':
            worker.onload( () => {
                worker.setConfig( {
                    rules: {
                        ruleName: severity,
                        // e.g.
                        semi: 2
                    }
                } );
            } );
            break;

        // Stylelint for CSS
        case 'css':
            worker.onload( () => {
                worker.setConfig( {
                    ruleName: option,
                    // e.g.
                    'color-named': 'never'
                } );
            } );
    }
} );

Now that CodeMirror6 has fully replaced CM5 and we have conditional user options, this task is only waiting on T373710: Metrics instrumentation for CodeMirror 6 to refine which options are default-on, right? Or is there something else too, or can we move forward right now?

In T252681#11881001, @PatchDemoBot wrote:

Test wiki created on Patch demo by Mr. Starfleet Command using patch(es) linked to this task:
https://997c0a9f49.catalyst.wmcloud.org/w/

That sounds good to me.

Note that the same issue exists for safesubst.

Perhaps something similar to T420323: Allow to disable a wikitext lint error locally could be a simpler route to take with this?

In T174145#11018889, @MusikAnimal wrote:

Stalled until CM5 is removed, as we want the new icon (and text) to be an indicator that CM6 is being used.

OK, fair enough.

@NguoiDungKhongDinhDanh:

In T259059#11822688, @MusikAnimal wrote:

[...] [T]here are only ~25 instances of the v6 modules being used on-wiki, so I can fix those manually as a global interface editor. [...]

In T386436#11828023, @MusikAnimal wrote:

In T386436#11817485, @Mr._Starfleet_Command wrote:

Adding CodeMirror tag since auto-linking could likely be applied to it too, similar to the suggestion for SyntaxHighlight (see T419335: Add CodeMirror auto-linking where missing).

Pardon my ignorance; Is it safe to assume that syntax like { src = 'Namespace:Foobar' } would always refer to the page title Namespace:Foobar?

Otherwise, it may make more sense to wait until we have the new mw.ext.templatestyles.add() method to bring CodeMirror into it. The new syntax would also make it more easy to add autocompletion when typing the page title such that only sanitized-css titles are suggested.

Adding CodeMirror tag since auto-linking could likely be applied to it too, similar to the suggestion for SyntaxHighlight (see T419335: Add CodeMirror auto-linking where missing).

Wikitext/non-wikitext is probably sufficient, especially since it wouldn't mean *losing* any functionality compared to what we have now (i.e. CodeEditor for non-wikitext, nothing more granular).

@Timwi: Sorry, I could have been clearer. What I meant by "the wrong extension" is just that the extension wouldn't necessarily match the file's actual type; I wasn't saying that it's a bad idea, on the contrary, I think what you suggest is probably a good idea.

@Timwi: Good point, I hadn't thought of that. Although, if indeed we implemented your suggestion for removing the file extension from the title where there isn't a collision, we could then also implement my suggestion, since you could upload a different file type over a file with the wrong extension, as you say. I hope I'm making sense :)

In principal I agree with this ticket, that the file extension shouldn't be part of the name, and you should be able to upload a JPEG over a PNG, for example. But in practice this change would create many many collisions, so I doubt if this is practical. That said, could we make it so, going forward, you can't upload a file X.jpg if X.png already exists? This would avoid future name overlap, at least, although obviously wouldn't fix existing overlap.

You're right; I only added it there because T333211 is listed as such, but I see now that it's not really a subtask of that.

In T402097#11592088, @Awesome_Aasim wrote:

Fandom still uses DPL3 it seems.

I'm no expert on this, but my guess is that CSS could scale the image to the right size from the start, even before the JavaScript changes the image source to a larger thumbnail. Thus there would be no text reflow. I could be wrong, though.

In T397133#11558353, @Bugreporter2 wrote:

In T397133#11555963, @Mr._Starfleet_Command wrote:

DPL3 is no longer maintained and is now incompatible with current MediaWiki, so obviously it is out of the question. DPL4, on the other hand, is now marked as stable, and is compatible with MediaWiki 1.44+. Maybe time to start considering it?

It might have been better to change the task description instead of just burying it.

DPL3 is no longer maintained and is now incompatible with current MediaWiki, so obviously it is out of the question. DPL4, on the other hand, is now marked as stable, and is compatible with MediaWiki 1.44+. Maybe time to start considering it?

DPL4 is now compatible with MediaWiki 1.44+. According to its MediaWiki.org extension page:

FYI, the successor to DynamicPageList3, DynamicPageList4, is now marked as stable (although it's currently incompatible with the latest stable release of MediaWiki). We should probably update this task's title and description to clarify that this is not about that extension.

It just occurred to me that we could do the same thing for links in comments on normal wikitext pages, too (e.g. <!-- [[Link]] -->). Should we start a separate ticket for that?

One difference I notice between CodeEditor and CodeMirror when it comes to CSS and JavaScript is that, when you're writing code that's indented (i.e. within one or multiple block statements/functions), if you click "enter" twice to create a blank line between one piece of code and another, CodeMirror gets rid of the tabs from that line, whereas CodeEditor leaves them. I personally don't mind this change, and in my experience dropping the tabs is indeed more typical behavior for CSS/JS editors, but I just wanted to make a note of it.

Yeah, I'd be ok with that.

CodeMirror should turn links in CSS/JavaScript comments (e.g. /* [[link]] */) into clickable links like it does for such links in wikitext, and like already happens when viewing the page, not editing it (i.e. viewing the page directly, showing preview, or viewing an old revision).

This has only ever applied in CodeEditor before (therefore only non-wikitext formats), but now that I think of it this would be good to have in wikitext too, i.e. with {{templates}}, (anything in parentheses), and [[links]]. Unless anyone objects.

Here is an exhaustive list of vulnerable attributes, taken from https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Values/url_function:

Also, double-clicking at the start or end of a bracket pair (...), [...], or {...} should highlight all the text between the brackets, like it does with CodeEditor.

Thanks for the history! It was sort of a rhetorical question, but still neat stuff to hear about. 😄

In my opinion, custom signatures are a bad idea in general, but I acknowledge that removing them would be difficult since they are well-liked and heavily used. More of a "why were they introduced in the first place?" kind of thing than "we should actually remove them."

The checkbox "do automatically prettyprint the code when editing and remove such temporary formatting when saving the code" is checked off on the list in the task description. It was checked off by @Bhsd in January 2024 at T166098#9469820. Unless I'm misunderstanding what this point is talking about, it has not been done. There's no additional context available since it doesn't link to a subtask like the others do. Was this a mistake? If not, can someone clarify the text or add a link to a relevant Phabricator task? Thanks.

Instead of displaying just one of the two logs when viewing page-nonspecific log lists, it would make more sense to simply have history merges generate a single log entry that is associated with multiple pages simultaneously. No idea how challenging that would be technically, but it seems the better solution in theory, right?

Agree that this should be bundled, but wait till v6 is out of beta.

At the vary least, I'd suggest we wait till DPL4 has a stable release, since that's supposed to come with significant performance improvements.

Defining custom CSS variables has been error-free for some time now (since at least MW 1.43, although I'm not sure exactly when the change occurred). However, warnings are still generated in most cases when using variables. One notable exception is the background property, which doesn't produce a warning, even though background-color does. It seems that background undergoes no validation whatsoever, because even totally bogus values like background: blah blah blah are warning-free. Go figure.

IMO, the parser should give the same output regardless of user preference, so if we keep this preference, it should be done via CSS. As Ladsgroup mentioned, this would result in users who set their preference above 250px getting blurry images. I can think of two possible solutions:

Yes, I believe so, since the contents of <title> should match the title shown on the page (minus any HTML tags, of course).

Also, the header should probably take its markup from MediaWiki:Newsectionheaderdefaultlevel instead of hard-coding it.