date:20110327

[Bug 25676] Deploy FirefoggChunkedUpload extension to Wikimedia wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25676

--- Comment #17 from Chad H.  2011-03-28 06:10:25 UTC 
---
(In reply to comment #16)
> We can enable Firefogg today, and think about implementing a better protocol 
> in
> core very soon after, and then try to convince Firefogg to support that? As a
> Firefox extension, we can expect Firefogg to auto-update, so we won't have to
> support their protocol forever.

I was pretty sure from comment 5, 6 and 7 that asking users to install an
extension is a non-starter.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 25676] Deploy FirefoggChunkedUpload extension to Wikimedia wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25676

--- Comment #16 from Neil Kandalgaonkar  2011-03-28 
04:12:40 UTC ---
I think(In reply to comment #15)
> This bug is about the deployment of a specific extension to Wikimedia wikis.
> The last few comments don't really relate to extension deployment, they relate
> to the underlying issue, which is covered in bug 17255 (now re-opened). I'm
> going to copy over the last few comments from this bug to bug 17255. This bug
> should probably be re-resolved, but I'll leave that for someone else.

I think MZ is right. Firefogg's protocol (as written) not actually give us
upload resumability, since the server can't say what its state is. So if the
real goal was resumability, bug 17255 is not fixed yet.

In practice, I think enabling Firefogg is at least useful (if not robust to the
kinds of errors Tim has mentioned) and has the advantage that it can be
implemented relatively simply on the server side. The worst case scenario would
be that an uploaded file would be corrupt, but that would be easily detected in
most cases.

Is it possible to pursue both goals? We are only talking about an extension,
after all. 

We can enable Firefogg today, and think about implementing a better protocol in
core very soon after, and then try to convince Firefogg to support that? As a
Firefox extension, we can expect Firefogg to auto-update, so we won't have to
support their protocol forever.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 17463] New pages log doesn't remove/update item after suppression redirect

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=17463

Phillip Patriakeas  changed:

   What|Removed |Added

 CC||dragonlordofxanther@gmail.c
   ||om

--- Comment #11 from Phillip Patriakeas  
2011-03-28 04:07:13 UTC ---
I don't know about the general case, but I think that the somewhat more
specific case of an unpatrolled page being moved to a different namespace
should result in the new page entry being removed.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 17255] Support Upload Resume via Server Side File Concatenation

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=17255

--- Comment #9 from MZMcBride  2011-03-28 03:57:20 UTC ---
(Copied from bug 25676 comment 14 by Tim)

(In reply to bug 25676 comment 12)
> Okay, so if the following things were added to a chunked upload protocol, 
> would
> this be satisfactory?

Yes, that is the sort of thing we need.

(In reply to bug 25676 comment 13)
> In Firefogg, the client is basically POSTing chunks to append until it says
> that it's done. The server has no idea when this process is going to end, and
> has no idea if it missed any chunks. I believe this is what bothered Tim about
> this. 

Yes. For example, if the PHP process for a chunk upload takes a long time, the
Squid server may time out and return an error message, but the PHP process will
continue and the chunk may still be appended to the file eventually. In this
situation, Firefogg would retry the upload of the same chunk, resulting in it
being appended twice. Because the original request and the retry will operate
concurrently, it's possible to hit NFS concurrency issues, with the duplicate
chunks partially overwriting each other.

A robust protocol, which assumes that chunks may be uploaded concurrently,
duplicated or omitted, will be immune to these kinds of operational details.

Dealing with concurrency might be as simple as returning an error message if
another process is operating on the same file. I'm not saying there is a need
for something complex there.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 17255] Support Upload Resume via Server Side File Concatenation

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=17255

--- Comment #8 from MZMcBride  2011-03-28 03:55:37 UTC ---
(Copied from bug 25676 comment 13 by Neil)

Okay, from some comments on IRC, it is apparently unclear why I just posted
some suggestions for changing the Firefogg protocol. I am trying to answer
Tim's objections that the way of uploading chunks is not robust enough.

In Firefogg, the client is basically POSTing chunks to append until it says
that it's done. The server has no idea when this process is going to end, and
has no idea if it missed any chunks. I believe this is what bothered Tim about
this. 

There was some confusion about whether PLupload was any better. As far as I can
tell, it isn't, so I looked to the Google Resumable Upload Protocol for
something more explicit.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 17255] Support Upload Resume via Server Side File Concatenation

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=17255

--- Comment #7 from MZMcBride  2011-03-28 03:54:54 UTC ---
(Copied from bug 25676 comment 12 by Neil)

(In reply to bug 25676 comment 11)
> (In reply to bug 25676 comment 9)
> > Reopening since Tim's arguments for WONTFIX pertained mostly to the Firefogg
> > add-on (client-side) rather than the FirefoggChunkedUpload extension
> > (server-side support).
> 
> Actually I think the second paragraph in comment 5, where I explained why I
> don't think the server-side extension should be enabled, was longer than the
> first paragraph, which dealt with my objections to the client-side.

I've had a look at Google's Resumable Upload Protocol. They do things in a
reasonable manner, also very RESTy. We have never used HTTP Headers or Status
fields for application state signalling, but we can emulate most of this in
ordinary POST parameters and returned data.

http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html#ResumableUpload

Okay, so if the following things were added to a chunked upload protocol, would
this be satisfactory?

* Before starting an upload, the client tells the server the length of the file
to be uploaded, in bytes.

* With each upload chunk, the client also tells the server which range of bytes
this corresponds to.

* With each response to an upload chunk, the server indicates the largest range
of contiguous bytes starting from zero that it thinks it has. (The client
should use this information to set its filepointer for subsequent chunks). n.b.
this means it's possible for the client to send overlapping ranges; the server
needs to be smart about this

* The server is the party that decides when the upload is done. (By signaling
that the full range of packets are received, saying "ok, all done", and then
returning the other usual information about how to refer to the reassembled
file).

We could also add optional checksums here, at least for each individual chunk.
(A complete-file checksum would be nice, but it's not clear to me whether it is
practical for Javascript FileAPI clients to obtain them).

And each upload could return some error status, particularly if checksums or
expected length doesn't match.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 25676] Deploy FirefoggChunkedUpload extension to Wikimedia wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25676

--- Comment #15 from MZMcBride  2011-03-28 03:51:39 UTC ---
This bug is about the deployment of a specific extension to Wikimedia wikis.
The last few comments don't really relate to extension deployment, they relate
to the underlying issue, which is covered in bug 17255 (now re-opened). I'm
going to copy over the last few comments from this bug to bug 17255. This bug
should probably be re-resolved, but I'll leave that for someone else.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28286] $wgHitcounterUpdateFreq is either not working or needs proper description

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28286

Bawolff  changed:

   What|Removed |Added

 CC||bawolff...@gmail.com

--- Comment #2 from Bawolff  2011-03-28 03:48:02 UTC ---
This bug seems to lack a problem statement.

I added the stuff you're referring to on the page on mw.org. Hopefully I didn't
say anything stupid and wrong.

The behaviour of how $wgHitcounterUpdateFreq updates is what I see on my
computer. However the code seems to indicate the more expected behaviour should
happen (it does a group by on hc_id, which is pointless unless you somehow get
duplicate rows into that table). On my computer, inserting a duplicate row into
the hitcounter table doesn't create two identical rows (As one expects in a
relational database...).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 16927] add support for firefogg

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=16927

Bug 16927 depends on bug 17255, which changed state.

Bug 17255 Summary: Support Upload Resume via Server Side File Concatenation
https://bugzilla.wikimedia.org/show_bug.cgi?id=17255

   What|Old Value   |New Value

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 17255] Support Upload Resume via Server Side File Concatenation

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=17255

MZMcBride  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||b...@mzmcbride.com
 Resolution|FIXED   |

--- Comment #6 from MZMcBride  2011-03-28 03:46:46 UTC ---
(In reply to comment #5)
> IIRC the new API upload module supports Firefogg chunck uploading. Marking as
> FIXED.

Based on comments at bug 25676, I don't think this bug is properly fixed
currently. Re-opening for now.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 25676] Deploy FirefoggChunkedUpload extension to Wikimedia wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25676

--- Comment #14 from Tim Starling  2011-03-28 03:35:46 
UTC ---
(In reply to comment #12)
> Okay, so if the following things were added to a chunked upload protocol, 
> would
> this be satisfactory?

Yes, that is the sort of thing we need.

(In reply to comment #13)
> In Firefogg, the client is basically POSTing chunks to append until it says
> that it's done. The server has no idea when this process is going to end, and
> has no idea if it missed any chunks. I believe this is what bothered Tim about
> this. 

Yes. For example, if the PHP process for a chunk upload takes a long time, the
Squid server may time out and return an error message, but the PHP process will
continue and the chunk may still be appended to the file eventually. In this
situation, Firefogg would retry the upload of the same chunk, resulting in it
being appended twice. Because the original request and the retry will operate
concurrently, it's possible to hit NFS concurrency issues, with the duplicate
chunks partially overwriting each other.

A robust protocol, which assumes that chunks may be uploaded concurrently,
duplicated or omitted, will be immune to these kinds of operational details.

Dealing with concurrency might be as simple as returning an error message if
another process is operating on the same file. I'm not saying there is a need
for something complex there.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28289] New: Pages created using hooks (by extensions) are not watched if chosen by user

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28289

   Summary: Pages created using hooks (by extensions) are not
watched if chosen by user
   Product: MediaWiki
   Version: wikimedia-deployment
  Platform: All
OS/Version: All
Status: NEW
  Severity: minor
  Priority: Normal
 Component: Watchlist
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: huji.h...@gmail.com


If a user chooses the pages he creates to be automatically added to his
watchlist, once he creates pages through an extension (such as creating User
Pages using the CheckUser's mass block feature), these pages are not added to
his watchlist. It appears that watchlist addition doesn't work if pages are
added through a hook, and not through edit.php directly.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 25676] Deploy FirefoggChunkedUpload extension to Wikimedia wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25676

--- Comment #13 from Neil Kandalgaonkar  2011-03-28 
03:20:52 UTC ---
Okay, from some comments on IRC, it is apparently unclear why I just posted
some suggestions for changing the Firefogg protocol. I am trying to answer
Tim's objections that the way of uploading chunks is not robust enough.

In Firefogg, the client is basically POSTing chunks to append until it says
that it's done. The server has no idea when this process is going to end, and
has no idea if it missed any chunks. I believe this is what bothered Tim about
this. 

There was some confusion about whether PLupload was any better. As far as I can
tell, it isn't, so I looked to the Google Resumable Upload Protocol for
something more explicit.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 25676] Deploy FirefoggChunkedUpload extension to Wikimedia wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25676

--- Comment #12 from Neil Kandalgaonkar  2011-03-28 
03:13:19 UTC ---
(In reply to comment #11)
> (In reply to comment #9)
> > Reopening since Tim's arguments for WONTFIX pertained mostly to the Firefogg
> > add-on (client-side) rather than the FirefoggChunkedUpload extension
> > (server-side support).
> 
> Actually I think the second paragraph in comment 5, where I explained why I
> don't think the server-side extension should be enabled, was longer than the
> first paragraph, which dealt with my objections to the client-side.

I've had a look at Google's Resumable Upload Protocol. They do things in a
reasonable manner, also very RESTy. We have never used HTTP Headers or Status
fields for application state signalling, but we can emulate most of this in
ordinary POST parameters and returned data.

http://code.google.com/apis/documents/docs/3.0/developers_guide_protocol.html#ResumableUpload

Okay, so if the following things were added to a chunked upload protocol, would
this be satisfactory?

* Before starting an upload, the client tells the server the length of the file
to be uploaded, in bytes.

* With each upload chunk, the client also tells the server which range of bytes
this corresponds to.

* With each response to an upload chunk, the server indicates the largest range
of contiguous bytes starting from zero that it thinks it has. (The client
should use this information to set its filepointer for subsequent chunks). n.b.
this means it's possible for the client to send overlapping ranges; the server
needs to be smart about this

* The server is the party that decides when the upload is done. (By signaling
that the full range of packets are received, saying "ok, all done", and then
returning the other usual information about how to refer to the reassembled
file).

We could also add optional checksums here, at least for each individual chunk.
(A complete-file checksum would be nice, but it's not clear to me whether it is
practical for Javascript FileAPI clients to obtain them).

And each upload could return some error status, particularly if checksums or
expected length doesn't match.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28288] Enable by default ability to edit own talkpage while blocked globally on all existing and future Wikimedia project wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28288

Bawolff  changed:

   What|Removed |Added

 CC||bawolff...@gmail.com

--- Comment #1 from Bawolff  2011-03-28 02:08:02 UTC ---
Honestly, given that we now have a nice interface in the block page where
admins can select "allow this user to edit talk page (yes/no)". Perhaps we
should kill this setting altogether.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 8001] Enable blocked users to still edit their talk page on en.Wikibooks and en.Wikiversity

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=8001

TeleComNasSprVen  changed:

   What|Removed |Added

 Blocks||28288

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28190] Enable blocked users to still edit their talk page on beta.wikiversity

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28190

TeleComNasSprVen  changed:

   What|Removed |Added

 Blocks||28288

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28288] New: Enable by default ability to edit own talkpage while blocked globally on all existing and future Wikimedia project wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28288

   Summary: Enable by default ability to edit own talkpage while
blocked globally on all existing and future Wikimedia
project wikis
   Product: Wikimedia
   Version: unspecified
  Platform: All
   URL: http://meta.wikimedia.org/wiki/Requests_for_comment/Bl
ocked_users_and_talkpage_access
OS/Version: All
Status: NEW
  Keywords: crosswiki, shell
  Severity: normal
  Priority: Normal
 Component: Site requests
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: afterthespaghe...@mailinator.com
Depends on: 8001,28190




-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28287] New: "Your Changes" box should be read-only

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28287

   Summary: "Your Changes" box should be read-only
   Product: MediaWiki
   Version: wikimedia-deployment
  Platform: All
OS/Version: All
Status: NEW
  Severity: trivial
  Priority: Normal
 Component: Page editing
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: tpars...@wikimedia.org


When running into an edit conflict, the "your changes" box at the bottom which
shows the version you submitted and got rejected is editable, making it easy
for users to mistake it for the edit box, copy the conflicted change in and
save, only for them to realize their changes were not applied. 

If the box is made read-only, this would be far less likely to happen.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 20246] Install Extension:Transliterator on fr and en.wiktionary

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=20246

--- Comment #17 from Conrad Irwin  2011-03-28 00:10:08 
UTC ---
Yes, I imagine that would be very useful, though not absolutely necessary.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28286] $wgHitcounterUpdateFreq is either not working or needs proper description

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28286

--- Comment #1 from Subfader  2011-03-27 23:45:22 UTC ---
For those who are too lazy to click:

It seems that nobody knows how $wgHitcounterUpdateFreq works or even saves CPU
load.

A few weeks ago someone FINALLY added a description about the technical
details:
"When this setting is set to a number bigger than 1, the page id of any page
viewed is stored in the hitcounter table. About 1 in every
($wgHitcounterUpdateFreq)*0.25 hits, the number of entries in the hit counter
table is checked. If there is more than $wgHitcounterUpdateFreq entries in the
hitcounter table, then for each entry in the hitcounter table, the relevant
page_counter field in the page table is updated by 1 (and the hitcounter table
is emptied). Note if the same page is visited twice (or more) between updates
of the page table, it is only counted once."

But this doesn't seem to be true:

Meanwhile I observed that the description ("if the same page is visited twice
(or more) between updates of the page table, it is only counted once.") can't
be true:
I use $wgHitcounterUpdateFreq = '1100';. According to the description this
means that the view counter of an accessed page is raised by 1 within 1100
total wiki page accesses, no matter if said page has been accessed more than
once within those 1100 page accesses. Today I added a new page which I knew
would be HOT. After 15 minutes the footer did not read the view count yet (less
than 1100 total page accesses within that time, which seems ok with ~200,000
real page hits per day). After 30 mins it read that the page was accessed 50
times. This seems real too but can't be true with $wgHitcounterUpdateFreq =
'1100'; according to the description! Cos this would mean that my wiki had 1100
x 50 = 55,000 page access in 30 minutes. No way!

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 25676] Deploy FirefoggChunkedUpload extension to Wikimedia wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25676

--- Comment #11 from Tim Starling  2011-03-27 23:35:58 
UTC ---
(In reply to comment #9)
> Reopening since Tim's arguments for WONTFIX pertained mostly to the Firefogg
> add-on (client-side) rather than the FirefoggChunkedUpload extension
> (server-side support).

Actually I think the second paragraph in comment 5, where I explained why I
don't think the server-side extension should be enabled, was longer than the
first paragraph, which dealt with my objections to the client-side.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28286] New: $wgHitcounterUpdateFreq is either not working or needs proper description

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28286

   Summary: $wgHitcounterUpdateFreq is either not working or needs
proper description
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: minor
  Priority: Normal
 Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: subfa...@gmail.com


http://www.mediawiki.org/wiki/Manual:$wgHitcounterUpdateFreq

$wgHitcounterUpdateFreq is not described properly. It is totally unclear how it
saves CPU load. The description is false. See the talk page.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28260] Dynamically using field values within the form

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28260

--- Comment #8 from John McClure  2011-03-27 23:31:20 
UTC ---
I suppose {{{for template|#set:}}} means 
(1) multiple & strict parameters are not applicable
(2) any fields withOUT values from property or show on select are meaningless
Anything else? It's interesting to have this capability/

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28260] Dynamically using field values within the form

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28260

--- Comment #7 from John McClure  2011-03-27 23:20:05 
UTC ---
Nice to know - many thanks! (didnt see this in the doc)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28282] secure.wikimedia.org certificate expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28282

Ryan Lane  changed:

   What|Removed |Added

 AssignedTo|wikibugs-l@lists.wikimedia. |rlan...@gmail.com
   |org |

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28285] PHP Notice: Thread 10859 has no title.

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28285

--- Comment #2 from Andrew Garrett  2011-03-27 22:38:36 
UTC ---
(In reply to comment #1)
> There should be no no debug warnings/notices during normal usage on a wiki.
> Raising priority.

In general yes, but the warnings/notices in LQT are so endemic and inherent to
the original LiquidThreads design that my response is a major backend rewrite,
rather than firefighting. It will be done by Easter.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28282] secure.wikimedia.org certificate expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28282

Reedy  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Reedy  2011-03-27 22:31:18 UTC ---
 !log pushing new star cert to singer

 !log restarting apache on singer

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28260] Dynamically using field values within the form

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28260

f.trott  changed:

   What|Removed |Added

 CC||f.tr...@gmx.net

--- Comment #6 from f.trott  2011-03-27 22:21:44 UTC ---
John,

for avoiding the annoyingly simple templates that do nothing but {{#set}}
values try

{{{for template|#set:}}}
... 
Category: {{{field|Category|values from property=Category}}}
...
{{{end template}}}

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28285] PHP Notice: Thread 10859 has no title.

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28285

Krinkle  changed:

   What|Removed |Added

   Priority|Normal  |High
 CC||krinklem...@gmail.com

--- Comment #1 from Krinkle  2011-03-27 22:21:15 UTC ---
There should be no no debug warnings/notices during normal usage on a wiki.
Raising priority.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28285] New: PHP Notice: Thread 10859 has no title.

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28285

   Summary: PHP Notice:  Thread 10859 has no title.
   Product: MediaWiki extensions
   Version: any
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: Normal
 Component: LiquidThreads
AssignedTo: agarr...@wikimedia.org
ReportedBy: s...@reedyboy.net
CC: bhar...@wikimedia.org


[27-Mar-2011 22:12:27] PHP Notice:  Thread 10859 has no title. [Called from
ThreadHistoryPager::getActionDescription in
/www/w/extensions/LiquidThreads/classes/ThreadHistoryPager.php at line 115] for
/w/i.php?title=Thread:Project:Translator/_zh_Chinese_%E2%80%93_%E4%B8%AD%E6%96%87_(3)&lqt_method=thread_history
GlobalFunctions.php line 3129 calls wfBacktrace()
Thread.php line 1229 calls wfWarn()
ThreadHistoryPager.php line 115 calls Thread::title()
ThreadHistoryPager.php line 95 calls
ThreadHistoryPager::getActionDescription()
Pager.php line 875 calls ThreadHistoryPager::formatValue()
Pager.php line 317 calls TablePager::formatRow()
ThreadHistoryListingView.php line 23 calls IndexPager::getBody()
Dispatch.php line 83 calls ThreadHistoryListingView::show()
Dispatch.php line 182 calls LqtDispatch::threadPermalinkMain()
- line - calls LqtDispatch::tryPage()
Hooks.php line 237 calls call_user_func_array()
Hooks.php line 38 calls Hooks::run()https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28260] Dynamically using field values within the form

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28260

Yaron Koren  changed:

   What|Removed |Added

Summary|Querying form variables |Dynamically using field
   ||values within the form

--- Comment #5 from Yaron Koren  2011-03-27 22:12:44 UTC ---
Changing to a more descriptive title.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28277] Error when importing [[Template:0]] from Wikipedia

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28277

--- Comment #3 from mybugs.m...@gmail.com 2011-03-27 21:59:26 UTC ---
Created attachment 8338
  --> https://bugzilla.wikimedia.org/attachment.cgi?id=8338
screenshot of error

(In reply to comment #2)
> Try it again?

Still the same.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28260] Querying form variables

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28260

--- Comment #4 from John McClure  2011-03-27 21:57:10 
UTC ---
As a consequence certain templates can be eliminated altogether, eg
the annoyingly simple templates that do nothing but {{#set}} values:

{{{for template|Minor|nowrite=nowrite}}}
... 
Category: {{{field|Category|values from property=Category}}}
...
{{{end template}}}

{{{for save step|x}}}
{{#set: Category={{#formvar:Minor|category}} }}
{{{end save step|x}}}

& about the Show on select approach..
Yes that's an option but life gets really difficult very fast when there's more
than one string whose visibility is to be controlled.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28282] secure.wikimedia.org certificate expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28282

--- Comment #3 from Martin Schröder  2011-03-27 21:39:08 UTC 
---
See also bug 27187

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28284] New: Undefined property: WikiImporter::$nodeType in /mediawiki/trunk/extensions/LiquidThreads/classes/Hooks.php on line 614

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28284

   Summary: Undefined property: WikiImporter::$nodeType in
/mediawiki/trunk/extensions/LiquidThreads/classes/Hook
s.php on line 614
   Product: MediaWiki extensions
   Version: any
  Platform: All
OS/Version: All
Status: NEW
  Severity: minor
  Priority: Normal
 Component: LiquidThreads
AssignedTo: agarr...@wikimedia.org
ReportedBy: s...@reedyboy.net
CC: bhar...@wikimedia.org


( ! ) Notice: Undefined property: WikiImporter::$nodeType in
/home/reedy/mediawiki/trunk/extensions/LiquidThreads/classes/Hooks.php on line
614
Call Stack
#TimeMemoryFunctionLocation
10.645264{main}( )../index.php:0
20.01903772640MediaWiki->performRequestForTitle( )   
../index.php:104
30.01983975576MediaWiki->handleSpecialCases( )../Wiki.php:63
40.02054310384SpecialPage::executePath( )../Wiki.php:246
50.02484506496SpecialImport->execute( )../SpecialPage.php:608
60.04746315648SpecialImport->doImport( )../SpecialImport.php:67
70.61298103600WikiImporter->doImport( )../SpecialImport.php:126
80.61908103976WikiImporter->handlePage( )../Import.php:371
90.62018117880wfRunHooks( )../Import.php:480
100.62018117880Hooks::run( )../Hooks.php:38
110.62028140312call_user_func_array ( )../Hooks.php:237
120.62028140928LqtHooks::handlePageXMLTag( )../Hooks.php:0


When trying to import from Enwiki to my dev wiki

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28277] Error when importing [[Template:0]] from Wikipedia

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28277

--- Comment #2 from Reedy  2011-03-27 21:35:46 UTC ---
WFM on trunk

Try it again?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28282] secure.wikimedia.org certificate expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28282

--- Comment #2 from Platonides  2011-03-27 21:35:11 UTC 
---
The newer star cert is deployed in kaulen and williams. This is trivial to fix
(with appropiate permissions).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28282] secure.wikimedia.org certificate expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28282

Martin Schröder  changed:

   What|Removed |Added

   Priority|Normal  |High
   Severity|major   |critical

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28277] Error when importing [[Template:0]] from Wikipedia

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28277

--- Comment #1 from Reedy  2011-03-27 21:34:24 UTC ---
I'd guess it's got ""

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28282] secure.wikimedia.org certificate expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28282

Reedy  changed:

   What|Removed |Added

 CC||mar...@oneiros.de

--- Comment #1 from Reedy  2011-03-27 21:32:38 UTC ---
*** Bug 28283 has been marked as a duplicate of this bug. ***

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28283] secure.wikimedia.org cert expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28283

Reedy  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Reedy  2011-03-27 21:32:38 UTC ---


*** This bug has been marked as a duplicate of bug 28282 ***

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28283] secure.wikimedia.org cert expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28283

Martin Schröder  changed:

   What|Removed |Added

   Priority|Normal  |High

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28283] New: secure.wikimedia.org cert expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28283

   Summary: secure.wikimedia.org cert expired
   Product: Wikimedia
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: blocker
  Priority: Normal
 Component: SSL related
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: mar...@oneiros.de


The current cert for secure.wikimedia.org (serial 0B:22:8F) expired 27.03.2011
22:57:55

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28260] Querying form variables

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28260

--- Comment #3 from Yaron Koren  2011-03-27 21:28:35 UTC ---
Okay... I think you could have just said, "set text in the form based on a
field value" and left it at that, but thanks. :) By the way, if what you
describe as the "category" field is set by a dropdown or radiobutton, this can
already be done via the "show on select=" parameter.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 27642] Missing dumps for last three months

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=27642

mybugs.m...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from mybugs.m...@gmail.com 2011-03-27 21:27:40 UTC ---
Latest dump was completed with no erros:
http://dumps.wikimedia.org/ptwikibooks/20110322/

The problem seems to have been fixed "by itself" ;-)
(or someone has a the number of revision in which this was fixed?)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 25676] Deploy FirefoggChunkedUpload extension to Wikimedia wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25676

--- Comment #10 from Michael Dale  2011-03-27 21:24:29 UTC ---
(In reply to comment #9)
> I would prefer chunked upload support to be in core. IIRC the reason it was
> disabled before was that security checks were only done on the individual
> chunks and not on the reassembled file, but that should be easy to fix.

That vulnerability was only in the extension not in the 'core' version we had
deployed. ie line 82 called the parent verifyUpload on the entire upload once
we received the last chunk [1]... it was used as the rational for disabling it
for who knows why ... but that is really water under a bridge with a dead horse
on top 

...

Happy to add the native html5 blob client side chunk uploading support to
upload wizard if we can get any movement on the server side support.  

[1]
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/upload/UploadFromChunks.php?revision=57732&view=markup&pathrev=59400

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28282] New: secure.wikimedia.org certificate expired

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28282

   Summary: secure.wikimedia.org certificate expired
   Product: Wikimedia
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: Normal
 Component: SSL related
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: nakor...@gmail.com


The certificate at secure.wikimedia.org expired 15 minutes ago: 03/27/2011
04:57 PM EDT

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28260] Querying form variables

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28260

--- Comment #2 from John McClure  2011-03-27 21:06:53 
UTC ---
Sure.

First of all, it's fair to say that ontologies can easily have hundreds if not
thousands of categories. As you well know the OWL world maps its classes to
wiki categories, and that larger ontologies can have thousands of classes both
explicitly and implicitly declared. And also that many strongly argue the need
to declare only classes that have at least one unique existential property or
constraint.

So the SF approach is that every class has its own form, and every form has its
own form-template (so that subclasses can inherit the same form-template which
defines the properties of that class perforce common to its subclasses) which
all suggests that SF envisions a hierarchy of form-templates coinciding fairly
exactly to the class hierarchy buried & expressed within Category: entries.

The SF approach can lead to systems more difficult to maintain. For instance,
let us propose that a Persons category has Adults and Minors category, the
latter has Boys & Girls categories. So I want a form for minors different than
for adults, and the only difference between the boys & girls forms is one says
Boy's Name & the other says Girl's Name. 

How do I do that simple thing?

Option 1. {{template:minor form|Boys}} is called by form:Boy and
{{template:minor form|Girl}} is called by form:Girl.

Option 2. embed either Boy or Girl into the name of the page so that it can be
queried in Form:Minor. eg {{#ifexpr: {{#titleparts:{{PAGENAME}}|...}}|Boys
Name|Girls Name}}. This method means there is no need for either a Form:Boy and
Form:Girl - hooray!

Option 3. Is there one?

How about one form:Minor with no templates at all:
{{#ifexp: 
{{#formvar:Minor|Category}}=Boy OR {{#show:{{PAGENAME}}|?Category}}=Boy
|Boys Name|Girls Name
}}

Hmm, why does SF require that my form need query the smw store to retrieve a
value simply stored by template:Minor? Especially when it's right there,
already parsed, and placed into a field on the form by SF? 

In other words, {{#formvar:}} retrieves the value of a variable for a template
as it would be 'saved' at that moment by the SF processor, which would HAPPEN
to correlate to the value that is used by the template itself.
-
Ultimately there is a direction for this. Currently SF is a stateless processor
- it even requires special forethought to tell when the form is being applied
to a new page vs an existing page!

{{#formvar}} blurs the line between when user-defined processng occurs; now
such is only when the form is SAVED, period. With {{#formvar}} one can then
define STEPS within a form, each corresponding to a NEXT STEP button. The
{{formvar}} parser function is invoked by a form step, storing intermediate
data itself, eg

{{for template|Minor}}
... 
{{end template}}

{{for step|x}}
{{Minor
|category={{#formvar:Minor|category}}
}}
{{end step|x}}

IOW, this could eliminate the SF function that SF executes the page that SF
stores. I realize that SF has got to do so when it provides no definition of
what is to be done AFTER user initiates SAVE (or NEXT STEP), but it seems to me
that piece can usefully be reformed and refactored!

Best regards,
John

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28252] MediaWiki doesn't parse HTML table attributes within a template inclusion

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28252

Thana  changed:

   What|Removed |Added

 CC||m8r-cyc...@mailinator.com

--- Comment #2 from Thana  2011-03-27 21:01:21 UTC 
---
> This shouldn't be the expected behaviour. BTW: Why is it impossible to match
> nested template inclusions against a regular pattern, so that the pipe hiding
> ("|" to e.g. {{!}}) is not neccessary? I would wish that something like that
> is possible in a near future version of MediaWiki:

depending on rené's actual needs, passing some table-generating template as a
parameter might be easier and more scrutable than using {{!}}.

> {{someTemplate|
>   {{make_some_table
>   | caption = some table
>   | c1 = content
>   | c2 = content
>   }}
> }}

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28152] Special:Preferences is not working on gu.wiki

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28152

--- Comment #10 from Andrew Garrett  2011-03-27 
20:54:36 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > Yes, the gu translations need to be fixed in TWN.
> 
> Ideally, the whole prefs interface shoulde be changed to work as 'value' => 
> 'ui
> message' instead of the other way around as we currently do it. Unfortunately,
> there's no clear way to do that except for a backward-incmpatible rewrite of
> HTMLForm. Sigh.

This is a deliberate design decision in HTMLForm, used to support grouped
options in select boxes. In theory it could have been done differently, I
suppose, but why would you want two options to be the same anyway? That's just
deliberately confusing.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

--- Comment #9 from Happy-melon  2011-03-27 
20:49:29 UTC ---
"incomplete" would work; "followup" would tend to suggest that the revision
*is* a followup, which it probably isn't.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 26016] When a user signs off a revision, log it somewhere (like status changes)

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=26016

--- Comment #4 from Reedy  2011-03-27 20:47:38 UTC ---
Enum killed in r84887

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 26676] Bugs that should be fixed for 1.17 release tarball (tracking)

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=26676

Bug 26676 depends on bug 27579, which changed state.

Bug 27579 Summary: [Installer] Chrome saves config as LocalSettings.php.php
https://bugzilla.wikimedia.org/show_bug.cgi?id=27579

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 27579] [Installer] Chrome saves config as LocalSettings.php.php

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=27579

Brion Vibber  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #4 from Brion Vibber  2011-03-27 20:46:53 UTC ---
I'm going to provisionally close this out; quick googly search seems to
indicate that this is still sometimes a Chrome issue, but depends on vague
mysterious things that no one can pinpoint -- possibly on what other
applications have claimed ownership of file types or some such horror that's
unpredictable.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 27579] [Installer] Chrome saves config as LocalSettings.php.php

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=27579

--- Comment #3 from Brion Vibber  2011-03-27 20:43:42 UTC ---
I cannot reproduce this with Chrome 10.0.648 on Windows XP. The file auto-saves
as "LocalSettings.php" in my downloads dir... if I right-click on the link and
select 'save file as', I see "LocalSettings" as the suggested filename, with
.php in the extension box. Files get saved as expected as "LocalSettings.php",
no double extension.

Changing Chrome settings to require prompting me instead of auto-saving to
%HOME%\My Documents\Downloads doesn't seem to affect this, I still get the
expected behavior.

Might depend on OS settings.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 26676] Bugs that should be fixed for 1.17 release tarball (tracking)

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=26676

Bug 26676 depends on bug 28158, which changed state.

Bug 28158 Summary: Labels for DB types on page=DBConnect are too narrow
https://bugzilla.wikimedia.org/show_bug.cgi?id=28158

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28158] Labels for DB types on page=DBConnect are too narrow

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28158

Brion Vibber  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Brion Vibber  2011-03-27 20:34:32 UTC ---
I can't reproduce this with Opera 11.01 either on Windows XP or Linux (tried
both English and Russian UI in MW installer, standard US English OS; Linux was
64-bit Ubuntu 10.10).

Tested current trunk and 1.17wmf1 as of r84871.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

--- Comment #8 from Reedy  2011-03-27 20:24:37 UTC ---
followup seems misleading to me

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

--- Comment #7 from MZMcBride  2011-03-27 20:23:32 UTC ---
(In reply to comment #6)
> Hmmm, that is true. And since fixme -> broken, we should probably be 
> consistent
> with using real words  here.
> 
> Suggestions for real words meaning 'improveme' or 'needsmore'?

"incomplete" or "followup"?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28281] New: Differentiate between MySQL and MySQL forks (ie MariaDB)

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28281

   Summary: Differentiate between MySQL and MySQL forks (ie
MariaDB)
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Database
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: s...@reedyboy.net


 just switched a mediawiki from MySQL to MariaDB on Debian squeeze,
went all fine, wiki kept running.  on Special:Version
"5.1.55-MariaDB-mariadb98~squeeze-log", the only minor thing is  the "Product"
Link is eventually MySQL and link to mysql.com 
 MariaDB isn't "supported" as a fork

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28280] Fatal error, page not available

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28280

Reedy  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||s...@reedyboy.net
 Resolution||FIXED

--- Comment #1 from Reedy  2011-03-27 20:16:33 UTC ---
r84870, merged out in r84871

Scapped out to site

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 26676] Bugs that should be fixed for 1.17 release tarball (tracking)

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=26676

Bug 26676 depends on bug 27170, which changed state.

Bug 27170 Summary: [Installer] Install does not complete when choosing a CC 
license
https://bugzilla.wikimedia.org/show_bug.cgi?id=27170

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 27170] [Installer] Install does not complete when choosing a CC license

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=27170

Brion Vibber  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Brion Vibber  2011-03-27 20:13:42 UTC ---
There were two things breaking this:
* X-Frame-Options forbade our final step of the license selector, or the
license selection shower, from being loaded properly. This lead to it looking
wrong.
* The installation URL fingerprinting broke on the long query string that's on
the final step. As a result, the user's selection got saved into a different
session subkey, thinking it belonged to a different installation. It would then
not get seen by the surrounding page's installer instance, causing the
confusion.

Fix removes the X-Frame-Options for the CC bit, and drops query strings before
the rest of URL normalization in the fingerprint check so the CC bits now see
the same session key as the rest.

Fixed in r84881.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 27170] [Installer] Install does not complete when choosing a CC license

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=27170

Brion Vibber  changed:

   What|Removed |Added

 AssignedTo|wikibugs-l@lists.wikimedia. |br...@pobox.com
   |org |

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 26676] Bugs that should be fixed for 1.17 release tarball (tracking)

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=26676

Bug 26676 depends on bug 26937, which changed state.

Bug 26937 Summary: [Installer] Javascript-opened sections not open on back or 
error
https://bugzilla.wikimedia.org/show_bug.cgi?id=26937

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 26937] [Installer] Javascript-opened sections not open on back or error

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=26937

Brion Vibber  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Brion Vibber  2011-03-27 19:22:30 UTC ---
Fixed on trunk in r84875.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 26937] [Installer] Javascript-opened sections not open on back or error

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=26937

Brion Vibber  changed:

   What|Removed |Added

 AssignedTo|wikibugs-l@lists.wikimedia. |br...@pobox.com
   |org |

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28280] New: Fatal error, page not available

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28280

   Summary: Fatal error, page not available
   Product: MediaWiki extensions
   Version: any
  Platform: All
   URL: http://fr.wikisource.org/wiki/Rig_V%C3%A9da
OS/Version: All
Status: NEW
  Severity: major
  Priority: Normal
 Component: ProofreadPage
AssignedTo: thoma...@gmx.de
ReportedBy: yan...@gmail.com


Hello,

When trying to access this page, I get

PHP fatal error in
/usr/local/apache/common-local/php-1.17/extensions/ProofreadPage/ProofreadPage_body.php
line 888: 
Call to a member function getArticleID() on a non-object

Thanks, Yann

http://fr.wikisource.org/wiki/Rig_V%C3%A9da

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 25744] Figure out why Firefox disobeys caching headers from RL, test cacheability of RL responses in other browsers

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25744

--- Comment #5 from Roan Kattouw  2011-03-27 18:21:29 
UTC ---
(In reply to comment #4)
> > That's not a proper fix, as it will make invalidations (updates to JS/CSS)
> > take unreasonably long.
> 
> Well, if they can change, why are they being sent without a version or date in
> the first place? :-)
Because the version parameter would be embedded in HTML and be cached in Squid
otherwise.

The version parameter has two uses. First, its presence indicates that the
request can be cached for 30 days (5 minutes if absent). Second, changing its
value will cause a cache miss (since the URL is different). The idea here is
that the startup module lists the last-changed timestamps for each module,
which we then use to build the versioned URLs. This way, the startup module is
refreshed every 5 minutes and the other modules are only refreshed when they've
changed (or after 30 days).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 25744] Figure out why Firefox disobeys caching headers from RL, test cacheability of RL responses in other browsers

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=25744

--- Comment #4 from Laurence 'GreenReaper' Parry  
2011-03-27 18:05:18 UTC ---
> That's not a proper fix, as it will make invalidations (updates to JS/CSS)
> take unreasonably long.

Well, if they can change, why are they being sent without a version or date in
the first place? :-)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28279] PostgreSQL 8.4.7 don't work extension

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28279

--- Comment #1 from Jack Phoenix  2011-03-27 
18:03:50 UTC ---
This is a known issue. Mark suggested in
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/75007#c11339 using a
Database method (Database::unixTimestamp) instead of UNIX_TIMESTAMP, and I
implemented his suggestion in
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/77339), but the said
method was removed in r79345 so I had to revert my changes in r79748. I'm not
aware of a replacement for Database::unixTimestamp() though. :-(

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28279] New: PostgreSQL 8.4.7 don't work extension

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28279

   Summary: PostgreSQL 8.4.7 don't work extension
   Product: MediaWiki extensions
   Version: any
  Platform: PC
   URL: http://thesecretworld.ru
OS/Version: Linux
Status: NEW
  Keywords: postgresql
  Severity: critical
  Priority: Normal
 Component: SocialProfile
AssignedTo: j...@countervandalism.net
ReportedBy: yackushe...@gmail.com


I have SocialProfile from SVN (84866), PostgreSQL 8.4.7 and Mediawiki 1.16.2
Tables in base are created, but at calling on page of the user I receive an
error:

A database error has occurred Query: SELECT
ug_id,ug_user_id_from,ug_user_name_from,ug_gift_id,ug_date,ug_status,gift_name,gift_description,gift_given_count,UNIX_TIMESTAMP(ug_date)
AS unix_time FROM user_gift INNER JOIN gift ON ((ug_gift_id = gift_id)) WHERE
(ug_user_id_to = 2) ORDER BY ug_id DESC LIMIT 4 OFFSET 0 Function:
UserGifts::getUserGiftList Error: 1 ERROR: function unix_timestamp(timestamp
with time zone) does not exist LINE 1:
...tatus,gift_name,gift_description,gift_given_count,UNIX_TIMES... ^ HINT: No
function matches the given name and argument types. You might need to add
explicit type casts. Backtrace:
0 /var/www/site/public_html/includes/db/Database.php(538):
DatabasePostgres->reportQueryError('ERROR: functio...', 1, 'SELECT ug_id,u...',
'UserGifts::getU...', false)
1 /var/www/site/public_html/includes/db/Database.php(874):
DatabaseBase->query('SELECT ug_id,u...', 'UserGifts::getU...')
2
/var/www/site/public_html/extensions/SocialProfile/UserGifts/UserGiftsClass.php(327):
DatabaseBase->select(Array, Array, Array, 'UserGifts::getU...', Array, Array)
3
/var/www/site/public_html/extensions/SocialProfile/UserProfile/UserProfilePage.php(920):
UserGifts->getUserGiftList(0, 4)
4
/var/www/site/public_html/extensions/SocialProfile/UserProfile/UserProfilePage.php(69):
UserProfilePage->getGifts('DuskMan')
5 /var/www/site/public_html/includes/Wiki.php(493): UserProfilePage->view()
6 /var/www/site/public_html/includes/Wiki.php(70):
MediaWiki->performAction(Object(OutputPage), Object(UserProfilePage),
Object(Title), Object(User), Object(WebRequest))
7 /var/www/site/public_html/index.php(117):
MediaWiki->performRequestForTitle(Object(Title), Object(UserProfilePage),
Object(OutputPage), Object(User), Object(WebRequest))
8 {main}

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28278] New: Add timestamp/time to complete each entry in update.php

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28278

   Summary: Add timestamp/time to complete each entry in
update.php
   Product: MediaWiki
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Maintenance scripts
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: s...@reedyboy.net
CC: innocentkil...@gmail.com


When running updates scripts locally, it's useful to know roughly how long
things take to execute, to note in CR or on bugs. Simply appending "... took
01:12" or something would suffice

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 26016] When a user signs off a revision, log it somewhere (like status changes)

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=26016

--- Comment #3 from Reedy  2011-03-27 17:24:58 UTC ---
*swap the enum for varchar

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28253] Mark animation on thumb links

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28253

--- Comment #3 from Umherirrender  2011-03-27 
17:21:14 UTC ---
(In reply to comment #2)
> I don't like that symbol/icon, It looks way to much like the one we already 
> use
> on thumbnail images[1] and would just confuse people I think...
> [1]. http://bits.wikimedia.org/skins-1.17/common/images/magnify-clip.png

The image is inspire from magnify-clip.png. I have not found an other image for
this, and then I have create a new one, which looks like an animation (One
picture behind other pictures)

It is only a image, you can change it or create a new one, no problem.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28275] Change 0/1 to common true/false in boolean settings in DefaultSettings.php

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28275

Roan Kattouw  changed:

   What|Removed |Added

 CC||roan.katt...@gmail.com

--- Comment #2 from Roan Kattouw  2011-03-27 17:17:56 
UTC ---
Preferences of the 'toggle' type (i.e. boolean preferences) are stored
numerically as 0 or 1, not as false or true. Applying this patch and checking
whether anything would break as a result is more trouble than it's worth IMO.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 26016] When a user signs off a revision, log it somewhere (like status changes)

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=26016

--- Comment #2 from Reedy  2011-03-27 17:11:36 UTC ---
Use code_prop_changes and add to cpc_attrib enum('status','tags')

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28260] Querying form variables

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28260

--- Comment #1 from Yaron Koren  2011-03-27 17:10:31 UTC ---
Can you list some other ways you'd like to be able to use field values within
the form, besides setting whether or not another field is mandatory? I'd like
to get a better sense of the scope of what you're asking about.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 27473] Apostrophe in linktrail breaks bolded links

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=27473

--- Comment #3 from Platonides  2011-03-27 17:06:07 UTC 
---
Created attachment 8337
  --> https://bugzilla.wikimedia.org/attachment.cgi?id=8337
Alternative fix: Modify Ca and Kaa linktrail

Patch for changing the linktrail in the messages file. The linktrail is not
NS_MEDIAWIKI customizable, so we have full control to make them match the
current code.

I am using a negative lookahead instead of duplicating the rest of the
linktrail.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28122] Path fragmenting results in all paths having the same modified property

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28122

Chad H.  changed:

   What|Removed |Added

   Priority|Normal  |High
   Severity|minor   |normal

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28277] New: Error when importing [[Template:0]] from Wikipedia

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28277

   Summary: Error when importing [[Template:0]] from Wikipedia
   Product: MediaWiki
   Version: wikimedia-deployment
  Platform: All
   URL: https://secure.wikimedia.org/wikibooks/pt/w/index.php?
title=Especial:Importar&action=submit
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: Special pages
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: mybugs.m...@gmail.com


If we try to use [[b:pt:Special:Import]] to import [[Template:0]] from
Wikipedia the page is reporting the following error:
 "Import failed: Expected  tag, got"
Could this be fixed?

PS: the error message should also be more descriptive (got what?)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28245] Title::getUserPermissionsErrors() does wierd things to StubObjects

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28245

Alexandre Emsenhuber [IAlex]  changed:

   What|Removed |Added

 CC||ialex.w...@gmail.com

--- Comment #2 from Alexandre Emsenhuber [IAlex]  
2011-03-27 16:51:12 UTC ---
Actually you can just remove the whole check since we don't use a StubObject on
$wgUser since r70970.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28276] New: Inconsistencies in irc.wikimedia make it hard to monitor certain wikis

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28276

   Summary: Inconsistencies in irc.wikimedia make it hard to
monitor certain wikis
   Product: Wikimedia
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Keywords: shell
  Severity: major
  Priority: Normal
 Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: krinklem...@gmail.com


The following (possibly more) can't be minitored easily due to their abnormal
channel name.
* #mediawiki.wikipedia
* #advisory.wikipedia
* #species.wikipedia
* pa.us.wikimedia.org (?) [1]

Note that #commons.wikimedia and #meta.wikimedia and #wikisource are fine and
represent the domainname exactly.

Bots using irc.wikimedia.org to monitor vandalism (ie. the [[m:Countervandalism
Network]]) are unable to monitor these (unless hacking the bot and hardcoding
the paths).

species.wikipedia is a bit of an exception as species.wikipedia.org redirects
to species.wikimedia.org so that one still works when monitored through the bot
as 'species.wikipedia' it will be able to connect to
species.wikipedia.org/w/api.php (as it redirects)

The others are however hard to monitor (eg. not monitored) as the channel
neither matches the hostname nor the interwiki prefix. As a result the
small-wiki monitoring team is unable to properly monitor these wikis.

Please move #mediawiki.wikipedia to #mediawiki as soon as possible (and leave
the old channel as redirect for backwards compatibility for those that have
hardoded the paths)

I was unable to find where this chapter wiki is monitored, nor have I found a
way to link to it with an interwiki link on-wiki (There is no pa-us or pa.us
wiki)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28275] Change 0/1 to common true/false in boolean settings in DefaultSettings.php

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28275

Chad H.  changed:

   What|Removed |Added

 CC||innocentkil...@gmail.com

--- Comment #1 from Chad H.  2011-03-27 16:39:56 UTC 
---
Does this break any strict comparisons?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28275] New: Change 0/1 to common true/false in boolean settings in DefaultSettings.php

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28275

   Summary: Change 0/1 to common true/false in boolean settings in
DefaultSettings.php
   Product: MediaWiki
   Version: 1.18-svn
  Platform: All
OS/Version: All
Status: NEW
  Keywords: easy
  Severity: enhancement
  Priority: Normal
 Component: Documentation
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: theevilipaddr...@hotmail.de


Created attachment 8336
  --> https://bugzilla.wikimedia.org/attachment.cgi?id=8336
Trivial patch

I think that boolean values in DefaultSettings.php should, for consistency,
always use true or false instead of 0 or 1. Though both works, I think it's
confusing for people when it differs. Not everyone might be aware that it's a
boolean value when there are numbers. Simple patch added, thanks.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

--- Comment #6 from Chad H.  2011-03-27 16:28:16 UTC 
---
Hmmm, that is true. And since fixme -> broken, we should probably be consistent
with using real words  here.

Suggestions for real words meaning 'improveme' or 'needsmore'?

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

MZMcBride  changed:

   What|Removed |Added

 CC||b...@mzmcbride.com

--- Comment #5 from MZMcBride  2011-03-27 16:25:25 UTC ---
Looking at the current statuses
(), most use real
words. The only one that doesn't is "fixme" currently. I think something like
"incomplete" makes more sense than another nonsense word like "improveme".

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

--- Comment #4 from Reedy  2011-03-27 16:20:50 UTC ---
r84852 adds "improveme"

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

Happy-melon  changed:

   What|Removed |Added

 CC||happy.melon.w...@gmail.com

--- Comment #3 from Happy-melon  2011-03-27 
16:16:50 UTC ---
+1 for "broken" and "improveme", with "broken" replacing the current "fixme".

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

Max Semenik  changed:

   What|Removed |Added

 CC||maxsem.w...@gmail.com

--- Comment #2 from Max Semenik  2011-03-27 16:15:37 UTC 
---
improveme :)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

Ariel T. Glenn  changed:

   What|Removed |Added

 CC||ar...@wikimedia.org

--- Comment #1 from Ariel T. Glenn  2011-03-27 16:02:12 
UTC ---
I propose "broken" and "needswork" (and retiring "fixme" since it's not
instantly clear from the name what is intended).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28274] New: Add 'needsmore' status

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28274

   Summary: Add 'needsmore' status
   Product: MediaWiki extensions
   Version: any
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: Normal
 Component: CodeReview
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: innocentkil...@gmail.com
CC: innocentkil...@gmail.com, s...@reedyboy.net


I'm not picky on the name if you can come up with a better one :) Per
wikitech-l over the past week or two, we've been discussing a lot of stuff
about the tool. A major problem with fixme has come up, in that we currently
use it for two things:

1) This is broken, needs immediate fix or reversion
2) This could use some more work/followup/tests, but isn't actually *broken*
as-is.

The former category is what fixme was originally designed to mark, but kind of
took on the second role since we don't have a status for it. Adding a status
for that situation where it's not broken but needs a little more love would
help us stop abusing fixme and better organize the state of code review (the
action)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28152] Special:Preferences is not working on gu.wiki

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28152

--- Comment #9 from Roan Kattouw  2011-03-27 15:48:03 
UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > Yes, the gu translations need to be fixed in TWN.
> 
> Ideally, the whole prefs interface shoulde be changed to work as 'value' => 
> 'ui
> message' instead of the other way around as we currently do it. Unfortunately,
> there's no clear way to do that except for a backward-incmpatible rewrite of
> HTMLForm. Sigh.

I agree that using translated strings as array keys is not nice, but the
expectation that different choices for the same preference are not translated
to byte-identical strings is not an unreasonable one IMO.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28273] New: Merge purgeList and purgeNamespace scripts

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28273

   Summary: Merge purgeList and purgeNamespace scripts
   Product: MediaWiki
   Version: 1.17
  Platform: All
OS/Version: All
Status: ASSIGNED
  Severity: enhancement
  Priority: Normal
 Component: Maintenance scripts
AssignedTo: has...@free.fr
ReportedBy: innocentkil...@gmail.com
CC: innocentkil...@gmail.com


r83404 introduced the new purgeNamespace script. It does the same thing as
purgeList, but just operates on a given NS rather than a list of pages.

Should probably just delete the latter and merge its functionality into the
former, including the batch size logic.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 18197] Revert recentchanges limit to 5000 (id.wikipedia)

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=18197

Lejonel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||lejo...@telia.com
 Resolution||WORKSFORME

--- Comment #5 from Lejonel  2011-03-27 14:44:17 UTC ---
Now the maximum limit seems to be 5000. So WORKSFORME (or maybe dupe of bug
18241).

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 20860] [[Special:Allmessages]] to have direct (edit) link

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=20860

--- Comment #4 from FT2  2011-03-27 14:40:54 UTC ---
Created attachment 8335
  --> https://bugzilla.wikimedia.org/attachment.cgi?id=8335
Suggested layout

Putting the links inline with the message name is asking for trouble. Try this
layout instead (see attachment). 

If it needs to be even shorter, then abbreviate to "(t | e)". Anyone who can
edit these messages will be very familiar with this style of abbreviation and
wiki-shorthand since "e | v" are used as edit and view links on many navigation
templates.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28152] Special:Preferences is not working on gu.wiki

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28152

--- Comment #8 from Max Semenik  2011-03-27 14:40:08 UTC 
---
(In reply to comment #7)
> Yes, the gu translations need to be fixed in TWN.

Ideally, the whole prefs interface shoulde be changed to work as 'value' => 'ui
message' instead of the other way around as we currently do it. Unfortunately,
there's no clear way to do that except for a backward-incmpatible rewrite of
HTMLForm. Sigh.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28270] Add /wmf-config/codereview.php to http://noc.wikimedia.org/conf/

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28270

Roan Kattouw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||roan.katt...@gmail.com
 Resolution||FIXED

--- Comment #1 from Roan Kattouw  2011-03-27 14:20:17 
UTC ---
Done.

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

[Bug 28264] Move ExpandTemplates into core

2011-03-27 Thread bugzilla-daemon

https://bugzilla.wikimedia.org/show_bug.cgi?id=28264

Reedy  changed:

   What|Removed |Added

 CC||s...@reedyboy.net

--- Comment #3 from Reedy  2011-03-27 14:14:07 UTC ---
The "most difficult" thing about doing this would be working out how to
move/merge the messages...

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.

___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

1 2 >

1 - 100 of 126 matches

Mail list logo