Mon, Aug 3
Sun, Aug 2
Sat, Aug 1
Wed, Jul 29
Tue, Jul 28
Thanks for the patch @Jdlrobson, much appreciated! Unfortunately I don't have a master devbox set up currently so I'm not able to test out your patch right now. I do know for a fact that ShoutWikiAds is a mission-critical extension for ShoutWiki and the placement of ads can be rather particular. Luckily the extension is somewhat testable; something like this in your wiki's LocalSettings.php should work:
Hey @SamanthaNguyen, could you please indicate the steps to reproduce the error? What's the namespace for accessible PictureGame?
Wed, Jul 22
I was still having the issue after that patch, but I found that it's fixed if you also change$this->msg( 'ga-back-link', $gift['user_name'] )->escaped() .
in SpecialViewSystemGift.php to this:$this->msg( 'ga-back-link', $gift['user_name'] )->parse() .
Tue, Jul 21
Jul 7 2020
Jun 30 2020
Mostly (though not completely) resolved by the aforementioned patch, hence closing this task.
Jun 28 2020
Yeah, this was fixed back in March.
I guess this is now resolved since I merged the patch earlier this month.
Jun 24 2020
As we discussed on IRC, this was apparently caused by an incompatibility between Comments and MediaWiki-extensions-CommentStreams, for the constructor method for Comments' Comment class was, is, has always been and remains public. Your CommentStreams patch hopefully addressed this incompatibility in an adequate manner.
Jun 16 2020
Jun 13 2020
Jun 12 2020
The whole API module was removed in 6b108f850027baa93ba3bc7109e9671bc6f2271b so thus the message is also gone.
Thanks for the bug report & fix! I've submitted it to the repository & merged the change.
Jun 9 2020
Can't speak for the WMF's analytics setup etc. but in general mw:Actor migration is a thing, so yes, attempting to use rev_user and/or rev_user_text would indeed result in NULLs. You'll need to JOIN the actor table (and for the time being, the revision_actor_temp table as well).
Update Comments and/or SocialProfile and/or any and all other Social-Tools to their latest version (master, not REL1_34 or any other release branch version! See social tools' MW compatibility policy for details.) Comments hasn't referenced SocialProfile's user_stats' stats_user_id field since late January 2020 (7c9a27d996aa27b3cb7669c28b96784e19ff3dd6).
Jun 6 2020
Jun 5 2020
Jun 3 2020
SkinTemplateToolboxEnd is super legacy and basically all even remotely maintained code uses BaseTemplateToolbox instead. That being said, almost (if not) all skins implement SkinTemplateToolboxEnd currently, so we should remove that technical debt from all other skins as well while at it.
Jun 1 2020
May 28 2020
May 26 2020
May 25 2020
Alright, with the aforementioned patch being reviewed and merged, all that's left here is to close this task and make it public. Could someone do that, please?
May 24 2020
May 23 2020
Proposed patch, which also contains parts of T248390: Better NoJS support for PollNY because splitting them up would've been quite a pain.
May 22 2020
Should be mitigated by 8e46a284bd7d80c3d2a09d2db1064144cb1767f0 (already merged a few days ago), but please check.
May 18 2020
May 16 2020
May 1 2020
Apr 13 2020
This is sorta "by design", although I do agree that this is a valid feature request/bug report.
Mar 30 2020
I'd like to propose keeping some of these hooks, at least:
Mar 29 2020
For what it's worth, I don't think it's a good practise to archive extensions without ever contacting their maintainer(s)/author(s), especially as in this case the maintainer/author -- me -- still happens to be around.
I'm aware of $wgReadOnly and such; what I'm not aware of is how exactly its existence obsoletes the very useful special pages. At ShoutWiki we regularly use those special pages for locking and unlocking wikis, as using an on-wiki special page does not require server access and it's thus theoretically possible to even create a user group which can (only) lock wikis without giving the relevant users server access. (Plus, let's be fair, even if you do have SSH access, special pages are so much easier to use for tasks like these.)
Uhh, wait what? Why?
They are long deprecated feature.
Mar 26 2020
Mar 25 2020
Reopening since the task itself is very much valid and something that should eventually be done, though it isn't quite as simple as "just run convertExtensionToRegistration.php on it and commit the result" since the AJAX code (/includes/specials/SpecialCreatePage_ajax.php) needs to be rewritten as API modules, given that extension registration intentionally does not support setting $wgAjaxExportList in an extension.json file.
Mar 24 2020
Mar 23 2020
Mar 18 2020
Per mw:Social tools/MediaWiki compatibility, the only supported combination is latest stable version of MediaWiki + master version of the desired social tools; any and all other combinations, including whatever you're trying to do here, are unsupported. Sorry. Please upgrade to MediaWiki 1.34 and try installing the master version of Comments and it should work. If not, please file a new bug.
Mar 15 2020
Mar 14 2020
Mar 13 2020
@ashley if this is still desired (per above comment), should it still be stalled?
I'm not sure why this seemingly simple request has now taken 3+ years to be completed, frankly. I'd have done this myself years ago but to the extent that I'm aware of, I don't have the relevant access rights to create these kind of groups. That being said, my comment from 2018 is still as relevant now as it was when I originally posted it, for better or for worse.
Mar 11 2020
You might want to use the error code sessionfailure for the case the token doesn't match.
Otherwise this looks good.
Mar 10 2020
cc @Bawolff for CR
Mar 4 2020
Thanks for the report, this should now be fixed in master; can you update your copy and see if I'm correct & then close this task if so?
Mar 3 2020
Feb 28 2020
Hi Tim, thanks for taking the time to report this!
Feb 27 2020
@ashley I was going to update UserProfile::getProfileComplete to accept a user as a parameter as part 4, but it doesn't seem to have any calls: https://codesearch.wmflabs.org/search/?q=getProfileComplete&i=nope&files=&repos=
Is it safe to remove?
getProfileComplete was originally used by various ArmchairGM skins; as the current documentation notes, it is indeed unused currently but, I quote, "looks useful enough to be kept around". You should be able to swap the global $wgUser to $this->user in that method to update it to have the global removed since it's not a static method.