Hi everyone,
We have a lot of issues to get through before pushing MediaWiki 1.19
out to commons on Tuesday afternoon (late Tuesday/early Wednesday UTC)
The general situation is that there still seem to be many Javascript
issues cropping up. Additionally, there's one logging bug that's
really causing problems for vandalism patrol. More below:
Newly added as blockers:
* Bug 34508: [Regression] IRC string output for log messages no longer
compatible
https://bugzilla.wikimedia.org/34508
Krinkle started looking into this one, and Nikerabbit chimed in.
This one can't be fixed until a bot author helps narrow down what the
important change was. Right now, there's more heat than light on this
issue.
* Bug 34510: monobook toolbar or vector with old toolbar not setup randomly
https://bugzilla.wikimedia.org/34510
Recently reported. RobLa has some irresponsible speculation on this
bug, but this hasn't had a hard look yet.
* Bug 34517: Sometimes scripts imported by mw.loader.load on common.js
are not executed
https://bugzilla.wikimedia.org/34517
* Bug 34495: patrol log credit the user patrolled, not the user patrolling
https://bugzilla.wikimedia.org/34495
* Bug 34478: Special:MergeAccount&action=submit generates error
https://bugzilla.wikimedia.org/34478
We've seen a couple of cases of this now. This may be related to
trying to merge an account on a 1.19 wiki with one on a 1.18 wiki.
* Bug 34504: [Regression] There should not be a mismatch between html
and stylesheet version
https://bugzilla.wikimedia.org/34504
Krinkle says: "This is what was causing the "Jump to navigation"
links to appear on cached
pages after the 1.19 roll-out. "
* Bug 34373: populateRevisionSha1.php misses archive rows, whose text
is stored directly in the archive table (not text table)
https://bugzilla.wikimedia.org/34373
This one was recently reopened
Old issues:
* Bug 34450: Probable Javascript loading issues (navigation and
tabbing issues, multiple browsers)
https://bugzilla.wikimedia.org/34450
See RobLa's note to wikitech-l
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/58858
Andrew fixed the issue with the collapsible sidebar not working as
expected. There are other issues in this bug that still need to be
resolved.
* Bug 34469: (un)watch button broken
https://bugzilla.wikimedia.org/34469
This appears to be fixed for debug mode. Still reliably busted in
debug mode. The latest speculation is that this is a cross-domain
cookie issue, since the javascript is served off of bits.wikimedia.org
in debug mode.
* Bug 34421: mutiple headers
https://bugzilla.wikimedia.org/34421
Hashar has adapted a patch from Krenair, and checked this into
trunk. Still needs to be merged and deployed.
* Bug 34458: Editing fails in IE7
https://bugzilla.wikimedia.org/34458
We believe this only happens on meta.wikimedia.org, and is caused by
common.js there. This may have also been a problem on 1.18.
* Bug 34409: 'mw.user.options' and 'mw.user.tokens' are sometimes
empty on 1.19, breaking watchlist, gadgets, etc.
https://bugzilla.wikimedia.org/34409
We think this one is dead.
For the very latest in BZ, run this query:
https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&list_id=91…
This status pad is being updated here:
http://etherpad.wikimedia.org/119triage
Rob
Le 18 févr. 2012 à 23:41, Nicolas Brouard a écrit:
> Le 16 févr. 2012 à 22:26, Platonides a écrit :
>
>> On 16/02/12 09:51, Nicolas Brouard INED wrote:
>>> Thanks to Platonides for his comment and also to Olivier (the author of the Realnames extension) who told me to forward the following patch to wikitech-l (which I just subscribed to) for advices, comments and critics.
>>>
>>> I was just wondering if this small patch in User.php (function idFromName) was enough in most cases:
(...)
>> This is only patching User::idFromName(), which won't be enough.
>
> Sorry, could you detail why it won't be enough!
>
>> You could well be storing the email instead of the username in the page
>> history.
>
> I was probably not clear enough: I don't want the email in the page history. Also the Realnames extension (quoted above) is trying to do what you seem suggesting but it is a complex extension which did not work on 1.18 for example.
>
> The proposed patch is also a solution which manages the transition for Wikipedians. Having an authentication with e-mail only is brutal and won't be understood. I like the possibility of having both option with a priority to username for performance also.
>
> But allowing new authors from Arabic or Asian (or Russian or ...) countries (with non Roman characters) to sign new articles in their own language with their own standard, not transliterated, signature will be appreciated if they also have an easy way to authenticate on an English keyboard (pad, smartphone etc.).
I didn't express it right.
If you do $user = User::newFromName("email(a)address.com"), that gets
cached, and if youlater use that object for eg. storing the username in
the history, boom, $uset->getName() will say it's called email(a)address.com
That's probably not happening, but you would need to check all paths in
core and the extensions...
>> As I said, you should fix it in SpecialUserlogin.php.
>
> What should I fix? Is there something wrong in the proposed patch?
The patch should go against SpecialUserlogin.php, authenticateUserData() function.
>>> Then, just try to enter your e-mail on a standard wiki in place of your username and you will be authenticated to the first ID (and user_name) having your e-mail.
>>>
>>> The importance of e-mails as a simple way to authenticate on modern sites can't be ignored.
>>
>> It can also expose the fact that someone is registered there with that
>> email address.
>
> I don't understand what you mean and if someone has already entered an email for a username what is the problem?
>
>> In the patch provided, it would also happily show under some
>> circunstances the username associated to an email (not a problem for the
>> internal wiki of a company, where everybody know each other's mail, an
>> issue for public wikis out there).
>
> That is the reason why I was asking this mailing list. But, as I said in a previous and detailed answer to Bergi,
> the patch is very short (a single "if") and thus consequences are not
tremendous.
Go to Special:Contributions and enter the email of an existing user.
I think it may show the user contributions.
> We made some tests on various wikis, and we haven't found yet any circumstance where the username associated to an email is displayed:
> - it can't happen when the authentication works;
> - the only situation that I have found is when you are asking for a new password: then the username associated with the email entered (in place of the username) is displayed in the received email, but it is not a security issue because you are the only person to read your email.
Hi,
recently I've completed a first version of API for the MobileFrontend
extension[1]. It allows to retrieve content in a mobile-friendly
format and is centered around two use cases:
1) Mobile site doesn't want its users to retrieve full pages at once.
Instead, it displays the article lead along with section headings that
have 'expand' buttons. When user clicks on those buttons, sections are
loaded via the API and are shown to the user.
2) Our mobile app doesn't need to retrieve skin HTML for every page.
It needs only page content.
The API extends core action=parse and thus it has all the niceties
like retireval of extra information about the page such as sections or
language links. Its description can be found at[2].
Your input needed: do you like it? Do you have another use cases for
it? Maybe, you want it to do something else?
P.S. The complete rewrite by John Du Hart currently dubbed
MobileFrontend2 can easily reuse this API and the class that converts
HTML into mobile formats, as this code is isolated from
the rest of MobileFrontend.
----
[1] https://www.mediawiki.org/wiki/Extension:MobileFrontend
[2] https://www.mediawiki.org/wiki/Extension:MobileFrontend#New_API
--
Best regards,
Max Semenik ([[User:MaxSem]])
Hey everyone,
Reading around MW and looking into some ideas for GSoC I ran into this bug, https://bugzilla.wikimedia.org/show_bug.cgi?id=14950, which I noticed (correct me if i'm wrong) isn't currently being worked on, and as Roan Kattouw said on one of the last comments, hasn't ever been written yet (i know it's kind of old, but anyway).
I wanted to get some feedback on the next couple of things:
1 - Is this a feature that could actually be needed/helpful/useful?
2 - Is it true that it's currently not being worked on?
3 - Would it be too big of a project for a single person to take on? (given the amount of time to actually implement it for GSoC)
Thanks for your time.
Jere.
Hi Guys,
I already posted about this, but I'm stuck in replying. I make a
report: http://en.wikipedia.org/wiki/Wikipedia:Help_desk#Render_server_error_while_…
and while someone did respond to me and said that a post was made at
WP:VPT, I'm stuck on how to respond to those messages.
Also would someone be able to help me on fixing those errors?
Thanks
Sorry for my poor english :(
Hi all,
I've created a copy of the Vector skin.
What is the recommended way to register resources (for the resource
loader) for a custom skin?
Vector registers the resources in resources/Resources.php
The recommended method for extensions seems to define
$wgResourceModules['ext.myExtension'] in the MyExtension.php file
This does not seem to work for styles. I get a blank page when I do this
in my skin, and load
/load.php?debug=true&lang=en-gb&modules=skins.myskin&only=styles&skin=myskin&*
in my browser.
Here is what I tried so far:
1. Don't define anything
--> PHP Fatal error: Call to a member function getGroup() on a
non-object in includes/OutputPage.php on line 2958
2. define $wgResourceModules['skins.myskin'] in the MySkin.php
--> blank page
3. define $wgResourceModules['skins.myskin'] in SkinMySkin (extends
SkinTemplate) __construct() function
--> blank page
4. call $resourceLoader->register('skins.myskin', ...) from a hook
function, defined by $wgHooks['ResourceLoaderRegisterModules'][] in
MySkin.php.
--> blank page
5. define $wgResourceModules['skins.myskin'] in the MySkin.deps.php
--> blank page
6. define 'skins.myskin' in resources/Resources.php
--> works fine
(but I rather not modify this file)
7. define $wgResourceModules['skins.myskin'] in LocalSettings.php
--> works fine
(but feels rather hackerish, since I have to manually set $wgStyleDirectory)
Unfortunately, http://www.mediawiki.org/wiki/Manual:Skinning is
deprecated, and
http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(developers) does
not mention skins at all.
Apparently, more people struggle with this:
http://www.mediawiki.org/wiki/Manual_talk:Skinning/Vector
Any help is kindly appreciated!
Regards,
Freek Dijkstra