Thu, Sep 12
No longer relevant since commit rEAFFe43c9ffb0d9b, which removed the relevant call from AFTv5.
Sat, Aug 31
Most wikiHow things, or dare I say all of them, are not 1:1 portable to vanilla MW as-is and have been designed with the wikiHow platform and its requirements etc. in mind. Or to put it somewhat bluntly, they're a dependency hell. (Mind you, the same certainly is true for certain "regular" MediaWiki extensions as well.)
Sun, Aug 25
They already are and have been since day #1.
Aug 16 2019
This was slightly trickier to test, given that the FileExporter extension is a beta feature which has to be activated on Special:Preferences for the link to the extension to show up on eligible files' file description pages.
@Krinkle Would you know what needs to be done to enable Fresnel for non-core MW repos (like the Timeless skin repo that this ticket is about)?
Aug 10 2019
Duplicate of T189083?
Aug 8 2019
Given that this patchset got merged quite a while ago, I'm going to close this task.
Aug 6 2019
Aug 2 2019
Jul 30 2019
You should probably open a separate ticket about that. (AIUI the Poll extension is pretty much unmaintained and for generic (non-social) pollls you may want to consider using AJAXPoll instead, but I'm biased since I'm one of the maintainers of AJAXPoll.)
Jul 28 2019
Jul 27 2019
This is somewhat of an edge case that happens only when Comments is installed without SocialProfile. That is a supported scenario in that having Comments fatal simply over that seemed outright nasty to me, so I opted to introduce a very simple fallback -- the default SocialProfile avatar image hotlinked from an external source, as I didn't want to duplicate the said image in Comments' repo as well. That's basically why it's configurable; to work around this, you can set $wgCommentsDefaultAvatar = 'https://cdn.jsdelivr.net/gh/wikimedia/mediawiki-extensions-SocialProfile@master/avatars/default_ml.gif';, for example, to serve the image securely from the GitHub repository via jsDelivr CDN.
Jul 22 2019
Jul 21 2019
Jul 18 2019
Per discussion with @Isarra, closing this task now that the aforementioned patch has been merged.
Jul 15 2019
Jul 13 2019
Jul 11 2019
@zeljkofilipin Pinging you here as per discussion on #wikimedia-releng. Thanks in advance for any and all insight you can provide into this!
Jul 10 2019
Thanks for the report, fixed in git master!
Jul 7 2019
And that's now done and the patch is merged (though not yet live on ShoutWiki), so closing this ticket!
Jul 5 2019
Patches welcome. :)
Jul 4 2019
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.