for that navigation box [02:38:20] "Gadget usage statistics" seems sufficiently clear. [02:38:35] http://p.defau.lt/?BkcOd8l85mbzzrrZVTh9lw [02:39:05] Annemarie: think of the children! [02:39:15] I did. [02:39:20] They put me on parole. [02:39:32] !defaultsettings [02:39:32] --mwbot-- For the current version of DefaultSettings.php, see: . [02:39:51] luna6: ta, so Faq/contact? [02:40:00] yes [02:40:11] FAQ / Contact [02:40:22] I probably do the same with actors & actresses too... [02:40:34] #n-FAQ {display:inline;} [02:40:34] #n-Contact-Form {display:inline;} [02:40:37] however [02:40:46] this would break if you reanmed 'Contact form' to 'Contact' [02:40:53] because the ID attribute is derived from the text [02:41:01] then it would be #n-Contact {display:inline;} [02:41:12] also, there is no background image, hmm [02:44:20] #n-FAQ {display:inline;margin-left:.5em;margin-right:.5em;} #n-Contact-Form {display:inline;} isn't too bad [02:45:01] ok stupid question but where would I input that? (#n-FAQ {display:inline;margin-left:.5em;margin-right:.5em;} #n-Contact-Form {display:inline;}) ? [02:45:15] or you could simply: [02:45:16] #n-FAQ {float:right;list-style:none !important;} [02:45:24] oh, MediaWiki:Monobook.css [02:45:36] edit that, insert: #n-FAQ {float:right;list-style:none !important;} [02:45:41] see how that looks [02:45:47] (purge browser cache) [02:47:31] ok... my monobook.css looks empty .. also I am using a customized skin of monobook which is renamed ... [02:47:52] bah [02:47:57] sorry :) [02:47:58] put it in MediaWiki:Common.css then [02:48:07] it'll work, just be a bit redundant for skins that don't see it [02:48:19] to be safe: .portlet #n-FAQ {float:right;list-style:none !important;} [02:48:23] I gotta go, bbl [03:07:08] <\s> Hey guys, I have a very important error (fatal on the main page) to report. Fatal error: Call to a member function isCurrent() on a non-object in /home/groups/n/ne/neokiller/htdocs/w/includes/SkinTemplate.php on line 710 on bleeding edge svn [03:08:28] when just viewing the page or what? [03:09:26] <\s> OverlordQ: Just viewing [03:09:50] <\s> The overall wiki works, when logging in (bypassing the main page), but it's a big bug [03:10:10] any special extensions? [03:10:31] <\s> I have a custom home page (NeoKiller:Home) and run Extension:CodeReview [03:12:16] that happens on wikimedia too [03:13:00] <\s> TimStarling: Is it a simple problem, or something more serious? [03:13:48] so it happens when you view the main page? [03:14:52] <\s> TimStarling: Yes, http://neokiller.sf.net/wiki/NeoKiller:Home [03:18:44] can you try opening SkinTemplate.php in a text editor and then on line 710 replace this: [03:18:56] if ( ( $wgArticle->isCurrent() && $istalk ) || $wgOut->showNewSectionLink() ) { [03:18:58] with this: [03:19:04] if ( ( $wgArticle && $wgArticle->isCurrent() && $istalk ) || $wgOut->showNewSectionLink() ) { [03:19:41] <\s> TimStarling: One moment [03:23:47] <\s> TimStarling: Done, I'll just try it now [03:24:25] <\s> TimStarling: It appears to be working now [03:24:52] ok, I'll commit that [03:25:40] <\s> Wonderful :) [03:27:20] 03tstarling * r52149 10/trunk/phase3/includes/SkinTemplate.php: Fix fatal error. Logged on WM but exact cause uncertain. [03:29:35] <\s> TimStarling: I just svn up'd it, and now "Parse error: syntax error, unexpected T_SL in /home/groups/n/ne/neokiller/htdocs/w/includes/SkinTemplate.php on line 710" [03:29:48] heh [03:30:00] <\s> Tsk tsk, syntax errors from a top dev :) [03:30:22] it's probably a conflict marker [03:30:35] you should open the file [03:30:59] <\s> What would it look like? [03:31:06] >>>>>>>> or <<<<<<< or ------- [03:31:10] you'll know it when you see it [03:31:23] just look at the same line you just changed [03:32:28] <\s> Ah, all better [03:51:45] what's the creative commons rdf output supposed to look like? Article::getContributors has MySQLisms in it [04:20:56] Anybody around? [04:21:09] http://www.uncyclopedia.com is currently a GoDaddy parking page [04:21:26] i think you want #wikia [04:21:31] Oh, right [04:21:37] *EugeNetBooK is a few beers in [04:22:29] I think I may hang out here, anyway [04:34:41] can someone help with http://wiki.kahaf.com/index.php/Main_Page ? i had a look at: http://www.mediawiki.org/wiki/Project:Support_desk/Archive_11#Database_error and out of all those i just upgraded my Linux recently. [04:36:33] sounds like mysql was upgraded and the config changed [04:37:33] if you change innodb settings you'll get that [04:39:39] i disabled innoDB in mysql, there is a skup-innodb in my.conf somewhere... [04:40:05] uh, don't do that [04:40:22] although that doesn't look like a missing innodb error [04:40:35] (since that shouldn't cause connection failures..) [04:40:36] i just commented out that line and wiki starts working [04:40:39] great... [04:40:44] thanks everyone [04:56:20] 03(NEW) Make importDump.php handle bzip2 and 7zip - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=19289 enhancement; Normal; MediaWiki: Maintenance scripts; (Emufarmers) [04:57:00] Emufarmers: do you have any caching running for fanhistory wiki? [04:57:08] chuck: of course [04:57:31] what do you use? [04:57:54] Memcached, APC, and file caching [04:59:32] How about you? [05:02:20] Emufarmers: We use memcached, we have APC enabled, and we use Squid [05:02:55] Occasionally we have problems with Squid, though [05:03:58] I've tried setting up Squid a couple times, but it always proved to be too much trouble and there was never enough need to actually keep trying [05:04:55] Yeah, I think I might bypass Squid and have nginx serve the requests directly if I can't fix some of the really really strange slowness [05:05:18] pages will be slow, even after repeatedly trying to refresh then, then when I tack on ?prof=true (to force profiling), it loads perfectly... *facepalm* [05:05:27] Do you use nginx for everything, or just images? [05:05:52] everything [05:06:24] squid does cache images and skin assets, which probably helps [05:06:52] I use apache-worker; solved the memory shortage I was having with -prefork [05:07:17] on a VPS? [05:08:41] Yes? [05:09:32] do you have to use fastcgi with apache-worker? [05:10:01] Yes [05:10:03] 03(mod) Make importDump.php handle bzip2 and 7zip - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=19289 (10Emufarmers) [05:10:07] It's not as bad as it sounds [05:10:39] I have to use fastcgi with nginx, and it's kind of annoying [05:10:50] Actually, you probably *can* still use mod_php with -worker; it's just not supported (and apt-get made it easy to set it up with fcgi) [05:10:50] how many fastcgi processes can you spawn? (how much memory do you have total?) [05:11:04] 2GB [05:13:13] wow, how does laura affora that? [05:13:57] With prefork I had to keep MaxSpareServers at around 10, and still seemed to be having problems; with -worker now, StartServers is at 2, and ThreadsPerChild is at 25 [05:14:06] Ask her \o/ [05:16:18] How much memory do you have? [05:17:57] we have 540MB, and 16 php-cgi processes running [05:18:01] mysql is running on another VPS [05:18:16] I'm thinking of switching from Linode to Mosso, it's a lot cheaper to get more memory there [05:19:44] Uh, they don't seem to say how much memory you get [05:20:36] it's on their "Cloud Server" page [05:20:48] http://www.mosso.com/pricing.jsp ? [05:20:58] Oh, I see [05:21:08] http://www.mosso.com/cloudservers.jsp too [05:21:44] It's paid by the hour, but the server with 1GB of ram translates to $43.20 a month [05:22:17] Sounds too good to be true [05:22:36] heh, well it's run by rackspace, which is a pretty reputable company [05:22:47] hi all [05:22:51] Yeah, but Slicehost is owned by Rackspace now too [05:23:11] yep [05:24:02] Ah, wait a minute [05:24:07] you have to pay for bandwidth on top of that? [05:24:15] May I ask a quick question? Who know the command line to import an xml file please? [05:24:41] Mat__: importDump.php [05:24:52] Emufarmers: oh, really? [05:24:54] didn't see that [05:25:04] Emufarmers thanks [05:25:18] chuck: I didn't see it at first either. I think that's the point. :D [05:25:48] they're good at hiding how much their service costs :D [05:26:09] Well, VPSes are good because they tend to be very up-front about costs [05:26:19] tried this but doesn't work: php importDump.php [05:26:22] Cloud computing is probably going to be less so [05:26:44] because everything will be configurable, so there'll be 20 different things the price is computed from [05:26:53] Mat__: what's the error? [05:27:05] -bash: syntax error near unexpected token `newline' [05:27:15] Uh [05:27:26] You know you have to replace with the name of the file, right? [05:27:27] my file has spaces in its name [05:27:31] Oh [05:27:32] yes [05:27:35] Surround it in quotation marks [05:27:41] ok [05:27:52] Emufarmers: I think "cloud" is just a buzzword they're using, it looks like it's exactly the same as traditional VPS hosting [05:28:03] yowch [05:28:17] .22/GB out .08/GB in [05:28:28] chuck: well, in theory, you should be able to adjust everything on the fly. Of course, you can already do that with Slicehost (and linode, I assume) [05:28:47] although in theory you'd also be able to have whatever allotments you want [05:28:52] so 666MB or whatever [05:29:02] Although it looks like they don't let you do that :( [05:29:15] I'm not sure about SliceHost, but you have to migrate to a new host in the datacenter to upgrade to a newer plan. (smaller memory extras can be added without a migration, but it's not very desirable to do that) [05:29:17] but yeah, mostly buzzwordy [05:30:11] chuck: http://www.slicehost.com/questions#upgrade [05:31:17] that answer is a little vague, but I'm guessing that's exactly how Linode does it too [05:31:47] I think I'll stick with Linode for now, we're rewriting with Rails soon anyways, and we'll be hosting with lovely Heroku.com when that time comes [05:33:04] You're dumping MW? [05:33:16] Er, bad choice of words; ditching? [05:33:47] yeah [05:34:11] :( [05:34:19] Why? [05:34:43] It's a pain to upgrade, and the fact that we have to make an entire copy of the schema that has to be upgraded and all of that makes it really hard to implement some new ideas that we have for what we'd like to do next [05:35:06] :| [05:35:12] If it's that hard to upgrade, urdoinitrong [05:35:28] what do you mean? how can I do it any other way? :P [05:35:43] What do you use for your farm? [05:36:11] we have to keep a copy of the entire mediawiki schema for each site that we host. doing it any other way would require rewriting a lot of database infrastructure in mediawiki methinks [05:36:17] Emufarmers: our own scripts [05:36:39] Well, what about kim's thing? [05:36:57] Anyway, I don't see why that would make it hard to upgrade; just have a script that runs update.php for every site [05:37:09] kims thing would be even harder [05:38:26] that's what we do, but then when we want to install a new extension, we have to mess with the extension table variables. when we want to delete an extension, we have to do weird stuff to get rid of the scehma [05:38:30] *schema [05:38:58] Meh, that doesn't sound *that* hard [05:39:25] And if you're a slow like me, you'll just leave old schemata sitting in the database o; [05:40:50] *slob [05:41:36] Emufarmers: do I have to be in the maintenance folder to enter the command line importDump.php? [05:41:39] using multiple databases in just wrong in the first place. using rails will allow us to correctly make schema changes using migrations that will affect all the wikis at once without any fuss and extra variables that could go wrong that come with having 100s of copies of the schema laying around [05:42:04] Mat__: no, you just need to adjust the path accordingly [05:42:12] ok [05:42:22] php maintenance/importDump.php if you're in the directory above, for instance [05:42:28] Same goes for the target file [05:42:29] thanks [05:42:33] x2 [05:42:52] chuck: well, you could use prefixes, though those seem to be icky [05:44:24] 03shinjiman * r52150 10/trunk/phase3/languages/messages/ (4 files): Localisation updates Cantonese, Chinese and Literary Chinese [05:45:23] that would just remove the need for new databases to be created, the schema would still be duplicated 100s of times unfortunately :( [05:45:56] Emufarmers: thanks [05:46:00] np [05:46:30] Well, I don't know enough (or really anything) about Rails, so I'll have to take your word for it that it would be better :p [05:48:49] Well, basically instead of having multiple copies of the schema in different databases, I'd use keys like wiki_id that would separate the pages and stuff in the database [05:49:06] I don't know enough about DBA to know if that would perform well, though. I might ask domas about that. [05:49:57] chuck: different databases allow different indexing [05:49:59] I'm pretty sure every time I've seen DBA near MediaWiki it was marked with skulls and crossbones [05:50:24] also, easier to handle such things as partial replication, etc [05:50:47] domas: would it be bad, though, to have a table with many rows for all of the wikis? [05:50:50] er, actually, I was thinking of something else [05:50:56] oh, is that the fracturing thing or whatever it's called? [05:50:58] I've said already two reasons, you need more? [05:51:09] no [05:51:31] simply, different collations would not be available with single large table [05:51:42] it's easier to handle stuff like partial replication if I use different databases, or if I use one table? [05:52:16] if you use different databases [05:52:27] you cannot split replication streams by data in it, yet :)) [05:52:35] maybe could do with proxy [05:52:51] would need additional development [05:53:08] so it would be better to use a single database with a single set of the schema for all of the wikis, then use a index, right? [05:53:20] better for what? [05:53:50] well, better isn't the right word [05:54:04] i'm not really comparing it to anything, but would it be okay performance-wise to do that? [05:54:09] yes [05:54:19] would be slightly faster, even [05:54:26] or not [05:54:27] depends [05:54:29] =) [05:55:05] haha [05:55:08] say, many tables avoid table open serialization issues [05:55:16] but many tables also don't hit auto-inc contention on single table [05:55:28] so it is version specific stuff :) [05:57:32] I even showed someone how to do this without changing code too much [05:57:46] you can create views that depend on session variables;-) [05:57:52] I don't think the auto-inc would get too far out of hand [05:57:53] and then use triggers to fill those fields [05:58:15] On Twitter, yes, it got so high that it went higher than the limit of an integer, but in reality on a wiki or something, it shouldn't be as bad :P [05:59:14] anyway, manageability and flexibility are the issues [05:59:26] tell me why multiple tables is bad [05:59:50] (in context of 1000 wikis, not 100000 ;-) [06:01:58] emumarkers: what is wrong inside MW schema? :) [06:02:12] why would developers mark with skull and crosses? :) [06:03:23] It gets tedious to maintain the schema of 100s of wikis, and it would only get worse as we grow... For example, we have a script pieced together that runs update.php on all of the wikis with the correct parameters, but if an update.php fails on a certain wiki for whatever reason, we have to go through the whole output and figure out what was wrong, fix it, then re run the updaters. As I said above, we have to mess with $wgExtNewTables to ... [06:03:29] ... install new extensions, and then we have to write new maintenance scripts to remove extension schema changes. it just seems like there are more variables to go wrong when the schema is to be duplicated 100s of times and then managed and upgraded after that [06:04:04] isn't that problem of your scripts? :) [06:04:33] domas: my bad; I was thinking of DBA for object caching [06:04:36] it doesn't matter, 2 or 200 or 2000 [06:04:56] once you have multiple, you automate :) [06:05:16] Well, the WMF seems to manage somehow [06:06:58] I assume you have some set of scripts cobbled together too? [06:07:37] for wiki in $(..) :) [06:08:08] domas: I just think it would be a lot more maintainable to just add a new row to the wikis table and be able to reference to that rather than having to create a new database, insert the schema, and then run the updaters to install extension schema [06:08:34] Of course then we have the problem of removing stuff, but that's DELETE FROM (pages|revisions|whatever) WHERE wiki_id = 666;... [06:08:43] chuck: how does it work when you need different collation for different wikis? [06:08:50] e.g. germans want their umlauts sorted properly [06:09:10] hmm... [06:09:19] Hmm, 'course the WMF uses $wgConf and CentralAuth and other scary stuff [06:09:25] MySQL can't magically do that? ;-) :-( [06:09:36] do what? [06:09:44] provide different indexing schemes in single index? [06:09:49] sort stuff nicely even with special characters [06:09:50] no, it is simply impossible [06:09:55] it can sort stuff nicely [06:09:59] but in one collation [06:10:14] spanish collation is different from german [06:10:23] and lithuanians treat 'y' as 'i' when sorting [06:10:33] darn those lithuanians [06:10:35] MySQL magically does a lot of things, but it's usually stuff it shouldn't be doing ;) [06:11:07] chuck: I assume you looked at Extension:Farmer? [06:11:25] yeah. [06:11:33] chuck: and of course, how do you manage sharding with such tables %) [06:11:45] Wasn't up-to-snuff at the time? (though I don't know if it is even now) [06:11:54] and in wikimedia scenario sharding is quite complicated due to data distribution [06:14:28] Emufarmers: It looks nice for smaller setups, but I don't think it's something that we want to piggyback off of and try to extend [06:15:20] Now that I think about stuff closely, I guess it would be remotely possible to do it with MediaWiki, but I don't think it's worth it to bend the software so far and make it do things that it was never designed to do, it will crack eventually [06:17:43] Wikia doesn't seem to have cracked [06:18:51] Wikia is different, that's not really bending MediaWiki far because MediaWiki was meant to work that way [06:19:48] What's the difference between what you do and what Wikia does? [06:20:19] Nothing right now, but we don't want to stay in that market because we don't think it's very profitable at all [06:20:36] What are you going to be doing? [06:21:24] My goal with a new wiki engine is to make it easy for people or groups to register an account and create spaces within their account for collaboration. We'll have different plans to limit the amount of spaces created, with a difference between private spaces and public spaces like you can see in sites like github and bitbucket [06:21:44] like pbwiki? [06:22:14] yeah, kind of like pbwiki [06:22:22] On wheels :D [06:22:43] we'd be organised more like how lighthouse is, where you have your own subdomain and then separate spaces/projects inside of that subdomain [06:30:17] chuck: myspace with a touch of wiki? [06:30:49] probably wouldn't be too many social networking features ;-) [06:31:11] I might throw in a Twitter-like clone for groups [06:43:22] sounds like a lot of work and alot of htaccessing [06:45:22] not really, ServerAlias *.ourdomain.com, and then a simple database query before the request is processed to make sure the account is in good standing [06:46:33] Oh i see, a flexible conf [06:47:56] Basically in Rails, we'd do: @current_account = Account.find(:subdomain => request.something.something) (I forget the rails specific stuff there), then I can just do stuff like @current_account.pages.find_by_name('Home') or whatever [06:48:00] and it's easy [06:48:04] i really like how apache handles the multiple languages in their conf, they use a rewrite rule based on a regexp w / sethandler on the type-map [06:48:45] you should look at the http-manual.conf, it is really nice remapping concepts [06:49:06] chuck: you can do that in any language.. and if you're considering your new project based on how you can write neat one-liners in your pet language, maybe you didn't consider it quite enough ;) [06:49:15] I thought he was using nginx? [06:49:52] flyingparchment: I'm just showing him that it wouldn't be a nightmare of hacked together scripts and "a lot of htaccessing" to make it work. ;-) [06:50:35] well, i would be wary if you werent doing some apache magic, because apache magic is how i would imagine a successful project would look like for this [06:51:06] Emufarmers: I think it's server_name *.ourdomain.com; in nginx [06:58:53] is there an easy way to put sessions in the db? [06:59:14] i have my own custom session handler but it doesnt seem to work 100%, i get the "loss of session data" error [07:00:05] $wgMainCacheType = CACHE_DB; $wgSessionsInMemcached = true; [07:00:12] (a bit hacky) [07:00:24] ialex: that actually works? [07:00:42] Emufarmers: it should [07:00:53] $wgMainCacheType should already be in LocalSettings.php [07:01:18] 03(NEW) French spacing matches where it shouldn't - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=19290 minor; Normal; MediaWiki: Page rendering; (tstarling) [07:01:51] *Emufarmers greps [07:02:42] Emufarmers: includes/MemcachedSessions.php [07:03:07] and wfSetupSession() in GlobalFunctions.php [07:03:49] Yeah, that's where I'm looking [07:05:37] ah so memcached will have to be enabled? [07:05:43] It looks pretty Memcached-specific to me, but I'll take your word for it [07:05:47] can i just use php's built-in session overrides? [07:06:08] in conjunction with wfSetupSession() ? [07:07:08] i just took down my nfs server by using session_save_path for some reason. with a single user :p [07:11:13] 03ialex * r52151 10/trunk/extensions/ (6 files in 4 dirs): svn:eol-style native [07:30:10] hey domas: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Special:BlankPage [07:31:34] i guess i have to use memcached [07:43:20] mshadle_: Not necessarily; $wgSessionsInMemcached is misnamed, 'memcached' there really means any caching mechanism you have enabled [07:43:32] And with $wgMainCacheType = CACHE_DB; that's the database [07:44:13] I *think* this stuff ought to work with non-memcached caches as well, but I'm not sure [07:45:10] *ialex uses it with CACHE_ACCEL [07:45:46] memcached sessions don't seem to work very well for me [07:45:50] they get lost very quickly [07:45:52] werdna: is the error_handler now restored at all if no exception is thrown? [07:46:05] *Emufarmers makes a note on the manual page [07:46:13] morning btw [07:46:18] hoi [07:47:18] wait CACHE_DB will use mysql? [07:47:32] yes [07:47:37] what else would it use? [07:47:38] well that's damn simple [07:47:44] i dont know, what table does it use? [07:47:50] objectcache [07:49:24] ah [07:49:31] mshadle_: you'll probably get better performance out of an accelerator or Memcached, if they're options [07:53:12] im not worried aobut performance. it will be a small site [07:53:44] Eh, well, if you like things to load fast, having a bytecode cache helps a lot :) [07:54:01] bytecode cche != session storage [07:54:10] although they can both use apc, sure [07:54:15] I know; I'm just saying [07:54:30] but i dont have a problem with a single server, im on a multi-webserver environment so i need central sessions [07:55:04] Emufarmers: Is adding "extension=apc.so" to php.ini enough to enable APC's bytecode cache? [07:55:23] I think the whole point of Memcached is for multi-webserver environments [07:55:34] chuck: I think so [07:55:48] Emufarmers: Yes, that's pretty much true [07:56:14] Memcached works in a single-server environment but I've heard people say that APC cache is faster in that case [07:56:19] Which makes perfect sense [07:56:21] I wonder which is faster, APC cache in MediaWiki or memcached in mediawiki [07:56:30] that answers my question ;-) [07:56:39] apc is better for a single server [07:56:42] does $wgSessionsInMemcached work with CACHE_APC? [07:56:49] apc is different than memcached, anyway. [07:56:52] ialex says it does [07:56:58] apc is a bytecode cache with optional storage. [07:57:04] chuck: CACHE_APC doesn't exist [07:57:04] memcached is storage, period [07:57:07] I think when I tried them out, the accelerator was a little faster, but Memcached used fewer resources, as I recall [07:57:16] chuck: you need CACHE_ACCEL [07:58:00] isn't that for eAccelerator? [07:58:02] I should benchmark them side-by-side again sometime [07:58:23] APC is an accelerator for this purpose [07:58:38] I wonder if memcached vs APC would make a difference in requests per second [07:58:52] again, apples and oranges [07:59:08] how is it apples and oranges? [07:59:30] apc is a bytecode cache, that allows for apc_store and locale in-memory storage. [07:59:35] comparing two request per second benchmarks seems like an apple to apple comparison :P [07:59:41] bye it is a bytecode cache *first* [07:59:54] memcached is for distributed memory-based storage, not opcode caching [08:00:22] So you still need APC or eAccelerator or another bytecode cache if you have Memcached, right? [08:00:31] your best bet is apc for local bytecode caching (or xcache, or eaccelerator) and memcached for objects [08:00:33] You don't *need* it [08:00:45] But yeah, memcached won't do it for you [08:00:47] yes, if you want bytecode caching [08:00:52] which you do [08:00:53] mshadle_: even for one server? [08:00:54] :p [08:00:55] RoanKattouw: well, you still get the huge benefit from bytecode caching [08:00:58] it will be built in to php6 [08:01:07] unless someone figures how to share apc cache between cli and cgi it has big downside [08:01:10] this is so strange [08:01:33] the reason is taht PHP is made by Zend, and they want to sell their commercial accelerator [08:01:34] I got 15 requests per second on a page on YourWiki, but every time I re-run ab with the same settings, the requests per second gets lower and lower... [08:01:35] not a huge one. the web requests are typically multitudes higher than cli requests [08:01:45] as in.. not able to access object cache from command line scripts [08:02:14] mshadle_: no that's not the real problem [08:02:40] chuck: wouldn't it be hitting Squid anyway? [08:02:56] It is, but I don't think Squid likes to cache the main page for some really odd reason [08:03:06] never, ever, buy or pay money for any zend product/training/etc. fyi. [08:03:26] even rasmus today said zend framework was nuts [08:03:50] he liked the ability to load only what you wanted but still too interdependent. quote "spaghetti" [08:03:57] < Cache-Control: private, s-maxage=0, max-age=0, must-revalidate [08:04:06] 03catrope * r52152 10/trunk/phase3/ (3 files in 2 dirs): API: (bug 14200) Add user and excludeuser to list=recentchanges and list=watchlist. Requires the rc_user_text index, which was finally added on all servers with the recent schema changes. [08:04:08] Emufarmers: ^ that's on the main page from curl, so there's no cookies or anything [08:04:11] kidna strange [08:04:11] *kinda [08:05:43] Emufarmers: have you experienced any weirdness with the file caching? [08:06:01] like what? [08:06:40] well, how often do you run into problems with dynamic stuff that got put into a page that gets cached? [08:07:09] I guess stuff like DynamicPageList wouldn't work correctly anymore, but that's probably the same for Squid too though, right? [08:07:17] ugga [08:07:36] which brings me.. it should be clearly documented somewhere how extensions can disable caching [08:07:46] chuck: I assume so; we don't use DPL, though [08:08:04] So the only time there's an issue is if the skin or sitenotice changes [08:09:19] have any of you notice content loss on adding a namespace to the wgcontentnamespace? the existing pages in that namespace seem to get clobbered [08:09:33] Nikerabbit: I hate thinking about caching in general :P [08:09:37] so many variables to take into account [08:09:44] Really? I love thinking about it. :D [08:09:52] you're crazy in the head ;-) [08:10:38] 03ialex * r52153 10/trunk/extensions/LiquidThreads/LiquidThreads.php: Quick fix, seems that the file does not exist [08:11:15] rook2pawn: run the fixing script under maintenance [08:11:34] the namespace in the database just doesn't magically change [08:18:56] when you make a page say foo:bar does foo get added to some namespace area in the db or the script area? [08:19:25] if there is no namespace foo [08:19:41] it will get 0, (NS_MAIN) foo:bar tuple in the namespace [08:19:50] ops, comman in wrong position [08:19:54] comma* [08:22:06] 03(mod) Gadget usage statistics - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=19288 (10niklas.laxstrom) [08:22:15] Will cookies set for .yourwiki.net get sent with a request to static.nocookie.yourwiki.net? [08:22:34] Pretty sure [08:23:28] 03(FIXED) Large images do not display in ProofreadPage extension - 10https://bugzilla.wikimedia.org/show_bug.cgi?id=18322 (10thomasV1) [08:24:53] Nikerabbit: I just made /Foo:bar , saved with "foo bar baz" as content. THen i added $wgExtraNamespaces[] = "Foo" and $wgContentNamespaces[] = "Foo", then reloaded, and /Foo:bar is gone [08:25:16] *Splarka pokles http://translatewiki.net/wiki/MediaWiki:Sectionlink/km at Nikerabbit [08:25:24] rook2pawn: sure, because not it is parsed (foo, bar) [08:25:30] and the old page is (0, foo:bar) [08:25:33] now* [08:25:38] where do all these typos come today [08:27:08]