[13:55:11] Hi, I upgraded my wiki to 1.39 but when I'm using PHP 8.0 I'm getting the following error while editing the pages "Fatal exception of type "TypeError"" I looked at the error log and found "TypeError: Cannot access offset of type string on string" is there a bug or something? if not then is there a solution? [13:59:16] !debug [13:59:16] For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms [13:59:20] We'll need a full stack trace [14:01:29] Or at least a line number [14:01:55] Hello Reedy, I have the debug file so what should I look for in the file? [14:02:28] Look for that error you mention above, with it should be more details [14:04:48] The full error is "[exception] [d31e4da185277d36b5afa3da] /index.php?title=Main_Page&action=edit TypeError: Cannot access offset of type string on string" [14:05:05] And the lines after that? [14:05:09] First couple [14:07:37] #0 /home/wiki/html/extensions/TitleBlacklist/includes/TitleBlacklist.php(277): MediaWiki\Extension\TitleBlacklist\TitleBlacklist->load() [14:07:37] #1 /home/wiki/html/extensions/TitleBlacklist/includes/TitleBlacklist.php(230): MediaWiki\Extension\TitleBlacklist\TitleBlacklist->getBlacklist() [14:07:38] #2 /home/wiki/html/extensions/TitleBlacklist/includes/TitleBlacklist.php(198): MediaWiki\Extension\TitleBlacklist\TitleBlacklist->isBlacklisted() [14:07:38] #3 /home/wiki/html/extensions/TitleBlacklist/includes/Hooks.php(63): MediaWiki\Extension\TitleBlacklist\TitleBlacklist->userCannot() [14:07:48] And there are some more after these messages. [14:14:57] Is it something related to the TitleBlacklist extension? [14:15:14] It would look like it, yeah [14:15:46] Alright so I'll try to disable it and retry editing the page and let's see. [14:16:50] Would be good to confirm [14:18:34] Your $wgTitleBlacklistSources config may be wrong/out of date though [14:18:39] Sure I'll confirm. [14:19:21] Maybe I have disabled the extension just waiting for the server to restart after php changes. [14:19:44] I suspect, your $wgTitleBlacklistSources may be a string, not an array [14:19:50] I'm not sure offhand when it changed, but it did at some point [14:20:31] Currently I have: $wgTitleBlacklistSources = 'MediaWiki:Titleblacklist'; [14:21:08] Yeah, that'll explain it [14:21:22] Try setting it to... [14:21:29] $wgTitleBlacklistSources = [ [14:21:29] [ [14:21:29] 'type' => 'localpage', [14:21:29] 'src' => 'MediaWiki:Titleblacklist' [14:21:29] ] [14:21:30] ]; [14:22:22] Ok [14:25:53] I changed the PHP version to 8 but for some reason in the Special:Version it's still showing 7.4 so I guess I have to wait for some more time. [14:33:09] Reedy ok so after commenting out the extension the edit option works so now let me try with enabling the extension with the settings you shared above. [14:33:58] You shouldn't need to wait for anything... [14:34:08] Is your webserver actually loading PHP 8 rather than PHP 7.4? [14:34:50] Great it's working with the settings above the issue was the code $wgTitleBlacklistSources = 'MediaWiki:Titleblacklist'; [14:35:12] Are you upgrading from 1.35 by any chance? [14:35:21] I checked in the Special:Version and it's showing PHP 8.0 [14:35:32] No I upgraded from 1.38 [14:41:23] Now the only issue I'm facing is the VisualEditor isn't working and throwing "Skipped unavailable module ext.visualEditor.desktopArticleTarget.init" error in the browser console nothing in the error log. [14:41:45] If it's skipping, it shouldn't be a blocker [14:42:14] It is working in different directory that I have for mobile because I'm using subdomain for mobile and it's also working on Vector 2010 but not on Vector 2022. [14:42:54] The other error for VE is Skipped unavailable module ext.visualEditor.targetLoader [14:43:36] Did you update all your extensions? [14:44:06] Yes I installed 1.39 in a fresh directory with all the new upgraded extensions. [14:45:34] https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/REL1_39/extension.json#L422 still has ext.visualEditor.targetLoader [14:46:34] Hmmm [14:47:36] When I click on the edit button for visual editor I can see &veaction=edit in the url but the edito isn't loading. [14:49:43] Anything else in the console? [14:51:50] jQuery.Deferred exception: wgNamespaceNumber is not defined ReferenceError: wgNamespaceNumber is not defined [14:51:51]     at :1:26 [14:51:51]     at HTMLDocument. [14:53:16] That's... not the most helpful error message :D [14:54:16] Yeah not related to VE [14:54:32] Nothing else in the console and no error in the error log. [14:55:32] But to my surprise it's only getting blocked in Vector-2022 not on Vector 2010. [14:56:37] If you append... &debug=true do your URL... Do you get a more useful error message? [14:59:13] along with &veaction=edit? [14:59:36] yeah [14:59:43] it won't load the JS all minified and stuff [15:02:11] If I add &debug=true nothing appear in the console but it loads the VisualEditor instead. [15:02:21] lol [15:02:31] I wonder if it's just some cache after the upgrade? [15:02:36] *some outdated [15:03:05] Hmm what's what I was wondering. I tried to clear cache a couple of times but didn't get any help. [15:03:44] Is it safe to drop the objectcache table in the database? [15:04:47] I'm using Openlitespeed and cleared cache for the same nothing helps. I didn't tired removing the cache folder from the directory where we see localsettings.php [15:05:21] Do you think removing the old cache folder and create a new one will help? [15:11:52] Depends what sort of cache you're using :) [15:17:18] $wgMainCacheType = CACHE_MEMCACHED; [15:17:19] $wgParserCacheType = CACHE_MEMCACHED; [15:17:19] $wgMessageCacheType = CACHE_ACCEL; [15:17:20] $wgCentralAuthSessionCacheType = CACHE_MEMCACHED; [15:17:27] And openlitespeed cache [15:20:31] have you restarted memcached? [15:23:43] Nope [15:24:26] Let me figure it our how to restart it from the command line. [15:24:35] out* [15:25:08] `/etc/init.d/memcached restart` [15:25:10] or something [15:25:39] Thank you :) [15:44:35] The above command didn't worked so I had to run service memcached restart [15:44:52] VisualEditor is still giving the same error. [15:45:13] I don't have any idea what openlitespeed would cache, unfortunately [15:46:17] Hmmm openlitespeed is very complicated actually and I'm planning to shift to Apache which is quite easy to handle. [15:47:54] Anyways thank you a lot for helping me with the main PHP issue that I was trying to fix from a last few days. Have a good time and holydays. Stay blessed. [15:53:17] Does anyone know if it's possible to use https://en.wikipedia.org/wiki/Wikipedia:Special:PrefixIndex on wikitech? Looking for a way to automatically generate an index of all pages under https://wikitech.wikimedia.org/wiki/User:Bking/Notes . [15:54:40] inflatador: yes, Special:PrefixIndex is available on all wikis [15:56:00] taavi thanks for confirming. I guess I'm not calling it correctly, then? `{{Special:PrefixIndex/User:BKing/Notes/}}` doesn't seem to work [15:57:01] page titles are case sensitive, https://wikitech.wikimedia.org/wiki/Special:PrefixIndex/User:Bking/Notes/ works better [15:58:53] taavi Excellent, that definitely works. Thanks! [18:29:31] Was wondering how heavily customized the query service for wikidata is. Our wiki is interested in setting up a wikibase of our own that could be queried and used by both our wiki and other applications, and most of my research so far is pointing to a heavily customized application built specifically for wikidata itself. [18:30:12] it should be at least all public... [18:31:43] I'm referring to the query service itself, not Wikibase. [18:31:52] the same [18:31:56] it's going to be FOSS-y [18:32:42] I expected it would be. I'm more interested in how I would go about setting it up. [18:32:48] https://github.com/wikimedia/wikidata-query-rdf [18:33:12] https://wikitech.wikimedia.org/wiki/Wikidata_Query_Service is our docs on it (which includes deployment) [18:33:37] Thanks, I haven't been able to find those browsing through mediawiki.org, so that's extremely helpful. Appreciate it! [18:33:54] yeah... "where our docs live" can be a bit of a mess :) [18:34:06] especially if it's not specifically mediawiki [18:34:20] Yeah, just the nature of the beast. [18:34:51] looks like https://www.mediawiki.org/wiki/Wikidata_Query_Service/Implementation has some similar info [18:57:24] Reedy: https://bash.toolforge.org/quip/IIj1iIIBa_6PSCT9fIYz :) [18:57:57] wikitech for all [18:58:37] Bash quotes have saved my sanity on long journeys a few times [18:58:47] A lot of my favourites involve you [19:00:43] RhinosF1, obligatory mention of Google Docs [19:01:06] ? [19:02:12] inflatador: `{{Special:Prefixindex|prefix={{FULLPAGENAME}}/|hideredirects=1|stripprefix=1}}` is my favorite way to make an index over a set of subpages. See https://www.mediawiki.org/wiki/User:BDavis_(WMF)/Notes for a usage example. [19:05:46] RhinosF1, regarding the quip [19:06:10] Izno[m]: are Google's docs as bad? [19:06:24] We can't see them so we don't know 🙃 [19:06:36] There's probably various things hidden there [19:06:52] Many things are hidden from other Staff... [19:22:59] bd808: handy! [19:24:42] Nikerabbit: my only complaint about it is that I have to go find a page I used it on every time to remember the right magic word to use. :) [19:27:07] I have a user page for that :) [19:32:38] technically it's a special page transclusion, not a magic word :) [19:34:33] {{FULLPAGENAME}} [19:35:59] We do have like 5 different ways to make a magic word [19:36:07] calling these magic words doesn't bother me [19:44:03] bd808: ah, true [19:47:03] bd808 excellent! Gotta tweak my page now ;) [19:51:41] Reedy: The best feature of documentation in Google Docs is that it eventually vanishes in the void when people leave, so people can no longer complain you should move it to mediawiki.org or Meta. [19:54:09] oh no [21:56:51] Hello, is this the right forum to ask about wikipedia download files? [21:57:51] Not exactly... But depends what your question is [22:00:10] Ah my apologies. Wanted to ask for guidance on what files I need to download for my project. I saw this forum linked in the wikipedia data download page [22:00:35] We can probably help [22:05:36] Nice - thanks! I'd like to download all of wikipedia and it's revisions. I understand that files with 'pages-meta-history' in the name include the revisions. But I'm not fully understanding the integer values after this string. eg, why are there multiple 'enwiki-latest-pages-meta-history1.xml' files - do I need to download all of them? And why are [22:05:37] there integer values of 1-27? (enwiki-latest-pages-meta-history27.xml) [22:05:57] (Referring to files for download at this URL: https://dumps.wikimedia.org/enwiki/latest/) [22:08:18] https://meta.wikimedia.org/wiki/Data_dumps/What%27s_available_for_download#More_about_filenames [22:09:42] Lovely, thanks! [23:20:44] Merry christmas security release! [23:20:57] Reedy: did you do a release today just so the date string would have as many 2s as possible? ;) [23:21:14] Not purposefully... [23:21:21] I did find it amusing when entering 2022-12-22 into wikida :) [23:21:36] omg, we should have used this as an opportunity to bump the major version number [23:21:46] it jumped out at me on https://www.mediawiki.org/wiki/Module:Version :) [23:21:51] bawolff: doh! [23:24:16] the "1" is symbolic anyway. We obviously use the semver minor position as our major version. [23:31:44] Really it should be a 3 anyways [23:31:57] Since this is the third rewrite [23:32:49] I just treat it as calendar versionioning [23:33:05] You just can't see the date