In T209892#9664164, @jrbs wrote:

Hey @Skizzerz, thanks for submitting a patch. This task was listed in our contractors' work package and I was just wondering what the status of the CR is?

page_dependencies would be my preference, as a native speaker. For the most part all multi-word table names in the MediaWiki schema contain underscores between the words, the exceptions seem to be all very old tables. Dependencies is a better word than relations, as it implies the direction of the relationship.

Reopening; this is still an issue. While it no longer tries to call those methods on a ForeignDBRepo it also doesn't actually work, because the code is still hardcoded to check explicitly for ForeignDBViaLBRepo (and nothing else). This results in nothing appearing along with a PHP warning of "trying to access array offset of type bool" due to there being effectively 0 sources.

$wgRevokePermissions has always been a very niche feature. I introduced it in conjunction with APCOND_BLOCKED so that blocked users could be "autopromoted" into a group that further restricts their access beyond what a normal block would. The partial block feature didn't exist back then, and APCOND_BLOCKED only interacts with sitewide blocks at the moment, so it's not particularly ideal for this feature.

https://www.mediawiki.org/w/api.php?action=expandtemplates&text={{MW%20stable%20branch%20number}}&prop=wikitext&formatversion=2&format=json is a better URL since it doesn't throw deprecation warnings.

New set of patches attached, including backports to 1.36, 1.35, and 1.31. For the 1.31 backport I changed the static anonymous function into a regular one to match how every other anonymous function in 1.31 is presented. 1.31 supports PHP 7.0.0+ and I believe static anonymous functions have existed long before then, but I felt it better to be safe and do what everything else does on that branch.

Patch against master to not apply autoblocks against untrusted XFF headers (generated via git format-patch and can be applied via git am). The backport to 1.36 is unfortunately not as trivial as cherry-picking, so if this patch passes code review I'll work on that backport as well as the 1.35 backport.

I think we would want autoblocks to apply normally to trusted XFF headers, not doing that would render autoblocks useless on wiki setups that proxy behind a caching layer. I also think the reasoning for XFF blocks to operate on all XFF headers and not just trusted ones as laid out in T25343 still applies.

In T282955#7090569, @GreenReaper wrote:

Not objecting or anything, but is there a reason for this? Extensions being split out, or this one isn't used in Wikimedia? I'm not regularly involved in development so am not aware of any codebase-wise changes (have been poking at Wikibase/WBStack recently for an upgrade, though).

In T282955#7090564, @Jdforrester-WMF wrote:

Presumably you want to abandon the five open patches?

The above doesn't actually work; while we aren't casting to Hook interfaces anywhere, a handful of constructors take the hook interface as strongly-typed arguments (e.g. WikiPageFactory). This causes fatals when HookRunner doesn't implement the hook interface classes, and I do not believe giving up type safety in that regard is worthwhile.

Something I thought of is the following:

In T217158#6807507, @Jdlrobson wrote:

I think the recently merged SkinMustache class provides an alternative to BaseTemplate which addresses the goals of T217158#5019573 with the exception that the new skin class is not mandatory but a recommended alternative. It's used to build CologneBlue and Modern, Vector and Minerva and this has led to a standard and simplified API that addresses the needs of all these skins in a generic way.

A new skin compatible with MediaWiki master can be made using the following tool: https://skins.wmflabs.org/#/add

@Skizzerz how would you feel about merging this RFC into https://phabricator.wikimedia.org/T249673 or calling it resolved?

@tstarling Mind taking a look at the above patch? It's been sitting out for a couple weeks now with no activity, and I feel you're probably the best qualified to review it given your work and research above.

In T271259#6724041, @Peachey88 wrote:

Affects any non existent page not just recently deleted by the looks

@Krinkle @eprodromou This would be useful to have. This isn't a security feature since can't say that a particular client only has access to a particular database, but more an interoperability feature with other (non-MediaWiki) applications that are making use of the same redis instance just in case they happen to use the same keyspaces (unlikely, but possible). It could also be useful when sharing a single redis instance across multiple MediaWiki installations where it's desired to not share certain things (such as rate limits) across all of those wikis because they are meant to be independent and not part of a farm.

@sbassett I know you were involved in the previous security issue with this extension (T245850). Is there anything else we need to do for this one in order to get wiki admins notified, and do you think this merits a CVE?

In T269718#6685174, @Kghbln wrote:

Ooops, I see that the patches are unmerged. I should have been more attentive. Now I officially published news about the issue without the fix in place. That's life I guess. In the future I personally would appreciate disclose only if the fix was merged. Otherwise I see no sense in doing so. Again this is just my personal opinion.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Widgets/+/647749 merged into master. I'll submit a backport to REL1_35 and REL1_31 tomorrow (as those are the only two currently-supported versions of MediaWiki, don't see a real need to backport to any other branch).

Cc'ing @Yaron_Koren as extension maintainer

The following patch should resolve the issue. I will submit this to gerrit (effectively making this issue public) once this is reviewed and relevant people are patched.

cc'ing ashley from ShoutWiki (if someone could add in some Fandom people as an FYI and so that they can patch before the issue is made public that would probably be good as well)

@tstarling any chance we can get this backported to 1.35 as well? I'm developing an extension making use of that hook and wish to support 1.35 with it (on account of it being LTS) and right now my options are to either only target 1.36+ or to use the legacy hooking system (losing all of the benefits of implementing the interface and getting guarantees on what the signature looks like)

CookieWarning should expose custom hooks that other extensions that integrate with it can use:

1. A way for extensions to tell CookieWarning what other cookies they are setting which would require consent and which categories they belong to. This is best accomplished by a custom hook imo
2. A way for extensions to check whether consent was given for a category in question. This is best accomplished by an API that extensions can call (e.g. a public static function) imo.

@lucamauri Sorry for the delay in response, got sidetracked with a lot of other stuff. That log is unfortunately not useful as it doesn't contain any of the API requests or responses. You can either try enabling the http debug log group, or enable the debug toolbar which also logs those requests/responses. Just be aware that the request will include things like plaintext passwords and auth tokens; you'll want to redact that from the log before posting it anywhere.

The code is fetching the correct properties; all successful API responses have a top-level element equal to the action specified in the request.

We now generate jobs proportional to the number of edits that need to be reattributed instead of total number of edits, which should reduce database impact by a lot. Some extra work is needed at import time to do this, however.

Random thoughts about my experiences with the RFC process:

It looks like the current behavior of the extension is to generate jobs for each block of 300 edits in the wiki, and then try to reattribute later within each block. So, if your wiki has 300,000 edits, each import would generate 1,000 jobs. This means that the majority of the jobs will actually be doing absolutely nothing, and it just serves to bloat the job queue.

What version of MediaWiki are you importing into (target wiki where MWA is installed)?

In T191231#5346642, @Anomie wrote:

In T191231#5346512, @Fheredia wrote:

Regarding Skizzerz said: "In any case, splitting DBMS out of core is an absolute non-starter until the installer can make use of them somehow without LocalSettings.php existing." it still looks like a good point to consider.

We're planning on doing the installer bit, and from private emails it sounds like Skizzerz is on board with that plan. As a rough straw proposal, we could have the installer detect database-providing extensions (via a flag in extension.json) and load them early for selection at the database setup stage of the installer. The one selected would continue to be loaded from then on, even before LocalSettings.php is generated.

In T226199#5337077, @Nikerabbit wrote:

The documentation states: "Allows extensions to add text after the page content and article metadata." and other code relies on the previous behavior. It doesn't matter whether it was right or wrong.

I’m going to be a bit more blunt here, since that seems that is required.

In T226199#5331432, @MarkAHershberger wrote:

This changed causes layout problems with SMW: "Move DataAfterContent outside of main content block" breaks Factbox display.

Is there any way to achieve what you want without breaking other extensions? Is there a way we could be consulted on changes like this before being surprised by them in the code?

@Krinkle Can you please point to a policy that all core features require someone at WMF to take "ownership" of it for maintenance even though there are plenty of parts in core and WMF-deployed extensions that are completely unmaintained by WMF? I am unaware of such a policy. This seems like a very odd double-standard where WMF employees can do whatever arbitrary thing they want, but volunteer developers have barrier after barrier erected to block their contributions and make them feel as unwelcome as possible.

Abstract schemas is an argument for keeping MSSQL, Oracle, and other lightly-supported DBMSes in Core, not splitting them out. Once we have an abstract schema, the supporting code to make use of it need only be written once, and that same schema can then apply everywhere.

I've tried two different devices and two different libraries. Checking my PC clock (one of the devices tested), it's about 1.5 seconds behind what the time.gov website lists as the current time.

I believe that the user stories mentioned in Goals adequately describe what this RFC is meant to tackle. If you disagree with some of the user stories, that is a valuable discussion to have. Many of these stories are things I have heard from other people across various channels. The "consistent DOM" point arose around VisualEditor rather than Gadgets, as VE expects certain elements to exist in order to power the editor interface. I mentioned Gadgets in the RFC to generalize it more as any js which would want to add things to a page needs to know where it should be adding it.

In T217158#5025694, @Jdlrobson wrote:

Why does the DOM need to be consistent? It certainly isn't in Minerva. I would truly value having a proper API for accessing skins via gadgets rather than relying on CSS selectors.

An elephant in the room is what will be happening to the DOM as a result of this RFC. As one of the explicit goals of this RFC is to unify DOM across skins so that Gadget authors don't have to do skin-specific things if they don't have to. This means, however, that the overall DOM of most if not all skins will change in order to make them unified.

In T217158#5019892, @Jdlrobson wrote:

Thanks for this clarification! FWIW any skin could copy BaseTemplate into their repo and/or we could leave it registered but deprecated and unused for several releases if need be. I do think templates serve a better purpose than this PHP class. Thanks for your patience with me!

This can move forwards without that RFC being settled yet. The work done on this patch set would help provide some of the work that's needed for the linked RFC, but additional changes will be required should the RFC be approved and work begun on it.

This RFC aims to deprecate BaseTemplate and as such make backwards-incompatible changes to the entire skinning system as a whole. This does not open up the option of using Mustache to generate parts of skins with PHP code to glue those parts together, it makes using Mustache mandatory for skins and eliminates PHP from the presentation logic entirely.

In T191231#5000601, @Freakolowsky wrote:

Honestly, unless you not only standardize trough abstraction the DDL, but also ALL of DQL and DML trough an abstraction layer without ANY hard coded SQL it's a loosing battle for anyone who picks it up. I doubt that anyone will be able to pull such abstraction off anyway. There were many attempts and it always came down to sacrificing WMF branch performance to maintain the abstraction or a heap of exceptions which never played well for others. I'd say it's a waste of time to even consider it.

Unless anyone has any lingering concerns or questions they'd like addressed before the RFC is submitted for TechCom perusal, I'm going to be moving this RFC along to the next step of the process in a few days (requesting an IRC meeting).

I opened the RFC T217158 due to the above change in gerrit that was made and reverted. I believe that an RFC is necessary for the expanded scope of making all skins use a template engine and have a mostly-consistent DOM between them. This task fits within the scope of the RFC I opened, and if the RFC is accepted, I would love to work with @Krinkle at moving this task forward in a way that serves the short-term needs presented here while still being usable for the long-term goals mentioned in the RFC.

In T201273#4844959, @Tgr wrote:

In T187634#4451554, @Skizzerz wrote:

A bot named WikimediaDevelop was recently k-lined from freenode by Sigyn due to sending a channel notice. Need to appeal the k-line (easy) and configure the bot to not send channel notices (just message the channel regularly instead).

In general, a channel notice (as opposed to channel privmsg) is synonymous with spam, and should never be done in the course of normal operation. Super important announcements may befit a channel notice, but nothing else should, especially not automated notices from bots.

@Skizzerz the bot sends plain text now (in theory). Where do I go to appeal the k-line?

I believe that patch execution fails:

Registering a freenode account requires email verification, and freenode is very picky about what email providers they accept (no temp/burner email accounts or email services without anti-spam measures on signup). In any case, it's a lot more work to have a botnet go through that process before spamming, so the spambots simply do not register accounts.

There is no quantitive data. The pingbacks are horribly inaccurate, especially insofar as enterprise installations of MediaWiki are represented. Corporate firewalls as well as an attitude of sysadmins to not share installation data by default both cause installation numbers (across all database systems) to be largely underrepresented. In any case, I know personally of at least 20 companies and government organizations using MediaWiki with mssql or that have used MediaWiki with mssql, and I would not be surprised if the true number was in the hundreds. Yes, this isn't much compared to MySQL installations, but it is a non-negligible number.

In T113831#4462876, @dbarratt wrote:

I think the majority want MSSQL moved out of core, but let's bring in some more voices into that.

Declining this task, as the structure to do this isn't nearly in a workable state. Moving out the Database class is about 10% of what is required here; the installer/updater need to work (keep in mind that LocalSettings.php doesn't exist when the installer is being run, yet that needs to be able to load the abstraction and schema). And, if the support isn't in core, then people will simply start using more and more MySQL-specific features making it impossible for an extension to work anyway.

A bot named WikimediaDevelop was recently k-lined from freenode by Sigyn due to sending a channel notice. Need to appeal the k-line (easy) and configure the bot to not send channel notices (just message the channel regularly instead).

In my opinion we should pick one datatype and standardize on it. Migrating existing columns to binary or utf8mb4 should be doable with a maintenance script, and these sorts of migrations and changes seem within scope for the schema abstraction RFC as part of the concerns there is taking the disparate environments of existing installs and standardizing them (although primarily with non-MySQL dbmses, but making MySQL focused on one and exactly one schema seems good as well).