User Details
- User Since
- Mar 29 2015, 10:29 PM (379 w, 9 m)
- Availability
- Available
- IRC Nick
- MGC_
- LDAP User
- MGChecker
- MediaWiki User
- MGChecker [ Global Accounts ]
Wed, Jun 8
May 31 2022
May 8 2022
Apr 19 2022
hmm. I mean it is an Danwe parser extension. It probably still works for now, and is installed on Wikis on 1.37.0 according to Wikiapiary.
Mar 9 2022
You can check the log to understand its behavior.
Feb 4 2022
Nov 14 2021
Nov 9 2021
Sep 24 2021
I am curious: Where has this topic come up recently?
Sep 21 2021
I deem it highly unlikely that a group like that would be added on a single community's request. We usually try to not bloat configuration settings to much, and your request could only be done by doing so or by adding one highly specific user permission which would not serve the potential needs of other communities.
Thank you, this is everything I asked for! From my side, this can be marked as resolved then.
Sep 20 2021
I have to admit that I have not been to mindful to making this information more widely accessible. I do not consider myself a real author of the extension, so I have not added my name on the respective places. I have added respective indications now.
Thanks for the task, but it's very unclear what the problem is, and what you're wanting doing.
Sep 18 2021
On dewiki, this has been used occasionally: https://de.wikipedia.org/wiki/Spezial:Logbuch?type=stable&user=&page=&wpdate=&tagfilter=&subtype=
This is the main mode of FlaggedRevs used in enwiki, and is quite popular there. In dewiki, it is used occasionally as well.
Sep 13 2021
With the patch merged, is there anything immediately left to do here?
I think with the code published on GitHub, there is not really a thing left to be done here.
This has been a bug in the 1.0.0-beta version, which is still in (quite stale) development. On current master, the variable should work as expected.
Jun 9 2021
Jun 6 2021
Jun 3 2021
Considering how Phabricator was maintained so far, I think that it might be possible for a small team to maintain it.
May 30 2021
May 28 2021
Took care of unarchival on Diffusion.
May 10 2021
@RobinHood70 Since, in my experience this can be helpful to have everyone aware what is actually talked about: Is your custom preprocessor implementation published somewhere?
If this is a real blocker, then, we'll have to introduce some kind of page property OR some kind of extension config option that will force full sequential reparse for any page that has that flag or extension config set.
To me that sounds like the Parsing Team is open to modifying Parsoid to support your use case.
Apr 27 2021
I like this idea quite much, as it would be an approach to incorporate Variables into Parsoid core. Exposing this caching would be a new feature, I think, which would rather be related to Variables than a replacement. I propose to bring this idea to the attention of the parsing team.
Apr 1 2021
Done.
Mar 22 2021
Mar 20 2021
Mar 16 2021
Mar 15 2021
The thing is that i am in over my head here. I was able to pick up and modernize this extensions regarding best practices, extension registration, and do some basic bug fixes and so on. However, the nuances of the MediaWiki parser and Parsoid in particular escape me. (And the parser documentation is horrible.) And these are points with significant security relevance too – at the moment I am wondering if the migration from ParserBeforeTidy to ParserAfterTidy has not introduced various security holes, since the output of these extensions is apparently no longer tidied. I do not want to be reponsible for introducing serious security vulnerabilities into thousands of wikis.
Mar 6 2021
See T236809 for further information. I do not think this can be really worked around, which makes this a wontfix.
Mar 1 2021
Feb 25 2021
Is there anything left to do here?
Feb 8 2021
Feb 4 2021
@hashar Afaik, Diffusion repositories should only be deactivated after the archival commit from Gerrit is mirrored over. Otherwise, they won't be updated.
Feb 3 2021
Jan 24 2021
Well, whereever in Ladsgroups current code we have wgNamespaceNumber we could just have a list of all globals which need replacement. In particular, this means we do not have to visit wikis multiple times.
Wouldn't it be easier to just replace all variables at once?
Jan 23 2021
I'm not 100% sure, at least I think we must clean mw namespace first before moving forward. I have been fixing cases in Common.js, we can't break a whole wiki because they are too small to have tech savvy admins.
Jan 18 2021
Jan 13 2021
Dec 23 2020
Is it possible to add me as a subscriber to the relevant tasks, so I can take a look at them?
Dec 16 2020
This sounds really promising! However, I would like to hear from the maintainers of this extension before initiating anything further.
A look at WikiApiary tells that this is the second most popular Mediawiki extension which is not deployed by WMF and the 21st most popular extension in general.
Dec 11 2020
Dec 8 2020
Nov 25 2020
Diffusion needs some time to sync its mirrors so the skin is shown as archived here as well.
Nov 23 2020
Oct 27 2020
This is just stale…
Oct 23 2020
Oct 17 2020
Oct 9 2020
You did not specify any extension/skin here. After doing so, feel free to repoen.
Sep 10 2020
Jul 20 2020
Jul 19 2020
Jul 13 2020
I think the way forward proposed by the patch is confusing. Either we should remove the setting altogether, or keep it functional for another version of MediaWiki. Removing its functionality without removing the setting seems unhelpful at best.