Feb 26 2019
This is now merged, so I see no reason why it was left open.
Jun 9 2018
Apr 12 2018
@IKhitron, I did quite a bit of work on this, even though this isn't really relevant to me (I don't even use this extension myself). I fixed each and every one of @Tgr's comments since the last time you pushed for this. @eranroz did a +1 review, but I have no way of forcing someone to actually go through a +2 review. It also seems some work was done on this extension since then, which requires a proper rebase - I think I'm done for now.
Nov 20 2017
I'm not really familiar with BoilerRoom, as I've never needed that functionality myself.
It seems like you are looking for the functionality of Extension:BoilerRoom. Maybe it fits your use case better?
Aug 3 2017
You probably need to send @Yaron_Koren an email directly. His email is on every one of his extensions' pages.
Jul 28 2017
Jul 11 2017
@IKhitron, I'm still around. I just did not have the time to deal with @Tgr's review, as I did this fix as a distraction, and according to the best practices I could find (as in, copied everything from extension:Score, assuming what was good enough for one deployed extension would be good for another). I probably need to rollback the exceptions I added, and that's it.
Jul 2 2017
Jun 26 2017
Jun 24 2017
May 14 2017
@Krinkle, we're definitely not in agreement there - but I appreciate your thoughtful reply.
May 6 2017
Sorry for taking so long on this... I have uploaded a patchset with your changes and merged it, @labster, and will merge it as soon as gerrit allows me.
I'm busy with other things ATM, so I'll leave the improved existence-check to another time.
Apr 23 2017
Eran's comments? Yeah, a long time ago. You can see everything looking at
the change (https://gerrit.wikimedia.org/r/#/c/324722/).
Apr 22 2017
@IKhitron, nothing new, and I'm sorry to say this is usually what happens when I try to make small contributions - I have no idea how to attract +2 commiters to them...
and I believe ImageMap has no specific ownership I'll try adding @Tgr as a reviewer, since he is the only listed member in the ImageMap project on Phabricator.
Yeah, I saw what it was for, but I guess in a perfect world it wouldn't
trigger for a single quote (which isn't special syntax) or for quotes
around a single word (which, again, isn't special syntax AFAIK).
Apr 20 2017
Apr 14 2017
I did too...
Using WikiPage->getContent() is indeed the new recommended method (see docs/contenthandler.txt). I'll submit the above patch for review in a few moments.
Mar 25 2017
Sure, this is my responsiblity to maintain, after all. @labster, any particular form of credit? Currently it's just a line in the changelog:
- Version 1.0.2, 2017-03-25: A much improved query of pre-existing categories, by Brent Laabs (labster).
Hmm, yes, that makes a *lot* of sense :-)
I'll update the code soon. Thank you very much!
Mar 3 2017
@EBernhardson - I don't think so, because ElasticSearch 1.x is EOL. Running EOL software is kind of... wrong. There no sense keeping back-compatibility with EOL software.
Feb 3 2017
Thank you, @TheDJ! This is great :-)
Feb 1 2017
It really should... 1.27 is the LTS release, after all (I just spent almost an hour digging through WikiEditor until I found the problem, and only then found this phab issue).
Dec 14 2016
This is very old and I see no current interest, so I'm declining this. Anybody can reopen if interested.
Dec 6 2016
Well, I didn't just backport it myself because I wanted to make sure with @daniel that this isn't dependant on other changes, so I fully agree with your tagging :-)
Dec 4 2016
Dec 1 2016
Anybody wants to review this? Basically I just copied stuff over from extension:Score, even though there's no indication if their way is the recommended one.
Nov 22 2016
I think there might still be an issue related to getEffectiveGroups():
- Using api.php?action=query&meta=userinfo&uiprop=groups, I'm not getting all the groups of my user.
- Using api.php?action=query&list=users&ususers=my_username&usprop=groups retrieves the correct groups.
Nov 6 2016
Hi Cboltz, I definitely symphatize with the overfilled todo - my queue never empties too - but this means the patch is just not good enough to make it into the code, which requires proper documentation and no loss of functionality.
Nov 3 2016
Is anybody actually interested in this?
If nobody replies in the next month or so, I will close this as 'declined'.
@Cboltz, first of all: thanks!
This is an extremely old plan by the original author of the extension. Because of the following:
May 26 2016
May 21 2016
Resolved with the merge of 260516.
Apr 9 2016
Apr 1 2016
@violetto, any obvious next steps you can think of?
Jan 18 2016
@Jhf2442, mind doing a quick review of my changeset? It'd be nice if I don't just self-merge things all the time, and besides, this is just small change upon your work.
Dec 24 2015
@Jhf2442, I uploaded a new changeset (somehow Gerrit hasn't notified Phabricator yet):
- The same change had to be applied for the special page, otherwise it broke (yes, code duplication is evil and should be remedied)
- I cleaned up the code in that part ("$things", really? talk about descriptive names)
- I documented the option in the README and the new version in the CHANGELOG (trying to set a good example in documenting stuff)
- I added your nick as an author/contributor. If you prefer a different wording for your credit, upload a new changset or let me know and I'll do that.
Dec 22 2015
@Jhf2442: I'll look at this now and merge.
Dec 3 2015
@Jhf2442: I'd like to move away from a wiki content model eventually and to cut out all this regex, but in the meantime, this is probably a good idea (even though it's not a use case of mine). I'll try to test and add it soon. Thanks!
Jul 28 2015
This makes no sense to me personally, and was submitted long ago without a use case, so I really can't see it as relevant. In an attempt to de-clutter things, I'm closing this as wontfix.
Jun 24 2015
May 25 2015
@Isarra, the terminals are very close together (a 2 minute drive terminal 2->1, terminals 2 & 3 are right next to each other).
So, is this a fair summary of our discussion?
My flight is at 12:00pm tomorrow (26th), flight TK1808 from terminal 1. I guess there's no reason to leave earlier than 9:45-10:00 by taxi. Anybody else?
May 24 2015
Cool. See you there :-)
May 23 2015
Well, I'm willing. Any other takers here?
Truthfully? a too-fancy way of saying "*any* ideas you've already came up
The textsize buttons are very clear, but do you feel that the contrast buttons are self-explanatory? I'm not sure.
@Isarra, do you have any established ideas regarding this?
@Krinkle, aren't we done with this now? Can we close it?
Actually, maybe update [[Manual:Extensions#Installing_an_extension]] and turn the template into a link only.
An even shorter title: "MediaWiki in space, by NASA".
May 21 2015
May 19 2015
Apr 4 2015
As robert mentioned many years ago, this seems out of scope for the extension. I'm considering creating another extension that will simplify doing this through WikiEditor, if one doesn't exist already.
Mar 24 2015
Seems to be fine now. @Nemo_bis, please approve :-)
Mar 20 2015
This bug should be closed as invalid; the original bug, T59732, should be a request to (operations project "operations/mediawiki-config"). It's not even a new request, just a typo fix. @Nemo_bis, @brion - know anybody we could ping?
So, it's a silly little thing - it's $wgDismissableSiteNoticeForAnons (an "s" at the end), but the config files (CommonSettings.php) have:
$wgDismissableSiteNoticeForAnon = true; // Bug 57732
No, that's great - thanks! I'll try to look into it.
I actually have no idea where to find *local* sitenotices. Could you point
me at one so I can try to debug?
Mar 19 2015
Nemo, looking deeper into the CentralNotice code, I can't see anything that prevents anons from dismissing the notice. Could it be a specific banner that didn't have a close button added to it for anyone, anon or logged-in? Apparently this isn't automatic with CentralNotice, probably in order to allow styling it individually. Could you point to one such banner that you can't dismiss?
Mar 18 2015
As I mentioned in ! In T59732#1130711, this won't actually have an effect, because CentralNotice uses its own banner-hiding code.
Apparently, even though I was worried about the effect on Wikimedia sites, I needn't have - CentralNotice uses its own code (bannerController.js) for hiding banners. Makes sense, as it needs a more complex mechanism - like hiding banners of a specific group (like "donations"), and not all banners whatsoever.
Forgot to mention this in the commit... just released 2.0.0, which takes care of this.
Mar 11 2015
Feb 27 2015
It's actually an old configuration variable re-introduced...
BTW, doesn't CentralNotice have its own banner-hiding code, and therefore
this can't be tested on WM wikis?
Feb 26 2015
The default is "off", to preserve the current Wikimedia behavior. I believe
enabling this on Wikimedia wikis is a separate request...
Feb 24 2015
Coming soon... the patch described above works well enough, and I will soon commit a new version (after testing).
Feb 11 2015
Old bug for a very old version. Closing.