[Bug 25379] New: Old Special:BannerLoader urls structure persist after argument updates
https://bugzilla.wikimedia.org/show_bug.cgi?id=25379 Summary: Old Special:BannerLoader urls structure persist after argument updates Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CentralNotice AssignedTo: rkald...@wikimedia.org ReportedBy: tf...@wikimedia.org Even though we changed the banner loader url structure on 9/29 were still seeing old style lookups like 2010-09-30T22:22:29 http://meta.wikimedia.org/wiki/Special:BannerLoader?banner=2010_testing41userlang=desitename=Wikipedia 2010-09-30T22:22:35 http://meta.wikimedia.org/wiki/Special:BannerLoader?banner=WMCZCeny02userlang=cssitename=Wikipedie Instead of ones with dbname= -- 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 25380] New: Magic word to indicate user blocked status
https://bugzilla.wikimedia.org/show_bug.cgi?id=25380
Summary: Magic word to indicate user blocked status
Product: MediaWiki
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: Normal
Component: Blocking
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: dma...@netspace.org
Feature request, arising from an idea I floated at en.wp [[Wikipedia talk:User
pages#Block notices and BLANKING]] that led to [[Wikipedia:Village pump
(technical)#Interface block notice while viewing user talk page?]]. The idea
hinged on a template being able to determine whether a certain user was
currently blocked, which is reportedly not possible to do at this time.
Possible syntax would be {{#ISBLOCKED:USERNAME}}, which would return true or
false indicating if User:USERNAME was currently blocked or not.
For the originally floated idea, that would mean WP admins could set something
like:
{{#if:{{#ISBLOCKED:{{PAGENAME|'''Note:''' This user is presently blocked.}}
in a user talkpage to avoid constant edit-warring (or endless debate about
guideline about) removing/readding active block messages. An additional use
might be in [[Template:Lu]], where this same logic could be used to display an
icon or other status indicator. This would be useful in sock-puppet and related
abuse discussions to reveal at a glance the status of the account(s) being
discussed.
--
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 25381] New: addOnloadHook not defined
https://bugzilla.wikimedia.org/show_bug.cgi?id=25381 Summary: addOnloadHook not defined Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Semantic MediaWiki AssignedTo: denny.vrande...@kit.edu ReportedBy: denny.vrande...@kit.edu Firebug sometimes says: addOnloadHook(smw_sortables_init); is not defined Appears when a query result of format table is on the page. Need to figure out, why exactly, and remove the 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 14407] CentralAuth global session doesn't include Incubator and other *.wikimedia.org public wikis
https://bugzilla.wikimedia.org/show_bug.cgi?id=14407 James Lu james@education.nsw.gov.au changed: What|Removed |Added CC||james@education.nsw.gov ||.au --- Comment #31 from James Lu james@education.nsw.gov.au 2010-10-01 06:54:23 UTC --- Using a separate browser helps and using the secure server also helps. If I was on Firefox and I login it won't log me in on IE, so on IE I can log into my alternate account for whatever reason and still be on my main account on Firefox, it's the same with the secure server, although I'm not quite sure about the latter. -- 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 25381] addOnloadHook not defined
https://bugzilla.wikimedia.org/show_bug.cgi?id=25381 Niklas Laxström niklas.laxst...@gmail.com changed: What|Removed |Added CC||niklas.laxst...@gmail.com --- Comment #1 from Niklas Laxström niklas.laxst...@gmail.com 2010-10-01 06:56:06 UTC --- With the new resource loader or without? -- 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 25382] New: Lqt preview is broken (javascript issue)
https://bugzilla.wikimedia.org/show_bug.cgi?id=25382 Summary: Lqt preview is broken (javascript issue) Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: major Priority: Normal Component: Resource Loader AssignedTo: tpars...@wikimedia.org ReportedBy: niklas.laxst...@gmail.com CC: roan.katt...@gmail.com Uncaught ReferenceError: mw is not defined doLivePreview preview.js:8 (anonymous function) lqt.js:228 success load.php:5267 script.onload.script.onreadystatechange load.php:5079 -- 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 25338] Resource loader: incorrect input to makeList()
https://bugzilla.wikimedia.org/show_bug.cgi?id=25338 Niklas Laxström niklas.laxst...@gmail.com changed: What|Removed |Added CC||niklas.laxst...@gmail.com --- Comment #1 from Niklas Laxström niklas.laxst...@gmail.com 2010-10-01 07:04:35 UTC --- The crucial point here seems to be that the request really contains amp; instead of . -- 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 14237] PAGESINCATEGORY should differentiate between pages and subcategories
https://bugzilla.wikimedia.org/show_bug.cgi?id=14237 --- Comment #11 from philippe.vign...@etat.ge.ch 2010-10-01 07:24:16 UTC --- I don't know if the index on the two columns (category_pageid, member_namespaceid) exists on the table categorymembers, but it seems to me that is the only thing that may be added in the database... performance can only be better... so when this improvment will be done ?... -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25374] Enable 'eliminator' flag on hiwiki and grant bureaucrats to add/remove this group
https://bugzilla.wikimedia.org/show_bug.cgi?id=25374 --- Comment #1 from mayurkumar mayur...@gmail.com 2010-10-01 08:19:42 UTC --- Hi, please also enable some more right for this group along with following $wgGroupPermissions['eliminator']['delete'] = true; $wgGroupPermissions['eliminator']['undelete'] = true; $wgGroupPermissions['eliminator']['autopatrol'] = true; $wgGroupPermissions['eliminator']['rollback'] = true; $wgGroupPermissions['eliminator']['ipblock-exempt'] = true; and enable bureacrats to add/remove this user group Thank you and Regards -- 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 25381] addOnloadHook not defined
https://bugzilla.wikimedia.org/show_bug.cgi?id=25381 --- Comment #2 from denny vrandecic denny.vrande...@kit.edu 2010-10-01 08:38:47 UTC --- The two MediaWikis in question have both been rather recent versions from SVN trunk, so if resource loader is installed by deafult on them, then yes. -- 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 25381] addOnloadHook not defined
https://bugzilla.wikimedia.org/show_bug.cgi?id=25381 p858snake p858sn...@gmail.com changed: What|Removed |Added CC||p858sn...@gmail.com --- Comment #3 from p858snake p858sn...@gmail.com 2010-10-01 09:39:12 UTC --- Try updating your semantic extensions, AFAIK addonloadhook has been removed from core because resource loader handles that, and I'm pretty sure the extensions have been updated to handle that. -- 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 25381] addOnloadHook not defined
https://bugzilla.wikimedia.org/show_bug.cgi?id=25381 --- Comment #4 from Niklas Laxström niklas.laxst...@gmail.com 2010-10-01 09:44:34 UTC --- It's not removed yet, but it is loader later. I think jQuery's ready() method is suitable replacement. -- 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 25383] New: Lqt call Language::getNsText() with null param
https://bugzilla.wikimedia.org/show_bug.cgi?id=25383 Summary: Lqt call Language::getNsText() with null param Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: LiquidThreads AssignedTo: agarr...@wikimedia.org ReportedBy: niklas.laxst...@gmail.com CC: amil...@wikimedia.org, bhar...@wikimedia.org PHP Notice: Language::getNsText: Requested nstext for N; (en) [Called from Title::makeName in /www/w/includes/Title.php at line 502] for //w/i.php?title=Project:Translatordir=prevoffset=20091117075805lqt_method=talkpage_history ul liGlobalFunctions.php line 3269 calls wfBacktrace()/li liLanguage.php line 309 calls wfWarn()/li liTitle.php line 502 calls Language::getNsText()/li liTitle.php line 298 calls Title::makeName()/li liTalkpageHistoryView.php line 97 calls Title::makeTitleSafe()/li liPager.php line 875 calls TalkpageHistoryPager::formatValue()/li liPager.php line 311 calls TablePager::formatRow()/li liTalkpageHistoryView.php line 25 calls IndexPager::getBody()/li liDispatch.php line 55 calls TalkpageHistoryView::show()/li liDispatch.php line 180 calls LqtDispatch::talkpageMain()/li li- line - calls LqtDispatch::tryPage()/li liHooks.php line 158 calls call_user_func_array() in /www/w/includes/GlobalFunctions.php on line 3274 -- 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 25384] New: It seems that the extension is not compatible with lists.
https://bugzilla.wikimedia.org/show_bug.cgi?id=25384 Summary: It seems that the extension is not compatible with lists. Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: SyntaxHighlight (GeSHi) AssignedTo: soxre...@gmail.com ReportedBy: cemalsur...@hotmail.com Created attachment 7713 -- https://bugzilla.wikimedia.org/attachment.cgi?id=7713 The parsed code with the splitted layout. Previously, I was using GeshiCodeTag.php and decided to switch to SyntaxHighlight_GeSHi due to the fact that it was supported widely. I heavily use listed descriptions in my wiki such as: We'll assume we're continuing from [[Installing mediawiki]]. #Create the directory for the new wikis #:codecd /wikifarm/ sudo mkdir wiki1 /code #Create the specific directories #:codecd wiki1 sudo mkdir images config sudo chmod a+w config /code #Link the source files from the main wiki #:codesudo ln -s /wikifarm/wikimain/* . sudo ln -s /wikifarm/wikimain/config/index.php config/ /code but when I tried to adopt it by replacing the code,/code tags with syntaxhighlight lang=bash,/syntaxhighlight it produced erratic results as captured in the attached file. If the block is a one-liner, the fontsize of the option links (i.e., page/discussion/edit/...) gets smaller and disoriented -- it the block is multi-lined it gets worse, with the layout becoming splitted. I repeated this error on the wikipedia (in the Sandbox page) to make sure that it wasn't my system configuration related. With my best regards, Sururi -- 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 25384] It seems that the extension is not compatible with lists.
https://bugzilla.wikimedia.org/show_bug.cgi?id=25384 --- Comment #1 from cemalsur...@hotmail.com 2010-10-01 13:03:40 UTC --- Correction: In the sandbox, the layout doesn't get distorted but the multi-lines still aren't supported. -- 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 25385] New: Invalid talk pages created before specific talk namespace was created showing up in search results
https://bugzilla.wikimedia.org/show_bug.cgi?id=25385 Summary: Invalid talk pages created before specific talk namespace was created showing up in search results Product: Wikimedia Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: General/Unknown AssignedTo: wikibugs-l@lists.wikimedia.org ReportedBy: pi...@hot.ee In Estonian Wikipedia portal namespcae (Portaal:) was used before it was actually created and therefore its talk pages were in regular talk namespace (Arutelu:Portaal: despite current namespace Portaali arutelu:). Now such initial talk pages show up as search results and give an error when clicked (eg http://et.wikipedia.org/w/index.php?title=Eri%3AOtsimineredirs=1search=Arutelu%3APortaal%3AMuusikafulltext=Searchns0=1). Could these results be somehow made accesible again by moving Arutelu:Portaal:... pages to current namespace Portaali arutelu: or just removed? 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 25305] Make an ultra-autoblock option
https://bugzilla.wikimedia.org/show_bug.cgi?id=25305 Kwon Yong-seok kyswiki...@gmail.com changed: What|Removed |Added CC||kyswiki...@gmail.com --- Comment #6 from Kwon Yong-seok kyswiki...@gmail.com 2010-10-01 13:23:58 UTC --- Korean Wikipedia is needed to this option. I think some people worry about this option because of abuse. But, this problem will be resolved by consensus. Only ultra-block option will be aroused under the consensus situation. -- 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 17390] Mailing lists need search function readded
https://bugzilla.wikimedia.org/show_bug.cgi?id=17390 Casey Brown b...@caseybrown.org changed: What|Removed |Added AssignedTo|fvass...@wikimedia.org |wikibug...@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 21928] oversight-l subscriber list error
https://bugzilla.wikimedia.org/show_bug.cgi?id=21928 Casey Brown b...@caseybrown.org changed: What|Removed |Added CC||b...@caseybrown.org AssignedTo|fvass...@wikimedia.org |wikibug...@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 15223] Bad unicode rendering in digest and mail send to name
https://bugzilla.wikimedia.org/show_bug.cgi?id=15223 Casey Brown b...@caseybrown.org changed: What|Removed |Added CC||b...@caseybrown.org AssignedTo|fvass...@wikimedia.org |wikibug...@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 25386] New: load.php outputs HTML on exceptions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25386 Summary: load.php outputs HTML on exceptions Product: MediaWiki Version: 1.17-svn Platform: All OS/Version: All Status: NEW Severity: normal Priority: Normal Component: Resource Loader AssignedTo: tpars...@wikimedia.org ReportedBy: maxsem.w...@gmail.com CC: roan.katt...@gmail.com It outputs the standard Internal error page. Probably, it should output something like /* Internal error: [error message] */ instead, but certainly not HTML. Discovered while investigating bug 25338. -- 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 25386] load.php outputs HTML on exceptions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25386 --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2010-10-01 15:58:07 UTC --- Note that we can only fix this to a certain degree. We can change what the exception handler outputs for load.php, but uncatchable fatal errors will still be output as HTML. -- 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 25320] Non-ASCII characters wreck mobile search
https://bugzilla.wikimedia.org/show_bug.cgi?id=25320 Dmitrij Rodionov di...@gmx.net changed: What|Removed |Added CC||di...@gmx.net --- Comment #2 from Dmitrij Rodionov di...@gmx.net 2010-10-01 16:39:06 UTC --- We have the same reports on ru.m.wikipedia.org. For example user tries to look for the article Хищники. Search page http://ru.m.wikipedia.org/wiki?search=%D1%85%D0%B8%D1%89%D0%BD%D0%B8%D0%BA%D0%B8 shows a page with an error message (Mobile Wikipedia is still under development and we are trying to correct our errors...) and then redirects to the main page of non-mobile page. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25346] Geo lookup causes mime type errors in Chrome
https://bugzilla.wikimedia.org/show_bug.cgi?id=25346 Ryan Kaldari rkald...@wikimedia.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Ryan Kaldari rkald...@wikimedia.org 2010-10-01 17:50:26 UTC --- fixed by Mark B. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 25386] load.php outputs HTML on exceptions
https://bugzilla.wikimedia.org/show_bug.cgi?id=25386 --- Comment #2 from Trevor Parscal tpars...@wikimedia.org 2010-10-01 18:12:42 UTC --- There's a comment in the code to this effect - it's on the todo list, thanks for filing a bug for 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 14977] $wgServer lacks brackets in IPv6 URLs
https://bugzilla.wikimedia.org/show_bug.cgi?id=14977 --- Comment #17 from Philippe Verdy verd...@wanadoo.fr 2010-10-01 18:23:56 UTC --- It would be much simpler if $_SERVER['SERVER_NAME'], which equals to 2a01:e0b:1:47:240:63ff:fee8:c3a, was simply replaced by adding surrounding square brackets very early every time it contains colons. My opinion is that a server name shoud always be delimited, independantly of where it is used. Then no more special code to test anywhere else... except if this value is used in a DNS resolver such as gethostbyname(), which may eventually fail if it does not accept the square brackets (my opinion is that such API should ALWAYS accept these brackets. So check for occurences of * gethostbyname(String name) or gethostsbyname(String name), which return one or several addresses (IPv4, IPv6, or other) from a hostname, using the locally configured name resolver (local hosts file, DNS, WINS, NetBios, or other service) so that it will reformat all IPv6 addresses in the returned set within brackets. Normally the returned addresses by this socket API are in binary format, but its PHP binding serializes it into a string, forgetting the bracket. However, in most installations of PHP, the variable is set by Apache in an environment string, and Apache (and other servers like IIS, or ISAPI and other interfaces) also forgets to adds the brackets for IPv6 addresses (there's an old bug about this, this was not changed because now too many applications expect to detect themselves the colons and add the brackets automatically : we should alsp do the same, by using these APIs indirectly via a proxying compatibility function). * gethostname(sockaddr_t address), which attempts to retrieve a hostname from the specified address (in binary IPv4 or IPv6 format, or other). The API normally expects an address in binary format (not restricted to IPv4 or IPv6 only, for example a NetBEUI address which is a short ASCII-only string). In all cases, the occurences of : or / in a canonical hostname (as used in the socket API or received from the webserver API or environment variables) should be blackboxed by inserting it within brackets, otherwise if these characters are not present, then NO surrounding bracket should be present. The algorithm is described in the RFCs describing URI formats and how to encapsulate a hostname into a valid URI. Note: MediaWiki should NOT be restricted to be used over Internet, it should be compatible with various network protocols to reach the webserver, not just IPv4 or even IPv6, so it should be neutral about which address type is effectively used: it should even work over a LAN with NetBEUI addresses (with the additional convenience that network datagrams not using an IP protocol are easily firewalled, without complex rules, or within a completely separate domain administration, as NetBEUI addresses will not pass through any router, unless it is proxied or transported over a private tunnel, usually secured and encrypted). So solution is effectively to blackbox the content of $_SERVER variable, i.e. the environment variables set by web servers (or FastCGI slave servers) when instanciating PHP, or the socket APIs used through the PHP APIs, before even setting our $wgServer variable from these values. -- 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 #18 from Philippe Verdy verd...@wanadoo.fr 2010-10-01 18:50:25 UTC --- Note to Allen: your regexp test is too much complex, and not sufficient: * any occurence of a colon (:) or slash (/) or question mark (?) or number sign (#) in the hostname should enforce the brackets to be added to surround it. * and if the hostname already contains brackets anywehere (except at the start and end only), these characters should be URI-encoded (this may occur in other transport protocols than IP, such as NetBEUI, possibly also AppleTalk, Token Ring, and various OSI/ISO transport or link layers). Yes we know that most networks have adopted the IP protocol, including for their private LAN (because of the ease of deployment and compatibility with routers, proxies, tunnel servers, firewalls, and network administration tools, also because this protocol is the most widely scrutinized one for security and performance tuning, and supports in the widest range of devices... But these protocols continue to exist in limited private domains. There's even a way to reach a server on the link layer only (using an Ethernet address to enforce the link-local only restriction): an Ethernet address also typically contains colons (it's a 48-bit address also formatted in hexadecimal 16bit blocks), and such topology does not use any port number (instead it uses a protocol number). I know one example of private network where the IP protocol is reimplemented using a private protocol number over Ethernet, in that case URL formats are like this: eth://[C000::]::80/path where C000:: is the Ethernet address, the private protocol number used, and 80 is the port number used in that protocol. For this case, the $_SERVER[SERVER_NAME] contains C000:: (remapped to [C000::] in applications), and $_SERVER[SERVER_PORT] contains :80. To deploy such protocol, one needs to use raw sockets that are administratively restricted in OSes, so that they will check the protocol number used (to avoid collisions with IPv4, IPv6, and a few other wellknown protocols such as ICMP or gateway-to-gateway protocols or router administration protocols, for which the standard socket layer should be used instead), before deciding what to do with the rest of the port specification). -- 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 25248] API: paraminfo errors
https://bugzilla.wikimedia.org/show_bug.cgi?id=25248 --- Comment #8 from Reedy s...@reedyboy.net 2010-10-01 19:08:09 UTC --- Interesting, on ApiUserrights, disable PARAM_REQUIRED on user, and get error code=unknownerror info=Unknown error: ``#039;#039; xml:space=preserve -- 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 25248] API: paraminfo errors
https://bugzilla.wikimedia.org/show_bug.cgi?id=25248 --- Comment #9 from Reedy s...@reedyboy.net 2010-10-01 19:14:54 UTC --- And this goes back further, it occurs in 1.16 Userrights didn't exist in 1.15 -- 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 25338] Resource loader: incorrect input to makeList()
https://bugzilla.wikimedia.org/show_bug.cgi?id=25338 --- Comment #2 from Max Semenik maxsem.w...@gmail.com 2010-10-01 19:42:17 UTC --- [19:44:20] MaxSem Nikerabbit, can you check server logs if their user agents are the same? [19:46:24] +Nikerabbit MaxSem: firefox [19:46:29] MaxSem ugh [19:46:54] *rakkaus* [01-Oct-2010 15:46:48] /w/load.php?debug=falseamp;lang=pt-bramp;modules=translate-cssamp;only=stylesamp;skin=modernamp;version=20100909T150640Z: Exception: DatabaseBase::makeList: empty input [19:47:07] +Nikerabbit MaxSem: referer is http://translatewiki.net/w/i.php?title=Special%3ATranslatetask=untranslatedgroup=ext-0-wikimedialanguage=ruelimit=1000 [19:47:31] +Nikerabbit okay that one was ie 6.0 [19:47:41] MaxSem every page seems to generate this very link [19:47:55] +Nikerabbit referer http://translatewiki.net/wiki/Portal:Th [20:35:56] MaxSem I think I can fix this bug, but I would like to narrow down the cause of such broken requests [20:37:23] +Nikerabbit MaxSem: broken clients most likely [20:37:36] MaxSem FF is broken? [20:37:39] MaxSem doubts [20:38:05] +Nikerabbit can't think of any other good explanation [20:38:34] MaxSem and this happens only with modern skin [20:48:48] +Nikerabbit MaxSem: are you sure? [20:48:58] +Nikerabbit it's the default skin [20:54:11] MaxSem http://translatewiki.net/wiki/Special:UserOptionStats/skin [20:54:21] MaxSem it's popular but not universally used [21:01:10] MaxSem all such errors I've found in my IRC logs are for modern [21:01:50] MaxSem mhm [21:04:50] MaxSem I vaguely recall I had problems with css/js not loading some time before. not sure if they disappeared after I switched from modern to vector [21:05:04] MaxSem could be due to this bug [21:05:49] +Nikerabbit I doubt that, we've had many other problems too -- 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 25023] show the protect-log, when the user have no permission to create the page
https://bugzilla.wikimedia.org/show_bug.cgi?id=25023 Umherirrender umherirrender_de...@web.de changed: What|Removed |Added Attachment #7689|0 |1 is obsolete|| --- Comment #6 from Umherirrender umherirrender_de...@web.de 2010-10-01 19:49:09 UTC --- Created attachment 7714 -- https://bugzilla.wikimedia.org/attachment.cgi?id=7714 New patch, which the same changes Sorry, I do not see any difference, but I have create a new patch, which the same changes. I hope it is better. -- 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 25248] API: paraminfo errors with certain modules
https://bugzilla.wikimedia.org/show_bug.cgi?id=25248 Reedy s...@reedyboy.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|API: paraminfo errors |API: paraminfo errors with ||certain modules --- Comment #10 from Reedy s...@reedyboy.net 2010-10-01 20:13:00 UTC --- r74098 -- 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 25387] New: Add a live preview link in the Central Notice interface
https://bugzilla.wikimedia.org/show_bug.cgi?id=25387 Summary: Add a live preview link in the Central Notice interface Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: CentralNotice AssignedTo: rkald...@wikimedia.org ReportedBy: tf...@wikimedia.org With the new banner loader override it would be helpful to have a link to the live site so that we can easily move between Central Notice Special page and then live preview. -- 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 25388] New: Deployment checklist for November 2010 Pending Changes release
https://bugzilla.wikimedia.org/show_bug.cgi?id=25388 Summary: Deployment checklist for November 2010 Pending Changes release Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: FlaggedRevs AssignedTo: ro...@wikimedia.org ReportedBy: ro...@wikimedia.org CC: jschulz_4...@msn.com, innocentkil...@gmail.com Blocks: 25293 We need a checklist similar to the checklist for Pending Changes: http://wikitech.wikimedia.org/view/FlaggedRevs_setup/enwiki The checklist for the upcoming deployment shouldn't be nearly as complicated, but we still need to make sure we've thought of everything. One thing we missed last time: checking all of the other wikis to make sure they stayed up after we deployed. -- 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 25293] Pending Changes November 2010 (tracking)
https://bugzilla.wikimedia.org/show_bug.cgi?id=25293 Rob Lanphier ro...@wikimedia.org changed: What|Removed |Added Depends on||25388 -- 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 25389] New: Flagged revisions information box overlaps the article making it impossible for non-js users to read the article
https://bugzilla.wikimedia.org/show_bug.cgi?id=25389
Summary: Flagged revisions information box overlaps the article
making it impossible for non-js users to read the
article
Product: MediaWiki extensions
Version: any
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: Normal
Component: FlaggedRevs
AssignedTo: ro...@wikimedia.org
ReportedBy: bawolff...@gmail.com
CC: jschulz_4...@msn.com, innocentkil...@gmail.com
This is based on a complaint made in #wikinews on irc by eboettcher
Problem: When users have javascript disabled, stuff should fail gracefully. The
flagged revisions information box that is normally collapsed by default, is
expanded (permanently) for non-js users, and overlaps the article text. Thus
preventing non-js users from reading the article.
This could potentially be fixed by display:none'ing the box, and having js
changing it back to display block so that non-js users don't see it at all, or
potentially by not using absolute positioning so that the article is redrawn
around the expanded box.
On wikinews we added the following css to mediawiki:Common.css
div#mw-fr-revisiondetails {position:static; border-top: none}
div#mw-fr-revisiontag { border: none}
div.flaggedrevs_short_basic { text-align:right; border: 1px solid
#CC;padding:1px;}
There's also a screenie of the problem at
http://img440.imageshack.us/img440/654/flaggedrevsbeingstupid.png
--
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
