[Bug 17222] eAccelerator determines not properly
https://bugzilla.wikimedia.org/show_bug.cgi?id=17222 Tim Starling changed: What|Removed |Added CC||tstarl...@wikimedia.org Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Tim Starling 2009-01-30 07:57:58 UTC --- Our code is correct, if the object cache is disabled then we can't use it. And note that it was disabled for good reason, if MediaWiki was configured to use eaccelerator as an object cache, it could trigger the DoS referred to in http://eaccelerator.net/ticket/37 -- 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 17240] history. js blocks gecko browser with 100% CPU when rendering long history
https://bugzilla.wikimedia.org/show_bug.cgi?id=17240 --- Comment #2 from Marcin Cieślak 2009-01-30 04:16:26 UTC --- The workaround is to put removeHandler(window, 'load', histrowinit); in your skin.js (i.e. Special:Mypage/monobook.js) file and kill the cache (pointy hat to Splarka:) -- 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 17240] history. js blocks gecko browser with 100% CPU when rendering long history
https://bugzilla.wikimedia.org/show_bug.cgi?id=17240 Mike.lifeguard changed: What|Removed |Added CC||mikelifegu...@fastmail.fm --- Comment #1 from Mike.lifeguard 2009-01-30 04:14:14 UTC --- (In reply to comment #0) > CSS restyling code in most of the gecko-based browsers (in the > FrameManager::ReResolveStyleContext for the curious, see > https://developer.mozilla.org/En/Style_System_Overview) when displaying a > history page with larger number of revisions. > > Everything is fine when histrowinit() from history.js is not loaded, i.e > removing the hook or blocking history.js load relieves the situation. > > The problem occurs only at initial page load, further clicks on the history > page do not slow down the browser. > This can (and does) crash the whole browser in at least some cases. -- 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 17240] New: history. js blocks gecko browser with 100% CPU when rendering long history
https://bugzilla.wikimedia.org/show_bug.cgi?id=17240 Summary: history.js blocks gecko browser with 100% CPU when rendering long history Product: MediaWiki Version: 1.15-svn Platform: All URL: http://pl.wikipedia.org/w/index.php?title=Strona_g%C5%82 %C3%B3wna&limit=500&action=history&useskin=monobook&usel ang=en OS/Version: All Status: NEW Severity: major Priority: Normal Component: User interface AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: marcin.cies...@gmail.com CSS restyling code in most of the gecko-based browsers (in the FrameManager::ReResolveStyleContext for the curious, see https://developer.mozilla.org/En/Style_System_Overview) when displaying a history page with larger number of revisions. Everything is fine when histrowinit() from history.js is not loaded, i.e removing the hook or blocking history.js load relieves the situation. The problem occurs only at initial page load, further clicks on the history page do not slow down the browser. -- 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 17232] Broken page layout
https://bugzilla.wikimedia.org/show_bug.cgi?id=17232 --- Comment #4 from Melancholie 2009-01-30 02:50:25 UTC --- Eh, for arz it's [[arz:نقاش_القالب:صندوق_التعديل#Edit_page_rendering_bug]]. (found using W3C validator, by the 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 17232] Broken page layout
https://bugzilla.wikimedia.org/show_bug.cgi?id=17232 Melancholie changed: What|Removed |Added CC||wiki.melancho...@web.de --- Comment #3 from Melancholie 2009-01-30 02:47:26 UTC --- See [[mk:MediaWiki_talk:Sitenotice#Page_rendering_bug]] and [[arz:MediaWiki_talk:Edittools#Edit_page_rendering_bug]] Users have been notified ... -- 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 17238] GENDER-Parserfunction can be abused to fetch the gender of a bunch of users
https://bugzilla.wikimedia.org/show_bug.cgi?id=17238 Melancholie changed: What|Removed |Added CC||wiki.melancho...@web.de --- Comment #1 from Melancholie 2009-01-30 01:53:08 UTC --- Sorry, I see this as invalid. Nobody is forced to specify his or her gender, users can leave/set it being 'Unspecified'! If someone wants to set its account to 'male/female', its a free choice of that user (and actually nothing 'that' private, there are only two possibilities, and mostly users are male anyway ;-) -- the username itself is most often much more revealing. The only thing that should be done is to note (beside the selection menu at [[Special:Preferences]]) that this information will be public! -- 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 17224] Wiki's license information is not available via API
https://bugzilla.wikimedia.org/show_bug.cgi?id=17224 brianna.laug...@gmail.com changed: What|Removed |Added Attachment #5744 is|0 |1 obsolete|| --- Comment #2 from brianna.laug...@gmail.com 2009-01-30 01:51:13 UTC --- Created an attachment (id=5747) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=5747) unified diff for ApiQuerySiteinfo.php -- 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 17050] Change upload rights at Russian Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=17050 Sergey Leschina changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Sergey Leschina 2009-01-30 01:46:14 UTC --- It is no answer here during 2 weeks, and we find other way to stop invalid uploads and want to try it first. If we'll not have good result, we'll back to this query. -- 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 5007] Remove border="0" from wiki footers (image with id=" f-copyrightico") as it is redundant and not W3C compliant
https://bugzilla.wikimedia.org/show_bug.cgi?id=5007 Aryeh Gregor changed: What|Removed |Added CC||simetrical+wikib...@gmail.co ||m Resolution|FIXED |INVALID --- Comment #7 from Aryeh Gregor 2009-01-30 01:35:40 UTC --- Just so no one gets any ideas in the future, changing resolution to INVALID. border="0" is completely valid in XHTML 1.0 Transitional, which is an XHTML standard approved by the W3C, and which we use. What's valid or invalid in XHTML 1.0 Strict is not relevant to MediaWiki. -- 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 17239] New: API should provide DISPLAYTITLE information
https://bugzilla.wikimedia.org/show_bug.cgi?id=17239 Summary: API should provide DISPLAYTITLE information Product: MediaWiki Version: 1.15-svn Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: API AssignedTo: roan.katt...@home.nl ReportedBy: mrzmanw...@gmail.com CC: bryan.tongm...@gmail.com, vasi...@gmail.com It would be nice if the title produced by the DISPLAYTITLE magic word (when present) could be retrieved through the API. This could be useful for things that create user-read content, so that they can use the correct title, not whatever is being substituted by title restrictions (iPod for example). The information is currently only stored in parserOutput, so it would probably have to be an option on action=parse. The only way to get this information now is by looking for it in the page text, which, besides being inefficient, breaks if wrapper templates are used around the magic word (like enwiki uses). -- 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 17072] "save drafts" doesn't work correctly on IE7
https://bugzilla.wikimedia.org/show_bug.cgi?id=17072 Trevor Parscal changed: What|Removed |Added Resolution|WORKSFORME |FIXED --- Comment #3 from Trevor Parscal 2009-01-30 00:26:29 UTC --- Excellent example of behavior. I was quickly able to narrow it down to the fact that IE doesn't register keypress events for non-chatacter keys like backspace which indeed change the content. I added keydown and keyup events to the text input widgets and it seems to be working great! -- 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 17218] Provide a magic word for a user's online status
https://bugzilla.wikimedia.org/show_bug.cgi?id=17218 --- Comment #8 from ^demon 2009-01-30 00:09:29 UTC --- *facepalm* That would be the user passed in the parser function :p So yes, disregard pretty much everything I've said. This "feature" does work as described. -- 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 17218] Provide a magic word for a user's online status
https://bugzilla.wikimedia.org/show_bug.cgi?id=17218 --- Comment #7 from ^demon 2009-01-30 00:08:08 UTC --- Looking at the code, it could potentially be one of two genders depending on the situation. For interface messages, it should always be in the gender you set in your preferences. Otherwise, it depends on the passed $user parameter. Not 100% where that user is coming from; is it the user who's page we're on? User who last purged the cache? User who added the tag? -- 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 17238] New: GENDER-Parserfunction can be abused to fetch the gender of a bunch of users
https://bugzilla.wikimedia.org/show_bug.cgi?id=17238
Summary: GENDER-Parserfunction can be abused to fetch the gender
of a bunch of users
Product: MediaWiki
Version: unspecified
Platform: All
URL: http://de.wikipedia.org/w/api.php?action=expandtemplates
&text={{GENDER:-jha-
|w|m|?}}{{GENDER:1001|w|m|?}}{{GENDER:32X|w|m|?}}{{GENDE
R:AHZ|w|m|?}}{{GENDER:APPER|w|m|?}}{{GENDER:AT|w|m|?}}{{
GENDER:Achates|w|m|?}}{{GENDER:Achim
Raschka|w|m|?}}{{GENDER:Ahellwig|w|m|?}}{{GENDER:Aineias
|w|m|?}}
OS/Version: All
Status: NEW
Severity: normal
Priority: Normal
Component: Page rendering
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: wikipe...@christophmueller.org
Currently the GENDER-parserfunction can be abused to crawel the gender:
This:
echo "http://de.wikipedia.org/w/api.php?action=expandtemplates&text=$(curl -s
"http://de.wikipedia.org/w/api.php?format=jsonfm&action=query&list=allusers&augroup=sysop";
|sed "s/"name": "/{{GENDER:/g"|sed "s/"/|w|m|?}}/g"|grep
\{\{GENDER\:.*\|w\|m\|\?\}\}| tr -d '\n\t')"
generates an URI for the api to read out the gender of some german admins.
I think it would be an easy fix to change the behavior of the template to
return only the gender of the current user instead of any other - this would
also allow to leave genderspecific notes on a user talk since the gender of the
text would be generated at the time of viewing but would close this
privacyhole.
--
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 17216] Expected HTML comments should be filtered
https://bugzilla.wikimedia.org/show_bug.cgi?id=17216 Andrew Garrett changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrew Garrett 2009-01-29 23:46:58 UTC --- Fixed in r46566. -- 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 17196] Log entry detail view table too wide
https://bugzilla.wikimedia.org/show_bug.cgi?id=17196 Andrew Garrett changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Andrew Garrett 2009-01-29 23:39:13 UTC --- Fixed in r46565. -- 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 17195] Missing messages in log details view
https://bugzilla.wikimedia.org/show_bug.cgi?id=17195 Andrew Garrett changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrew Garrett 2009-01-29 23:36:31 UTC --- Fixed in r46564. -- 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 17237] Better integration of patrol feature
https://bugzilla.wikimedia.org/show_bug.cgi?id=17237 --- Comment #2 from Gurch 2009-01-29 23:29:44 UTC --- (In reply to comment #1) > I agree, let's put the patrol flag (and the bot flag too, for that matter) in > the revisions table as well. Bot flag kind of makes sense where it is, given that its purpose (at least its original purpose) is to keep bulk edits out of recentchanges. (The somewhat fuzzy relationship between bot accounts and bot edits always confuses me.) Though having said that, I guess patrol flag kind of makes sense where it is too, if its purpose is to review new edits. I just looked at bug 17215 again and there's talk of adding an index, something I have only a very vague understanding of, but I assume has the same intention of making revision/recentchanges queries easier. I guess that would be easier than a schema change. -- 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 17213] manual not corresponding to menu
https://bugzilla.wikimedia.org/show_bug.cgi?id=17213 Andrew Garrett changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andrew Garrett 2009-01-29 23:29:25 UTC --- Fixed in r46563. -- 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 17237] Better integration of patrol feature
https://bugzilla.wikimedia.org/show_bug.cgi?id=17237 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@home.nl --- Comment #1 from Roan Kattouw 2009-01-29 23:04:25 UTC --- I agree, let's put the patrol flag (and the bot flag too, for that matter) in the revisions table as well. -- 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 17072] "save drafts" doesn't work correctly on IE7
https://bugzilla.wikimedia.org/show_bug.cgi?id=17072 --- Comment #2 from Mr.Z-man 2009-01-29 23:02:37 UTC --- I'm using the same IE version on the same OS. It seems the button only fails to un-disable if text is removed, but none added. -- 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 17237] New: Better integration of patrol feature
https://bugzilla.wikimedia.org/show_bug.cgi?id=17237 Summary: Better integration of patrol feature Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: matthew.brit...@btinternet.com Now that patrolling is part of MediaWiki core, it should really be better integrated than it is. However it seems the database structure does not allow it. This creates usability issues. Unlike other actions such as editing, deleting and moving, users can only patrol a page if they follow a link to it from the new pages log. Bug 15936 asked for the links to always be visible, but was reverted. Querying patrol status is also difficult. It was added to the user contributions API listing, but is currently producing a fatal error on en.wikipedia and will likely be removed (bug 17215). So you can't ask which of a user's contributions are un-patrolled, and other information like whether a page's last edit is patrolled requires scraping the UI instead. The situation is even worse for external tools. A revision or page can (thanks to recent fixes) now be patrolled with reasonable ease if the client happened to catch its entry in recent-changes or the IRC recent-changes feed. However it is impossible to patrol a new page if all you know is its name, page id and/or revision id. The IRC feed now (bug 16604) shows patrol log entries, but the API's recent-changes query does not. There is an API query to retrieve rcid of a page/edit from recent-changes, but it basically scans the whole recent-changes table looking for it, which means if you happen to ask for one that's near the back (or not present at all) of en.wikipedia's recent changes, you get a query that takes several minutes to run. To summarize, patrol status should be as easily manipulated as, say, whether a revision is marked as minor, but isn't. I don't really have a clue how these things work, but would it be better if patrol status was an attribute of revisions rather than recent-changes? -- 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 17218] Provide a magic word for a user's online status
https://bugzilla.wikimedia.org/show_bug.cgi?id=17218
Casey Brown changed:
What|Removed |Added
CC||cbrown1...@gmail.com
--- Comment #6 from Casey Brown 2009-01-29 22:17:58 UTC
---
(In reply to comment #5)
> I'm not convinced this is actually do-able. {{GENDER:}} is parsed based on
> your
> user preference of gender, not the user you're currently looking at. The
> behavior is right, and this bug is actually INVALID, I believe.
1) I saw Melancholie do it on Meta-Wiki and change it. ;-)
2) Look here: http://translatewiki.net/wiki/Gender#Testing_and_more_examples
It seems to also show different users as different genders based on what *they*
set.
--
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 17236] New: IP range blocks should not try to watch the user page
https://bugzilla.wikimedia.org/show_bug.cgi?id=17236 Summary: IP range blocks should not try to watch the user page Product: MediaWiki Version: unspecified Platform: All URL: http://test.wikipedia.org/wiki/Special:Blockip/10.10.10. 10/30 OS/Version: All Status: NEW Keywords: need-review, patch Severity: minor Priority: Normal Component: Blocking AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: morme...@centrum.cz Created an attachment (id=5746) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=5746) simple fix When trying to create a range block (e.g. 10.20.30.0/24), the Special:Blockip page should not offer to watch the user’s user and talk page, since there is nothing like that for an IP range. -- 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 17232] Broken page layout
https://bugzilla.wikimedia.org/show_bug.cgi?id=17232 --- Comment #2 from P.Copp 2009-01-29 21:58:24 UTC --- For mk, the problem seems to be a broken Sitenotice. Removing the additional < /div>-tags at the end of http://mk.wikipedia.org/w/index.php?title=%D0%9C%D0%B5%D0%B4%D0%B8%D1%98%D0%B0%D0%92%D0%B8%D0%BA%D0%B8:Sitenotice&action=edit should fix it. -- 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 17232] Broken page layout
https://bugzilla.wikimedia.org/show_bug.cgi?id=17232 ^demon changed: What|Removed |Added CC||innocentkil...@gmail.com --- Comment #1 from ^demon 2009-01-29 21:40:18 UTC --- What exactly is the problem on mkwiki. Nothing is jumping out, and it certainly isn't garbled. On arz, I do see the disconnected tabs at the top though. -- 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 17222] eAccelerator determines not properly
https://bugzilla.wikimedia.org/show_bug.cgi?id=17222 ^demon changed: What|Removed |Added CC||innocentkil...@gmail.com --- Comment #1 from ^demon 2009-01-29 21:35:07 UTC --- Seeing as the MW wrapper for eAccelerator (eAccelBagOStuff, defined in BagOStuff.php) uses eaccelerator_get(), I think this is a good choice. We don't want to configure that it's ok, only to later find out we can't use it (although the cache setup handles it too :) Is there a function we should be using instead of eaccelerator_get(), since it does in fact seem to be disabled by default? -- 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 17218] Provide a magic word for a user's online status
https://bugzilla.wikimedia.org/show_bug.cgi?id=17218
^demon changed:
What|Removed |Added
CC||innocentkil...@gmail.com
--- Comment #5 from ^demon 2009-01-29 21:23:57 UTC
---
I'm not convinced this is actually do-able. {{GENDER:}} is parsed based on your
user preference of gender, not the user you're currently looking at. The
behavior is right, and this bug is actually INVALID, I believe.
FWIW: I'm very much against any of the per-user magic words (be it online
status, username, user groups, etc) as they break the parser cache.
--
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 17186] "Threshold for stub link formatting (bytes)" functionality is broken
https://bugzilla.wikimedia.org/show_bug.cgi?id=17186 Brion Vibber changed: What|Removed |Added CC||br...@wikimedia.org --- Comment #5 from Brion Vibber 2009-01-29 21:13:07 UTC --- I've merged that change live to fix the regression. -- 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 17206] Allow disabling namespace filter on Special: Oldreviewedpages and Unreviewedpages
https://bugzilla.wikimedia.org/show_bug.cgi?id=17206 Aaron Schulz changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #3 from Aaron Schulz 2009-01-29 20:45:23 UTC --- (In reply to comment #2) > Thanks! Could you also add it to Special:Unreviewedpages? > The schema doesn't permit 'all' added to the dropdown unless a is category *is* selected. That is, just going to oldreviewedpages with namespace 'all' and no category would crash. -- 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 17206] Allow disabling namespace filter on Special: Oldreviewedpages and Unreviewedpages
https://bugzilla.wikimedia.org/show_bug.cgi?id=17206 P.Copp changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #2 from P.Copp 2009-01-29 20:37:40 UTC --- Thanks! Could you also add it to Special:Unreviewedpages? -- 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 17205] Hack mediawiki/trunk/backup/worker. py to skip enwiki history dumps
https://bugzilla.wikimedia.org/show_bug.cgi?id=17205 Russell Blau changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Russell Blau 2009-01-29 20:28:04 UTC --- Brion has made a patch that accomplishes the same result. -- 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 17235] New: unified account status per API
https://bugzilla.wikimedia.org/show_bug.cgi?id=17235 Summary: unified account status per API Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CentralAuth AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: umherirrender_de...@web.de Please add a option to list=users that make it possible to get the unified account status about a username. Maybe a 'attached=""' is added wenn username is attached to the global account (like the "emailable" option). -- 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 17234] New: All attached accounts per API
https://bugzilla.wikimedia.org/show_bug.cgi?id=17234 Summary: All attached accounts per API Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CentralAuth AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: umherirrender_de...@web.de Please add a option to meta=userinfo that make it possible to get (all) attached accounts per API, if the account is global, like [[Special:MergeAccount]] show it. Maybe with prefix, language and url. 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 17233] New: More useful links on Special:MergeAccount
https://bugzilla.wikimedia.org/show_bug.cgi?id=17233 Summary: More useful links on Special:MergeAccount Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CentralAuth AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: umherirrender_de...@web.de If there attached accounts [[Special:MergeAccount]] shows the projects, which account are attached. Please add here more useful links like the "Personal tools" (Userpage, usertalkpage, preferences, watchlist, contributes). See the languagename like the "In other languages" by article where helpful to identify the language of each project. 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 17232] New: Broken page layout
https://bugzilla.wikimedia.org/show_bug.cgi?id=17232
Summary: Broken page layout
Product: MediaWiki
Version: unspecified
Platform: All
URL: http://mk.wikipedia.org/w/index.php?title=%D0%A8%D0%B0%D
0%B1%D0%BB%D0%BE%D0%BD:Bar_box&action=edit
OS/Version: All
Status: NEW
Severity: major
Priority: Normal
Component: Page rendering
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: bugzilla.wikime...@publi.purodha.net
CC: bugzilla.wikime...@publi.purodha.net
This page is completely garbled:
http://mk.wikipedia.org/w/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:Bar_box&action=edit
The same template in another wiki only has he tabs ("edit" "talk" etc)
misplaced:
http://arz.wikipedia.org/w/index.php?title=%D9%82%D8%A7%D9%84%D8%A8:Bar_box&action=edit
Whether or not the problems are related, is unclear 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 16854] without
https://bugzilla.wikimedia.org/show_bug.cgi?id=16854 --- Comment #22 from Robert Rohde 2009-01-29 19:26:13 UTC --- (In reply to comment #21) > (In reply to comment #16) > > English Wikipedia have already blanked the error printed by this bug so > > you'd > > have to wonder if it was worth the effort in the first place. > > > > I thought it was a rather informative error. Suggestions welcome on exact > wording though. To be honest: it doesn't really matter what enwiki does with > the message. Do other communities like it? If the general agreement is in > favor, I fail to see how one wiki's actions should cause so much > backpedaling. I think the primary complaint with the error message isn't the text, but rather that many people saw silently failing as the expected behavior under some circumstances. Specifically, when one copies text from an article to a talk page for discussion, that text may contain ref tags, but that does not necessarily mean that people want or expect a references section on the talk page. On enwiki, this modification added error messages to hundreds of pages where no one really thought there was a problem. Hence people are going out of their way to hide the error message from those pages, since they don't really see it as an error. -- 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 16854] without
https://bugzilla.wikimedia.org/show_bug.cgi?id=16854 --- Comment #21 from ^demon 2009-01-29 19:05:04 UTC --- (In reply to comment #16) > English Wikipedia have already blanked the error printed by this bug so you'd > have to wonder if it was worth the effort in the first place. > I thought it was a rather informative error. Suggestions welcome on exact wording though. To be honest: it doesn't really matter what enwiki does with the message. Do other communities like it? If the general agreement is in favor, I fail to see how one wiki's actions should cause so much backpedaling. > Here's a patch that will place footnotes at the bottom of pages which don't > have tags while silently reporting Eww eww eww. is almost never at the bottom, and this will just encourage lazy editing/formatting of pages. I would hope the wiki never outputs markup you didn't add, only warn you when something's wrong. On semi-related note: if there's issues with how Cite outputs errors, that's for a different bug. Not within the scope of this one. -- 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 16854] without
https://bugzilla.wikimedia.org/show_bug.cgi?id=16854 Robert Rohde changed: What|Removed |Added CC||ro...@robertrohde.com --- Comment #20 from Robert Rohde 2009-01-29 18:46:20 UTC --- (In reply to comment #18) > What en.wiki did was exactly what I was asking for, a hidden category that is > used for tracking these error. huge red error messages are not as graceful as > a > hidden category. > Actually enwiki's approach is still badly borked. Because "Cite error: $1" is used in a filter in front of each error message, changing this specific message to a category results in an output of "Cite error:" with no visible error text, e.g. see [[1949_Grand_Prix_season]] for a current example. That can be fixed locally, but the solutions are generally inelegant, such as changing cite_error to "$1". Also, since people apparently don't want this message on talk pages (even as a category), a hack has been added with the effect of killing ALL cite error messages appearing outside the mainspace. Again, a solution to that could be put together locally but it won't be particularly pretty. Not to mention that the hard coding of the formatting on cite_error also makes changes to the presentation difficult to implement. -- 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 17231] New: Transcluding Special:PrefixIndex affects the page title
https://bugzilla.wikimedia.org/show_bug.cgi?id=17231 Summary: Transcluding Special:PrefixIndex affects the page title Product: MediaWiki Version: 1.15-svn Platform: All URL: http://sr.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0 %BF%D0%B5%D0%B4%D0%B8%D1%98%D0%B0:%D0%9C%D0%BE%D0%B6%D0% B4%D0%B0_%D0%BA%D0%BE%D1%80%D0%B8%D1%81%D1%82%D0%B0%D0%B D_%D0%BC%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D1%98%D0%B0%D0%BB OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Special pages AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: dungod...@gmail.com Transcluding Special:PrefixIndex in a page affects the page title in that it's apparently renamed to "Prefix Index" (or the localized variant). Maybe some sort of cache issue, since I can't reproduce it on enwiki? On srwiki (see URL), Википедија:Можда користан материјал is the page that transcludes Spec:PI, but the title is Списак префикса (which means Prefix Index). Note that this is in the Project: namespace, so that may mean something. -- 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 15936] New page's patrol button should always be visible
https://bugzilla.wikimedia.org/show_bug.cgi?id=15936 Brion Vibber changed: What|Removed |Added CC||br...@wikimedia.org Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #2 from Brion Vibber 2009-01-29 18:01:24 UTC --- Backed this out in r46542 for now -- the extra checks have caused nasty performance regressions. -- 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 17215] API: Fatal error with ucprop=patrolled
https://bugzilla.wikimedia.org/show_bug.cgi?id=17215 --- Comment #10 from Roan Kattouw 2009-01-29 17:55:37 UTC --- (In reply to comment #9) > That's not an access pattern RC is supposed to support, though. It's really > just supposed to summarize other tables. If you have the revision id's > already, all relevant info should be in other tables like revision and page. > The problem is, for some reason rc_patrolled is not. > Exactly, same story with the bot flag. So we either need to move/copy the patrolled flag elsewhere, or add that index. -- 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 17215] API: Fatal error with ucprop=patrolled
https://bugzilla.wikimedia.org/show_bug.cgi?id=17215 --- Comment #9 from Aryeh Gregor 2009-01-29 17:54:35 UTC --- That's not an access pattern RC is supposed to support, though. It's really just supposed to summarize other tables. If you have the revision id's already, all relevant info should be in other tables like revision and page. The problem is, for some reason rc_patrolled is not. -- 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 17215] API: Fatal error with ucprop=patrolled
https://bugzilla.wikimedia.org/show_bug.cgi?id=17215 --- Comment #8 from Roan Kattouw 2009-01-29 17:52:25 UTC --- (In reply to comment #7) > The reason was almost certainly just because having unneeded indexes is slow. > Is there any compelling justification for keeping this? What actually would > need to use it other than some API queries? > It makes it possible to find the recentchanges entries for a set of revisions/revids (either with a join on the revision table or with a WHERE clause), which is generic enough to warrant an index IMO, even if it's just an index on rc_this_oldid. -- 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 17215] API: Fatal error with ucprop=patrolled
https://bugzilla.wikimedia.org/show_bug.cgi?id=17215 --- Comment #7 from Aryeh Gregor 2009-01-29 17:44:23 UTC --- (In reply to comment #5) > Why not? FORCE INDEX doesn't work on views, and non-root toolserver users only have access to views. > For me too, except that on one of my two computers, I don't *have* an > rc_patrolling index, while on the other one I do. The index also isn't listed > in tables.sql, and there's no updater patch that adds it. Where did my index > go? :O :D Um, yeah, that would explain it. See r25527. The index doesn't exist. I've dropped it from localhost so I don't get confused in the future. I don't see any good way to get pages' patrolled status, as long as it's only in RC -- why isn't it in revision as well, again? Grr. (simulpost) (In reply to comment #6) > Deeper research (thanks to TortoiseSVN's search facilities) turned up r25527 > in > which Domas removed the rc_patrolling index (added by Greg in r24699) for no > apparent reason and without adding a remover in updaters.inc . The reason was almost certainly just because having unneeded indexes is slow. Is there any compelling justification for keeping this? What actually would need to use it other than some API queries? -- 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 17215] API: Fatal error with ucprop=patrolled
https://bugzilla.wikimedia.org/show_bug.cgi?id=17215 --- Comment #6 from Roan Kattouw 2009-01-29 17:40:56 UTC --- (In reply to comment #5) > The index also isn't listed > in tables.sql, and there's no updater patch that adds it. Where did my index > go? :O :D > Deeper research (thanks to TortoiseSVN's search facilities) turned up r25527 in which Domas removed the rc_patrolling index (added by Greg in r24699) for no apparent reason and without adding a remover in updaters.inc . -- 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 17215] API: Fatal error with ucprop=patrolled
https://bugzilla.wikimedia.org/show_bug.cgi?id=17215 --- Comment #5 from Roan Kattouw 2009-01-29 17:33:00 UTC --- (In reply to comment #4) > Note join type ALL, key NULL. I only have views on the toolserver, not the > actual tables, so I can't try forcing rc_patrolling as the index to use for > recentchanges there (nor can I use the FORCE INDEX that was already in the > query). Why not? > When I run it on localhost, it chooses rc_patrolling for the > recentchanges join. > For me too, except that on one of my two computers, I don't *have* an rc_patrolling index, while on the other one I do. The index also isn't listed in tables.sql, and there's no updater patch that adds it. Where did my index go? :O :D Back on topic: maybe adding FORCE INDEX(rc_patrolling) will fix this, provided that index is present on the WMF DB servers. You also seem to indicate that the effect of this FORCE INDEX can't be tested on the toolserver for some reason. -- 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 17072] "save drafts" doesn't work correctly on IE7
https://bugzilla.wikimedia.org/show_bug.cgi?id=17072 Trevor Parscal changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Trevor Parscal 2009-01-29 17:24:51 UTC --- I have been unable to reproduce the behavior you experienced. I am using IE 7.0.6001.18000 on Windows Vista. Please give some more specifics about your environment so we can get this 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 17110] No stylesheets for flagged revisions box on cologne blue skin
https://bugzilla.wikimedia.org/show_bug.cgi?id=17110 --- Comment #5 from FUZxxl 2009-01-29 17:04:02 UTC --- It doesn't looks like the other parts of the coogne blue skin. The font, it isn't a sans-serif fon like he ohers in cologne blue, the box does not looks like the rest of the page. -- 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 17215] API: Fatal error with ucprop=patrolled
https://bugzilla.wikimedia.org/show_bug.cgi?id=17215 --- Comment #4 from Aryeh Gregor 2009-01-29 16:50:03 UTC --- This is the explain I get on the toolserver: mysql> EXPLAIN SELECT rev_timestamp,page_namespace,page_title,rev_user_text,rc_patrolled FROM `page`,`revision` LEFT JOIN `recentchanges` ON ((rc_this_oldid=rev_id)) WHERE (page_id=rev_page) AND rev_deleted = '0' AND rev_user_text = 'Gurch' ORDER BY rev_user_text DESC, rev_timestamp DESC LIMIT 11; ++-+---++---++-+--+-+--+ | id | select_type | table | type | possible_keys | key| key_len | ref | rows| Extra| ++-+---++---++-+--+-+--+ | 1 | SIMPLE | revision | ref| PRIMARY,page_timestamp,usertext_timestamp | usertext_timestamp | 257 | const| 187372 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | recentchanges | ALL| NULL | NULL | NULL| NULL | 524 | | | 1 | SIMPLE | page | eq_ref | PRIMARY | PRIMARY| 4 | enwiki.revision.rev_page | 1 | | ++-+---++---++-+--+-+--+ 3 rows in set (0.01 sec) Note join type ALL, key NULL. I only have views on the toolserver, not the actual tables, so I can't try forcing rc_patrolling as the index to use for recentchanges there (nor can I use the FORCE INDEX that was already in the query). When I run it on localhost, it chooses rc_patrolling for the recentchanges join. -- 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 17215] API: Fatal error with ucprop=patrolled
https://bugzilla.wikimedia.org/show_bug.cgi?id=17215 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@home.nl --- Comment #3 from Roan Kattouw 2009-01-29 16:36:58 UTC --- (In reply to comment #2) > What's the query that would be run? > SELECT /* ApiQueryContributions::execute Catrope */ rev_timestamp,page_namespace,page_title,rev_user_text,rc_patrolled FROM `page`,`revision` FORCE INDEX (usertext_timestamp) LEFT JOIN `recentchanges` ON ((rc_this_oldid=rev_id)) WHERE (page_id=rev_page) AND rev_deleted = '0' AND rev_user_text = 'Gurch' ORDER BY rev_user_text DESC, rev_timestamp DESC LIMIT 11 I personally don't see how this produces huge joins, as we're joining on unique indices, but then I've been known to be completely wrong about DB-related stuff before :D -- 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 17229] MediaWiki installation on PHP 5.28 and XAMPP is troublesome
https://bugzilla.wikimedia.org/show_bug.cgi?id=17229 AN Other changed: What|Removed |Added Blocks||17230 -- 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 17230] New: MediaWiki installation on PHP 5. 28 and XAMPP is troublesome
https://bugzilla.wikimedia.org/show_bug.cgi?id=17230 Summary: MediaWiki installation on PHP 5.28 and XAMPP is troublesome Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: testme Severity: major Priority: Normal Component: Installation AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: whitestre...@mailinator.com Depends on: 17229 +++ This bug was initially created as a clone of Bug #17229 +++ Just tried installing the latest SVN build on XAMPP, and the install script did not work at all. The following errors came up in the script: Query "CREATE TABLE `tag_summary` ( ts_rc_id int NULL, ts_log_id int NULL, ts_rev_id int NULL, ts_tags BLOB NOT NULL, UNIQUE KEY (ts_rc_id), UNIQUE KEY (ts_log_id), UNIQUE KEY (ts_rev_id), ) ENGINE=InnoDB, DEFAULT CHARSET=binary " failed with error code "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ENGINE=InnoDB, DEFAULT CHARSET=binary' at line 9 (localhost)". I am using PHP 5.28 and the latest MySQL build; no idea why this happened, but it did. Anyone else had this 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 17224] Wiki's license information is not available via API
https://bugzilla.wikimedia.org/show_bug.cgi?id=17224 Roan Kattouw changed: What|Removed |Added CC||roan.katt...@home.nl --- Comment #1 from Roan Kattouw 2009-01-29 16:18:27 UTC --- (In reply to comment #0) > I hope it is clear which bits relate to rightsinfo. If it is too annoying I > can > try and make a proper diff. Sorry for the hassle. > Sorry, but it is annoying, and it's not a unified diff. Please submit a proper patch that I can just apply and test. -- 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 13040] Gender switch in user preferences
https://bugzilla.wikimedia.org/show_bug.cgi?id=13040 --- Comment #17 from Niklas Laxström 2009-01-29 16:04:54 UTC --- (In reply to comment #16) > Note that this preference should be changed automatically to all projects if > the user has a global account (SUL), just like password and e-mail. That would be bug 14950. -- 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 3438] not all hooks (ParserBeforeStrip) available in template
https://bugzilla.wikimedia.org/show_bug.cgi?id=3438 --- Comment #7 from Eloy Lafuente 2009-01-29 16:02:44 UTC --- Thanks Kinsey. bug 17131 looks promising! B-) -- 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 13040] Gender switch in user preferences
https://bugzilla.wikimedia.org/show_bug.cgi?id=13040 --- Comment #16 from Kostas Stampoulis 2009-01-29 15:59:58 UTC --- Note that this preference should be changed automatically to all projects if the user has a global account (SUL), just like password and e-mail. -- 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 3438] not all hooks (ParserBeforeStrip) available in template
https://bugzilla.wikimedia.org/show_bug.cgi?id=3438 Kinsey Moore changed: What|Removed |Added CC||nyphb...@gmail.com --- Comment #6 from Kinsey Moore 2009-01-29 15:49:41 UTC --- As a response to the P.S., please see bug 17131. I believe it is the beginning of what is mentioned. -- 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 16599] RC IRC related issues (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=16599 Bug 16599 depends on bug 5247, which changed state. Bug 5247 Summary: RC bot report changes harmed RC patrol ability. https://bugzilla.wikimedia.org/show_bug.cgi?id=5247 What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||WONTFIX -- 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 5247] RC bot report changes harmed RC patrol ability.
https://bugzilla.wikimedia.org/show_bug.cgi?id=5247 Aaron Schulz changed: What|Removed |Added CC||jschulz_4...@msn.com Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #8 from Aaron Schulz 2009-01-29 15:47:33 UTC --- Closed -- 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 5247] RC bot report changes harmed RC patrol ability.
https://bugzilla.wikimedia.org/show_bug.cgi?id=5247 --- Comment #7 from Mike.lifeguard 2009-01-29 15:46:15 UTC --- Suggest closing this as WONTFIX. I'm unaware of any problem this actually causes. -- 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 3438] not all hooks (ParserBeforeStrip) available in template
https://bugzilla.wikimedia.org/show_bug.cgi?id=3438
Eloy Lafuente changed:
What|Removed |Added
CC||stro...@moodle.org
--- Comment #5 from Eloy Lafuente 2009-01-29 15:45:55 UTC
---
Just in case this helps to somebody.
We have some normal wiki pages, called:
Moodle 1.9.4 release notes =>
http://docs.moodle.org/en/Moodle_1.9.4_release_notes
Moodle_1.8.8 release notes =>
http://docs.moodle.org/en/Moodle_1.8.8_release_notes
And then, one "container" (Latest release notes =>
http://docs.moodle.org/en/Latest_release_notes) page including them by using:
{{:Moodle 1.8.8 release notes}}
{{:Moodle 1.9.4 release notes}}
Our ParserBeforeStrip and ParserAfterStrip hooks weren't processing those
"included" contents when they work perfectly in the individual pages. We have
changed those hooks to InternalParseBeforeLinks and now it seems that
"included" content is being processed properly. Not sure why, but it works.
Just in case this helps to somebody.
Ciao, stronk7 :-)
This is our version page: http://docs.moodle.org/en/Special:Version
P.S: I really think this IS a bug and "included" content should be processed
too. Else there is one important inconsistency between how pages are rendered
individually and when included in others. ;-)
--
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 17218] Provide a magic word for a user's online status
https://bugzilla.wikimedia.org/show_bug.cgi?id=17218 --- Comment #4 from Gurch 2009-01-29 15:43:13 UTC --- Changing gender to go offline, haha, I love it. Definitely the best MediaWiki feature abuse of the year so far. :) -- 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 16136] Add Commons as an import source for Meta
https://bugzilla.wikimedia.org/show_bug.cgi?id=16136 Mike.lifeguard changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Mike.lifeguard 2009-01-29 15:36:51 UTC --- (In reply to comment #0) > Please allow transwiki import from Commons to Meta. > That was done at some point. -- 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 17229] New: MediaWiki installation on PHP 5. 28 and XAMPP is troublesome
https://bugzilla.wikimedia.org/show_bug.cgi?id=17229 Summary: MediaWiki installation on PHP 5.28 and XAMPP is troublesome Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: testme Severity: major Priority: Normal Component: Installation AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: whitestre...@mailinator.com Just tried installing the latest SVN build on XAMPP, and the install script did not work at all. The following errors came up in the script: Query "CREATE TABLE `tag_summary` ( ts_rc_id int NULL, ts_log_id int NULL, ts_rev_id int NULL, ts_tags BLOB NOT NULL, UNIQUE KEY (ts_rc_id), UNIQUE KEY (ts_log_id), UNIQUE KEY (ts_rev_id), ) ENGINE=InnoDB, DEFAULT CHARSET=binary " failed with error code "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ENGINE=InnoDB, DEFAULT CHARSET=binary' at line 9 (localhost)". I am using PHP 5.28 and the latest MySQL build; no idea why this happened, but it did. Anyone else had this 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 16854] without
https://bugzilla.wikimedia.org/show_bug.cgi?id=16854 --- Comment #19 from Michael Walsh 2009-01-29 15:12:57 UTC --- I think the most intuitive way of applying the Cite extension would but to display the output of ... tags without automatically requiring the input of tags. New users will see and copy the tag format but then find out that their footnotes aren't being displayed. -- 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 17228] Moving a page back does not work as described
https://bugzilla.wikimedia.org/show_bug.cgi?id=17228 crangasi2...@yahoo.com changed: What|Removed |Added Summary|Moving a page back does not |Moving a page back does not |work as intended|work as described -- 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 17228] New: Moving a page back does not work as intended
https://bugzilla.wikimedia.org/show_bug.cgi?id=17228 Summary: Moving a page back does not work as intended Product: Wikimedia Version: unspecified Platform: All URL: http://ro.wikipedia.org/wiki/(3359)_Purcari OS/Version: All Status: NEW Severity: normal Priority: Normal Component: wikibugs AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: crangasi2...@yahoo.com On the last June, I moved a page on the romanian wikipedia from [[:ro:3359 Purcari]] to [[:ro:(3359) Purcari]]. Two days ago, I moved the page back, then I tried to move it back, but it wouldn't let me. According to http://en.wikipedia.org/wiki/Wikipedia:Move#Moving_over_a_redirect , this kind of move should happen any number of times. -- 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 16854] without
https://bugzilla.wikimedia.org/show_bug.cgi?id=16854 --- Comment #18 from Betacommand 2009-01-29 14:44:57 UTC --- What en.wiki did was exactly what I was asking for, a hidden category that is used for tracking these error. huge red error messages are not as graceful as a hidden category. -- 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 16854] without
https://bugzilla.wikimedia.org/show_bug.cgi?id=16854 --- Comment #17 from Brad Jorsch 2009-01-29 14:43:21 UTC --- I disagree, since we already output a big red error message for all ''other'' ref tag errors. But if you want to include the references on the page, change [[MediaWiki:Cite error refs without references]] to something like this:not supplied. References are:[[Category:B0rken refs]] And change [[MediaWiki:Cite error group refs without references]] to the corresponding: was not supplied. References are:[[Category:B0rken refs]] (the unbalanced "" tags in there are to make the reference list itself not be big and red). It wouldn't really solve bug 5984 though, as a section preview with a named ref defined in a different section would show up as broken. -- 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 17227] New: r46460 breaks non-MySQL databases: table tag_summary does not exist
https://bugzilla.wikimedia.org/show_bug.cgi?id=17227 Summary: r46460 breaks non-MySQL databases: table tag_summary does not exist Product: MediaWiki Version: 1.15-svn Platform: All OS/Version: All Status: NEW Keywords: postgresql Severity: major Priority: Normal Component: Database AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: b-jor...@northwestern.edu r46460 introduced a "tag_summary" table, but did not add it to the database definitions or update.php script for databases other than MySQL. Visiting a non-existent page, a page history, or whatever else tries to use that table now gives an internal error. -- 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 16854] without
https://bugzilla.wikimedia.org/show_bug.cgi?id=16854 --- Comment #16 from Michael Walsh 2009-01-29 14:19:49 UTC --- Created an attachment (id=5745) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=5745) Print the footnotes and report the error silently English Wikipedia have already blanked the error printed by this bug so you'd have to wonder if it was worth the effort in the first place. Here's a patch that will place footnotes at the bottom of pages which don't have tags while silently reporting the error. -- 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 17226] New: I can not operate edit/movement/deletion for the page
https://bugzilla.wikimedia.org/show_bug.cgi?id=17226 Summary: I can not operate edit/movement/deletion for the page Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: User interface AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: lemonsqu...@live.jp Hello. I am [[:wikt:ja:User:Lemonsquash]]. I report on trouble. I move from [[:wikt:ja:利用者:Lemonsquash/者]] to [[:wikt:ja:利用者:Lemonsquash/者]]. And, I can not edit/move/delete [[:wikt:ja:利用者:Lemonsquash/者]] Yours truly. -- 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 17201] Arbcom Wiki crats to remove sysop and crat
https://bugzilla.wikimedia.org/show_bug.cgi?id=17201 John Mark Vandenberg changed: What|Removed |Added Keywords||shell -- 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 17193] Reupload form
https://bugzilla.wikimedia.org/show_bug.cgi?id=17193 --- Comment #8 from Lupo 2009-01-29 12:55:30 UTC --- I see at http://wikitech.wikimedia.org/view/Server_admin_log that Brion merged this already, and indeed the changes are already live. However, it seems to me that the associated change in ImagePage.php from r46483 is *not* live yet (diff: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/ImagePage.php?r1=45963&r2=46483&pathrev=46483 ) The Commons still serves image pages with an "Upload a new version link" that contains "wpReUpload=1" instead of "wpForReUpload=1". Hence these links don't trigger the reupload form at all. -- 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 17225] New: GenericEditPage breaks Show Preview and Show Changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=17225 Summary: GenericEditPage breaks Show Preview and Show Changes Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: critical Priority: Normal Component: Uniwiki AssignedTo: minuteelect...@googlemail.com ReportedBy: mikel_ma...@yahoo.com CC: wikibugs-l@lists.wikimedia.org Clicking "Show Preview" is the same as toggling between Generic and Classic Mode. Clicking "Show Changes" always goes to Classic Mode. -- 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 17224] New: Wiki's license information is not available via API
https://bugzilla.wikimedia.org/show_bug.cgi?id=17224 Summary: Wiki's license information is not available via API Product: MediaWiki Version: unspecified Platform: All OS/Version: All Status: NEW Keywords: easy, need-review, patch Severity: enhancement Priority: Normal Component: API AssignedTo: roan.katt...@home.nl ReportedBy: brianna.laug...@gmail.com CC: bryan.tongm...@gmail.com, vasi...@gmail.com Created an attachment (id=5744) --> (https://bugzilla.wikimedia.org/attachment.cgi?id=5744) diff for ApiQuerySiteinfo.php Patch attached that gets license info from $wgRightsPage, $wgRightsUrl and $wgRightsText (similar to Skin.php). New 'rightsinfo' for query=siteinfo for api/ApiQuerySiteinfo.php Note: I made this patch by editing my MediaWiki 13.3, but I didn't copy the original file before editing it. :( So I performed the diff with http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/api/ApiQuerySiteinfo.php?revision=46337&content-type=text%2Fplain and so some of the diff relates to other additions to this page made, that were not in my copy. I hope it is clear which bits relate to rightsinfo. If it is too annoying I can try and make a proper diff. Sorry for the hassle. -- 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 17223] Autopatrolling on Ukrainian Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=17223 Reedy changed: What|Removed |Added Keywords||shell -- 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 17223] Autopatrolling on Ukrainian Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=17223 Anatoliy Honcharov changed: What|Removed |Added CC||pustomyt...@gmail.com --- Comment #1 from Anatoliy Honcharov 2009-01-29 11:45:21 UTC --- *** Bug 12601 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 12601] Create patroller group on Ukrainian Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=12601 Anatoliy Honcharov changed: What|Removed |Added URL|http://uk.wikipedia.org/wiki|http://uk.wikipedia.org/wiki |/Вікіпедія:Кнай|/Вікіпедія:Кнай |па_(допомога)#.D0.|па_(допомога)#.D0. |AF.D0.BA_.D0.BF.D1.80.D0.B8.|AF.D0.BA_.D0.BF.D1.80.D0.B8. |D0.B7.D0.BD.D0.B0.D1.87.D0.B|D0.B7.D0.BD.D0.B0.D1.87.D0.B |8.D1.82.D0.B8_.D0.B6.D0.B0.D|8.D1.82.D0.B8_.D0.B6.D0.B0.D |0.BD.D0.B4.D0.B0.D1.80.D0.BC|0.BD.D0.B4.D0.B0.D1.80.D0.B. |.D0.B0.3F |D0.B0.3F Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #3 from Anatoliy Honcharov 2009-01-29 11:45:21 UTC --- *** This bug has been marked as a duplicate of bug 17223 *** -- 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 17223] New: Autopatrolling on Ukrainian Wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=17223 Summary: Autopatrolling on Ukrainian Wikipedia Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: Site requests AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: ahonc...@gmail.com Please enable "autopatrol" flag for patrollers on Ukrainian Wikipedia -- 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
