[02:14:28] Does visualeditor require installing RESTbase? [03:41:46] no [03:56:33] How significant is the performance improvements between RESTBase + VE and just VE by itself? [03:56:33] There has been some improvements on Parsoid since so I am wondering if it is still the case. [03:59:47] Hi, can someone please help me with the following error while running update.php? I just upgraded to MediaWiki 1.39 and when I'm updating I'm getting this error and it's not letting the update finish. [03:59:47] .Wikimedia\Rdbms\DBQueryError from line 1618 of /includes/libs/rdbms/database/Database.php: Error 1091: Can't DROP 'PRIMARY'; check that column/key exists [03:59:48] Thank you [04:39:31] any advice on $wgAutoCreateTempUser? [04:42:47] doesn't seem informative enough to me though [05:07:56] "any advice on $wgAutoCreateTempU..." <- Don't use it until it's finished? [06:26:52] `$wgAutoCreateTempUser['enabled'] = false;` [06:28:36] There are still a lot of caveats depending on your setup, you can see them here: https://phabricator.wikimedia.org/tag/ip_masking/ [08:57:36] good then [11:16:28] Hi, I upgraded my database from 1.38 to 1.39 but now the templatelinks table in mysql giving the following error: [11:16:29] ERROR 1062 (23000) at line 10415329: Duplicate entry '79253-167' for key 'templatelinks.PRIMARY' so is there any way to fix it? Thanks [11:18:22] Guest1 did you run update.php? [11:18:29] Yes I did [11:18:36] but no effect on this error. [11:30:17] Is there a way to remove duplicate key? [11:30:27] I mean duplicate entry. [11:32:24] The error message already says what's the duplicate entry (the one with values 79253 and 167 as the primary key fields). However, I'm not sure if that row exists already. The software should do a delete + insert, or update / insert, preventing this error from happening [11:33:46] But the software is not removing the duplicate entry when I'm running update.php and due to that I'm not able to have all the entries. It's only showing half of them. [11:33:52] Be sure you extracted all files from 1.39 on a new, empty directory, instead of merging them with the existing 1.38 files, that may generate errors due to files from mixed versions [11:34:37] Does the error happen when running update.php? or when saving a page/running jobs? [11:35:10] I installed 1.39 in a new directory and then moved all the files to the existing folder (without overwriting). [11:36:18] what? That would leave existing files from 1.38 untouched, if I understand correctly [11:37:37] ideally, you should point the webserver to the new directory, or rename the existing folder to _old (for example) and rename the new folder to the previous one [11:37:46] No it's not showing the error when I'm running update.php nor its showing when saving or creating pages. In my previous installation I had around 10389720 rows in the templatelinks database but after running update.php the numbers came down to 6650873 mean it removed a lot of rows. [11:38:40] of course, you should copy some files from 1.38 folder to 1.39 folder. Basically LocalSettings.php. Ideally the images folder should be outside of that directory, to not be affected by upgrades [11:39:00] And now when I'm trying to import templatelinks table from my last backup it's throwing that error. [11:40:18] Ah, well, why would you import the contents of a table from before a upgrade? if you're trying to downgrade, you should restore a complete backup, including table structure, not only data [11:42:03] Ok so any idea how am going to recover the lost rows? or they are not important in new upgraded version like the new version 1.39 does not require tl_title and tl_namespace fields anymore. [11:43:32] Also, I'm not importing contents from 1.38 the table I'm importing is from 1.39. [11:45:42] that's a bit confusing. You mentioned the number of rows from the 1.38 version, but you say you're importing from 1.39 [11:50:55] Yeah like I first installed a fresh 1.39 on testwiki which have the same database and it went well and then I moved the files to the main wiki and linked my main database and then after running the update.php i got into this issue. [11:51:22] The database in my test wiki has all the rows/ [11:59:36] Well this is something new I discovered. If I added a prefix to the templatelinks table its showing all the rows but if I remove the prefix the rows again came back to what I mentioned earlier. :| [12:05:19] adding a prefix where? To the table name? That makes no sense, unless you're creating tables from different sources [12:06:45] No i was just just trying to rename it by adding prefix so I can import the table from backup and notice these changes. [12:07:04] Yes to the table name. [12:08:20] How do I remove that duplicate entry? How do I find that particular entry that is causing the error? [12:11:37] your data is inconsistent. Review what are you importing. If the data was exported with the same table structure as the actual one, that duplicate key can't happen. This means the table structure changed between the export and the import [12:14:25] Ok I'll check and need to find out a solution for this. Thank you for your time and energy. :) [12:15:28] note that you should be doing backups with mysqldump, avoid exporting data as csv for backup purposes, since you're losing the table structure [14:00:25] Hi I installed visualeditor on MW1.39 but it's not working on vector-2022 and mobile. I'm not getting any error but when I click on the edit button nothing happen. Can someone please point out if there is any bug? [14:37:09] Hi, can someone please help with the issue? [14:56:19] I do get this message in DevTool: [14:56:19] Skipped unavailable module ext.visualEditor.desktopArticleTarget.init [14:56:20] Skipped unavailable module ext.visualEditor.targetLoader [15:07:25] Is this issue connected with cahce? [15:37:45] Here I got this error on visual editor : mediawiki Could not open '/tmp/mw-GlobalIdGenerator0-UUID-128'. [15:39:38] But the file does exist in /tmp/ folder [15:46:40] The file has 644 permission. [15:52:16] Anyone aware of this error? [15:52:18] Please [21:14:15] Live sexy aunty show [21:14:24] T [21:15:30] legoktm: thanks, you're fast :) [21:15:32] legoktm, Guest1472 too [21:34:47] !issync [21:34:48] Syncing #mediawiki (requested by legoktm) [21:34:49] Set /cs flags #mediawiki AntiComposite +Aiotv [21:34:52] Set /cs flags #mediawiki Waggie +Aiotv [21:35:24] hmm [21:36:02] ircservserv-wm doesn't need to op itself to do that [21:36:14] hrm? [21:39:57] Noisytoot: I think it needs +o to look at some channel modes [21:40:21] If it needs to look at +e or +I, then it does [21:42:25] https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia/irc/ircservserv/+/refs/heads/master/src/command.rs#136 [21:42:53] !issync [21:42:54] Syncing #mediawiki (requested by legoktm) [21:42:56] Set /cs flags #mediawiki Waggie -Aiotv [22:21:40] +b doesn't need op, +I does