it's 2020, support for generic web notifications is wide enough now.

mm I guess easiest way is to check if the user is already online when they load Special:Chat. Shouldn't be too hard

cheers for your work on this guys

hmm, wonder why I ever wrote GlobalContribs if GlobalContributions was already there, be it defunkt

I reckon this can be closed now if people agree?

done and working

ahh typed in the wrong bug number, new commit is here https://gerrit.wikimedia.org/r/#/c/329687/

Having just implemented that, I actually think that

* >:-/ >:/ >:( >:-( >:O >:-O NE24.gif
* :) :-) smile.gif

would be a better way, so I'll do that

Sure, if the people who want access can give me their email address I can share the folder with them

ooh, also, I'll need to update and re-enable those extensions I disabled (just putting it here so I remember)

btw, once this is merged, any feedback/alteration to the graphical design would be welcome

I might suggest something more like

* >:-/
* >:/
* >:(
* >:-(
* >:O
* >:-O NE24.gif
* :)
* :-) smile.gif

as it would be backward compatible, making shipping the update much easier. (As the old syntax would still be valid)

hmm, I can't reproduce this on chrome

I've changed the animated dots to a loading gif, so there should be no CPU drain now.

snippet was really created specifically for Brickipedia, and given T154220, I'm never gonna do this, so I'm closing if that's okay

This is a little DIY loading GIF which is set to visible in the time between sending your message and it appearing on the screen. On a fast wiki like en .bm this is a very small period of time, but on other wikis it can be much longer. It's strange that some computers horifically struggle with this while most take it fine, but I'll work out how to stop the animation when the dots aren't shown.

ooh cor,

$wgLocalDatabases = array( "en", "customs", "gbc", "ideas", "meta");
$wgConf->wikis = $wgLocalDatabases;

brings back some memories. I feel like I may have tried to use this for global new messages or something, can't really remember. According to https://www.mediawiki.org/wiki/Manual:$wgConf it used by CentralAuth which we don't use, so I suspect it is safe to remove. Only way to know is to test though...

All the current DBs are backed up, and they come to a total of 803MB, although that does include some older ones like nl, dev, answers, etc

could be implemented in T151514

could be implemented into T151514

Sounds like a good idea

This is technically quite hard to implement, given the way MWC stores messages at the moment

Right, as George said, there's a daily DB backup which is stored on our server, and then on my dropbox. I'm happy to share these with anyone, the ones on the server are at /home/nxt/Dropbox/backups and any sysadmin can get to those (using root)

Right hold on, those examples there are referring to using sockets to send messages (this is when the client and the server keep an open connection on which messages can be passed). MWC uses polling however (a new connection is made every so often to check if there are new messages, then closed). This is still a valid suggestion however.

should be fixed

mmm well resolved as it's fixed, there just may be a better way of doing it.

BeforeParserrenderImageGallery would be the one

(from chat, here so I remember it) I guess you could hook in, then check the page title, and if it's wikiforum, load the module. Such effort though

Okay I've spent a while looking through the source trying to find when mediawiki.page.gallery is loaded, and can't, so I guess we'll just have to load it on every wikiforum page.

Yeah, mediawiki.page.gallery.styles isn't being loaded. Loading it specifically isn't gonna be the best way of doing it as then it'll be loaded even when there's no gallery. Not sure what the best way is though.

It feels like there's some sort of stylesheet that isn't being loaded when it should be

@SamanthaNguyen what do you think about closing this as the top case listed above no longer exists in the code, and the bottom one can't be moved into CSS due to the PHP in it?

okay looks like this can be done then

oops hold on

oops, wrong bug number, you can ignore that gerritbot message

Of the two cases listed above, only the bottom still seems to exist in the code, and that can't be moved into CSS due to the PHP stuff, so I suggest this is closed?

Would this actually be possible?

Okay, this is T4700

hmm, looks like there is some sort of pre-parsing for this trick: https://en.wikipedia.org/wiki/Help:Pipe_trick

Hmm, I'm pretty sure I remember there being some code for this, so I'll have a look.

Ooh I didn't even know that was a thing in normal wikitext... :D I'll have a look, I would have expected that to work as I thought MWC used the same parser as normal wikitext.

My apologies guys.

Sorry should say, we are MW 1.16.2 and thanks 1.2.0 (2ee8d58)

This is breaking history and diff pages on our site

I'm on it

I've realised this is to do with XDebug, and not a core PHP/MW thing.

Sorry about this. No more references to those old columns now, I've grep'ed as well. While I was at it I rewrote a bit of the comments of the day stuff that hadn't been updated last time.

Oh, my apologies, so there are. I'll get on it.

@Aklapper @Tgr sorry it's late, here we are:

Which version of comments (commit hash if possible) are you using? The function CommentsPage::getCommentList which is causing this error no longer exists, it was removed in december. The rewrite in december removed those columns, but also removed that function - is it possible there is a mix of versions going on?

Also getting this on http://meta.brickimedia.org. Like Grondin, ack-grep just gives me the one expected find.

Yeah, this patch inserts <br> tags after == titles ==, preventing them from rendering. I'm afraid for the mo I'm going to disable this though, as there is no simple fix, and mucking with the parser is not something I want to do lightly - ie we should keep it as similar to the standard parser as possible.

This seems to be breaking some of the parsing, == titles == are no longer parsed when this fix is in place. I am not sure why though...

Ahhh sorry it seems I'd done it wrong

What Lewis said there is exactly what I'm doing (total coincidence though, I never saw that!)

Oh, sorry about that.

Well $wgEnableSidebarCache was not set at all, and I'm told the default is false, so I assumed we had no caching. I just set it to be false in localsettings, and that's fixed it, so there was some sort of caching going on there, but it's fixed now, cheers.

Done.

I'm about to do this. I'm not going to add a config variable though, as I can't see this as a feature anyone would want to turn off.