[00:00:59] I know it will be some point long ago, but with which version of MediaWiki did we break compability to the latest version of PHP 4? [00:01:47] Umm. Its the one with five billion point releases [00:02:06] since we supported it an extra long time [00:07:03] MGC: 1.6.12 was the last version to support php4 afaik [00:07:25] Wow [00:07:29] That's long ago [00:07:55] Almost a decade ago [00:08:28] keep in mind in different periods of time we released versions at different rates [00:08:50] e.g. 1.17 took a super long time to get released [00:10:09] Yeah. I always wondered why some extensions used var for class members until a point several years ago. However, I have confirmed now that it served absolutely no purpose, as MW 1.6 has been obsolete eben longer ^^ [00:10:33] I see, it always stroke me as odd in the version lifecycle why 1.17 took so long [00:11:59] Old habbits die hard [00:12:20] there are still parts that are passing objects by reference [00:12:49] esp. Hooks, although maybe there is fear about changing the type signature or something [00:13:26] MGC 1.17 was around when i started contributing [00:13:35] Yeah, for example the code that brought me this var example ^^ [00:13:40] long ago :p [00:14:22] it was even worse because we didnt do weekly deploys. So you had to wait like 9 months for your code to show up on wikipedia [00:15:02] O.o How can you work like that? It's a miracle that these releases became even ready at some point… [00:15:18] Or it seems to be, from my perspective ^^ [00:15:21] on the flip side, no suffering through (pre-commit) code review [00:15:34] Yeah, I can imagine it's something about signatures. All things considered, Hooks are weird things. [00:16:02] 1.17 took so long because that was the one that introduced ResourceLoader [00:16:18] and that was a pretty huge change [00:17:09] Oh, I see [00:19:21] pre-commit code review is a pain (You can wait 9 months waiting to get your changes merged as well!), however I think it has benefits in code quality. Although probably the group of people who could actually push anything to the repo was much smaller than the count of contributors these days. [00:19:37] I think there were some structural changes in mw community around that time as well [00:20:03] For example? [00:20:07] but i wasnt involved enough at the time to know what was really going on [00:21:13] it was when the WMF started growing significantly and hiring the developers ish [00:21:41] the wikitech-l archives are always a fun read to find out what was going on at the time [00:21:42] And moving away from the brion does all the things model [00:21:49] ^^ [00:22:02] :) [00:22:56] Afaik it was just a little later that we switched from svn to git? Seems like quite a big change as well [00:23:42] Git was when we introduced precommit review [00:24:21] previously we used special:codereview where people would mark revisions "fixme" after the fact if you screwed up [00:24:31] Gosh [00:24:32] or revert you if you really screwed up [00:24:48] and before that, I just reviewed every commit and cursed a lot in the office :D [00:25:41] I remember that I have seen this "beautiful" special page before ^^ I think I know why we moved away from that... [00:25:48] Sounds like funny times :p [00:26:08] * bawolff has fond memories of special:codereview [00:27:04] MGC: precommit review does indeed help code quality. For example when 1.17 was deployed it took down wikipedia [00:27:45] It wasn't tested before to make sure this won't happen? O.o [00:28:04] Testing on your laptop aint the same [00:28:55] i think it was something like a cache key got renamed and having a cold cache overloaded the servers [00:29:33] I know, but you'd think the WMF has the means to setup a testing environment [00:29:45] well we do now [00:29:58] Of course [00:30:18] things used to be a bit more rough [00:31:45] this was also before "hetdeploy" so all sites had to run the same version of mediawiki [00:34:54] Sounds like really different times [00:35:11] Well, it's been 7 years ago. [00:40:35] *Well, it have been 7 years [00:42:22] (I should probably stop trying fixing the grammar of this sentence.) [00:42:30] *to fix [03:35:10] I'm having a problem with some of the pages on my wiki: https://www.mediawiki.org/wiki/Topic:Ukb5rc95hg6n7ilb [04:50:41] Is anyone here who can help? [15:51:35] Hmm, its unclear to me what the 'default' field of an HTMLMultSelect HTMLForm field should be set to [16:47:11] I figured it out [17:41:34] Does anyone know, does hosting on Windows break pages with nonalphanumeric characters in the title? [17:41:52] Or is there a reason that it would do that? [17:41:54] No [17:42:07] On old versions, it would break images with non-ascii characters in titles [17:42:19] However, I believe that's been fixed for a while [17:42:32] And normal pages should always have worked with non-alphanumberic characters [17:43:08] Odd. [17:43:41] KeySpyMaster: Check to make sure you don't have something like apache mod_security, or some sort of WAF system potentially blocking things [17:43:50] I just moved my wiki from a shared Windows server to one to itself, but the pages with nonalphanumeric titles don't load. [17:44:19] if you moved db servers, check things related to charset encoding [17:44:33] They're all still there though; I can load the delete form via URL, and I can even create pages with those characters, I just can't load them. [17:44:48] e.g. sometimes people move from a db server using latin1 to one using utf-8 and that messes things up [17:45:04] Do you have your php error log, it will probably have a more specific error [17:45:06] !500 [17:45:06] A blank page or HTTP 500 error usually indicates a fatal PHP error. For information on debugging (including viewing errors), see . [17:50:52] Ok, I enabled the debugging code on localsettings.php, and I did get an error, but it wasn't related to the issue. I've already fixed it, and it's still getting the same result [17:52:36] KeySpyMaster: Sometimes that can happen if the error happens before mediawiki starts its configuration (although that's rare). So it is better to try and find your actual php error log (Also, looking at your web server error log is a good idea, in case its something wrong with the webserver instead of php) [17:53:37] Sorry, I'm super new to all this. Where would that be? [17:53:55] I'm not really sure on windows. It will depend on which web server you are using [18:31:45] Welp, I found the php error file, but there's nothing other than the previous error that I already fixed. [18:31:59] How can I check the charset encoding? [19:34:00] Welp, I found the php error file, but there's nothing other than the previous error that I already fixed. [19:38:04] Apache/nginx/IIS error file maybe? [19:38:42] * bawolff cant think of anywhere else to look [19:39:49] oh, if you moved servers did you change $wgServer. Maybe its redirecting to your old domain (but that wouldnt explain why only some pages affected) [19:46:29] Yeah, I changed the $wgServer [19:48:44] In $wgDBTableOptions, the DEFAULT CHARSET=binary [19:49:14] Is that the issue? It says the same in the old server. [19:49:37] That's normal and correct [19:50:11] if it was something wrong with that most likely pages would have a bunch of ???? But stillwork [19:54:03] It's also correct that according to phpMyAdmin, the server charset says utf-8 [19:54:11] Right? [19:54:45] The table charset is what matters, not the server charset [20:38:48] Maybe I'm explaining the issue incorrectly. The character I'm having trouble with is the greek letter chi "χ", which I believe is nonalphanumeric since it's not a standard character used, but I guess it could be something else [20:44:49] Usually the big distinction is ascii vs (non-ascii) unicode [20:45:01] where chi would be the latter