Sat, May 18
Wed, May 15
Fri, May 10
The API request when you attempt to give the page N stars fails with the error code writeapidenied and the extended error info tells you that You're not allowed to edit this wiki through the API.. You need to set $wgGroupPermissions['*']['writeapi'] = true; in your wiki's LocalSettings.php to allow anonymous users to vote, because like so many other Social-Tools and other MW extensions in general, VoteNY basically relies on the (write) API being enabled.
Thu, May 9
Sun, May 5
Tue, Apr 30
Apr 22 2019
Opened https://gitlab.com/hydrawiki/extensions/DynamicPageList/merge_requests/95 for the latter issue as it appeared to be a two-line fix.
Apr 18 2019
Apr 16 2019
Apr 13 2019
Outside core user rights can and in many cases do exist without the corresponding action-* message, for the action-* message is primarily (AFAIK) used by the code in SpecialPage#checkPermissions which extensions can use when checking for sufficient access privileges in the execute method of a restricted SpecialPage; but special page extensions are hardly the only kind of extensions which exist.
Apr 11 2019
Apr 5 2019
Apr 4 2019
I imported the CreateBox code from Wikimedia's SVN (rSVN, path /trunk/extensions/CreateBox), cleaned it up a bit and made it compatible with MW 1.32.0 and dumped the end result on GitHub. Not quite the "shim" you were expecting, but it should work nevertheless.
Closing this as RESOLVED now that @Reedy has merged my aforementioned patch.
Global site-wide default theme is configurable via the $wgDefaultTheme global; on ShoutWiki this is default in GlobalSettings.php but can be/is overridden on a per-wiki basis when a wiki wishes to use e.g. Dark MonoBook as their default skin+theme setup.
Right now Theme includes the following themes:
Having played around with this when Oasis was released for the very first time...this is doable (in the sense that I believe just about anything is doable) but certainly not easy. Why? Your average third-party MW skin is pretty simple; your average legacy Wikia or ArmchairGM skin (AGM: Nimbus, Games; Wikia: Monaco, Quartz) is not simple but it's still...MediaWiki-esque. Oasis reinvents so many wheels it wasn't funny nearly a decade ago or so and it certainly isn't funny now.
Yeah, this was fixed a while ago.
Apr 2 2019
Right, that was a typo on my part; please do that in a follow-up patch (and add me as a reviewer)!
Apr 1 2019
Mar 31 2019
Not just a MediaWiki-extensions-PageAssessments issue but easily reproducible whereever a special page provides a search field to search (e.g. T218565 used Special:PageMigration, a special page provided by MediaWiki-extensions-Translate, and thus available on MediaWiki.org for example for privileged users). This issue is due to Timeless' CSS rules which, as noted in T218565, are needed to fix a different bug; this problematic behavior is also visible on pages where the mediawiki.userSuggest RL module is used to allow to search for a user account (e.g. SocialProfile's Special:GiveGift).
If after upgrading both your copy of the Timeless skin as well as that of MediaWiki to either the latest stable version or the latest Long-Term Support (LTS) Release you're still seeing this issue, please feel free to reopen this ticket with details on how to reproduce the bug. For the time being, as per @Izno's comment above, I'm closing this ticket. Thanks!
Mar 29 2019
Sure! Whenever you have a patch ready, please feel free to add me as a reviewer to it.
Mar 28 2019
Closing as no further details have been provided and I was unable to reproduce the issue back in 2018. If this is still occurring, please feel free to reopen this task with further details about the issue.
Per our IRC discussion, assigning to @Isarra so she can work on this during the next week.
Mar 27 2019
Mar 23 2019
Mar 22 2019
Hi @Onlyou408 and thank you for the detailed bug report!
Mar 21 2019
Mar 19 2019
Ditto; that's the error I also get locally when $wgReadOnly is set and I attempt to either submit a brand new feedback post or action the already submitted ones (e.g. mark as resolved, inappropriate, etc.).
Given that AFTv5 has been undeployed from WMF production, the logs aren't accessible at that URL either and one would need some SQL voodoo to fetch those...but in all honesty, either this was a temporary one-time hiccup affecting enwiki (and/or some other WMF wikis?) back in 2013, or then this was a real bug that got fixed at some point somewhere, wheter in the API-related code in MW core or in AFTv5. Either way, let's just close this as RESOLVED since based on some quick tests, it indeed is not possible to do AFTv5-related actions when the read-only flag is set.
Versioning is confusing anyway!
The "nonexistent message" was introduced in 9ac9a637792e97d903125074b683272fdd489274 in February 2012, replacing a prior console.log call which'd log the "helpful" string "error" and nothing else to the browser's JS console. The FIXME comment about a missing i18n message was added in early March 2012 in 8087227e394acb351f6cbad8dce4a2bc6932f76e.
Personally I'd really prefer if the error message would provide more context than just "Error" but even that is better than attempting to call a nonexistent message.
Mar 18 2019
Sounds like something that could be achived by subclassing ResourceLoaderWikiModule.
Mar 16 2019
@JamesBond.007 It's a very valid question, given that there's quite a difference between the standard desktop view (Vector skin), mobile view (Minerva Neue skin & MobileFrontend extension) as well as the officially supported mobile apps for the two biggest mobile OS platforms (Android and iOS).
Mar 14 2019
Mar 13 2019
Re-closing this as resolved since the aforementioned patch was already merged and as far as I can see, the issues mentioned here are fixed. Should any further i18n-related or other issues pop up, new, separate tickets can be opened for those.
Mar 12 2019
Mar 7 2019
Mar 6 2019
Mar 3 2019
Mar 2 2019
@TheROFL98 Thank you for taking the time to report this. As per social tools' compatibility policy, social tools target the latest stable release of MediaWiki and are guaranteed only to work with that, and the branched versions of the extensions are unmaintained. Basically, latest stable MW + master of the social tools extensions = works, everything else = unmaintained/not supported.
Mar 1 2019
This bug was caused by this changeset, as it de facto bumped up the MediaWiki version required to 1.33/git master, whereas Brickipedia was and is currently running 1.31. After we rolled back to an earlier version that did not include that change, page moves are working again.
Seems that Matthias Mullie wrote this feature back in 2013, but the patch was abandoned in March 2014 as support for AFTv5 was being dropped. It seems like something that could be resurrected relatively easily, though the Echo classes need to extend EchoEventPresentationModel these days (but back when the patch was written, that class didn't exist so all extensions wanting to implement notifications had to extend EchoBasicFormatter instead).
Feb 28 2019
Feb 27 2019
Feb 23 2019
Judging by the error message and line numbers, you're trying to use a REL1_28 (MediaWiki 1.28-compatible) version of Gadgets on MediaWiki 1.32.0 (in REL1_28, line 211 of /extensions/Gadgets/GadgetsHooks.php references the WrappedString class and L23 of the same file shows that unlike in more current releases, the WrappedString class is expected to exist in its own namespace, as opposed to in REL1_32 and master, where it exists in the "Wikimedia" namespace; see, for example, L24 and L222 of the REL1_32 version of Gadgets).
ShoutWiki would like to take over the maintainership of this extension for we have at least one wiki (Jedipedia, the Finnish Star Wars wiki) that would be interested in using the extension. Given that the extension has ~112 lines of code, it's considerably easier to install this extension as opposed to installing Wikibase and whatnot. As far as I'm able to tell, the extension is feature-complete and functional, which is why I'd like to question the original archiving rationale of "unmaintained and deprecated" -- it's deprecated for WMF usage only and perfectly functional elsewhere and most third-parties are likely to want to install this for this one particular feature instead of setting up a full Wikibase installation for a relatively simple and easy feature (listing of related sites in the sidebar).