[00:00:20] is there a way to rename an image despite reuploading it with a different name? [00:01:17] a bot to do this would be nice. (if it would fix all links to the image as well). [00:02:07] can anyone point me in the right direction n how to install a new style to the mediawiki? [00:02:19] !skins | newrkv [00:02:19] --mwbot-- newrkv: Overview: . Skin usage: . Gallery of CSS styles: . Writing your own: [00:02:30] !css | newrkv [00:02:30] --mwbot-- newrkv: To change styles for your wiki, go to one of the MediaWiki:xxx.css wiki page and put your custom styles there (sysop/admin rights required). MediaWiki:common.css is for all skins and should be used for content styles. MediaWiki:monobook.css is for the MonoBook skin (default), etc. For more information, see !skins and [00:02:59] jamasi: Nope, renaming images isn't possible. [00:03:05] I'm not aware of any extensions to do it, either. [00:03:44] hmm, wouldn't that be very useful for wikicommons? [00:04:14] A lot of editors would drool over it, yes. [00:04:35] I guess it just needs someone to change the code. :) [00:05:02] for starters a bot/script would be sufficient, I suppose. [00:05:09] Pathoschild: a rewrite of the media backend is in the works, afaik [00:05:54] Whee. [00:06:18] "in the works" [00:06:29] Maybe for a very loose definition of that term. [00:07:09] E.g., "nobody's worked on it for months except VasilievVV, whose commits so far have gotten either reverted or disabled" [00:07:14] *for alternate universe definitions of "in" and "works", and possibly "the" [00:07:35] It's remarkably tricky to do image redirects properly when so much code assumes their nonexistence. [00:07:41] Lots of things you have to consider. [00:07:56] Of course, image redirects are more or less a prerequisite to image moves. [00:08:13] Which is why I discuss them. If you don't need redirects, moves could be hacked on somewhat trivially. [00:08:15] I thought Tim's work was meant to be more radical [00:08:20] might be better to do transparent redirects [00:08:23] Well, yes, but he's not working on that now. [00:08:30] have them, for all client side purposes, be a 'copy' [00:08:31] He's working on the parser. [00:08:41] Splarka, ugh. [00:08:50] except for Special:ImageRedirects listing them for movement [00:08:52] Actually, what might be a good idea is allowing moves without redirects. [00:09:00] I suspect the Commons people would love that. [00:09:12] and when deleting them, they'd not delete, just remove the symbolic link [00:09:13] Even without the redirect part, that is. [00:09:20] Although if they got redirects they'd *really* love that. :) [00:09:23] That's the first thing I did in my personal wiki, hack MovePage so it didn't create redirects [00:09:26] heh [00:09:52] Special:Copyimage and Special:Moveimage, and then ditch any attempt at redirects [00:09:56] Well, a 'copy image to new name' would be pretty good. Then you can just copy to the new name, update pages, and delete the old version. [00:10:06] Splarka, interesting thought. [00:10:17] "Warning, image is still in use, use Copyimage instead" [00:10:18] Of course we don't have support for copying *pages*; [00:10:19] . [00:10:33] It would be a bit odd to allow it for copying image pages only. [00:10:35] better to wait until non-deleted files are stored by hash name on back end [00:10:38] then you don't have dupes [00:10:51] Simetrical: would there be some reference between the copy and original? [00:10:52] ^er hash of contents [00:11:13] DavidSeymore, in what case? You could always add one manually, or put it in the image history, etc. [00:11:32] Splarka: How would that work when an image is updated? [00:11:45] Splarka, that would just result in not wasting storage, it seems to me, it wouldn't affect front-end issues. [00:11:54] *shrug* [00:11:55] I like the idea a whole lot.. but could see where it would become a mess if a 'move' was left half done.. and no one knew which way the move was going [00:11:58] not my job to figure it out ^_^ [00:12:20] copying an image could copy the top version of image as well as copying the logs, but... [00:12:39] DavidSeymore, it would obviously be logged. [00:12:42] it would not copy the history of the description page, it should probably just copy the top version and create a new revisionid and curid [00:12:57] (and Moveimage would move that description probably) [00:13:00] Simetrical: cool cool [00:13:27] moving images would obviously have to be a special permission, especially if no redirects were left behind to block vandalism replacements [00:13:43] move "george bush.png" -> "george bush2.png" [00:13:43] DavidSeymore, I'm not saying anyone will do this, you realize. [00:13:48] move "penis.png" -> "george bush.png" [00:14:06] Actually this might be better as an extension, on the logic that temporary hacks should go in extensions. [00:14:08] Like Oversight. [00:14:18] It's an interesting thought. [00:14:21] Splarka: eeek [00:14:24] Special:Copyimage would probably suffice. [00:14:25] Simetrical: yeah, but its a good idea [00:14:32] That way you have no permissions issues. [00:14:38] Since nobody's affecting the old image. [00:14:49] restrict to 'sysop' or maybe possibly vaguely 'bot' [00:14:49] Of course it's still a pain, but much less so than now. [00:14:55] Splarka, no need, for copying. [00:15:07] The image already exists and is already acceptable, so there's no harm in *anyone* copying it. [00:15:09] for moving, I am talking 'boot, read my context! [00:15:13] *Splarka growls [00:15:16] *Simetrical growls back [00:15:17] make image moves leave redirects and don't let people move an image under a name that already has an image without special privileges [00:15:31] darkcode, implementing redirects is the hard part. [00:15:34] copying would just check for permission 'upload' of course [00:15:48] Which is why we're discussing hacks to allow partial improvements as a stopgap measure. [00:16:08] Splarka, it doesn't even really need to check for that, in principle. It may as well have its own permission, but it should be set 'user' by default. [00:16:17] (If not '*', but that causes issues for logging.) [00:16:29] 'upload' 'upload-url' 'upload-copy' ? [00:16:30] Anyway, this sounds like an easy extension. Maybe I'll even write it. [00:16:32] or whatever they are [00:16:35] Sure. [00:17:55] seems unnecessary but probably good to be able to limit it when 'tards start copying 20 meg jpegs on commons [00:17:55] Simetrical it shouldn't be that hard, can either follow the redirect like is done for templates, or have the process of moving a imagine also create symbolic links [00:18:32] darkcode, it's not so simple to do it The Right Way. You can look at VasilievVV's recent image redirect commit and Brion's disabling of it by default. [00:18:49] !r 29858 [00:18:49] --mwbot-- http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=29858 [00:19:06] !r 29870 [00:19:06] --mwbot-- http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=29870 [00:20:47] I can also see why it was probably reversed, looks like it allows for infinity redirecting, not good. should only allow single redirects like for everything else [00:23:15] symlinks that pointed to the current location transparently wouldn't be so bad... except that people might continue to use the old version indefinitely, not knowing it was moved [00:23:23] foo.jpg -> bar.jpg [00:23:40] but say bar.jpg -> baz.jpg, you'd go back and update foo.jpg -> baz.jpg server-side [00:26:56] http://meta.wikimedia.org/w/index.php?title=Migration_to_the_new_preprocessor/how_to_test&curid=112202&diff=842198&oldid=841492 [00:27:13] in my day, "hacking" meant more than editing unprotected pages that anyone can edit [00:34:09] Splarka: you're dating yourself ;) [00:34:23] both meanings of hack are old ;p [00:36:26] hacking means to change, to improve on something, as well as to gain access to something for self-curiously and educational pursuit. [00:36:35] *darkcode refuses to acknowledge any other meaning ;p [00:37:16] 03(NEW) Some edits only show when logged in. - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12696 normal; normal; MediaWiki: General/Unknown; (brett) [00:38:11] darkcode is dating himself even further back [00:39:02] 03(mod) Some edits only show when logged in. - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12696 +comment (10brett) [00:39:10] 70s: improve, 80s: dial lots of phone numbers with your 300 baud hayes and start a nuclear war, 90s: crack into the federal reserve database and steal $1 billion, 00s: edit a wiki page [00:44:22] I thought the 90's meaning was "to point and click on a icon in order to steal $1 billion from the federal reserve database" [00:49:47] *Simetrical is still impressed that the Matrix made some attempt at plausibility with their power-plant hacking scene in whichever one that was [00:50:20] (Of course, that's more than negated by their failure to elsewhere observe, e.g., the first law of thermodynamics.) [00:50:49] it was the matrix laws of thermodynamics don't apply [00:51:32] No, I'm talking about the real-world part, with the robots enslaving humans to get energy from their body heat. [00:51:58] how do you know it was the real-world? could of been another layer of the matrix [00:52:31] Well, the way I look at it, it certainly wasn't in the real world, it was in a movie. [00:52:42] Doesn't stop it from pretending to be a portrayal of the real world in the future. [00:53:09] well maybe in the future the real-world is just another layer of the matrix ;p [00:53:46] and the only reason they called it the real-world is because they didn't realize it was another layer of the matrix [00:54:14] 13th floor syndrome [00:55:41] woulda been more believable to say that humans irradiated the world's supply of (some element needed for AI chips) and the AIs had to turn human brains (or the offduty cycles) into part of their giant processor [00:56:31] would have made much more sense in the "we require many enslaved connected humans" and "we needed their brains active and fooled" [00:59:47] Irradiation doesn't much affect stuff like computer chips, does it? [00:59:58] Anyway, you can always purify it, you just have to filter out the radioactive material. [01:00:58] You could just say that the robots didn't want to kill the humans because they were nice? [01:01:36] Humans cut off the solar light, and presumably humans make better power plants than nuclear or hydroelectric plants. [01:02:48] Why can't the robots un-cut-off the solar light? They have to be at least as technically sophisticated as the humans to pull the whole plot off. [01:03:42] 03(mod) Orphaned pages and other special pages do not show pages in custom namespaces - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12689 +comment (10voyagerfan5761) [01:04:15] The human filled the atmosphere with some undefined opaque gas that spread and covered the globe. I'm guessing the robots felt it was more appropriate to torture the humans for a few centuries until it dissipated, [01:04:20] humans*. [01:05:40] It looked like ordinary cloud cover to me. [01:05:41] Microsoft won't support Theora because of the patent risk [01:05:52] so let's use H.261 [01:06:00] Theora is patent-encumbered? [01:06:21] Let's use a timed sequence of BMP files. [01:06:23] No patents there. [01:06:24] well, it was published in about 2001, so yeah [01:06:45] but the first revision of H.261 was approved in 1988 [01:06:59] so that makes it 20 years this year [01:07:13] that means any patents regarding it would have expired [01:07:36] a timed sequence of BMP files uses a lot more bandwidth than H.261 [01:08:08] H.261 is a DCT-based compression method with inter-frame coding, just like every codec that followed it [01:09:35] I'm not kidding [01:11:06] TimStarling: hi! is there any quick way of having parserdifftest not output 2 side-to-side columns? [01:11:35] patch it [01:11:58] I wouldn't dare [01:12:07] well you're stuck then [01:12:21] hmm [01:12:47] thanks anyway :) [01:12:53] TimStarling: I'd like to run a proposal by you, if you have a sec [01:13:03] H.261 has motion compensation as well [01:13:11] so basically everything theora has [01:13:25] .page-Special_ParserDiffTest .pdt-side-by-side td {display:block; width:100%} [01:13:27] sorta works [01:13:30] carl-m: yes? [01:14:08] Splarka: if it's a .css-only hack, I might try it locally. thanks [01:14:28] BrokenArrow: doesn't make them full width, just stacks them, heh [01:14:35] TimStarling: we keep running into the following situation on enwiki: we would like to transclude a page if it is smaller than a cetain size, and link to it otherwise. There's no way to achieve this right now as ar as I know. The question is whether any solution to it is feasible [01:15:22] ooh but that works... [01:15:48] BrokenArrow: .page-Special_ParserDiffTest .pdt-side-by-side td, .page-Special_ParserDiffTest .pdt-side-by-side th, .page-Special_ParserDiffTest .pdt-side-by-side col {display:block; width:100%} [01:16:11] Splarka: nifty! in common.css? [01:16:25] if you wanna get stabbed, sure [01:16:32] but if not, put it in your user/skin.css [01:16:42] carl-m: sounds feasible to me [01:16:43] it is horribly ugly [01:16:45] {{#ifsize:10|{{template}}|[[Template:template]]}} [01:16:57] maybe [01:17:00] TimStarling: how would you implement it? [01:17:16] Splarka: not on en.wiki :) [01:17:20] with a parser function [01:17:28] and unconditional registration in templatelinks [01:18:02] ok. with a limit, like ifexists? or is there a way to combine the queries somehow? [01:18:40] I just mean a parser function to do the whole job [01:18:54] check the size, and do the link or transclusion [01:19:27] probably a day's work for an inexperienced programmer, maybe half a day for someone experienced in MediaWiki [01:19:29] would this be combinable with labeled section transclusions? [01:19:34] TimStarling: I will see what I can do [01:19:44] Splarka: no [01:20:41] {{#transclude:{{pagename}}|conditions|failure}} where conditions might be: section=name, size > foo, size < foo, mmm, complex [01:20:59] Splarka: the main use we need on enwiki is size < limit [01:21:02] *Splarka giggles [01:22:13] TimStarling: should it be a new parser function, or part of ParserFunctions.php ? [01:22:17] new file [01:23:53] with transclude parser function might as well make one of the conditions a test for existence and make #ifexists obsolete [01:24:34] well, size > 0 is almost the same thing [01:24:44] dark: #ifexist:media is also handy for "no image exists for this, you can upload one" [01:24:49] that's why I was concerned about load [01:27:41] carl-m: ParserFunctions I guess, or maybe LST [01:29:59] Hello, I'm trying to find out how to change the default time in Mediawiki 1.11.0. As {{CURRENTDAY}}, is inaccurate for everyones timezones that use my wiki. [01:30:29] Same, goes without saying, for {{CURRENTHOUR}} [01:31:38] what version of mediawiki? see http://meta.wikimedia.org/wiki/Help:Magic_words#Local_time (these can't change by user's prefs, really) [01:31:45] [h261 @ 009C7B20]The specified picture size of 352x480 is not valid for the H.261 codec. [01:31:45] Valid sizes are 176x144, 352x288 [01:31:53] that's a bit of a catch, isn't it? [01:31:55] It's 1.11.0 [01:34:28] Well, that seemed to do the job. [01:34:59] Splarka maybe it make more generic then like {{#page:{{pagename}} or [[pagename]]|condition|failure}} [01:35:03] Also, the information provided on that page I had been unable to find regardless of what I searched for, thank you. [01:35:07] err maybe make it [01:35:24] hmm [01:35:54] PCOA: it isn't very intuitive is it [01:37:18] No, it isn't. [01:37:27] darkcode: maybe something that is just for getting page properties [01:37:37] yes [01:37:55] #ifexpr:{{#page:size|template:foo}} [01:38:03] *Splarka shudders internally [01:38:10] Splarka: I tested out my own wiki with a page name, even with all namespaces searched, it still couldn't find the page until I type in either the last word, or the full page name. [01:38:48] could fix bug requests too like being able to get the revision time of a template, rather then the page its transcluded in if it were done [01:38:50] Prefixindex is handier than Search, I find [01:40:00] darkcode: isn't it fun inventing syntax and making devs write it? ^_^ [01:40:04] Splarka: Tried that, worked perfectly. Be nice if that was merged later on in another version. [01:40:51] Splarka, I never said I expected someone else to do it ;p [01:41:07] {{#if:{{#page:topeditgroup="sysop,bot,bureaucrat,emailconfirmed"|template:foo}}|{{foo}}|[[template:foo]]}} [01:41:36] fun for me then [01:44:56] it would also be fun of the new preprocessor that Tim is working on catched results of each run of running parser function and tag parsers [01:45:20] so that they could speed things up by not having to run them away for repeated requests that are identical [01:47:28] parser functions are not memoized [01:48:04] but there is an empty argument expansion cache [01:48:21] so if you call a template multiple times with no arguments, then it's only expanded once [01:48:58] the idea is do that for any that identical not just for no arguments [01:49:30] yes, that's called memoization [01:49:38] I know [01:49:47] but the DOM tree structure doesn't have a fast equality operation [01:50:15] so comparing arguments may well be slow [01:50:39] it can test for identity, but not equality [01:50:52] I mean before you can pass something off to an extension you have to parse out the name of the parser to know what extension its passed off to and parse the arguments to let the function that handles it know what to do [01:52:15] well, you need to know the name, but you don't need to expand the arguments [01:52:29] with SFH_OBJECT_ARGS, arguments are passed through without being expanded first [01:52:46] so something like if ($parsercache[$parserhook . "|" . $parse_args]) $parsercache[$parserhook . "|" . $parse_args] else call_parser_function_hook() [01:52:48] You could maintain a cache at the level of the function that returns a wikitext value for a given template call. [01:52:58] Which I assume there must be one of, somewhere. [01:53:18] cache invalidation would be a pain [01:53:22] Simetrical: separately in every function? [01:53:46] TimStarling, I don't know the function names. The way I'm envisioning it, it would only be one function. [01:53:51] Of course a per-request cache might not be worth it due to the low hit rate, and a global cache seems like it would have a very high overhead. [01:53:58] anyway, I don't know why you're all talking about caching without ever having looked at the profiling [01:54:09] So this isn't necessarily useful even in theory. [01:54:13] Simetrical a lot of functions maintain a cache already of there own if the call is expensive, the idea is to enforce it at the parser level rather then the extension level [01:55:10] darkcode: a lot as in #ifexist? [01:55:12] which other one? [01:55:21] I think he means functions generally. [01:55:25] Not parser functions specifically. [01:55:36] E.g., the wfMsg() functions. [01:55:37] one thing you have to understand about the parser is that it's as much memory constrained as it is time constrained [01:55:42] so you have to be careful about what you cache [01:56:10] yes I mean functions generally [01:58:59] what operation are you worried about exactly? [01:59:08] that you think is expensive? [02:00:51] I mentioned both parser functions and tag parsers as examples. I think most are probably expansive except for the very small ones [02:01:48] you mean like #if? [02:01:49] recomputing results takes more time then reusing results which have already been computed [02:02:32] can be if nested enough times [02:02:36] not necessarily [02:03:19] if you use so much memory that you send the computer into swap, just to achieve a 10% hit rate, you're probably not improving the speed [02:03:30] TimStarling: an issue that I have, that I ran into earlier today for a different reason, is that functions like getTemplateDom() hide the length of the template wikitext [02:03:34] I'm not suggesting you use a lot of memory [02:03:50] carl-m: store it in a different array [02:04:31] darkcode: memoizing all parser functions and template expansions could use hundreds of megabytes [02:05:09] I'm suggesting using a small amount that would only be valid during the page parsing and would become invalidated and reused after a page is finished being parsed [02:05:41] I don't know why I'm arguing about this [02:05:52] I'll review it when I see a patch [02:06:12] its not that important to me yet [02:07:31] it was just a thought in terms of like certain programming languages might do to optimize performance [02:07:44] treating wikitext like a programming language basically [02:10:14] hello [02:11:46] has anyone put the s5 web slideshow together with MW? [02:12:05] *AaronSchulz feels wovey dovey today [02:14:13] http://en.wikipedia.org/wiki/Special:Contributions/Bramlet_Abercrombie [02:14:20] 20:37, January 17, 2008 (hist) (diff) Jimmy Wales‎ (it is not a dispute between Wales and Sanger, but between Wales and all objective evidence) [02:14:27] TimStarling: that makes me giggle ;) [02:15:13] darkcode, memoization even for only one parser session would use at least a few megabytes more memory for pages with a moderately large number of templates, and the hit rate would be very low. [02:15:45] You could push off the memory and hit rate problems by using Memcached, but that adds probably unacceptable latency. [02:15:46] i have a hardcore n00b question [02:15:58] is this the place to ask it? [02:16:09] Notoriety: just ask [02:17:04] i'm having trouble with tables on a wiki i set up myself... how do i make it so that the etc. tags work? [02:17:29] Simetrical it could always only cache results that use less then a certain size, so that it speeds up "small" results [02:18:02] darkcode: I don't need you to evangelise about caching [02:18:11] we're all well aware of its existence [02:18:11] darkcode, which probably take only a little time anyway . . . the point is that according to Tim, who knows quite a bit about optimization and has presumably thought about this, it's probably not helpful in this instance. [02:18:19] Notoriety: I am faily new myself, but try this: copy the wiki code from a simple table and paste it into a test doc [02:18:31] s/optimization/optimization and the parser/ [02:18:43] all right [02:19:04] simple like an infobox? [02:19:07] or even more simple... [02:19:10] Notoriety: the wiki code for a table is way simpler than all those 's anyaway [02:19:48] oh, so i can just work around those? [02:19:56] Simetrical, I'm sure Tim has, I wasn't suggested that Tim hasn't or doesn't know what he's talking about, it was just a thought [02:19:58] Notoriety: copy from my wiki if you like : http://bsdtips.utcorp.net/mediawiki/index.php/Freebsd_equivalents_for_linux_commands [02:21:54] darkcode, sure, nothing wrong with suggestions. But when the person in charge of the relevant component repeatedly says flat-out it's not useful, it's probably not helpful to continue arguing for very long unless you're prepared to write up a test implementation and benchmark it. [02:21:58] Just a remark. [02:22:02] *Simetrical shrugs [02:22:06] okay thanks [02:22:10] i think i can figure it out from here [02:23:18] Simetrical I had stopped when Tim mentioned he didn't know why he was arguing this, until you commented on it further. [02:25:22] *AaronSchulz devient nerveux [02:38:20] 03(mod) Special:Userlogin?type= signup should have an internal link to it - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=11897 (10dan_the_man) [02:39:03] 03(mod) requesting Special:Userlogin shortcode Special:Userlogin/signup - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12674 (10dan_the_man) [03:07:30] 03(mod) MediaWiki:Licenses/foo sometimes ignored when viewing Special: Upload&uselang=foo - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=11695 (10vinhtantran) [03:48:40] Simetrical: http://www.sciencebasedmedicine.org/?p=26#comments [03:48:48] man "pec" has me rofl [04:00:22] Hey, how do I edit the links on the sidebar? [04:00:24] what's the page for that? [04:02:45] 03(NEW) Serbian Planet is unreachable - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12697 normal; normal; Wikimedia: DNS; (shinjiman) [04:03:51] MediaWiki:Sidebar [04:05:36] thank you darkcode [04:23:33] what about the bottom part? [04:24:26] you can't edit the toolbox via a message, you'll need javascript or a server-side extension or hack [04:24:35] unless you just want to change the translation of the text [04:25:30] that's cool, I mean the very bottom where the image is but I remembered where it is thanks [04:25:50] ahh [04:25:55] Special:Allmessages is handy [04:26:21] as is: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/messages/MessagesEn.php?view=co&content-type=text%2Fplain [04:30:15] that's the one :D [04:32:51] I still can't work it out actually [04:33:00] how do I change the link to where the poweredby_mediawiki_88x31.png goes to? [04:38:02] 14(INVALID) Serbian Planet is unreachable - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12697 +comment (10brion) [04:41:11] Hello [04:42:57] Hi [04:43:28] I recently updated a Mediawiki and I have this all over my site Warning: Cannot modify header information - headers already sent by (output started at /home/content/a/d/m/admiralsmith/html/nxd/database/LocalSettings.php:1) in /home/content/a/d/m/admiralsmith/html/nxd/database/includes/WebResponse.php on line 10 [04:44:00] Moss: Do you have a closing ?> in your LocalSettings.php? [04:45:21] Yes, I do, I'm looking at the file now, but ion case I don't what should it be [04:45:21] Oh, wait, on line one. Moss: You have some whitespace at the head of the file it looks like, which will need to be deleted [04:45:34] And you should remove the closing ?> [04:46:09] Line one looks like [04:46:12] and then a space for line two [04:46:34] Hmm .. okay [04:46:47] how every there is no There shouldn't be [04:47:26] Can you remove the password / user info and pastebin the file? [04:48:25] Here you go URL: http://rafb.net/p/7iwC1e37.html [04:49:09] at the end of the page you should have ?> [04:49:34] on line 127 put ?> [04:49:34] Hmm [04:49:42] MiCCAS: No, you don't need that. [04:49:46] And it causes problems [04:50:04] MiCCAS: What modifications have you made to the file since the upgrade? [04:50:08] Nothing's sticking out at me [04:50:16] I have it for mine [04:50:17] ?> [04:50:27] check the permissions of the file? [04:51:51] MiCCAS: Well, they're unnecessary and prone to causing problems, as it causes a term of the php block and the rest of the file (if there is a rest, whitespace and what not) is then interpreted as HTML [04:52:28] weird.. I think I'm using an old copy of mediawiki anyway [04:52:29] maybe that's why? [04:52:46] Couls be .. we used to have them in all our files [04:56:10] So is there any way to get mines to work right [04:56:33] Moss: What changes have you made to the file since you upgraded? [04:57:32] Oh, after everything was loaded I went back into the file and turn $wgEnableUploads = true; [04:58:56] That's all you changed? [05:03:23] 03(mod) MediaWiki:Licenses/foo sometimes ignored when viewing Special: Upload&uselang=foo - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=11695 (10N/A) [05:04:07] Yea [05:04:41] Is that the entire file (minus uname's/passwords) that you posted? [05:05:03] The problem's in that file somewhere, but I'm not seeing it [05:05:25] Yes, that everything do you need to see WebResponse.php? [05:05:52] No, the error said output started at /home/content/a/d/m/admiralsmith/html/nxd/database/LocalSettings.php:1 [05:06:06] Which means that somewhere in LocalSettings.php output is being generated [05:06:19] You're absolutely positive there isn't a blank linke or something before the opening nope, Line 1 is 03(mod) Serbian Planet is unreachable - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12697 (10shinjiman) [05:10:07] Moss: Okay, can you quickly execute "php LocalSettings.php" and see if it produces any output? [05:10:21] how do I do that [05:11:00] Do you have shell access to the server? [05:11:16] I don't think so [05:11:25] How did you do the upgrade? [05:12:05] I make LocalSetting.old.php and updated the pages and such [05:13:17] Did you run the update script? [05:14:27] How do I do that, I used wiki before but I never done and update [05:14:48] Okay, what version did you upgrade from / to ? [05:16:16] 03(NEW) new parser function for conditional transclusion based on page size - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12698 15enhancement; normal; MediaWiki extensions: ParserFunctions; (cbm) [05:26:15] 03brion * r29964 10/trunk/phase3/ (RELEASE-NOTES math/render.ml): * (bug 12695) Suppress dvips verbiage from web server error log [05:26:39] 03(FIXED) texvc sends dvips output into the webserver error log - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12695 +comment (10brion) [05:27:20] 03(mod) MediaWiki:Licenses/foo sometimes ignored when viewing Special: Upload&uselang=foo - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=11695 (10ewenste) [05:28:11] sorry about that, my computer messed up [05:29:27] amidaniel: what was your last question? [05:33:39] Okay, what version did you upgrade from / to ? [05:34:03] 1.8 [05:43:48] 03(NEW) MediaWiki: Licenses message corresponding to purpose-specific upload forms - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12699 15enhancement; normal; Wikimedia: Language setup; (vinhtantran) [05:44:33] Splarka: Do you think you can help Smoss? His/her LocalSettings.php is producing accidental output and causing warnings [05:44:39] *amidaniel has to go take care of a few things [05:44:48] ami: nope, I am for the clients :/ [05:44:57] >:O [05:45:02] *Splarka knows zilch mysql, php, apache, greek [05:45:09] Liar [05:45:22] I can read pseudocode, but really, the FSM is hiding at svn.wikimedia [05:45:36] eg: looks like a cross between MeatBall and spaghetti code [05:45:52] Praise Him [05:46:54] rAmen [05:47:18] Hehe [05:47:38] 03(mod) MediaWiki:Licenses/foo sometimes ignored when viewing Special: Upload&uselang=foo - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=11695 (10vinhtantran) [05:50:30] So I somehow messed up [05:56:19] 03shinjiman * r29965 10/trunk/phase3/languages/messages/ (MessagesKk_arab.php MessagesKk_cyrl.php MessagesKk_latn.php): [05:56:19] * (bug 12145) Update Kazakh translations [05:56:19] Patch by AlefZet [05:56:21] 03(mod) Allow editor-control of order of cites expanded at "< references/>" - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12498 (10bill.mitchell) [05:56:23] 03(FIXED) Kazakh message updates - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12145 +comment (10shinjiman) [06:00:07] I'm guessing I should upgrade from 1.8.2 haha [06:02:30] Should I just dump my MySQL and reinstall it [06:25:31] 14(INVALID) Special:Export should mention multiple pages in one URL - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=9889 +comment (10brion) [06:49:13] 03vasilievvv * r29966 10/trunk/phase3/includes/ (ImagePage.php filerepo/File.php filerepo/LocalFile.php): Introduced File::getHistory(), which should be used instead of ugly nextHistoryLine() which is now deprecated [06:51:06] 03vasilievvv * r29967 10/trunk/phase3/includes/AjaxFunctions.php: Fix AJAX search caching on invalid titles [06:58:44] 03(mod) File histories should be paged, requires modification of File. php and friends - 10http://bugzilla.wikimedia.org/show_bug.cgi?id=12645 +comment (10vasilvv) [07:01:36] brion: what does "* Redirect behavior doesn't match between the image and the page" means? [07:02:19] VasilievVV: mm, for example if you go to Image:Foo page, it shows one thing (the target page), but if you embed [[Image:Foo]] it does something else (not following the redirect) [07:03:07] Ah... ok [07:03:55] brion: btw, can you enable $wgFileRedirects on testwiki? [07:04:15] sure [07:04:40] wow, someone *else* will be using it again? [07:04:49] *Splarka flooded off everyone else with parser tests [07:06:12] 03vasilievvv * r29968 10/trunk/phase3/includes/ (EditPage.php filerepo/FileRepo.php filerepo/LocalRepo.php): [07:06:12] Image redirects: [07:06:12] * Forbid users who can't create redirects when they are not allowed to upload files [07:06:12] * Move target namespace check from checkRedirect() to findFile() [07:07:32] VasilievVV: enabled on test [07:07:37]