I've been developing MediaWiki since 2008, maintaining social tools as well as a few other extensions and skins.
Since 2013 I've had +2 rights to mediawiki/skins/* repositories.
I'm also a staff member at ShoutWiki, a wiki hosting service.
I've been developing MediaWiki since 2008, maintaining social tools as well as a few other extensions and skins.
Since 2013 I've had +2 rights to mediawiki/skins/* repositories.
I'm also a staff member at ShoutWiki, a wiki hosting service.
Thanks for reporting this!
MediaWikiChat is not installed on translatewiki.net or on MediaWiki.org, hence why you're obviously not seeing any results on either site. :)
This is easy enough to fix by just removing the offending line of code (and the associated code comments, for completeness):
Thank you for tagging this task with good first task for Wikimedia newcomers!
To ask the most obvious question...why?
First off, a brief disclaimer: post-1.39 versions of MW are untested and, in this sense, "unsupported"; but of course 1.39 will go EOL at some point, and then social tools will _target the next LTS (more details on MW.org @ mw:Social tools/MediaWiki compatibility). So in a way, you're charting uncharted waters here - thank you for your bravery, it's appreciated! :)
Thanks for fixing this, @Umherirrender! 👍
@Umherirrender Wanna take care of this one and the other one in ArticleFeedbackv5Hooks, in the UserLoginComplete hook handler function? Seeing that you started this work back in de146af041c3a569f6a738a93d9a96023ffe1df5 and all... :)
Thanks for filing this task! 👍
As social tools not only support but _target the LTS release (per mw:Social tools/MediaWiki compatibility), this is not a high priority item by any means currently, but should you wish to work on addressing this/the same issue in other Social-Tools, you're more than free to copy the mouthful of code that ArticleRatings, MediaWikiChat, etc. use to support MW 1.39 and newer without triggering deprecation notices on WMF CI: see fd5bb4e2f070ef5bfd276efb09c163dd68aee4b3 (ARE) / 233e3cd4720d36442e1c292e8392e2e9ef705a2d (MWC) 😃 I'll be happy to +2 any and all such patches!
Some things to be done here...
In T370198#9988784, @Dogu wrote:
In T370198#9987522, @Dogu wrote:
The "after" screenshot isn't visible (for me at least), maybe its visibility is incorrect?
This was actually somewhat harder to update than I thought, but definitely not impossible. That said, I have no opinion one way or the other, but perhaps someone finds the aforementioned patch useful enough to give it +2, or maybe not.
This isn't a MediaWiki bug but rather a bug with your rewrite rules -- most likely caused by a null $wgScriptPath. Usually $wgScriptPath is set to something like /w and the "pretty" URLs are set to /wiki/ so you have URLs like https://example.com/wiki/Main_Page for a nice, pretty, view action URL, and "ugly" URLs like https://example.com/w/index.php?title=Main_Page&action=edit for actions like edit (in this example), purge, delete, etc.
Can this be backported to 1.39 (and whatever newer, non-LTS versions are currently supported)?
This seems to (only) happen with ?limit=500 on the aforementioned Special:Contributions page.
Here's a quick "before and after" comparison.
Caused by c9c359be345e65575574b0b419e29cd876aa3570 (which fixed T365769) as subclassing the old MobileSpecialPage by default would create an UnlistedSpecialPage (see MobileSpecialPage::$listed and MobileSpecialPage::isListed()) but in folding the class' functionality into SpecialMobileOptions it was changed to extend regular SpecialPage instead of UnlistedSpecialPage nor does it call $this->isListed( false ); anywhere; hence the behavior you're seeing (an undefined string appearing on Special:SpecialPages).
The merged patch also adds the edit summary field to Special:UserBoxes when creating a brand new UserBox, not just when editing an existing one.
qqq message documentation was amended in 8252df7e9b3559f4286be0b913175aaf9b8b41cb and message keys were adjusted in 774c7d30d0004ed99b00c7d4102c7b4a4831ff69, a577ea29af8d3f713fe3c6404fcec2855050131c, 61b23f23c4fc13c73adc034efc72eff61abd8a09 and 778e3c9cfa3a91f1ec3df4b29e0e09d268f1c80f back in the latter half of 2020.
Removed a significant chunk of super legacy CSS in this patch (which gerritbot didn't pick up because I forgot the ticket # from the initial patchset's commit msg and apparently adding it in a newer version doesn't register to gerritbot or something).
Still some work to be done when it comes to coding conventions compliance so leaving this open for a(nother) rainy day.
As per above, I've done some work on this, but I'm leaving this open anyway, since:
Currently on MW 1.39, with the following skins, the header gets hidden during the editing process, but reappears immediately after saving changes:
Something somewhere has changed enough that this isn't happening anymore as far as I'm able to tell (on MW 1.39).
Fixed now in the aforementioned patchset, although without fixing the parent task (since that's even more complicated).
@Sophivorus merged the aforementioned patch, so this bug is now fixed in master.
In T332815#8869767, @Platonides wrote:In T332815#8863252, @ashley wrote:This, of course, has the rather obvious performance impact since now we're purging caches for the page on every vote...
Well, it seems to be what it takes. I would do that, and perhaps it may get more efficient later.
Having played around a bit more with this, I swapped the hook code to use BeforePageDisplay instead of ArticleViewFooter to realize the obvious: comments cannot be posted on a nonexistent page, and as long as comments stores "merely" the page_id (as Comments.Comment_Page_ID) instead of a (namespace, title) tuple as the core MW page table does, this feature request remains "unfixable" as-is without a schema change to Comments and the best that can be done is "auto-activate on all existing pages' talk pages (for given namespace(s))". :-/
Hopefully addressed by the patch which got merged in February 2022. If not, please reopen and report back with as much details as possible. For now, I'm assuming that this is fixed.
This patch, too, got merged a while ago.
The patch got merged a while ago (but I do need to look into the phan-reported double escaping issues, but that's out of scope for this patch; the security problem is fixed).
Now implemented.