[Bug 24037] Add bytes of revision to Special:Contributions
https://bugzilla.wikimedia.org/show_bug.cgi?id=24037 Umherirrender umherirrender_de...@web.de changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #8 from Umherirrender umherirrender_de...@web.de 2011-11-23 08:03:08 UTC --- The diff-size in history is there since r100722, but this bug is older than the change. Closing as WONTFIX, because no body want it 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 14977] $wgServer lacks brackets in IPv6 URLs
https://bugzilla.wikimedia.org/show_bug.cgi?id=14977 --- Comment #36 from Philippe Verdy verd...@wanadoo.fr 2011-11-23 08:16:42 UTC --- I also confirm the low priority here. Most wiki websites, including those only for Intranet use, will use a domain name, and not refer to the server using an IP address, should it be IPv4 or IPv6. So this is a non issue for the creation of URLs. All large web sites anyway won't want to be refered to by IP address but only by domain name, to help balance the load into multiple servers or front proxies, with the help of the DNS system. This is also needed in case of change of web hosting providers, or if there are alternate providers, or if for some reason a server must be stopped or fails and the trafic redirected to some other server: IP addresses are not intended to be stable across time (the myth of static IP address has lived, even in absence of NAT routing. Everyone uses a domain name because it is really a cheap solution with lots of benefits. It is only on issue if there are limitations in the webserver software itself (but IPv6 support in Apache, or even IIS, is present since long), or in some server log analysis tools, or with some proxy softwares (no longer an issue for proxies used by the Wikimedia Foundation). We should really not recommand the installation of MediaWiki on servers without a domain name, or at least a hostname on a private LAN (and on private LANs, IPv4 still works without limitations; IPv6 is mostly for the Internet). -- 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 31063] MediaWiki should use a reservation system for namespaces
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063 --- Comment #24 from Daniel Friesen mediawiki-b...@nadir-seen-fire.com 2011-11-23 08:35:29 UTC --- (In reply to comment #23) No, that's not today's standard system, that's the verbose XML cult of thought. You mean the Internet and the Semantic Web (including other serializations than xml) is a cult? :-) Extension authors should have no reason to need to type in a full long uri every time they refer to a namespace. Absolutely no need, they would use a local variable name. Extensions shouldn't need to store something like that in a variable. And they WILL need to use it in multiple places in an extension so they WILL have to write it out multiple times. And the moment they store it into a SMW_PROPERTY like constant all of the extra value of that full uri practically disappears. Not to mention how decision on renaming extension pages or switching to a different system for extension management could affect something that should not be dependent on them. I don't understand the above. Say our extension is located at http://www.mediawiki.org/wiki/Extension:SemanticMediaWiki; and we decide to use the url as the property: http://www.mediawiki.org/wiki/Extension:SemanticMediaWiki#Property; But say we later decide to move SemanticMediaWiki to Semantic MediaWiki. Now the url we're using isn't actually the url that the extension uses. And we can't change that, because that's what we use as a unique identifier and if we change it MW will try to create a new namespace and make all our current content disappear. Likewise say we ditch the Extension: namespace and switch to some sort of dedicated system that has a special interface for managing extensions, versions, releases, etc... and say we use http://extensions.mediawiki.org/ for that. Now all the urls used in extensions are either incorrect or things break. Decisions like these shouldn't have an effect on something like the identifier used for an extension namespace. My assumption is that extensions need globally unique identifiers. Else you either have to create yet another global registry, or two extensions end up using the same identifier. Traditionally many domain specific registries existed, but I stand by my comment: increasingly we do switch these to URIs, whether it is photometadata, institutions, publications, authors, biological organism names, etc. It is not strictly a standard system - please excuse my lax use of language. But it is not a cult, it is a well reasoned, sane decision. Except we don't need unique identifier at the level of a url. In fact if we're going by the extension's MW.org page then of the identifier http://www.mediawiki.org/wiki/Extension:SemanticMediaWiki#Property; the entire http://www.mediawiki.org/wiki/Extension:; portion of that identifier is worthless. Quite frankly smw.* or maybe ext.smw.* is enough specificity for our purposes. Do remember that these keys we're using all just map to very non-unique things like Property:, Thread:, Video:, etc... That level of non-uniqueness is not going away, and all we need on top of that for keys is a little differentiation between different extensions, core, and site namespaces. And for those purposes the extension name is enough (and for well known extensions like Semantic MediaWiki short keys like smw are even enough). We haven't had an issue with conflicts. And DPL Wikimedia vs. DPL2 isn't a conflict, we'd probably 'want' those to use the same namespace. And there may be other cases where there's a reason for extensions to share a namespace key. -- 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 25458] fix help for signature in WikiEditor
https://bugzilla.wikimedia.org/show_bug.cgi?id=25458 Umherirrender umherirrender_de...@web.de changed: What|Removed |Added Keywords||i18n --- Comment #2 from Umherirrender umherirrender_de...@web.de 2011-11-23 08:47:33 UTC --- bug 12472 is WONTFIX, please fix the message. 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 17486] Parser generates malformed XML with a list inside a table
https://bugzilla.wikimedia.org/show_bug.cgi?id=17486
--- Comment #23 from Philippe Verdy verd...@wanadoo.fr 2011-11-23 08:54:37
UTC ---
No, this is about tables inside lists (or any wiki feature that requires a
single line syntax: this applies to unnumbered lists with * converted to
ul/li, numbered lists with # converted to ol/il, and definition lists
starting with ; and : converted to dl/dt/dd).
Lists inside tables have no problems.
I really think that wiki-tables should have a syntax that removes the single
line constraint : I suggested a syntax starting with {|| instead of just {|
to mean that every thing, up to the closing |} would be a table, and that all
cells MUST be initiated by || for td, or !! for th, and new rows start with
|-, independantly of how newlines are found in the wikisource, so that a
single or multiple line wiki-syntax for tables would be accepted and recognized
such as:
* list item
* another list item containing a table: {||class=wikitable |-valign=top
!!scope=row|header cell of 1st row ||align=right|1st data cell
|-valign=top !!scope=row|header cell of 2nd row ||align=right|2nd data
cell |}
* another list item containing a table broken multiple lines:
{||class=wikitable
|-valign=top !!scope=row|header cell of
1st row ||align=right|
1st data cell
|-valign=top !!scope=row|header cell of
2nd row ||align=right|
2nd data cell
* another list item containing a table: {||class=wikitable
|+align=center|Table caption
|-valign=top !!scope=row|header cell ||align=right|data cell
|-valign=top !!scope=row|header cell ||align=right|2nd data cell
|}
When parsing this syntax, all cell contents are parsed as if they were already
at the begining of a new block, meaning that line breaks are only converted to
create new paragraphs if there are two line breaks. If there are no
two-linebreaks, then the cell content will not be converted into a paragraph
(with the p element), however, if there are any two-linebreaks in that
content, all paragraphs including the first one will be converted to a p
element in that cell content. Whitespaces in cell contents or captions should
continue to be compressed, and single line breaks converted to a compressable
whitespace.
In this syntax, the !! cell separator would not convert cells starting by
|| on the same line into header cells (I think this is a bad inconsistency of
the Wiki syntax, which also forces us to break the line when a header cell is
followed by a data cell, and does not help making the syntax compact and easily
readable, just like in the last list item above).
The parser should also take care of NOT breaking a list item where it contains
a new explicit HTML block element that requires an explicit closure (for
example div, blockquote, pre, and HTML or wiki tables). This requires a change
on how wiki-lines starting by *, #, ; and : are parsed: they will have
to read for more lines to find the end of the embedded elements.
Also, there's stil lthe lack of support for adding attributes to list items and
to their containing list element.
Why can't we have the syntax like:
{* attributes for the unnumbered list container (ul)
* simple list item
* another list
item
* attributes for the list item| bulleted list item content whose
content includes...
multiple paragraphs...
* attributes for the list item| bulleted list item content whose content
is splitted on multiple lines (whitespace compressed by the parser)
*}
Note: attributes on list items, separated by *-lines are optional: the first
| delimits where attributes are terminated before the visible content. We
then gain also more freedom in adding empty lines between list items, because
whitespaces at end of an item are always trimmed.
Idem for numbered lists using {# and #}:
{# attributes for the numbered list container (ol)
# attributes for the list item| numbered list item content
# attributes for the list item| numbered list item content
*}
Or for definition lists using {; and ;}:
{; attributes for the definition list container (dl)
; attributes for the defined term| defined term content
; attributes for the list item| numbered list item content
*}
This would also simplify the design of lots of templates, with less problems
when transcluding them in lists (notably when a text-like template requires
some special formatting to support some advanced typography, or special layouts
emulating some text features using positioned block elements).
--
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 17486] Parser generates malformed XML with a list inside a table
https://bugzilla.wikimedia.org/show_bug.cgi?id=17486
--- Comment #24 from Philippe Verdy verd...@wanadoo.fr 2011-11-23 09:08:15
UTC ---
No, this is about tables inside lists (or any wiki feature that requires a
single line syntax: this applies to unnumbered lists with * converted to
ul/li, numbered lists with # converted to ol/il, and definition lists
starting with ; and : converted to dl/dt/dd).
Lists inside tables have no problems.
I really think that wiki-tables should have a syntax that removes the single
line constraint : I suggested a syntax starting with {|| instead of just {|
to mean that every thing, up to the closing |} would be a table, and that all
cells MUST be initiated by || for td, or !! for th, and new rows start with
|-, independantly of how newlines are found in the wikisource, so that a
single or multiple line wiki-syntax for tables would be accepted and recognized
such as:
* list item
* another list item containing a table: {||class=wikitable |-valign=top
!!scope=row|header cell of 1st row ||align=right|1st data cell
|-valign=top !!scope=row|header cell of 2nd row ||align=right|2nd data
cell |}
* another list item containing a table broken multiple lines:
{||class=wikitable
|-valign=top !!scope=row|header cell of
1st row ||align=right|
1st data cell
|-valign=top !!scope=row|header cell of
2nd row ||align=right|
2nd data cell
* another list item containing a table: {||class=wikitable
|+align=center|Table caption
|-valign=top !!scope=row|header cell ||align=right|data cell
|-valign=top !!scope=row|header cell ||align=right|2nd data cell
|}
When parsing this syntax, all cell contents are parsed as if they were already
at the begining of a new block, meaning that line breaks are only converted to
create new paragraphs if there are two line breaks. If there are no
two-linebreaks, then the cell content will not be converted into a paragraph
(with the p element), however, if there are any two-linebreaks in that
content, all paragraphs including the first one will be converted to a p
element in that cell content. Whitespaces in cell contents or captions should
continue to be compressed, and single line breaks converted to a compressable
whitespace.
In this syntax, the !! cell separator would not convert cells starting by
|| on the same line into header cells (I think this is a bad inconsistency of
the Wiki syntax, which also forces us to break the line when a header cell is
followed by a data cell, and does not help making the syntax compact and easily
readable, just like in the last list item above).
The parser should also take care of NOT breaking a list item where it contains
a new explicit HTML block element that requires an explicit closure (for
example div, blockquote, pre, and HTML or wiki tables). This requires a change
on how wiki-lines starting by *, #, ; and : are parsed: they will have
to read for more lines to find the end of the embedded elements.
Also, there's stil lthe lack of support for adding attributes to list items and
to their containing list element.
Why can't we have the syntax like:
{* attributes for the unnumbered list container (ul)
* simple list item
* another list
item
* attributes for the list item| bulleted list item content whose
content includes...
multiple paragraphs...
* attributes for the list item| bulleted list item content whose content
is splitted on multiple lines (whitespace compressed by the parser)
*}
Note: attributes on list items, separated by *-lines are optional: the first
| delimits where attributes are terminated before the visible content. We
then gain also more freedom in adding empty lines between list items, because
whitespaces at end of an item are always trimmed.
Idem for numbered lists using {# and #}:
{# attributes for the numbered list container (ol)
# attributes for the list item| numbered list item content
# attributes for the list item| numbered list item content
*}
Or for definition lists using {; and ;}:
{; attributes for the definition list container (dl)
; attributes for the defined term| defined term content
; attributes for the list item| numbered list item content
*}
This would also simplify the design of lots of templates, with less problems
when transcluding them in lists (notably when a text-like template requires
some special formatting to support some advanced typography, or special layouts
emulating some text features using positioned block elements).
--
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 17486] Parser generates malformed XML with a list inside a table
https://bugzilla.wikimedia.org/show_bug.cgi?id=17486 --- Comment #25 from Philippe Verdy verd...@wanadoo.fr 2011-11-23 09:13:25 UTC --- Finaly I am waiting for long the support for styling column groups (col, colgroup) and row groups (thead, tbody, tfoot) notably because it simplifies a lot the editing of long or large tables, and also offers additional accessibility features (such as *auto* scrollable column groups or row groups when the diaply size is narrow, while preserving the alignment of fixed header/footer cells on the sides, but also allows printing tables with the duplication of fixed header cells on each 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 32439] java.sql.SQLException: Incorrect string value: '\xF0\x9D\x9E\xB1_\xF0...' for column 'page_title' at row 9
https://bugzilla.wikimedia.org/show_bug.cgi?id=32439 --- Comment #1 from eyal albili...@gmail.com 2011-11-23 10:20:07 UTC --- i found a way to fix the problem... the sql schema file provided by wikipedia, at : http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/tables.sql has some defaults in it. steps for solution : 1.at page table defintion : at page_title field :change the varchar type to varbinary. 2.at table revision : field re_comment : change type tinyblob to mediumblob(not the exception i described above, but still it's necessary if you want to avoid future exceptions. that's it you're good to go.. -- 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 32603] New: limit option is missing on Special:BlockList
https://bugzilla.wikimedia.org/show_bug.cgi?id=32603 Web browser: --- Bug #: 32603 Summary: limit option is missing on Special:BlockList Product: MediaWiki Version: 1.18 Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Blocking AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: duplicate...@googlemail.com Classification: Unclassified A option to increase the limit is missing on Special:BlockList after the rewrite in 1.18 (Show [20 50 100 250 500] items per page or so) -- 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 32604] New: Some messages while blocking needs escaping of wikitext inside username
https://bugzilla.wikimedia.org/show_bug.cgi?id=32604 Web browser: --- Bug #: 32604 Summary: Some messages while blocking needs escaping of wikitext inside username Product: MediaWiki Version: 1.18 Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: Blocking AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: duplicate...@googlemail.com Classification: Unclassified The username ($1) in the following messages needs escaping of wikitext, because a block of user Foo''Bar is produce italics. unblocked blockipsuccesstext ipb-unblock-addr ipb-needreblock mabye more -- 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 32503] ArticleFeedback extension on sr.wikipedia
https://bugzilla.wikimedia.org/show_bug.cgi?id=32503 --- Comment #4 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 10:39:24 UTC --- (In reply to comment #3) Confirmed. I'm getting 1146: Table 'srwiki.article_feedback_stats_types' doesn't exist (10.0.6.21) for [[sr:Special:ArticleFeedback]] This is fixed now. I've also set up a cron job to update the dashboard every hour, although I really really have to find a better way of doing that than putting individual jobs in my personal crontab. -- 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 32537] Don't load some (default) modules if they've been loaded before
https://bugzilla.wikimedia.org/show_bug.cgi?id=32537 --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 10:44:56 UTC --- How could we possibly detect this case? The script tag is produced server-side. Also, what kind of extension module would load 'site' or 'user'? That sounds evil 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 32598] API requests to commons frequently return 500
https://bugzilla.wikimedia.org/show_bug.cgi?id=32598 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #3 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 11:07:25 UTC --- (In reply to comment #2) What queries? It is a simple page.put() in pywikipedia: Updating page [[Commons:Quality images/Subject/Places/Man made structures]] via API HTTPError: 500 Internal Server Error WARNING: Could not open 'http://commons.wikimedia.org/w/api.php'. Maybe the server is down. Retrying in 1 minutes... Could you get on IRC some time and find me (RoanKattouw)? Then we can do a controlled experiment where you try to reproduce the error while I watch the server logs. -- 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 25952] Current fundraiser site-notice is fiddly to dismiss.
https://bugzilla.wikimedia.org/show_bug.cgi?id=25952 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||fr-t...@wikimedia.org Component|General/Unknown |Fundraising - misc AssignedTo|jalexan...@wikimedia.org|wikibugs-l@lists.wikimedia. ||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 32549] Wikipedia pages freezes on Konqueror
https://bugzilla.wikimedia.org/show_bug.cgi?id=32549
Roan Kattouw roan.katt...@gmail.com changed:
What|Removed |Added
CC||roan.katt...@gmail.com
--- Comment #5 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 11:10:27
UTC ---
(In reply to comment #1)
The alternate selector that you're recommending looks like it would perform
the
exact same operations as the first one (in both cases, I believe it would
start
with getElementById lookups on the four IDs, then call
getElementsByTagName('a') within each one, and combine the results into one
collection).
In an ideal world, that would be true, but $( '#foo' ).find( 'a' ) really is
faster. See also [[mw:JSPERF]].
--
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 32602] Localization regression on trunk
https://bugzilla.wikimedia.org/show_bug.cgi?id=32602 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 11:14:04 UTC --- I am going to be bold and just remove the code that makes APC the default storage backend for LC. I had a number of objections to it, but you're the third person that complains about it from a user / wikiadmin perspective. -- 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 17486] Parser generates malformed XML with a list inside a table
https://bugzilla.wikimedia.org/show_bug.cgi?id=17486
--- Comment #26 from Amalthea amalthea.wikime...@googlemail.com 2011-11-23
12:19:53 UTC ---
Tim Starling, DieBuche: Part of the issue was resolved, the wikicode from
Comment 6 works now. I can still reproduce it with the old editnotice mentioned
in the OP though. I've placed a minimal test case at
http://test.wikipedia.org/wiki/MediaWiki:Editnotice-2-Amalthea-bug17486 which
can be checked in the page source of
http://test.wikipedia.org/w/index.php?title=User:Amalthea/bug17486action=edit
In brief:
table
tr
td
* CC
* DD/td
/tr
/table
results in
table
tr
td
ulli CC
/lili DD/td
/li/ul
/tr
/table
Written like this it's understandable that it may go wrong, it is less obvious
if the table is built by a template with something like td{{{text}}}/td
like w:en:Template:fmbox does.
Philippe Verdy: tldr. Generic wiki syntax improvements are certainly off topic
here 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 32600] Special:IndexPages could use some RTL love
https://bugzilla.wikimedia.org/show_bug.cgi?id=32600 --- Comment #1 from Robin Pepermans (SPQRobin) robinp.1...@gmail.com 2011-11-23 12:25:35 UTC --- This is a usual problem, nothing special here :) I'll add a direction mark, and btw, I am also going to put the number as a parameter in the message, I suppose that is better for localisation. -- 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 32605] New: RSS extension doesn't support protocol-relative URLs
https://bugzilla.wikimedia.org/show_bug.cgi?id=32605 Web browser: --- Bug #: 32605 Summary: RSS extension doesn't support protocol-relative URLs Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: RSS AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: b...@mzmcbride.com CC: jeroen_ded...@yahoo.com, m...@tgries.de Classification: Unclassified I tried to do rss max=6//blog.wikimedia.org/feed//rss at https://wikimediafoundation.org/wiki/Template:Blogbox and it produced the error Not a valid URL: //blog.wikimedia.org/feed/. The RSS extension should support protocol-relative URLs, I think? -- 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 32227] blog.wikimedia.org show mixed-content warning with https
https://bugzilla.wikimedia.org/show_bug.cgi?id=32227 MZMcBride b...@mzmcbride.com changed: What|Removed |Added Keywords||easy, ops, shell CC||b...@mzmcbride.com AssignedTo|gpaum...@wikimedia.org |wikibugs-l@lists.wikimedia. ||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 32227] blog.wikimedia.org show mixed-content warning with https
https://bugzilla.wikimedia.org/show_bug.cgi?id=32227 --- Comment #1 from MZMcBride b...@mzmcbride.com 2011-11-23 12:29:58 UTC --- I think the blog config is somewhere in SVN (or it should be). A few patches should be trivial here, if so. -- 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 32600] Special:IndexPages could use some RTL love
https://bugzilla.wikimedia.org/show_bug.cgi?id=32600 --- Comment #2 from Robin Pepermans (SPQRobin) robinp.1...@gmail.com 2011-11-23 12:46:53 UTC --- Done in r104027. -- 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 32600] Special:IndexPages could use some RTL love
https://bugzilla.wikimedia.org/show_bug.cgi?id=32600 Robin Pepermans (SPQRobin) robinp.1...@gmail.com changed: What|Removed |Added 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 32602] Localization regression on trunk
https://bugzilla.wikimedia.org/show_bug.cgi?id=32602 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 13:12:44 UTC --- (In reply to comment #2) I am going to be bold and just remove the code that makes APC the default storage backend for LC. I had a number of objections to it, but you're the third person that complains about it from a user / wikiadmin perspective. Did so in r104029. -- 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 32227] blog.wikimedia.org show mixed-content warning with https
https://bugzilla.wikimedia.org/show_bug.cgi?id=32227 Guillaume Paumier gpaum...@wikimedia.org changed: What|Removed |Added Keywords|ops, shell | CC||gpaum...@wikimedia.org AssignedTo|wikibugs-l@lists.wikimedia. |gpaum...@wikimedia.org |org | --- Comment #2 from Guillaume Paumier gpaum...@wikimedia.org 2011-11-23 13:13:31 UTC --- The blog's theme isn't yet hosted by us, but it will soon be (see bug 29113). Reassigning to me since I'm currently the one maintaining the theme. -- 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 32519] language caching problem for MediaWiki message 'missing-article'
https://bugzilla.wikimedia.org/show_bug.cgi?id=32519 --- Comment #2 from Niklas Laxström niklas.laxst...@gmail.com 2011-11-23 13:26:26 UTC --- I guess it's a stuck page in squid cache with parser cache key not considering ui lang. The parser guys are a better bet for figuring this out. -- 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 32580] radio button fields produce superfluous None field and do not obey query strings
https://bugzilla.wikimedia.org/show_bug.cgi?id=32580 --- Comment #12 from Yaron Koren yaro...@gmail.com 2011-11-23 13:29:45 UTC --- Well, the Semantic Forms philosophy is that categories should only be added to pages via templates. -- 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 29569] Calling $out-addModuleStyles( 'invalid.module' ); with an invalid module name causes php fatal
https://bugzilla.wikimedia.org/show_bug.cgi?id=29569 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 13:30:10 UTC --- r104030 fixes the OutputPage issue described in comment 3 and comment 4. -- 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 30096] SRF - Exhibit queries no longer work with SMW 1.6
https://bugzilla.wikimedia.org/show_bug.cgi?id=30096 --- Comment #28 from Jeroen De Dauw jeroen_ded...@yahoo.com 2011-11-23 13:37:41 UTC --- That's incompatibility with MediwWiki 1.17 and later... Should be not to hard to load the compatibility modules, if they still exist on trunk that is :) Will have a look at this soonish. -- 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 32598] API requests to commons frequently return 500
https://bugzilla.wikimedia.org/show_bug.cgi?id=32598 --- Comment #4 from Reedy s...@reedyboy.net 2011-11-23 13:51:52 UTC --- (In reply to comment #2) What queries? It is a simple page.put() in pywikipedia: Updating page [[Commons:Quality images/Subject/Places/Man made structures]] via API HTTPError: 500 Internal Server Error WARNING: Could not open 'http://commons.wikimedia.org/w/api.php'. Maybe the server is down. Retrying in 1 minutes... Right, but you didn't say this in your original post, so you could've been doing one of many different things. We're not mind readers ;) -- 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 32599] Requesting creation of a mail list for Kaqchikel Wikipetya'
https://bugzilla.wikimedia.org/show_bug.cgi?id=32599 Reedy s...@reedyboy.net changed: What|Removed |Added Severity|normal |enhancement -- 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 32598] API requests to commons frequently return 500
https://bugzilla.wikimedia.org/show_bug.cgi?id=32598 --- Comment #5 from Daniel Schwen dan...@schwen.de 2011-11-23 14:22:50 UTC --- The page in question is very large (3.3Mb). Might this be a problem? I just went through the logs of the last few weeks and 17 out of 18 times the error happens when the bot is trying to update that particular page! Sometimes it works after a few retries, sometimes all retries fail (pywikipediabot seems to ignore the increased retry count I 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 32598] API requests to commons frequently return 500
https://bugzilla.wikimedia.org/show_bug.cgi?id=32598 --- Comment #6 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 14:25:40 UTC --- (In reply to comment #5) The page in question is very large (3.3Mb). Might this be a problem? You mean you were trying to save 3.3 megs of *wikitext*? That should just be rejected, because $wgMaxArticleSize is set to 2000 KB. -- 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 30096] SRF - Exhibit queries no longer work with SMW 1.6
https://bugzilla.wikimedia.org/show_bug.cgi?id=30096 --- Comment #29 from Jeroen De Dauw jeroen_ded...@yahoo.com 2011-11-23 14:35:32 UTC --- r104038 might have fixed it. -- 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 32521] Request for new name space on the Japanese Wiktionary
https://bugzilla.wikimedia.org/show_bug.cgi?id=32521 --- Comment #2 from eg...@ymail.com 2011-11-23 14:36:06 UTC --- (In reply to comment #1) Done Thank you. -- 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 32480] [SRF] function getParameters(); Define parameter dependencies, display in Special:Ask
https://bugzilla.wikimedia.org/show_bug.cgi?id=32480 Jeroen De Dauw jeroen_ded...@yahoo.com changed: What|Removed |Added Priority|Unprioritized |Low Severity|normal |enhancement -- 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 32537] Don't load some (default) modules if they've been loaded before
https://bugzilla.wikimedia.org/show_bug.cgi?id=32537
--- Comment #2 from Liangent liang...@gmail.com 2011-11-23 15:17:01 UTC ---
On zhwiki, there were a bunch of JavaScript tools depending on wgULS which is a
converter for zh variants and was defined in Common.js and those tools worked
fine. After some time they don't work anymore because wgULS is not defined. I
tried to add mw.loader.using('site', to them and found the site JS run twice
and filed 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 32598] API requests to commons frequently return 500
https://bugzilla.wikimedia.org/show_bug.cgi?id=32598 --- Comment #7 from Daniel Schwen dan...@schwen.de 2011-11-23 15:17:21 UTC --- Oops, that scratch that. I was looking the the rendered HTML. Wikitext is 'just' 276K. However the observation still holds, that this particular page causes most of the bot failures (and it is not the first page that is accessed by the bot!) -- 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 32481] UploadWizard: Multiple files selected, only one file uploads, wrong info
https://bugzilla.wikimedia.org/show_bug.cgi?id=32481 Jeroen De Dauw jeroen_ded...@yahoo.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Jeroen De Dauw jeroen_ded...@yahoo.com 2011-11-23 15:21:37 UTC --- Also confirmed this with Firefox 11 nighly. -- 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 22215] Review SignWriting MediaWiki Plugin extension code and commit it to SVN
https://bugzilla.wikimedia.org/show_bug.cgi?id=22215 Sumana Harihareswara suma...@panix.com changed: What|Removed |Added CC||suma...@panix.com --- Comment #11 from Sumana Harihareswara suma...@panix.com 2011-11-23 15:24:44 UTC --- Hi! I saw on https://www.mediawiki.org/wiki/Extension:SignWriting_MediaWiki_Plugin that your extension is not available in the MediaWiki SVN repository. Just an update that we have a new procedure for developers who want access to commit their extensions to Subversion, in case you'd like to do that. https://www.mediawiki.org/wiki/Commit_access_requests#Requesting_commit_access -- 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 30096] SRF - Exhibit queries no longer work with SMW 1.6
https://bugzilla.wikimedia.org/show_bug.cgi?id=30096
--- Comment #30 from Neill Mitchell mitchell_ne...@hotmail.com 2011-11-23
15:26:18 UTC ---
Hi. Just tried it. Still not working I'm afraid. Errors are:
NetworkError: 404 Not Found - http://localhost/iow/common/wikibits.js;
wikibits.js
wgBreakFrames is not defined
[Break On This Error] if ( wgBreakFrames ) {
wikibits.js?301 (line 124)
NetworkError: 404 Not Found - http://localhost/iow/common/wikibits.js;
wikibits.js
wgServer is not defined
[Break On This Error] wgServer + wgScriptPath +
...ax/simile-ajax-api.js?bundle=false :
exhibi...e=false (line 254)
onloadFuncts is undefined
error source line: [Break On This Error]
message);}else{messageDiv.innerHTML=me...r);}}function addClickHandler(element
Cheers
Neill.
--
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 27580] new extension: Offline database driver reads articles.xml.bz2
https://bugzilla.wikimedia.org/show_bug.cgi?id=27580 Sumana Harihareswara suma...@panix.com changed: What|Removed |Added CC||suma...@panix.com --- Comment #6 from Sumana Harihareswara suma...@panix.com 2011-11-23 15:28:27 UTC --- Adam, did you end up applying for commit access? As far as I can tell, your extension is not available in the MediaWiki SVN repository. So please do apply and put it in there, as Max suggested in comment 1. https://www.mediawiki.org/wiki/Commit_access_requests#Requesting_commit_access -- 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 30096] SRF - Exhibit queries no longer work with SMW 1.6
https://bugzilla.wikimedia.org/show_bug.cgi?id=30096 Jeroen De Dauw jeroen_ded...@yahoo.com changed: What|Removed |Added Priority|Unprioritized |High AssignedTo|jeroen_ded...@yahoo.com |wikibugs-l@lists.wikimedia. ||org --- Comment #31 from Jeroen De Dauw jeroen_ded...@yahoo.com 2011-11-23 15:30:13 UTC --- Ok - then it does not work with 1.17. Need to find someone who wants to maintain the Exhibit format... -- 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. You are the assignee for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 32606] New: duplicate link: is not HTML-linked to file page, not red and points to the wrong URL
https://bugzilla.wikimedia.org/show_bug.cgi?id=32606 Web browser: --- Bug #: 32606 Summary: duplicate link: is not HTML-linked to file page, not red and points to the wrong URL Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: trivial Priority: Unprioritized Component: UploadWizard AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: saibotr...@arcor.de CC: asha...@wikimedia.org, ne...@wikimedia.org Classification: Unclassified FF 3.6 on openSUSE 11.1 When I try to upload a file which was already uploaded before but was deleted UW displays a warning about this and includes a link to the file. However this link is pre a href=#andere Datei/a /pre but should be pre a href=//commons.wikimedia.org/w/index.php?title=File:Burning_eyes_smileygree2tra4.pngaction=editredlink=1andere Datei/a /pre Otherwise a middle click on it doesn't work. I did it since it seems to be a usual link to a file page on Commons. Please also color it red if it doesn't exist and use the action=editredlink=1 URL params. -- 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 30096] SRF - Exhibit queries no longer work with SMW 1.6
https://bugzilla.wikimedia.org/show_bug.cgi?id=30096 --- Comment #32 from Neill Mitchell mitchell_ne...@hotmail.com 2011-11-23 15:46:13 UTC --- HI. This all looks MW side? Do you know why is the interface so different to the other Simile formats that work? Cheers Neill. -- 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. You are the assignee for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 32598] API requests to commons frequently return 500
https://bugzilla.wikimedia.org/show_bug.cgi?id=32598
--- Comment #8 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 15:51:50
UTC ---
I worked with Daniel to obtain a backtrace; it's an OOM error. Offhand I'd say
there are three explanations for this:
1) the object fetched from memcached is large, e.g. because it includes
metadata (I now realize that the (tried to allocate 8208 bytes) part of the
error message disproves this)
2) GlobalUsage fetches many file objects, and there's a memory leak somewhere
3) we're in the post-parse LinksUpdate hook while the parser has just finished
parsing a large wiki page, so the wikitext and all sorts of metadata and parser
data structures are still in memory
[23-Nov-2011 15:41:47] Fatal error: Allowed memory size of 125829120 bytes
exhausted (tried to allocate 8208 bytes) at
/usr/local/apache/common-local/php-1.18/includes/objectcache/MemcachedClient.php
on line 918
Server: srv300
Method: POST
URL: http://commons.wikimedia.org/w/api.php
Cookie: commonswiki_session=CENSORED; commonswikiUserID=126604;
commonswikiToken=CENSORED; commonswikiUserName=QICbot;
Backtrace:
#0
/usr/local/apache/common-local/php-1.18/includes/objectcache/MemcachedClient.php(918):
unserialize('a:15:{s:7:vers...')
#1
/usr/local/apache/common-local/php-1.18/includes/objectcache/MemcachedClient.php(436):
MWMemcached-_load_items(Resource id #146, Array)
#2
/usr/local/apache/common-local/php-1.18/includes/objectcache/MemcachedPhpBagOStuff.php(63):
MWMemcached-get('commonswiki:fil...')
#3
/usr/local/apache/common-local/php-1.18/includes/filerepo/LocalFile.php(184):
MemcachedPhpBagOStuff-get('commonswiki:fil...')
#4
/usr/local/apache/common-local/php-1.18/includes/filerepo/LocalFile.php(340):
LocalFile-loadFromCache()
#5
/usr/local/apache/common-local/php-1.18/includes/filerepo/LocalFile.php(569):
LocalFile-load()
#6 /usr/local/apache/common-local/php-1.18/includes/filerepo/FileRepo.php(126):
LocalFile-exists()
#7 /usr/local/apache/common-local/php-1.18/includes/filerepo/FileRepo.php(179):
FileRepo-findFile('Case_??_la_chef...', Array)
#8
/usr/local/apache/common-local/php-1.18/extensions/GlobalUsage/GlobalUsageHooks.php(20):
FileRepo-findFiles(Array)
#9 [internal function]:
GlobalUsageHooks::onLinksUpdateComplete(Object(LinksUpdate))
#10 /usr/local/apache/common-local/php-1.18/includes/Hooks.php(216):
call_user_func_array('GlobalUsageHook...', Array)
#11 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(3626):
Hooks::run('LinksUpdateComp...', Array)
#12 /usr/local/apache/common-local/php-1.18/includes/LinksUpdate.php(113):
wfRunHooks('LinksUpdateComp...', Array)
#13 /usr/local/apache/common-local/php-1.18/includes/WikiPage.php(2022):
LinksUpdate-doUpdate()
#14 /usr/local/apache/common-local/php-1.18/includes/WikiPage.php(1200):
WikiPage-doEditUpdates(Object(Revision), Object(User), Array)
#15 [internal function]: WikiPage-doEdit('==Man made stru...', 'sorted into
the...', 118)
#16 /usr/local/apache/common-local/php-1.18/includes/Article.php(1921):
call_user_func_array(Array, Array)
#17 [internal function]: Article-__call('doEdit', Array)
#18 /usr/local/apache/common-local/php-1.18/includes/EditPage.php(1214):
Article-doEdit('==Man made stru...', 'sorted into the...', 118)
#19 /usr/local/apache/common-local/php-1.18/includes/api/ApiEditPage.php(273):
EditPage-internalAttemptSave(Array, true)
#20 /usr/local/apache/common-local/php-1.18/includes/api/ApiMain.php(692):
ApiEditPage-execute()
#21 /usr/local/apache/common-local/php-1.18/includes/api/ApiMain.php(358):
ApiMain-executeAction()
#22 /usr/local/apache/common-local/php-1.18/includes/api/ApiMain.php(342):
ApiMain-executeActionWithErrorHandling()
#23 /usr/local/apache/common-local/php-1.18/api.php(115): ApiMain-execute()
#24 /usr/local/apache/common-local/live-1.5/api.php(3):
require('/usr/local/apac...')
#25 {main}
--
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 32607] New: User factories return null or false
https://bugzilla.wikimedia.org/show_bug.cgi?id=32607
Web browser: ---
Bug #: 32607
Summary: User factories return null or false
Product: MediaWiki
Version: 1.19-svn
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General/Unknown
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: has...@free.fr
Classification: Unclassified
The User class propose several factory methods. Most of them will always return
a User object but two of them would not:
User::newFromName() can return false
User::newFromConfirmationCode() can return null
I would prefer having factories return null if no object have been made. This
way we will avoid fatal errors when passing the result to a function explicitly
expecting a User object. Example
?php
function delete( User $user ) {
// do something
}
delete( User::newFromName( '127.0.0.1' ) );
?
That code will throw a catchable fatal error since the delete function expect
either a User object or the null value.
--
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 32598] API requests to commons frequently return 500
https://bugzilla.wikimedia.org/show_bug.cgi?id=32598 --- Comment #9 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 15:58:56 UTC --- (In reply to comment #8) I worked with Daniel to obtain a backtrace; it's an OOM error. Offhand I'd say there are three explanations for this: 1) the object fetched from memcached is large, e.g. because it includes metadata (I now realize that the (tried to allocate 8208 bytes) part of the error message disproves this) 2) GlobalUsage fetches many file objects, and there's a memory leak somewhere 3) we're in the post-parse LinksUpdate hook while the parser has just finished parsing a large wiki page, so the wikitext and all sorts of metadata and parser data structures are still in memory Daniel blanked the page in question, upon which the bot edit worked fine. He mentioned the page used to contain a gallery with 7000 images, so I'm now leaning towards theory #2. -- 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 32607] User factories return null or false
https://bugzilla.wikimedia.org/show_bug.cgi?id=32607 Antoine hashar Musso has...@free.fr changed: What|Removed |Added Blocks||700 -- 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 700] Code quality issues (and other stuff that sucks) (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=700 Antoine hashar Musso has...@free.fr changed: What|Removed |Added Depends on||32607 -- 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 32607] User factories return null or false
https://bugzilla.wikimedia.org/show_bug.cgi?id=32607 --- Comment #1 from Antoine hashar Musso has...@free.fr 2011-11-23 16:02:35 UTC --- So basically, User::newFromName() should return null :-) -- 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 29475] Move trackbacks out of core
https://bugzilla.wikimedia.org/show_bug.cgi?id=29475 Antoine hashar Musso has...@free.fr changed: What|Removed |Added CC||has...@free.fr --- Comment #4 from Antoine hashar Musso has...@free.fr 2011-11-23 16:16:08 UTC --- Maybe we should remove it once and for 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 22215] Review SignWriting MediaWiki Plugin extension code and commit it to SVN
https://bugzilla.wikimedia.org/show_bug.cgi?id=22215 Platonides platoni...@gmail.com changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #12 from Platonides platoni...@gmail.com 2011-11-23 16:24:02 UTC --- (In reply to comment #4) [19:02:29] Reedy Size: 6.83 MB (7,164,781 bytes) [19:02:39] Reedy Size on disk: 148 MB (156,164,096 bytes) on NTFS.. I get 28 MB vs 171 MB (it has grown?). And 15 MB in the zip. The file footprint could be much smaller (~96:1) if the rotation, flipping and filling was done by the script. That would appeal small sites. Large ones would still want to cache it in the fs. The server code seems very messy, including html injection, register globals problems and ugly direct $_REQUEST manipulation (I understand you may want to keep it separate from, but you should avoid the notices if they are unset, eg. array addition to some defaults). There's a general lack of indentation, and at least on swmp.php should be tab based. Old conventions MW extension uses: Registration should be done to the passed $parser with ParserFirstCallInit, not to $wgParser with $wgExtensionFunctions. Should use $wgExtensionAssetsPath You should have very good reasons to defend this line: $parser-disableCache();//should solve caching problem. Luckily, it is apparently unneeded, so it seems it could be removed without harm. The chdir() 'quick hack so scripts works' should be removed if possible. You can use __DIR__ or dirname( __FILE__ ) in the server includes (also not that include_path is not duaranteed to contain .). Classes should be autoloaded. There are also html injection problems in swmp.php but in general, shouldn't be hard to fix that file. I'm more concerned about making the server safe. As it is now, there's no chance it gets enabled in any WMF project. -- 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 32217] Drop MySQL 4 support
https://bugzilla.wikimedia.org/show_bug.cgi?id=32217 --- Comment #4 from Reedy s...@reedyboy.net 2011-11-23 16:29:14 UTC --- r104045 kills $wgDBmysql4 r104046 kills some mysql 4 related code from the installer r104047 Kill mysql4 code from DatabaseMysql, bumps minimum mysql version in the installer TODO: * Kill 'config-charset-mysql4' ? * Kill $existingSchema = 'mysql4'; ? * -- 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 32601] revert wikidiff2
https://bugzilla.wikimedia.org/show_bug.cgi?id=32601 Antoine hashar Musso has...@free.fr changed: What|Removed |Added Status|NEW |RESOLVED CC||has...@free.fr Resolution||WONTFIX --- Comment #1 from Antoine hashar Musso has...@free.fr 2011-11-23 16:41:33 UTC --- We are not going to revert it on live site. But for sure, will need to fix the bug you referenced :-) -- 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 32605] RSS extension doesn't support protocol-relative URLs
https://bugzilla.wikimedia.org/show_bug.cgi?id=32605 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Brion Vibber br...@wikimedia.org 2011-11-23 16:44:31 UTC --- Protocol-relative doesn't really have meaning here; the feed is fetched from the server-side code and cached, so would be fetched the same way from: * web hits to http * web hits to https * server-side batch processing You should either use the http or the https URL. -- 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 32217] Drop MySQL 4 support
https://bugzilla.wikimedia.org/show_bug.cgi?id=32217 Platonides platoni...@gmail.com changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #5 from Platonides platoni...@gmail.com 2011-11-23 16:45:35 UTC --- MySQL 5 has been production release since October 2005 [1], I think we've been supporting it long enough. I can't imagine too many people are still running it...? We were running mysql 4 until 2009 or so. $wgDBmysql4 is always true for compatibility with extensions that might be checking. Seems $wgDBmysql5 should follow the same fate. Anyway $wgDBmysql5 does a useful task. Suddenly sending SET NAMES utf8 to everybody would break utf8-in-latin1 installs (beginning with WMF servers). A second reason to avoid subqueries was that 'they were inefficient'. Which ones did you want to add? If we don't have a direct gain from dropping support, I'd keep it in. -- 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 32607] User::newFromName should return null instead of false on invalid input
https://bugzilla.wikimedia.org/show_bug.cgi?id=32607 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Summary|User factories return null |User::newFromName should |or false|return null instead of ||false on invalid input --- Comment #2 from Brion Vibber br...@wikimedia.org 2011-11-23 16:46:00 UTC --- Updated summary to say so :) -- 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 32598] API requests to commons frequently return 500
https://bugzilla.wikimedia.org/show_bug.cgi?id=32598 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 16:51:32 UTC --- (In reply to comment #9) Daniel blanked the page in question, upon which the bot edit worked fine. He mentioned the page used to contain a gallery with 7000 images, so I'm now leaning towards theory #2. Turns out I was right. Fixed in r104049 and deployed. -- 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 32217] Drop MySQL 4 support
https://bugzilla.wikimedia.org/show_bug.cgi?id=32217 --- Comment #6 from Reedy s...@reedyboy.net 2011-11-23 16:56:35 UTC --- (In reply to comment #5) MySQL 5 has been production release since October 2005 [1], I think we've been supporting it long enough. I can't imagine too many people are still running it...? We were running mysql 4 until 2009 or so. We only got rid of it it on the live WMF sites in the last few months... -- 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 32217] Drop MySQL 4 support
https://bugzilla.wikimedia.org/show_bug.cgi?id=32217 --- Comment #7 from Platonides platoni...@gmail.com 2011-11-23 16:58:52 UTC --- I wouldn't run to remove it, then. -- 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 32608] New: prefillLocation catches a wrong GPS height ouf of EXIF
https://bugzilla.wikimedia.org/show_bug.cgi?id=32608 Web browser: --- Bug #: 32608 Summary: prefillLocation catches a wrong GPS height ouf of EXIF Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: UploadWizard AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: raimond.spekk...@gmail.com CC: asha...@wikimedia.org, ne...@wikimedia.org Classification: Unclassified Created attachment 9531 -- https://bugzilla.wikimedia.org/attachment.cgi?id=9531 GPS height prefillLocation catches a wrong GPS height ouf of EXIF. Testcase: All images from https://commons.wikimedia.org/wiki/Category:Videoguides_im_Rautenstrauch-Joest-Museum The EXIF data were written with GeoSetter 3.4.16/ExifTool 8.71. -- 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 32608] prefillLocation catches a wrong GPS altitude ouf of EXIF
https://bugzilla.wikimedia.org/show_bug.cgi?id=32608 Raimond Spekking raimond.spekk...@gmail.com changed: What|Removed |Added Summary|prefillLocation catches a |prefillLocation catches a |wrong GPS height ouf of |wrong GPS altitude ouf of |EXIF|EXIF --- Comment #1 from Raimond Spekking raimond.spekk...@gmail.com 2011-11-23 17:10:52 UTC --- See the altitude of 55/1 in the screenshot. 55 is correct but where does the /1 comes from? -- 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 29145] Core features that shouldn't be in core (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=29145 Bug 29145 depends on bug 29475, which changed state. Bug 29475 Summary: Move trackbacks out of core https://bugzilla.wikimedia.org/show_bug.cgi?id=29475 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 29475] Move trackbacks out of core
https://bugzilla.wikimedia.org/show_bug.cgi?id=29475 Chad H. innocentkil...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Chad H. innocentkil...@gmail.com 2011-11-23 17:14:27 UTC --- Done in r104051. -- 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 31256] AntiSpoof: Want to customize blacklist.
https://bugzilla.wikimedia.org/show_bug.cgi?id=31256 --- Comment #12 from Van de Bugger van.de.bug...@gmail.com 2011-11-23 17:25:46 UTC --- Those seam like characters we absolutely don't want to see,… Why? AntiSpoof is an extension, optional by nature. If those are characters you are /absolutely/ do not want to see, why they are not blacklisted in core? All these blacklisted characters are allowed in MW out-of-the-box, and disabled only if AntiSpoof is installed and enabled. How about keeping that built in character list as it is, but adding the $wg stuff in addition to it. IMHO, it complicates implementation with no real benefit. -- 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 20416] ee-helper is not compatible with Chinese namespace names and file/title names
https://bugzilla.wikimedia.org/show_bug.cgi?id=20416 Sumana Harihareswara suma...@panix.com changed: What|Removed |Added Keywords||i18n CC||suma...@panix.com --- Comment #4 from Sumana Harihareswara suma...@panix.com 2011-11-23 17:39:25 UTC --- Liangent, is this patch still necessary? Tagging i18n. -- 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 32609] New: API: Move captchaid/captchaword of action=edit from core to Captcha extension(s)
https://bugzilla.wikimedia.org/show_bug.cgi?id=32609 Web browser: --- Bug #: 32609 Summary: API: Move captchaid/captchaword of action=edit from core to Captcha extension(s) Product: MediaWiki Version: 1.19-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: API AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: duplicate...@googlemail.com CC: bryan.tongm...@gmail.com, roan.katt...@gmail.com, s...@reedyboy.net, soxre...@gmail.com Classification: Unclassified The description of action=edit contains the params captchaid/captchaword, but the params are only needed for the captcha extension. Please move the params to the captcha extension, because not all installation has this installed and need the params. 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 32595] clean up use of abusefilter-private user rights
https://bugzilla.wikimedia.org/show_bug.cgi?id=32595 duplicate...@googlemail.com changed: What|Removed |Added Status|NEW |RESOLVED URL|http://meta.wikimedia.org/w |http://meta.wikimedia.org/w |/api.php?action=querymeta= |/api.php?action=querymeta= |globaluserinfoguiuser=Brio |globaluserinfoguiuser=Brio |n |n%20VIBBERguiprop=groups|r |VIBBERguiprop=groups|right |ights |s | Resolution||FIXED --- Comment #2 from duplicate...@googlemail.com 2011-11-23 17:50:49 UTC --- The api result looks now ok. All caches should have now the right values. 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 32227] blog.wikimedia.org show mixed-content warning with https
https://bugzilla.wikimedia.org/show_bug.cgi?id=32227 --- Comment #3 from duplicate...@googlemail.com 2011-11-23 17:52:44 UTC --- It is not alone the theme. Some posts contains images, which are load over http. -- 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 32120] New Assamese Transliteration Scheme
https://bugzilla.wikimedia.org/show_bug.cgi?id=32120 Junaid junu.pv+pub...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Junaid junu.pv+pub...@gmail.com 2011-11-23 17:55:42 UTC --- r104056 M and nG is now ং No need to change ZWJ. ` as ZWJ has been kept. Please update table. While _ made as ZWNJ. -- 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 32227] blog.wikimedia.org show mixed-content warning with https
https://bugzilla.wikimedia.org/show_bug.cgi?id=32227 --- Comment #4 from Guillaume Paumier gpaum...@wikimedia.org 2011-11-23 17:56:04 UTC --- (In reply to comment #3) It is not alone the theme. Some posts contains images, which are load over http. I understand, and while we can try to watch for them in new posts, I can't guarantee that we're going to go through ~600 blog posts just to change image links to protocol-relative URLs. -- 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 32609] API: Move captchaid/captchaword of action=edit from core to Captcha extension(s)
https://bugzilla.wikimedia.org/show_bug.cgi?id=32609 Reedy s...@reedyboy.net changed: What|Removed |Added Priority|Unprioritized |Low Severity|normal |minor -- 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 12500] [[MediaWiki:Antispoof-name-illegal]] should provide information about the illegal and / or blocked characters in / at the wiki
https://bugzilla.wikimedia.org/show_bug.cgi?id=12500
--- Comment #6 from Van de Bugger van.de.bug...@gmail.com 2011-11-23 18:14:54
UTC ---
Non-printable characters can be handled in badCharErr:
private static function badCharErr( $msgId, $point ) {
$char = codepointToUtf8( $point );
$code = sprintf( 'U+%04X', $point );
if ( preg_match( '/^[^:print:]/', $char ) ) {
$char = '';
}
return array( ERROR, wfMsg( $msgId, $char, $code ) );
}
Or:
private static function badCharErr( $msgId, $point ) {
$char = codepointToUtf8( $point );
$code = sprintf( 'U+%04X', $point );
if ( preg_match( '/^[^:print:]/', $char ) ) {
return array( ERROR, wfMsg( $msgId . '-np', $code ) );
}
return array( ERROR, wfMsg( $msgId, $char, $code ) );
}
(The latter variant will require some more error messages.)
Which variant do you prefer? I will prepare a new patch.
--
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 32608] prefillLocation catches a wrong GPS altitude ouf of EXIF
https://bugzilla.wikimedia.org/show_bug.cgi?id=32608 --- Comment #2 from Brion Vibber br...@wikimedia.org 2011-11-23 18:26:06 UTC --- Is this same as bug 32410? -- 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 32608] prefillLocation catches a wrong GPS altitude ouf of EXIF
https://bugzilla.wikimedia.org/show_bug.cgi?id=32608 --- Comment #3 from Raimond Spekking raimond.spekk...@gmail.com 2011-11-23 18:33:44 UTC --- (In reply to comment #2) Is this same as bug 32410? Hmmm looks very similar. But in my examples the latitude is exactly 55.0 m. Where does the /1 comes from? -- 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 30042] Form inputs need to reject problem characters
https://bugzilla.wikimedia.org/show_bug.cgi?id=30042
--- Comment #25 from Van de Bugger van.de.bug...@gmail.com 2011-11-23
18:34:15 UTC ---
I believe that Forms *must* *not* generate invalid code. The simplest method to
achieve this -- deny {{, |, and }}, which is now implemented and available as a
patch. The patch fulfils my current needs. I do not object if somebody
implements any of advanced validation techniques mentioned above.
--
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 31576] Magic words are considered to be (non-existing) templates
https://bugzilla.wikimedia.org/show_bug.cgi?id=31576 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #11 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 18:37:01 UTC --- I've investigated some of the occurrences, and discovered the following: * this bug is related to bug 31577: all the wrongly-categorized pages there also had PAGENAME, NAMESPACE, etc. in the template list * the current parse results (from the parser cache) actually DON'T list the bad templates, but the templatelinks table does. Purging the page doesn't remove them, but null editing the page does I've put in a live hack for debugging in r104059 that does the following things: * add the server name to the parser cache comment, so we can see which server rendered the cached HTML. This is probably generally useful for debugging and I'll probably put it in MediaWiki as an optional feature later * before saving a parse result to the parser cache, check the templates list for PAGENAME, FULLPAGENAME and NAMESPACE. If any of those three are in the templates list, write the details (page name, pcache key, timestamp, server name) to a log file Hopefully this'll allow me to narrow down this issue. What I'm particularly interested in, meanwhile, is NEW occurrences of this bug, because I want to determine whether these bad template/category entries are still being created. If they aren't, we can just clean up the old ones and be done with it, but if they are, we have a real bug to fix. -- 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 31577] Categories containing pages which should not be in that category
https://bugzilla.wikimedia.org/show_bug.cgi?id=31577 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #8 from Roan Kattouw roan.katt...@gmail.com 2011-11-23 18:44:24 UTC --- (In reply to comment #5) I bet this is somehow related to bug 31576. This seems to be the case, yes. I've investigated these issues a bit today, see my comment on bug 31576 for details. Also, from now on I'll comment on bug 31576, not on 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 31706] Android app should give up a page load if its been going for more then X amount of time
https://bugzilla.wikimedia.org/show_bug.cgi?id=31706 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Blocks||31447 Depends on|31447 | --- Comment #1 from Brion Vibber br...@wikimedia.org 2011-11-23 18:51:48 UTC --- Switching dependency to a block, looks like it was inverted by mistake. -- 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 31447] Tracking bug for 1.0 release of Android App
https://bugzilla.wikimedia.org/show_bug.cgi?id=31447 Brion Vibber br...@wikimedia.org changed: What|Removed |Added Blocks|31706 | Depends on||31706 -- 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 14977] $wgServer lacks brackets in IPv6 URLs
https://bugzilla.wikimedia.org/show_bug.cgi?id=14977 --- Comment #37 from Allen Stambaugh allen4na...@gmail.com 2011-11-23 18:57:42 UTC --- (In reply to comment #36) It is only on issue if there are limitations in the webserver software itself (but IPv6 support in Apache, or even IIS, is present since long), or in some server log analysis tools, or with some proxy softwares (no longer an issue for proxies used by the Wikimedia Foundation). We should really not recommand the installation of MediaWiki on servers without a domain name, or at least a hostname on a private LAN (and on private LANs, IPv4 still works without limitations; IPv6 is mostly for the Internet). With some exceptions I agree, but we should allow for those who wish to develop content over the Internet before adding a domain name and for testing and experimentation. -- 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 32485] SemanticForms: Creating new articles with `page name' formula is broken.
https://bugzilla.wikimedia.org/show_bug.cgi?id=32485
--- Comment #4 from Van de Bugger van.de.bug...@gmail.com 2011-11-23 19:05:13
UTC ---
Hmm… r103718 looks like a good fix, but it does not help in my case (checked on
r104063). My problem is caused by `SF_FormEdit.php' line 110:
if ( $target_name === '' ) {
This is the first fork where execution goes to wrong direction. Note: This is
the first, but not last. If I fix this one
if ( $target_name == '' ) {
I have another error:
Fatal error: Call to a member function getUserPermissionsErrors() on a
non-object in
/var/www/ocw/mediawiki-1.17.1/extensions/SemanticForms/includes/SF_FormPrinter.php
on line 390
I tried to debug further but later I decided
if ( is_null( $this-mTarget ) ) {
$this-mTarget = '';
}
in the beginning of `execute' is the easiest workaround.
--
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 14977] $wgServer lacks brackets in IPv6 URLs
https://bugzilla.wikimedia.org/show_bug.cgi?id=14977 Bawolff bawolff...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bawolff...@gmail.com Resolution||FIXED --- Comment #38 from Bawolff bawolff...@gmail.com 2011-11-23 19:06:52 UTC --- Tim fixed this a while back (r90105) and presumably forgot to mark this bug as fixed. Marking 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 32609] API: Move captchaid/captchaword of action=edit from core to Captcha extension(s)
https://bugzilla.wikimedia.org/show_bug.cgi?id=32609 Reedy s...@reedyboy.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Reedy s...@reedyboy.net 2011-11-23 19:11:18 UTC --- Done in r104064 Minor remnants (setting of wgRequest stuff) left in core, due to it being the simplest 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 796] Trackbacks
https://bugzilla.wikimedia.org/show_bug.cgi?id=796 LordAndrew reachouttothetr...@hotmail.com changed: What|Removed |Added CC||reachouttothetruth@hotmail. ||com --- Comment #3 from LordAndrew reachouttothetr...@hotmail.com 2011-11-23 19:13:57 UTC --- Trackback support removed in r104051 (1.19alpha). Is this a feature that would be still be desired in an extension? -- 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 32608] prefillLocation catches a wrong GPS altitude ouf of EXIF
https://bugzilla.wikimedia.org/show_bug.cgi?id=32608 --- Comment #4 from Neil Kandalgaonkar ne...@wikimedia.org 2011-11-23 19:25:17 UTC --- Raimond: it's a rational, just a fraction, same as what you learned in grade school. 55/1 = 55. Your camera is actually supplying similar values for latitude and longitude, but MediaWiki does the right thing in those cases. It's totally the same bug, IMO. Unless you want to temporarily turn off altitude in UW until bug #32410 is 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 32608] prefillLocation catches a wrong GPS altitude ouf of EXIF
https://bugzilla.wikimedia.org/show_bug.cgi?id=32608 Raimond Spekking raimond.spekk...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #5 from Raimond Spekking raimond.spekk...@gmail.com 2011-11-23 19:28:11 UTC --- Neil: Thanks for the explaining. Marking as dupe now. *** This bug has been marked as a duplicate of bug 32410 *** -- 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 32410] MediaWiki api doesn't serve EXIF GPSAltitude (and other tags) as decimals
https://bugzilla.wikimedia.org/show_bug.cgi?id=32410 --- Comment #4 from Raimond Spekking raimond.spekk...@gmail.com 2011-11-23 19:28:11 UTC --- *** Bug 32608 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 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 32610] New: Don't show create an instance for a project if the user doesn't have sufficient rights
https://bugzilla.wikimedia.org/show_bug.cgi?id=32610 Web browser: --- Bug #: 32610 Summary: Don't show create an instance for a project if the user doesn't have sufficient rights Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: OpenStackManager AssignedTo: rlan...@gmail.com ReportedBy: rlan...@gmail.com Classification: Unclassified There's no point in giving a link to something a user can't use. -- 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 32605] RSS extension doesn't support protocol-relative URLs
https://bugzilla.wikimedia.org/show_bug.cgi?id=32605 --- Comment #2 from MZMcBride b...@mzmcbride.com 2011-11-23 19:39:35 UTC --- (In reply to comment #1) Protocol-relative doesn't really have meaning here; the feed is fetched from the server-side code and cached, so would be fetched the same way from: * web hits to http * web hits to https * server-side batch processing You should either use the http or the https URL. I was trying to make the output flexible based on the user's current protocol. Is there no way to do that? Should there be? -- 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 32485] SemanticForms: Creating new articles with `page name' formula is broken.
https://bugzilla.wikimedia.org/show_bug.cgi?id=32485 --- Comment #5 from Yaron Koren yaro...@gmail.com 2011-11-23 19:52:07 UTC --- Okay, I get it. I took your advice, but put in very similar code SF_FormEdit.php, instead of SF_FormPrinter.php, because it seemed like the more general solution. I checked it in to SVN - does this fix your problem? -- 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 31336] Ordered properties does not work as described.
https://bugzilla.wikimedia.org/show_bug.cgi?id=31336
--- Comment #3 from Van de Bugger van.de.bug...@gmail.com 2011-11-23 20:12:54
UTC ---
Hi guys, please respond whether it is a bug in code or in documentation.
If it is a bug in code, by fixing return statement in `SMW_DV_Number.php':
protected function convertToMainUnit( $number, $unit ) {
$this-m_dataitem = new SMWDINumber( $number );
$this-m_unitin = '';
return ( $unit === '' );
}
to
return ( preg_match( '/^(-$)/', $unit ) );
you will let `Number' ignore pseudo-units starting with dash, as described in
the help:
SMW's number datatype ignores the - description after the number. This gives
the set of properties a numerical order and lets you make two values
equivalent.
If it is a bug in documentation, page
http://semantic-mediawiki.org/wiki/Property:Allows_value should be updated.
--
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 16572] Search via API fails intermittently
https://bugzilla.wikimedia.org/show_bug.cgi?id=16572
Peter Bena benap...@gmail.com changed:
What|Removed |Added
CC||benap...@gmail.com
--- Comment #3 from Peter Bena benap...@gmail.com 2011-11-23 20:19:55 UTC ---
FYI: this bug is still happening on current 1.18wmf1, I will do some more tests
and try to find out what's causing it
way to reproduce it:
Open link
http://en.wikipedia.org/w/api.php?action=querylist=searchsrnamespace=5|6|7srsearch=wordsrlimit=5format=jsonfm
and refresh it like 10 times, it should appear then.
example:
{
servedby: mw74,
error: {
code: srsearch-text-disabled,
info: text search is disabled
}
}
--
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 32485] SemanticForms: Creating new articles with `page name' formula is broken.
https://bugzilla.wikimedia.org/show_bug.cgi?id=32485 Van de Bugger van.de.bug...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #6 from Van de Bugger van.de.bug...@gmail.com 2011-11-23 20:24:00 UTC --- I took your advice,… No, that was not an advice. That was description of my attempt to get my site works after an update, and spend not too much time debugging the code. …does this fix your problem? Yes, not it works. Checked on r104081. Thanks. BTW, please pay attention to bug 32533 -- it requires 3 characters (`\s*') to be fixed. Thanks again. -- 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 32485] SemanticForms: Creating new articles with `page name' formula is broken.
https://bugzilla.wikimedia.org/show_bug.cgi?id=32485 Van de Bugger van.de.bug...@gmail.com changed: What|Removed |Added Status|RESOLVED|VERIFIED -- 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 32611] New: SemanticForms: Invalid input leads to fatal error.
https://bugzilla.wikimedia.org/show_bug.cgi?id=32611
Web browser: ---
Bug #: 32611
Summary: SemanticForms: Invalid input leads to fatal error.
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: SemanticForms
AssignedTo: yaro...@gmail.com
ReportedBy: van.de.bug...@gmail.com
CC: wikibugs-l@lists.wikimedia.org
Classification: Unclassified
A HTTP request with the following query string:
title=Special:FormEditForm=SomeFormtarget=xxx%7B
causes
Fatal error: Call to a member function getPrefixedText() on a non-object in
/var/www/ocw/mediawiki-1.17.1/extensions/SemanticForms/specials/SF_FormEdit.php
on line 361
Not a big deal, because target page name is invalid, but it is kind of security
issue -- code should control input to avoid crashes. It would be more better to
show error page and say `xxx{' is not a valid page 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 32612] New: Update Doyxgen from 1.6.3 to 1.7.x
https://bugzilla.wikimedia.org/show_bug.cgi?id=32612 Web browser: --- Bug #: 32612 Summary: Update Doyxgen from 1.6.3 to 1.7.x Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: Unprioritized Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: has...@free.fr Classification: Unclassified Doxygen documentation for MediaWiki is generated on formey using Doxygen 1.6.3 : https://svn.wikimedia.org/doc/ That version is a bit old and generates slow HTML. Doxygen 1.7.x is lighter and cleaner to the eye. It is not available in Ubuntu lucid (10.4) though. We could either: 1) upgrade Ubuntu on Formey 2) backport Doxygen 1.7.x in Lucid (10.4) Willing to hear from the ops about this :-) -- 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 32612] Update Doyxgen from 1.6.3 to 1.7.x
https://bugzilla.wikimedia.org/show_bug.cgi?id=32612 Antoine hashar Musso has...@free.fr changed: What|Removed |Added Keywords||ops -- 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 32612] Update Doyxgen from 1.6.3 to 1.7.x
https://bugzilla.wikimedia.org/show_bug.cgi?id=32612 Reedy s...@reedyboy.net changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Reedy s...@reedyboy.net 2011-11-23 21:05:32 UTC --- Reedy 1.7.4 in oneric Reedy Needs libc6 = 2.4, 10.04 has 2.11 Reedy libstdc++6 is ok Reedy having said that it needsd = 2.4 on lucid http://packages.ubuntu.com/oneiric/doxygen http://packages.ubuntu.com/lucid/doxygen Might just be able to repackage it for lucid then -- 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
