User Details
- User Since
- Sep 13 2022, 7:52 PM (204 w, 4 d)
- Availability
- Available
- LDAP User
- Peter Li
- MediaWiki User
- PetraMagna [ Global Accounts ]
Mon, Aug 10
Patch uploaded. It seems that Baidu's webmaster tools redirect to https://ziyuan.baidu.com/ which is called 百度搜索资源平台 so I used that in the descriptions.
I just realized that I pinged an inactive personal account this whole time. Hopefully @Jdlrobson-WMF wouldn't mind now that I finally pinged the right account.
Thu, Jul 23
Now that CodeMirror 6, which comes with link suggestions, is the default on MediaWiki 1.46, fixing this issue no longer seems necessary because there isn't a reason to use LinkSuggest when CM6 is already activated.
Mon, Jul 20
Hi @Jdlrobson! I'm wondering if you are willing to review this patch. If not, what is the WMF's stance on patches like this for skins that are not widely used in production?
Sat, Jul 18
Since they are on Miraheze I cherry-picked the branch for REL1_46, which Miraheze is expected to upgrade to in August.
Jul 12 2026
Hi @Samwilson, since you seem to be the de facto maintainer of the extension and introduced the original commit, do you have any thoughts on whether the fix should restore the DOM structure or simply put a band-aid on the shim positioning?
Jul 11 2026
As was suggested by @TheWWRNerdGuy in a Discord chat, the Shim is completely unused and is safe to be moved around.
Jul 8 2026
Jul 5 2026
Jun 28 2026
Forgot to note: as said in the commit message, a lot of effort went into backward compatibility. If that requirement is dropped, the patch can be greatly simplified. Timeless uses #37a for external links and #36c for internal links. I doubt many will notice the difference if we merge them into #36c.
There's a patch for T426907 now. Just need someone who is willing to review it. It worked well on my local machine, and the screenshot for https://phabricator.wikimedia.org/T426907#12062868 shows how it looks like with the patch applied.
Current dark mode look (after inserting the skin-theme-clientpref-night class into <html>). There are some elements missing support, such as table headers and icons, which are already noted in the task. They are planned to be addressed in follow-up patches to keep the current one lean.
Jun 27 2026
Related: T426907, which would clear most of the hurdles for dark mode Timeless support.
Jun 3 2026
Yeah. Thank you @SomeRandomDeveloper @MusikAnimal !
Jun 1 2026
I was informed by @RhinosF1 that this is a deliberate upstream change in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/966315. In particular, adding autocreateaccount to AbstractBlock.php.
May 31 2026
May 30 2026
Besides Widget, Flex Diagrams has {{#display_diagram, DataMaps has {{#displaydatamap, and Mustache (this is the intended use case, but it's a new extension and is still very niche, so I used Widget as the example) has {{#html and {{#mustache. There are some other extensions such as CSS which conditionally needs to link to a wiki page, so those use cases may require some more abstractions which could overcomplicate things.
May 21 2026
May 20 2026
@Jdlrobson Since the maintainers of Timeless are all inactive, I'm wondering if you'd be willing to review the patch when someone submits one to do the the conversion? I am interested in doing it, though this seems like a pretty time-consuming task and will likely take a while.
Apr 25 2026
Apr 12 2026
Resolved since the patch is merged and backported to 1.45.
Resolved since the patch is merged and backported to 1.45.
Apr 11 2026
I think "related changes" already has nofollow. The rest still don't and would require either a core patch or an extension patch (e.g. Extension:CiteThisPage).
Mar 13 2026
@0xJacks While some of your arguments make some sense, it's very clear that you have no idea what you are talking about when you write:
checking if the user has the editinterface or smw-admin permission
Each debug request forces the server to re-fetch wiki page content and re-run the minifier (CSSMin / JavaScriptMinifier) without any caching. An attacker sending repeated requests can cause significant server load, particularly on wikis with many asset pages listed in MediaWiki:Renderblocking-pages.
Feb 22 2026
Jan 23 2026
It seems that MW 1.44 is unaffected, so 1.45 is as far as backporting needs to go.
Jan 22 2026
Jan 20 2026
Should be easy enough to pass an additional argument to writeText.
Jan 19 2026
I'll submit a patch, though it's yet to be seen whether !important or slapping more selectors is the right way to fix this.
A similar patch submitted earlier also exists https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiCategoryTagCloud/+/1221109
Jan 18 2026
Shouldn't be too hard to fix.
Thanks for the pointer. I guess we'll wait and see how things play out then. This schema migration will be pretty painful so I won't be able to do it in the short term either.
Thanks for the quick reply. I suppose this is more of a documentation issue then since https://www.mediawiki.org/wiki/Extension:ImageRating doesn't mention the need to explicitly add <vote type=1 /> to uploaded file pages.
The problematic SQL is
SELECT page_id,page_title,COUNT(vote_value),AVG(vote_value) AS vote_avg FROM `page` LEFT JOIN `Vote` ON ((page_id = vote_page_id)) WHERE page_namespace = 6 AND (vote_page_id = page_id) GROUP BY page_id, page_title ORDER BY page_id DESC LIMIT 5;
The vote_page_id = page_id in the WHERE clause is the cause. If no rating exists for the image, the left join would result in null values for all fields in the Vote table, so the equality comparison will always fail. This WHERE clause is redundant anyway since page_id = vote_page_id is specified in the join already.
Jan 17 2026
I'll submit a patch once I figure out how to submit patches to gerrit for the third time.
Jan 12 2026
Jan 5 2026
Follow-up: works on 1.45 on Mirabeta. Whatever was causing the issue originally went away.
Dec 5 2025
Backtrace from @SomeRandomDeveloper in https://issue-tracker.miraheze.org/P567
Oct 13 2025
@stjn I believe it was you who suggested reporting this on Phabricator on Discord since the username matches your profile.
Oct 9 2025
As a workaround, the url can be inserted in the form of //static.wikitide.net.... Dropping the protocol will prevent $wgAllowExternalImages from touching it, but the url is still recognized by WikiSEO and by some applications (discord was okay with it).
Downstream: https://issue-tracker.miraheze.org/T13802
Sep 30 2025
I'm not sure why 320px is the center of the argument here. I feel like I made some good points independent of the exact size of the mobile screen (i.e. the padding used by other responsive skins and the need to have more space available for content on mobile). Regardless, I updated the original task description and changed 320px to 400px (along with all the screenshots).
Sep 23 2025
I tried some other widths. Vector 2022 uses 1.5rem padding for screen widths 1100px and below. Using the same padding for 400px and 1100px width screens does not seem like a good idea to me and I don't think any other major responsive skin is doing this. Besides 0.45em and 1em, there's Fandom which uses 0.75em and Citizen which uses 20px=1.25em, and Citizen's spacing also seems awfully large to me.
Which hardware is this? I don't think we want to spend a lot of effort on such extreme screen widths.
Yeah that does seem to be the case. I switched TemplateStyles to the master branch and, after dropping the MW 1.45 version check, CodeMirror functions correctly for sanitized stylesheets.
Thanks for the suggestion. It did not make a difference on my end since codemirror still refuses to work with templatestyles stylesheets and scribunto.
I noticed that mw-body-header already has display: flex, so what is preventing us from setting flex-wrap to wrap under narrow screens?
Sep 20 2025
Thanks for the suggestion. I modified $wgCodeMirrorContentModels to include more content models. css and javascript worked and the editor used CM6, but Scribunto and sanitized-css did not. I got the following error for both sanitized-css and Scribunto.
Warning: [CodeMirror] Unsupported content model sanitized-css [Called from MediaWiki\Extension\CodeMirror\Hooks::loadCodeMirrorOnEditPage in /var/www/mediawiki/extensions/CodeMirror/includes/Hooks.php at line 220]
Of course, if I remove these content models from CM's configuration, I get the plaintext input box again instead of the old CodeEditor.
Sep 19 2025
Forgot to note: this also affects Lua modules and javascript pages, which are handled by CodeEditor but would become plaintext editors after enabling "Improved Syntax Highlighting".
Sep 16 2025
Any updates on this? Moving the edit button's position in the DOM up so that it is before the description and then making it float: right should be a quick and easy solution? This button is small enough that usual concerns of float don't apply. Plus, users will be using mobilefrontend on narrower screens.
Aug 31 2025
AFAIK there is no fix for this. Your best bet is to disable this extension and write your own dark mode CSS. You can also use the Theme or ThemeToggle extensions to allow switching between multiple themes.
Aug 21 2025
Thanks @Samwilson. Looks like this is all good. Just need to wait for the patch to reach downstream.
@Jdlrobson-WMF I uploaded a patch for MinervaNeue as well. Minerva's CSS is a bit different, but I think the outcome is the same. The extra gray background mentioned in T361838 should be gone without compromising the scrolling behavior for larger tables.
Aug 20 2025
In particular, width: fit-content gets overridden by max-width: 100% with the screen is narrow, so I don't understand why this needs to be closed. It should be a strict improvement over the current solution.
The proposed fix does not compromise responsiveness in any way. It simply removes the problematic borders on the right.
Aug 16 2025
Looks like the CSS was added as a result of T330527. I'm surprised it passed all the quality control steps considering how it breaks smaller tables on narrower screens.
Aug 11 2025
Jul 10 2025
Jun 5 2025
It probably has to do with the following js. It doesn't do anything with client-darkmode if the user is anonymous. @Kizule would it be fine to execute the if ( darkMode ) statement for both anonymous and logged-in users? This change works on my local testing environment, but I'm not sure if the code is the way it is for some other reasons.
if ( mw.user.isAnon() ) {
// If the user is anonymous (not logged in) write a cookie
mw.user.clientPrefs.set( 'skin-theme', darkMode ? 'night' : 'day' );
} else {
// If the user is logged in write with API to user settings
new mw.Api().saveOption( 'darkmode', darkMode ? '1' : '0' );
if ( darkMode ) {
docClassList.add( 'skin-theme-clientpref-night' );
docClassList.add( 'client-darkmode' );
docClassList.remove( 'skin-theme-clientpref-day' );
} else {
docClassList.add( 'skin-theme-clientpref-day' );
docClassList.remove( 'client-darkmode' );
docClassList.remove( 'skin-theme-clientpref-night' );
}
}Jan 19 2025
Looks like this is the offending table name.
((SELECT cst_c_comment_page_id AS `union_page_id` FROM `cs_comments` ) UNION (SELECT cst_r_reply_page_id AS `union_page_id` FROM `cs_replies` )) AS union_table
As far as I can tell, extractTableNameComponents checks whether there is a quotation mark in the string. If there is, it'll panic an throw the exception seen here. The backticks (`) are the culprit.