Sun, Nov 22
Fri, Nov 20
I feel inclined to point out that the ugliness in Social-Tools predates MW's stable interface policy by years. :) As always, better solutions are more than welcome.
Thu, Nov 19
Wed, Nov 18
Mon, Nov 16
Sat, Nov 14
Fri, Nov 13
Thu, Nov 12
Wed, Nov 11
Mon, Nov 9
Sorry, there was a typo in my original comment, the "confirmed" should have been "configured". That's to say, the global links menu isn't showing up unless you created the on-wiki page, MediaWiki:Global-links-menu, which sets it up. If that page exists, try either deleting it or setting its content to - (just a single dash character and nothing else).
So just to clarify that we're on the same page, @Volker_E ...you are proposing that we reopen T65521 and reintroduce a lot of unnecessary code duplication because the current module implemention has some bugs. Why not to fix those bugs? (Full disclaimer: I collaborated with @Isarra, @matmarex and @lcawte on T65521 and I might've written a skin or two over the years.)
Sun, Nov 8
I cannot figure out how this relates to ArticleFeedbackv5 besides that the report title has "OH-AFT" in it (though I have no idea what "OH" stands for) and the original report URL has some AFTv5 query parameters in it, which mostly seem to relate to AFTv5 bucket selection.
Sat, Nov 7
Still present in master (L3903). The associated code comment notes: TODO: hard deprecate old hook in 1.33. master is now on 1.36 so maybe it's time to do something about this?
There aren't that many DOM differences between Daddio and Modern. Portlets (/skins/Modern/templates/Portlet.mustache) use h3 on Modern and h5 on Daddio. div#footer is wrapped in a new, separate div which has the ID mw_bottom, which is not present in Modern.
Fri, Nov 6
I do want to note my objection to the use of the word "unmaintained" to describe several ShoutWiki skins (Bouquet, Dusk, DuskToDawn, Gamepress, Nimbus, Refreshed, Truglass) as well as some of @Isarra's skins (HasSomeColours, Mask); additionally I sorta maintain MediaWiki-skins-WebPlatform and WPtouch. @SamanthaNguyen is the primary author of MediaWiki-skins-Amethyst and has recently contributed to Cosmos.
Probably a duplicate of T254302.
The global links menu ([[MediaWiki:Global-links-menu]]) is supposed to show up only when that MediaWiki: message has been defined with some content; by default the message itself isn't even defined (because it's used across many skins, so defining it in only one skin would likely cause some unexpected side-effects). As intended, after installing the skin, the global links menu does not show up unless explicitly confirmed; tested on MediaWiki 1.35.0 and the git master version of the HasSomeColours skin as of a few minutes ago.
Thu, Nov 5
cc'ing @Bawolff for thoughts
Wed, Nov 4
Sun, Nov 1
Sat, Oct 31
Fri, Oct 30
Wed, Oct 28
Tue, Oct 27
@Legoktm Thanks for the CR! While attempting to implement your changes, I found a few more nasty stored XSS lines in that same file...here's a new patch which hopefully catches 'em all, for good this time around.
Mon, Oct 26
Proposed patch which fixes the issues noted here and includes some unrelated no-JS work (T248390); the relevant chunks are obviously the ones where htmlspecialchars is mentioned, except for the last one ("next poll" URL stuff), that's strictly no-JS related and not related to this ticket.
Sun, Oct 25
Proposed and tested patch which adds relevant, missing htmlspecialchars() calls to all three callback functions to ensure that whatever is stored in the DB is properly sanitized before being sent back.
Oct 24 2020
Thanks for the report! Fixed now with the aforementioned patch.
Oct 23 2020
Oct 21 2020
Nice catch, thanks for reporting! Fixed now in master.
Oct 9 2020
I can't reproduce this locally. The only way I can trigger that particular error is by trying to create a blog page with the precise same name as an existing one via the Special:CreateBlogPost special page. For example, my localhost wiki had a page titled Blog:Another test, so when I entered Another test as the title on Special:CreateBlogPost, the error would be displayed, the page would not be created and I would correctly be prompted to change the title. Adding a character to make the title unique (for example, Another test2) allowed the page to be correctly created.
Oct 8 2020
Oct 6 2020
Sep 24 2020
Like with other ShoutWiki maintained extensions, the compatibility policy is basically "latest stable version OR the version used by ShoutWiki with the latter given preference should these two differ". If and when HHVM support is gone, code related to it can safely be removed from here. Obviously things change quite a bit in 4 years. :)
Ah, thanks for the explanation, @Ammarpad! I've submitted & merged a patch which should take care of this, even if I wasn't able to reproduce the issue on my own.
Sep 11 2020
Went ahead and decided to be bold and created WPtouch. :)
Is this still a problem in git master? Normally these sort of errors are rather easy to fix but looking at this particular code, I cannot fathom why it'd fail. UserSystemGifts' constructor intentionally accepts both strings (user names) as well as full User objects; assuming a string is provided, User::newFromName() is called on it to turn it into a User object. There is some potential for failure here as the code does not ensure that the aformentioned call to User::newFromName() indeed returns a valid User object, but provided that you're logged in and all, I think it's safe to say your user name is valid at that point.
Thanks for reporting this! Should be fixed now in master.
Sep 7 2020
This seems to be done by the older word wrapping fix in /extensions/WikiForum/resources/css/styles.css, specifically the word-break: break-all; rule on td.mw-wikiforum-thread-main. At a glance just removing that looks like it'd fix something but probably breaks something else. The main gotcha here is that WikiForum and SocialProfile do not depend on each other, thus avatars *can* be available but they don't *have* to be, which is what's causing some interesting things to happen, CSS and design-wise. (There's also the fact that WikiForum hasn't been touched in quite a while.)
The WPtouch skin is available for download for version 1.34 [--]
Indeed, this is because branches are created automatically whenever a major version of MediaWiki is released, regardless of whether a skin/extension is compatible w/ that MW version or not. (Coincidentally this is also the reason why I recommend for users of social tools to use the latest stable MW version + master version of the extensions and pretend that the always-outdated branches that literally nobody maintains just don't exist.)