[03:30:05] o/ again [03:30:41] hey there! if this is an inappropriate forum in which to seek assistance administering my 1.37.1 installation, please let me know. happy to file a bug, i just assume that i've made a mistake [03:31:41] i upgraded to 1.37.1 about a week ago? the same day the update notice came out. since then, search has been broken on my installation with the error "Fatal exception of type "Error"". there's no error output in my apache logs, just a 500 response [03:32:06] this can be seen at https://nick-black.com/dankwiki/index.php?search=test [03:32:40] and i was wondering what i ought do to run this down. normally any problems i've had corresponded to apache error logs, but i'm stuck on this one. [03:33:01] any help is appreciated =]. otherwise, thanks for mediawiki--been running it since 2008 or so with much love [03:33:40] i was using sphinxsearch until 1.35(?) or so; no obviously relevant extensions since then [03:44:36] !debug [03:44:36] 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 [03:47:14] thanks, i bet that will be sufficient! [03:48:14] is this safe to do on a publicly-exposed wiki, or ought i firewall it off before taking the outlined steps? [03:48:46] like is this going to dump my adminsettings or anything into pages [03:48:58] Unless you've done something very weird somewhere, no [03:49:11] i think i will firewall it just to be sure [03:49:17] ahhh thanks Reedy [03:49:21] Depending on what debugging you enable, the minimum is generating logs to logfiles [03:49:32] At most, displaying actual stack traces rather than just error codes and messages [03:54:12] alright, i am indeed now getting a wealth of php messages injected into my pages [03:55:32] though the results reported for a working page vs a non-working one are pretty much the same, and nothing is shown at a level greater than *Warning* (almost entirely *Deprecated*) [03:57:55] all the Warnings are about "can't modify header information -- transmission already started" which don't really seem applicable to this case [04:03:42] hrm you know, i think around that time i upgraded to php 8.1, as well. and i notice that it is not listed as supported on https://www.mediawiki.org/wiki/Manual:Upgrading [04:03:49] php --version [04:03:49] PHP 8.1.0 (cli) (built: Nov 25 2021 19:57:29) (NTS) [04:03:55] let me try downgrading to 7.x [04:03:57] mediawiki doesn't support php 8 [04:04:17] (as in, it's broken on php 8, not just a "you won't receive support for it") [04:04:36] so definitely downgrade to 7.x [04:04:40] then rebuild your search indexes [04:04:59] ^ [04:05:14] We'll certainly accept bug reports for PHP 8.0 and 8.1 if you can provide them [04:06:39] if you have the other error (it'll be the first thing listed above all of the "headers already sent" errors) that'd be helpful! [04:08:45] downgraded to 7.4 and reran maintenance/update.php [04:09:12] sure, will happily file a bug regarding the 8.1 situation [04:10:06] does running maintenance/update.php rebuild my search indexes? i noticed that "Special:SpecialPages" was broken after downgrading php, but update.php resolved that issue [04:10:28] o_0 [04:10:31] search still returns the same "Internal error: Fatal exception of type 'Error'", though =/ [04:11:13] (i am back on php 7.4.26 + mpm_prefork, down from 8.1 + mpm_event) [04:12:15] at this point, no content seems to be injected by the debugging steps taken earlier. the pages look normal [04:12:28] so all that deprecation stuff was almost certainly php8.1-related [04:12:37] but now nothing informative =\ [04:13:29] $wgShowExceptionDetails = true; [04:13:52] boom, stack treacer [04:14:22] I'd suggest your vendor is out of date [04:14:25] Error: Class 'OOUI\Theme' not found [04:14:30] yep, i think i can take this and run with it [04:14:40] thanks tremendously [04:15:42] ok i'm sitting on REL_1_37 tip but yeah i show a ton of git diff garbage [04:16:13] "deleted: oojs...." thar we go [04:16:37] Yeah, stuff like that ain't gonna help [04:17:13] yep, this is surely my fault, repairing now [04:17:36] search is fixed [04:17:38] yay [04:17:49] =] thank you very much for the assistance [04:18:24] i will do a quick switch to php8.1, collect those logs, and file a bug for y'all [04:19:05] We already have some bugs filed [04:19:32] https://phabricator.wikimedia.org/project/view/5132/ [04:20:03] ahh looks like what i saw is encompassed in T289926 and T289879 [04:20:03] T289926: MediaWiki passes nulls to non-null parameters of PHP internal functions - https://phabricator.wikimedia.org/T289926 [04:20:04] T289879: Signatures of several built-in interfaces implemented by MW have changed in PHP 8.1 - https://phabricator.wikimedia.org/T289879 [04:20:39] in that case i will happily stick to working php 7, and hope y'all have a great day/night. again, sure do appreciate all the hard work on mediawiki [04:21:24] extra logging disabled, all good, see ya [14:51:13] Hi - there's a patch (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GoogleDocCreator/+/749604) in a new repository (GoogleDocCreator) that's still waiting to get picked up by Jenkins-bot. Do we need to do something to get it picked up, or just wait? [15:15:03] Yaron: CI needs enabling for extensions individually [15:15:09] So if no one has done that, Jenkins will never do anything [15:21:37] Reedy: okay; do I need to request that? Or will it just happen at some point? [15:27:32] Nothing happens unless you ask :P [15:27:37] I can do it for you in a few mins though [15:28:52] Okay, thank you! Yes, please consider this my request. :) [15:34:55] Yaron: A recheck should kick it off now [15:44:46] Reedy: okay, that worked! Thank you! [18:41:05] Yaron: please don't just +2 patches [18:41:17] You can see the issues in the build output [19:13:34] *sigh* kind of sad that $wgTiffThumbnailType doesn't have a sane default [19:13:49] * urbanecm waves to bawolff [19:13:58] (does it have an insane default? :)) [19:20:35] So the choices are, thumbnail tiff files as JPEG or thumbnail tiff files as PNG. And the default is do neither [19:20:55] Seems like we should default to something that makes tiff files actually show up out of the box [19:22:46] that would make too much sense [19:29:01] or maybe we should delete built in tiff support. Nobody uses it, it requires customization, and anyone bothering to do that is probably using PagedTiffHandler [19:42:02] could PagedTiffHandler be merged into core to replace it? [19:42:36] Sounds like a reasonable idea to me [19:46:23] we have several tiffs uploaded to commons, so I'm not sure if I'm misunderstanding you when you say 'delete built in tiff support'. just in the thumbnailing system? [19:47:04] Izno: So commons uses PagedTiffHandler which is an extension made by WM-DE. MediaWiki core has older tiff thumbnailing support, that pretty much nobody uses [19:47:14] ah, ok [19:47:26] But was messing up my extension due to hardcoding in https://github.com/wikimedia/mediawiki/blob/master/includes/media/TiffHandler.php#L52 [19:50:25] * legoktm[m] waves to Izno [19:50:31] that hardcoding seems pretty fragile [19:51:19] * Izno waves to legoktm[m]. [21:05:27] bawolff: TimedMediaHandler and QuickInstantCommons don't play nice together either, if you weren't already aware [21:05:46] I have a local patch against TMH for that, was unsure of how to do it better [21:06:06] Oh i didn't think to test that one [21:06:18] TimedMediaHandler does so many weird things, I guess its not surprising [21:06:24] heh [21:06:57] I have a second local patch against TMH to make it support ForeignDBRepo in addition to ForeignDBViaLBRepo since it apparently only supports the latter despite them being basically equivalent in terms of how to use them [21:06:58] TimedMediaHandler doesn't work very well with remote file repos, or at least some configurations seem to not be supported at all [21:07:02] that I should really send upstream [21:08:53] I think a general-purpose solution for TMH would be to make use of extension.json attributes so that other extensions can register supported foreign repo/file types [21:11:14] Vulpix: Some would say it doesn't work great with local files either :P [21:11:33] Or maybe use file repositories properly? I though all of them share a common interface that provide the necessary methods to interact with