- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Wed, May 1
Mon, Apr 29
Apr 8 2024
Yeah, I have had a Gerrit account for seven years but I have finally gotten around to figuring out how it works. Hopefully this is what you need.
Apr 6 2024
Oct 4 2022
In T236809#6164955, @thiemowmde wrote:The release notes currently say:
* The following parser-related hooks have been deprecated: […] - ParserSectionCreate * No replacement; <section> tag wrapping will be done by core in future. - ParserPreSaveTransformComplete * No replacement; Content::preSaveTransform() provides for customizable PSTs - BeforeParserrenderImageGallery * No replacement; MediaHandler provides for customizable media renderingI'm not exited to see "no replacement". What I wish we would have done is to first get rid of deprecated calls in codebases we actively monitor, and only then hard-deprecate stuff. What are the next steps now? Rewrite code that relies on these hooks? Who is supposed to do this? When? Consuming which budget? And a rewrite seems what's now necessary to keep the Wigo3 extension running.
I don't own any of the codebases in question, so I have not much reason to care about them. I'm not even paid to look after them. But what I care about is that we try to help volunteers as good as we can. And I think we can do better.
Dec 28 2020
It is a public wiki where it could be seen three years ago for a couple months. It has since disappeared -- not sure if there was some maint script that has been run in the meantime, but there have been several MW version upgrades since then. Likely pages added to the category, too. Can no longer reproduce, sorry.
Jan 10 2018
It's not as big of a a barrier to contribution as you think. Generally, when I want to commit something on a project hosted by WMF, I push a commit to somewhere else like Github, and then ask someone else who understands Gerrit to merge it. Usually, this is the extension developer, and from there they can either do git remote add or download a patch file.
Sep 16 2017
This one is marked as resolved in our tracker at Miraheze, @Reception123. Is it ok to close this bug, or did someone find the cause?
Aug 28 2017
May 21 2017
Huh. I didn't expect when I wrote this ticket that it would be resolved by deleting all the documentation. Thanks, I guess?
Apr 17 2017
Well, I'll fire our sysadmins just as soon as I start paying them :P
Mar 25 2017
That credit works for me.
Hi, I'm here, a little. Just going to say that caching the entire category namespace sounds like a nightmare, if only because of the cache invalidation problem. So I just removed the TODO, because that seems like the Wrong Thing.
Feb 13 2017
Just want to let you know that this task is what kept us from installing this extension on allthetropes.org. Using an unsupported third-party library doesn't inspire confidence from a privacy point-of-view.
Feb 10 2017
Just a comment: this seems like a cleanup here would be a easy task. The body file is under 200 lines of code.
Jan 18 2017
Just because the issue has come up again and I've done more reading since then... apparently <html> and <body> elements aren't required for valid HTML 5. But the <!DOCTYPE html> is missing, and that is required. Same suggested solution as in the comment above.
Jan 15 2017
Dec 29 2016
Thanks for the quick turnaround!
Dec 25 2016
Dec 24 2016
Dec 17 2016
Ah, OK. You just said "already fixed in master" and assigned a duplicate task that is already closed, but didn't say that there was a fix for this branch. I assumed that you didn't understand the request.
If you're not going to fix the problem, don't just close the ticket resolved. I'm taking this to mean that you're declining to fix this issue.
Dec 12 2016
Your guide seems pretty good, I'll give it a shot the next time I think of a patch. Actually, BlogPageClass.php is taunting me with:
Nope. The sectioning is done here:
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/MobileFormatter.php#L541 That looks complicated.
As of iOS 10, all pages are zoomable. There is no API to prevent zooming on a page.
Dec 11 2016
Dec 5 2016
You chose the worst day to start working on this as our db server decided to crash today. I'll get back to you when we're back online.
Nov 14 2016
Nov 5 2016
Oct 16 2016
Oct 7 2016
Can anyone take over maintainership for this extension?
Oct 5 2016
I don't understand. How is mw-editsection-divider an internal class for VE if it's in includes/skins/Skin.php? And if SkinEditSectionLinks is not a public API, why is it mentioned in docs/hooks.txt as replacement for a different public API?
Sep 26 2016
Sep 25 2016
Sep 21 2016
In terms of the DOS attack @Bawolff mentioned, maybe ini_set on some PCRE options would be useful?
Sep 3 2016
No activity in over 3 months. If no one is interested in merging this code, can they please decline the task?
Aug 7 2016
If you are unable to upgrade to PHP 5.5.9, then you can use MediaWiki 1.23.13, which requires PHP version 5.3.2 or later
As far as I can tell, SQL Server does not support regular expressions -- or at least not without using a CLR function.
Jul 31 2016
Jul 21 2016
Thanks, this is great work. Sorry I didn't reply earlier, as I've been swamped by $dayjob stuff. I do have some other suggestions, but I'll reply in T140941.
May 22 2016
I just suggested updating the extension because I thought it would be easiest. If you want, you just just do some HTML filtering in the original extension -- a good place to start would be here:
We're nearing 2 months since I first reported the vulnerability to the authors. Is there any WMF guidance as to how long before I can publicly disclose the vulnerability?
May 16 2016
May 9 2016
OK. If wfLoadExtension is recommended, then there was a docs bug on https://www.mediawiki.org/wiki/Extension:Comments I went ahead and added registration=1 to the install template.
May 6 2016
Oh, right, I have $wgShowDevelopmentWarnings = true;, but doesn't everyone? 🤓
May 2 2016
The same thing applies at https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FComments/master/CommentClass.php#L175 and L317
May 1 2016
Agreed, documentation is extremely poor.
Apr 25 2016
That was me informing the authors. With the same message as above. Felipe Schenone replied back to me with this message on 30 March:
Apr 24 2016
If it is intentional, I suppose we could host a fork of this. All we'd have to do is delete a few lines from the extension.json file, track upstream otherwise, and warn people outside the WMF to use our fork instead of the official one. Somehow this solution seems suboptimal, but I'd be willing to do it.