Thu, Jul 18
Per discussion with @Isarra, closing this task now that the aforementioned patch has been merged.
Mon, Jul 15
Sat, Jul 13
Thu, Jul 11
@zeljkofilipin Pinging you here as per discussion on #wikimedia-releng. Thanks in advance for any and all insight you can provide into this!
Wed, Jul 10
Thanks for the report, fixed in git master!
Sun, Jul 7
And that's now done and the patch is merged (though not yet live on ShoutWiki), so closing this ticket!
Fri, Jul 5
Patches welcome. :)
Thu, Jul 4
Jun 2 2019
The original Trello ticket detailing this issue, complete with a user-submitted screenshot, was created on April 2nd and while my memory is a bit hazy, I think I fixed it within a couple days of reporting, which'd get us in the April 4-6 range or so; that being said, I'm quite sure we were using MW 1.32 at the time regardless.
On Inciclopedia (the Spanish Uncyclopedia, an Uncyclomedia project), we had a similar issue with the oldest log entry (a user rights log entry, also from 2006) having a bad log_title, which contained a trailing underscore for whatever reason (which MediaWiki correctly normalizes into a space, as it always does and as it should). Because "SomeUser " (note the space) is obviously not a valid Title, MW would barf.
May 18 2019
May 15 2019
May 10 2019
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.
May 9 2019
May 5 2019
Apr 30 2019
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.