[01:57:33] what should i be looking into, in order to have a article language link displayed on the left lower side of mediawiki like wikipedia has? [03:08:18] I have a question. Is there any way to create a table that users can add data to without editing the table ? [03:11:23] So something like this wiki http://www.entropiawiki.com/Chart.aspx?chart=Material [03:11:53] Users can add to the table, but also it can be link to another page [03:13:40] Can anyone help? [05:57:23] Version number not updating in Special:version page after mediwiki upgrade [05:57:55] php : v7.0 [05:58:00] MySQL 5.5.6 [05:58:13] MediaWiki upgraded to 1.31 from1.28 [06:05:27] Version number not updating on Special:version Mediawiki [06:05:38] how to resolve this [14:35:26] OK this is weird: my installation seems to have a page with its title starting with a whitespace (in the Module namespace), is there a standard way to somehow move it? Or do I have to poke inside the database? [22:34:12] I am trying to remove a file from the object cache in a maintenance script, calling ->invalidateCache on the LocalFile object, but it isn't removing the row from the database. any idea why? [23:04:41] ningu: I think you might be confusing several different things [23:04:52] The object cache and the row in the db are separate [23:05:09] objectcache means either memcached, or APCu or the objectcache table in db [23:05:30] the row in the image table is permenet and not part of caching [23:06:47] there is an objectcache in my database [23:06:50] objectcache table* [23:07:07] backing for SqlBagOStuff, I believe [23:08:08] and the keyname column matches the result of ->getCacheKey() [23:08:17] so, if this isn't the object cache, what is it? [23:09:01] what I've found is that certain circumstances can cause the object cache to be invalid for a particular image. it works again if I turn the caching off entirely. but since I know what triggers this bug (if it's a bug) I figured I could just invalidate the cache for that image [23:09:16] but, I am not finding a way to actually do that [23:09:30] because calling ->invalidateCache() seems to leave the row intact [23:09:51] invalidateCache on the file object should indeed delete the cache object for the File in question [23:10:41] here is the test script: https://pastebin.com/55K2p2di [23:10:54] I tried adding commit but dunno if that's needed [23:11:29] bawolff: is the syntax of the rows in objectcache documented somewhere? I saw prefixes like :v: and :m: [23:11:45] I don't think you should add the commit (since you didn't call a ->begin) [23:12:03] usually its prefixed with your database name (wfWikiId()) [23:12:14] ok [23:12:59] bawolff: maybe you can take a quick look at the code that is causing the caching issue: https://github.com/internetarchive/mediawiki-extension-archive-leaf/blob/master/ArchiveLeaf.class.php#L33 [23:13:39] Some quick things to check: If you have multiple wikis setup, make sure your script is running as the right wiki. Make sure that $wgMainCacheType is the same between cli and web [23:13:56] this imports a series of images from an item at archive.org, creating images with names like usadha_0.jpeg, usadha_1.jpeg, etc. what's weird is that when I run it, the first image -- the _0.jpeg -- gets imported successfully but its objectcache item is corrupted, so it doesn't actually display [23:14:13] on a page with [[File:usadha_0.jpeg]] etc [23:14:20] but everything after the first one is fine [23:14:26] and if I turn caching off it's fine [23:14:33] single wiki setup [23:15:06] mediawiki 1.32 on ubuntu 16.04 (I wish was 18.04 but ...) [23:15:17] Not directly related - but is $id trusted. If not you should make sure it doesn't have like ../ in it to prevent security issues [23:15:23] ok [23:15:29] let me look [23:15:59] what sort of security issues? [23:16:26] Someone could try and use relative paths to make you load a file that is attacker controlled [23:16:27] calling $uploader->initialize? [23:16:45] that may or may not be a serious thing [23:16:50] well, it's easy to add a check [23:17:12] also I don't really understand what this line is doing: DeferredUpdates::clearPendingUpdates(); [23:17:17] I wasn't the author of that line [23:21:22] normally you wouldn't call that [23:21:37] it would delete all the db updates that are currently pending, which would normally be a bad thing [23:21:43] yeah [23:21:55] that could even be the source of the cache corruption [23:22:00] although that seems a bit indirect [23:22:48] but I agree, it looked wrong when I saw it, but I haven't tested turning it off [23:23:50] I think what was happening was that they manually created a new thumbnail, but as part of the upload process, all existing thumbnails are deleted (since they have to be regenerated for new file) so the one they just created was deleted [23:23:57] so they just disabled the deferred updates [23:24:04] hrm... ok [23:24:06] which is a bad solution as that's not the only update there [23:24:11] is there a better solution? [23:24:18] I agree, that this may be the cause of your corruption issue [23:24:55] thumbnails are auto-created when needed anyway, aren't they? [23:25:10] I'm not sure why he would need to pre-create the thumbnail [23:25:15] yeah [23:25:24] ok, well I will just comment out that bit [23:25:27] depending on config, either on request, or during page render [23:25:44] on request meaning createThumb or something else? [23:26:15] if you have 404 thumbnailing enabled (not default, but like wikipedia) then the thumbnail gets created the first time anyone tries to view it (via thumb.php) [23:26:30] I am fine with storing thumbnails on disk, that seems desirable in fact, but ok to only generate them when needed [23:26:40] these are included on pages via [[File:...]] [23:26:49] usually either way results them saved on disk [23:26:50] specifying 400px as thumbnail size [23:26:58] Its more about when they are first created [23:27:01] oh, ok [23:27:24] the on request thing is nice because if things ever get screwed up, its kind of self-fixing [23:27:32] I wonder if there is any harm leaving the createThumb thing in there or if it's better to take it out? [23:27:39] I doubt there's any harm [23:28:48] ok. well I've removed the clearPendingUpdates bit and turned caching back on. will see [23:29:08] thanks for the help. I was wading through mediawiki code but it got beyond what I could easily wrap my head around [23:29:37] I am not really a php or mediawiki person, I just am pretty good at reading code and grepping around :P