This user is a MediaWiki enthusiast and third-party wiki system administrator.
Languages: de-N, en-3, fr-1
Based in Berlin, Germany: UTC+1 (CET) / UTC+2 (CEST)
The profile picture is licensed CC BY-NC-ND DE 3.0, my contributions here are licensed CC BY-SA 4.0, and my code contributions are licensed according to the software's license or ISC if the software provides no explicit license information.
Thank you. I have no objections from my side to move the extension’s functionality into MediaWiki core.
Yes.
Please note that this affects not just private wikis but public wikis also. See merged task T257851.
@Osnard, I am sorry for the noise. I did not check out the fixed code. After eventually doing so, it worked. Senior moments, I guess. Thanks a lot!
@Osnard Regretably, the fix does not work, i.e., I still get API response errors when trying to reply to a comment. There must be something else in the water.
@Osnard, I can confirm the issue. I suspect that the extension can currently only be used with the new page content model introduced with version 9.0.0, although I have not verified this. Either way, it will be great if you could fix the issue, which can only be circumvented by disabling the Echo extension. That's a nasty workaround.
The author of Cargo does not care about branches. If you follow them, you are looking at a lost cause in a lot of cases. Use tags instead: https://www.mediawiki.org/wiki/Extension:Cargo/Version_history 3.8.2 will provide you with the fix, however, there is already an even newer version around.
Cool. Thank you!
Ah, ok, good! It was just not back-ported, which indeed does not appear to be strictly necessary. Thanks for the info.
I do not want to spoil the party after starting it myself. The above configuration results into:
Regrettably, I cannot provide the stack trace. It was something like a 10 liner.
Shouldn't this be redirected from OOUI to Codex?
Actually, this was already fixed.
MW 1.28.x and the software versions associated with it are no longer supported. Please create a new issue report in case this problem still exists for supported versions of MediaWiki.
Looks like I am not the only one linking this. Thanks for your feedback. Yeah, your suggestion for improvement is even better. I forgot about subpage listings.
Oops, I did hit save to create this task? Obviously. :(
@Reedy Thanks a bunch. Works perfectly!
What am I?
Running order issue?
I do think that establishing some norms for extension versioning would be helpful.
Sort of "fixed". No big deal, just a matter of documenting since we cannot change the code for already tagged versions and already have a tag beyond without the issue.
So you shouldn't be using the master version with REL1_39 as is seemingly happening..
In other words, the change was breaking for MW 1.40.x and earlier?!
@MarkAHershberger @cicalese, could you have a look at this? For now, I rolled back to version 7.1.0 for both extensions, waiting on feedback on whether SSO integration works. Perhaps version 7.3.0 of PluggableAuth was breaking for 1.39, though it does not look like it, judging from the backporting activity.
I guess we can proceed with the task. This extension is dead as a dodo.
Have you required email confirmation ($wgEmailAuthentication)?
I am unsure what your comment refers to, but yes, categories are in the "Category" namespace. I added an image to the description to demonstrate the issue.
@Varnent I do not have the impression that you would like to put more effort into this extension?!
It will be great to get a note about this new special page in the release notes for 1.43
I am a bit late with my reply. :( Thank you for your responses and work on this issue; I appreciate it. Really cool!
@Paladox It would be fantastic if you could continue your work.
Fine with me. I see no reason why 4.5.3+ should not work with this extension. A field test with a couple of widgets confirmed this. If @Yaron_Koren is OK with this change, Robert could add the patch to Gerrit.
I guess i would check if the page table has any pages with a negative id. If not i would just delete the negative entries from page_props. Afterall it should be impossible to ever match the negative entries.
It will probably remain a mystery. The wiki uses a lot of extensions. Thus, it may well be that the issue is to find somewhere here.
Well, what I reported is what I got. I'm not sure how this can happen, either, but it appears to be like this.
Ah, oh, that was fast. :)
@Winston_Sung https://github.com/wikimedia/mediawiki-extensions-Editcount/commit/116bf43c5ab68cc5f124627f4fa099e5c6a27c4a#diff-6a6295f752062fb0eec4a9df4e87c164b8d8d3b48023a54a1e682671296eb8a3R12 This should have been 1.40.0 if I am not mistaken.
or
I checked out REL1_39. Aaaaarrrrgh. Thanks for the info.
In this case, we are talking about a public wiki.
I like the proposed changes. As an MW LTS user, I am forced to stick to outdated versions of MLEB due to PHP incompatibility, so the first proposed change is no change for me. If I am not mistaken, integration into the MediaWiki tarball as proposed with change 2 would even improve my situation.
On top, we have the policy not to support upgrades from older versions than two LTS releases: T259771: RFC: Drop support for older database upgrades