Author: slboat
Description:
i just install mw 1.21,and found there are no such thing exister,seems has be complate remove,but not yet move in the core(seems that happen in 1.22),so the delete has too early for 1.21 branch for extenion Vector
Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49270
Hi sen,
unfortunately this report is not very useful because it does not describe the problem well. If you have time and can still reproduce the problem, please read https://www.mediawiki.org/wiki/How_to_report_a_bug and add a more useful description to this report by explaining what exactly has happened, and what should have happened instead. Thanks!
slboat wrote:
sorry,i try to say again,the function editwaring in mw1.22 is in the core:
:resources/mediawiki.action/mediawiki.action.edit.editWarning.js
but before 1.22,its not in the core,so it should still be vector,but in branch v.121 vector,the file is alardy delete
I think you mean that the edit warning code should be restored in the Vector extension REL1_21 branch (it was removed from master in Gerrit change 57320)?
slboat wrote:
for myself,i restore to this version
:https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FVector/8fb9a909d4c81abb8db46d9a35763ef68723c69f
so it not break the editwaring.i dont know how you do this,but this happen to the download version in mw1.21 too,so i think is kind imporant for some guy really like this further
Related URL: https://gerrit.wikimedia.org/r/67253 (Gerrit Change I236086380cf7520d156b491661086bfefa0cb129)
So to recap, the issue is that change I164f1725 in Vector is included in the 1.21 release version, while change I7bdbd09f in core isn't. Either both should be included or none.
CC-ing Mark (the release manager).
Related URL: https://gerrit.wikimedia.org/r/67254 (Gerrit Change I236086380cf7520d156b491661086bfefa0cb129)
slboat wrote:
waw!that's really fast!this my first do such thing(submit bug)!i cant belive this how it work,so fast and so great!thx you guys!you are the great guy to keep mediwiki be nice.
i use mw for my site about 1 years,i really like it!easy but can do a lot thing.
http://see.sl088.com/
now i know the mw have you guys to push it going,that's a really cool thing!
(In reply to comment #9)
i use mw for my site about 1 years,i really like it!easy but can do a lot
thing.
http://see.sl088.com/
Just FYI, I've added your site to WikiApiary: http://wikiapiary.com/wiki/森亮号航海见识_-SLboat_Insight;-
I can't say that this fix is going to be released before July, but, if you can patch your own system, you can get the fixes from the above links.
(In reply to comment #7)
CC-ing Mark (the release manager).
By the way, only one of those emails is needed. They both go to the same place.
The reason the MediaWiki 1.21 release with the bundled version of Vector is incompatible is because Mark accidentally bundled the lastest master of each extension instead of the (at that point in time, not yet created) REL1_21 branch.
As a result, developments that happened in the Vector extension after the 1.21 branch point that rely on 1.22 developments, are broken.
Timeline:
The MediaWiki 1.21.0 bundle contains core from before the move and extensions/Vector from after the move. So the bundle doesn't have either version, it is missing in both.
Though this particular incompatibility is harder to detect, there an infinite number of ways extensions can become incompatible with core when taken from different points in core. Whenever core changes, extensions usually follow soon after. Especially if the change is backwards incompatible.
This was to be expected, of course, and is hopefully a sign that next time "quick testing" to make sure it all works is not going to be acceptable. Releases must bundle the appropriate versions of extensions regardless of whether or not the latest version seems to work. Release branches in extension repositories need to be created from the right timestamp. If you want certain newer developments to land in the release bundle they'll have to be back ported like we do for everything else by cherry-picking them onto the release branch from master and through Gerrit review.
Now for the current situation, the release has already been made so we can't go back on this one.
The simplest course of action is to revert the 1.21-incompatible commit from 1.22-master in REL1_21 branch. That will (hopefully) resolve the specific problem raised by this bug.
However I don't think we should do that. I'd recommend we reset (by deleting and re-creating) the REL1_21 branches to where they should've been created by the make-extension-branches script. In other words, undo the exceptions we made in bug 48837. Not just for the Vector extension but for all bundled extensions, because no doubt there are other non-obvious incompatibilities released as a result of this. I can easily do this in a few minutes.
This would solve any and all incompatibilities (including the problem reported in this bug)
@mark: Regardless of which action we take, can we actually release patches to bundled extensions?
(In reply to comment #12)
However I don't think we should do that. I'd recommend we reset (by deleting
and re-creating) the REL1_21 branches to where they should've been created by
the make-extension-branches script. In other words, undo the exceptions we
made
in bug 48837. Not just for the Vector extension but for all bundled
extensions,
because no doubt there are other non-obvious incompatibilities released as a
result of this. I can easily do this in a few minutes.
The other bundled extensions that received one or more non-l10n changes appear
to be Cite, ConfirmEdit, Gadgets, ParserFunctions, RenameUser,
SyntaxHighlight_GeSHi, TitleBlacklist, and WikiEditor.
Of course, keep in mind that simply reverting all such changes *might* also
break things, because some fix bugs that were introduced shortly before
the branch point. For example, "d6013d7 The hebrew translation for #ifexpr is
borked on 1.21wmf12, breaking tons of templates" addressed bug 46613,
marked "Highest critical".
This is another reason it is so important to announce the branch date on
wikitech-l, preferably in advance, and branch extensions at the same time
as core. I have attempted to clarify the latter part in our release
checklist.
(In reply to comment #12)
@mark: Regardless of which action we take, can we actually release patches to
bundled extensions?
I'm not sure what you mean by releasing patches so I'll answer with what I know.
A new release is in the works and set to be released before the end of the month. There is no reason why that version couldn't include a patched version of Vector to address the problem here.
Until the new release happens, is there some fix to get JavaScript working again with 1.21 and Vector?
slboat wrote:
(In reply to comment #17)
Until the new release happens, is there some fix to get JavaScript working
again with 1.21 and Vector?
use git checkout to reback
git checkout 8fb9a909d4c81abb8db46d9a35763ef68723c69f
Seems to be fixed by doing
git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/Vector
and using that to replace .../extensions/Vector
I was just able to reproduce this bug by un-tarring 1.22 on top of an existing installation. I can find no reference to jquery.collapsibleTabs except in the file itself.
It seems like this may be caused by old files left over that RL is finding.
Pinging Timo for his opinion.
To be clear, the error I saw was "Uncaught Error: Unknown dependency: jquery.collapsibleTabs" from bug #49270
mediawiki-core@1.22.4 shows no mention of a 'jquery.collapsibleTabs' dependency in Resources.php
mediawiki-extensions-Vector@REL1_22 is empty entirely.
So if packaged correctly, and assuming the error you mention in comment 23 is indeed originating from a Vector module (and not some other gadget or extension), this looks like it is caused by packaging the wrong old version, because core 1.22.4 with Vector#REL1_22 is incapable of producing such an error.
(In reply to Krinkle from comment #24)
mediawiki-core@1.22.4 shows no mention of a 'jquery.collapsibleTabs'
dependency in Resources.phpmediawiki-extensions-Vector@REL1_22 is empty entirely.
So if packaged correctly, and assuming the error you mention in comment 23
is indeed originating from a Vector module (and not some other gadget or
extension), this looks like it is caused by packaging the wrong old version,
because core 1.22.4 with Vector#REL1_22 is incapable of producing such an
error.
(In reply to Mark A. Hershberger from comment #22)
I was just able to reproduce this bug by un-tarring 1.22 on top of an
existing installation.
Just to eliminate the possibility, when you say un-tarring you don't mean you have an existing installation of some arbitrary MediaWiki version and Vector extension version and unpacked it on top in such a way that any files in common directories that should not be there, were kept around? Replacing an extension should replace the entire directory, not just overwrite conflicting files. There is no telling what could happen when unzipped and merged (the only directory of which its direct file contents are safely mergeable with older versions is mediawiki-core root, any subdirectory should just be replaced, except maybe 'extensions' or 'uploads').
Though even then, the module registry isn't composed of globbing directories. overwriting extensions/Vector/Vector.php with the extension REL1_22 version and resources/Resources.php with the core REL1_22 version doesn't reproduce this problem either.
Ok, I am currently seeing this bug. I added a line to Resources.php to provide the dependency and hide the bug, but I've removed that now.
Based on comments here, I've removed the inclusion of the old Vector.php extension and the bug disappeared. Yay!
jlerner wrote:
(In reply to Mark A. Hershberger from comment #26)
Based on comments here, I've removed the inclusion of the old Vector.php
extension and the bug disappeared. Yay!
Worked for me as well - thanks!!!!