[00:58:22] <gps>	 lighttpd 1.4.40 release earlier this week.  mediawiki with shortened URLs (using lighttpd rewrite) results in 301 redirect loop.  Discussed on https://redmine.lighttpd.net/issues/2738 with suggested change to mediawiki.  Should I file a feature request in mediawiki phabricator?
[01:00:10] <gps>	 lighttpd 1.4.40 sets REDIRECT_URI to original URL if request was redirected internally.  REQUEST_URI is set to the current URL, as opposed to previous behavior where REQUEST_URI was set to the original URL.  (This only affects rewritten URLs since otherwise REQUEST_URI and current URL are the same)
[01:05:14] <Vulpix>	 there's a bug about infinite redirects, let me see if I find it
[01:06:57] <Vulpix>	 there's https://phabricator.wikimedia.org/T106793 but that doesn't seem the same issue, since it happens with single quotes
[01:09:18] <MatmaRex>	 gps: i know nothing about lighttpd, but you should probably be redirecting everything just to /w/index.php, rather than /w/index.php?blahblah. mediawiki should be able to figure our the page to display from the original URL
[01:10:27] <MatmaRex>	 gps: the last major edit to the documentation page you linked was in 2008 (https://www.mediawiki.org/w/index.php?title=Manual:Short_URL/wiki/Page_title_--_Lighttpd_rewrite--root_access&action=history), so it might be a little bit out of date ;)
[01:12:29] <gps>	 MatmaRex: user reporting this issue was following https://www.mediawiki.org/wiki/Manual:Short_URL/wiki/Page_title_--_Lighttpd_rewrite--root_access
[01:13:04] <gps>	 ah (scrolled to see the rest of your post)
[01:13:09] <MatmaRex>	 that very well might have been the best way when it was written, back in 2007. but it probably isn't now, unless lightppd is very different from apache :)
[01:13:53] <gps>	 there are differences, but the mediawiki code is expecting REQUEST_URI, if present, to be the original URL.
[01:15:01] <gps>	 In lighttpd 1.4.40, REDIRECT_URI was introduced when request is internally redirected, and points to original URL.  REQUEST_URI is current URL, and this breaks mediawiki when the URL has changed from the original
[01:16:03] <gps>	 MatmaRex: is your suggestions about to do an external redirect to /w/index.php, sending 301 and Location to client, or to do it internally on server-side?
[01:17:21] <MatmaRex>	 no, internally
[01:18:35] <Vulpix>	 that looks like they swapped the variables... by "request" I understand "the URL requested by the client", and by "redirect" the "URL where it has been redirected"
[01:18:38] <gps>	 with the just-released lighttpd 1.4.40, this results in 301 redirect loop with mediawiki, since mediawiki is looking at REQUEST_URI since it is present
[01:18:59] <MatmaRex>	 gps: i'm sorry, i know very little about servers (and only a bit more about mediawiki). but my local apache configuration for short urls is just this in .htaccess:
[01:19:00] <MatmaRex>	 RewriteEngine On
[01:19:00] <MatmaRex>	 RewriteRule ^/?wiki(/.*)?$ %{DOCUMENT_ROOT}/w/index.php [L]
[01:19:03] <gps>	 (yes, it is confusing, especially the misuse of URI and URL)
[01:20:03] <MatmaRex>	 unless someone else who understands this better appears, i suggest just filing a bug: https://phabricator.wikimedia.org/maniphest/task/edit/form/1/
[01:20:19] <gps>	 MatmaRex: your .htaccess is a useful data point.  thanks.
[01:21:28] <gps>	 Vulpix: "they" might be "me" trying to understand and reuse conventions, since neither REDIRECT_URI or REQUEST_URI are standardized CGI vars
[01:22:13] <gps>	 Apache prepends REDIRECT_ to env vars when the request is redirected, so the REDIRECT_* are from the prior request, and the current CGI vars are for the current request.
[01:23:56] <gps>	 Having both REDIRECT_URI and REQUEST_URI identical seemed redundant to me.
[01:24:51] <gps>	 As non-standard vars. Should they be fully-qualified URIs with scheme://authority/path?query, or just /path?query  ?  I guess users should check before use, and reconstruct fully qualified URIs from other env vars, as needed.
[01:28:06] <Vulpix>	 a lack of standards is bad
[01:29:59] <gps>	 Yes.  Standard would be nice.  The reason for the "extra" variables and mediawiki path shenanigans is to get unmolested path info, before physical path translation which might remove multiple slashes (///), or relative paths (/./, /../, etc), or lowercase path if the filesystem is case-insensitive, or ...
[09:28:07] <Reception123>	 If anyone has time: https://phabricator.wikimedia.org/T140479
[14:06:25] <Reedy>	 Reception|away: https://gerrit.wikimedia.org/r/300024
[14:08:58] <theaetetus>	 hey guys. have a short template that's just supposed to do a simple #expr on param 1 and then display the result inline. however, it adds a newline after. any hints on preventing this?
[14:19:37] <Ed_WikiBrasil>	 hello guys. i'm having some issues with google maps. the maps appears and them gives an error 2 second lates with "something went wrong".
[14:21:22] <Reedy>	 Ed_WikiBrasil: Which extension? http://www.mediawiki.org/wiki/Extension:Google_Maps
[14:21:51] <Ed_WikiBrasil>	 https://www.mediawiki.org/wiki/Extension:Maps
[14:22:45] <Ed_WikiBrasil>	 I have done the installation from composer and I noticed a line has been removed from Maps_Settings.php, from the installation. $GLOBALS['egMapsGMaps3ApiKey'] = 'AIzaSyCFqbiT8G6HCeBDd3MSs7hKM-8ypv3Y7BQ';
[14:23:06] <Ed_WikiBrasil>	 that line exists on the Maps installation procedure, on the website
[14:23:14] <Ed_WikiBrasil>	 but is not that either
[14:23:31] <Ed_WikiBrasil>	 ops, thats my code
[14:39:50] <Reception|away>	 Reedy: Thank you very much! This will be a great help!
[14:43:43] <Reedy>	 Reception|away: just need to find someone to review it ;)
[16:44:45] <Pennth>	 Anyone know a replacement for Auth_remoteuser that works with 1.27.0?
[16:47:55] <bawolff>	 You can disable auth manager to make it work...
[16:58:42] <Reception|away>	 Reedy: Let's hope you do! This change would be useful for us
[17:33:45] <Reedy>	 Reception|away: Should be easy enough to find reviewers... You can of course, help by testing it and comment on gerrit that it works for you :)
[17:34:50] <Reception|away>	 Well it's more complicated because its for Miraheze (a wiki hosting service) where I'm a volunteer and we can't really test stuff there..
[17:39:58] <fturco>	 hello. i just installed mediawiki on my vps server. but my browser somehow doesn't display the css stylesheet when connecting to the wiki
[17:40:14] <fturco>	 may i post the url here?
[17:40:26] <MatmaRex>	 sure
[17:40:34] <fturco>	 https://wiki.fturco.net/
[17:42:19] <Reedy>	 https://wiki.fturco.net/index.php/Main_Page?useskin=monobook that works
[17:42:56] <fturco>	 yeah, indeed
[17:43:00] <MatmaRex>	 that is quite interesting, it has some styles, but not all
[17:43:49] <fturco>	 this is my second attempt at installing mediawiki. i had no css problems with my first attempt
[17:44:29] <fturco>	 i reinstalled mediawiki because i moved it to the "wiki" subdomain
[17:45:18] <fturco>	 before i entered it as https://fturco.net/mediawiki/
[17:45:37] <MatmaRex>	 fturco: in debug mode: https://wiki.fturco.net/index.php/Main_Page?debug=1 this is a blank page, while it should have skin styles: https://wiki.fturco.net/load.php?debug=true&lang=en&modules=skins.vector.styles&only=styles&skin=vector
[17:46:50] <fturco>	 even during installing the css was lacking
[17:46:56] <MatmaRex>	 normally there should be some error there if something's not working… hm
[17:47:03] <MatmaRex>	 fturco: i dunno, first i'd check that all the files for Vector are really there
[17:48:19] <fturco>	  /usr/share/webapps/mediawiki/skins/Vector/ is full of files
[17:48:42] <MatmaRex>	 if they really are, turn on all the debugging from https://www.mediawiki.org/wiki/Manual:How_to_debug#PHP_errors (the PHP ones, and the MediaWiki $wg ones below) and see if that gives us an error message somewhere
[17:53:07] <fturco>	 MatmaRex: i added the following settings: http://dpaste.com/1Z66443
[17:55:36] <fturco>	 this is my virtualhost config: http://dpaste.com/1R7AXSW
[17:59:16] <fturco>	 this is the end of accesslog: http://dpaste.com/1HS40H2
[17:59:42] <fturco>	 errorlog is empty
[18:01:48] <fturco>	 mmh. on another errorlog i get the following error:
[18:01:50] <fturco>	 You configured HTTP(80) on the standard HTTPS(443) port!
[18:04:28] <MatmaRex>	 fturco: i'm honestly stumped. i can access https://wiki.fturco.net/skins/Vector/ and all the files are there (btw, you might want to prevent listing directories somehow). and your https://wiki.fturco.net/index.php/Special:Version says all dependnecies are installed
[18:05:16] <MatmaRex>	 fturco: you're on PHP 7, i guess we don't test with that very often (but it should be supported)
[18:08:02] <fturco>	 MatmaRex: should i try reinstalling it again?
[18:08:06] <fturco>	 mediawiki i mean
[18:10:27] <MatmaRex>	 fturco: i suppose it wouldn't hurt, but i have no idea if it would help. mediawiki seems to genuinely think that there are no styles to show: https://wiki.fturco.net/load.php?debug=false&lang=en&modules=skins.vector.styles&skin=vector
[18:12:18] <fturco>	 MatmaRex: beside deleting LocalSettings.php and dropping the wiki table from mysql, what should i do to start from scratch?
[18:12:46] <fturco>	 *wiki database
[18:13:50] <MatmaRex>	 fturco: that should be all
[18:17:31] <fturco>	 MatmaRex: it works now!
[18:18:01] <MatmaRex>	 huh.
[18:18:18] <MatmaRex>	 that is even more surprising to me than the fact that it didn't before. but okay! :P
[18:18:25] <fturco>	 :)
[18:18:32] <fturco>	 thank you for the help!
[18:19:16] <MatmaRex>	 :)
[18:24:57] <oscoo>	 hi
[18:58:06] <Ulfr>	 Hi All! I'm baaack! Got a good one for you lot today I hope. I've got wikis running on IIS 6.2 that are having a very odd issue. Widgets will not update on the pages they're encoded into even after a page's cache is purged.
[18:58:59] <Ulfr>	 The IIS user has full read and write permissions on the compiled_templates directory for that extension, and when I check inside the compiled_templates directory the code seems updated, but the display will absolutely not update
[18:59:03] <Ulfr>	 Any thoughts?
[18:59:35] <MaxSem>	 Extension:Wifgets?
[18:59:39] <MaxSem>	 *Widgets
[19:00:30] <Ed_WikiBrasil>	 hello guys. i'm having some issues with google maps. the maps appears and them gives an error 2 second lates with "something went wrong".
[19:00:33] <Ed_WikiBrasil>	 https://www.mediawiki.org/wiki/Extension:Maps
[19:00:36] <Ed_WikiBrasil>	 any clue?
[19:02:52] <Ulfr>	 MaxSem: as
[19:02:54] <Ulfr>	 Yas*
[19:03:31] <Ulfr>	 Ed_WikiBrasil: Any chance you can check your javascript error log for a lil more info? Ctrl + Shift + J on Firefox
[19:14:08] <Ed_WikiBrasil>	 Ulfr, still asking for the key.
[19:14:09] <Ed_WikiBrasil>	 js?language=pt-br&sensor=false:32 Google Maps API error: MissingKeyMapError https://developers.google.com/maps/documentation/javascript/error-messages#missing-key-map-error
[19:14:55] <Ed_WikiBrasil>	 I have added on Maps_GoogleMaps3.php as someone told to try
[19:15:28] <Ed_WikiBrasil>	 I dont know if this has to do with this "As of 22 June 2016, Google Maps require a key for new sites, i.e. sites first using Google Maps after that date. See"
[19:16:15] <Ulfr>	 Ed_WikiBrasil: Honestly bud, I have no idea how to help you, I just know the more troubleshooting information you provide the more likely someone will tell you the fix. Best of luck! :)
[19:27:12] <Amir1>	 MatmaRex: hey, I have a question regarding collation in mediawiki, for when you have some free time.
[19:27:28] <MatmaRex>	 Amir1: anytime. hi
[19:27:30] <Reedy>	 "how long have you got?" :P
[19:27:35] <MatmaRex>	 heh
[19:27:55] <Amir1>	 MatmaRex: awesome, https://phabricator.wikimedia.org/T139110
[19:28:03] <Amir1>	 I'm trying to fix this
[19:28:13] <Amir1>	 I made this patch: https://gerrit.wikimedia.org/r/300001
[19:28:28] <Amir1>	 It got merged and It's in beta cluster. http://fa.wikipedia.beta.wmflabs.org/wiki/%D9%88%DB%8C%DA%98%D9%87:%D9%86%D8%B3%D8%AE%D9%87
[19:28:42] <Amir1>	 but it's not fixed: http://fa.wikipedia.beta.wmflabs.org/w/index.php?title=%D8%B1%D8%AF%D9%87:%D8%B5%D9%81%D8%AD%D9%87%E2%80%8C%D9%87%D8%A7%DB%8C_%D8%A7%D8%A8%D9%87%D8%A7%D9%85%E2%80%8C%D8%B2%D8%AF%D8%A7%DB%8C%DB%8C
[19:28:57] <Amir1>	 maybe there is cache or something?
[19:30:40] <MatmaRex>	 hm
[19:32:18] <MatmaRex>	 Amir1: it has a cache, see IcuCollation::getFirstLetterData. $cache::TTL_WEEK
[19:32:46] <Reedy>	 PURGE ALL TEH THINGS
[19:32:53] <MatmaRex>	 gogogog Reedy
[19:33:04] <Amir1>	 okay
[19:33:29] <Amir1>	 I think there is a maintenance script but not sure if it purges this cache
[19:33:30] <MatmaRex>	 Amir1: by the way, the ordering is correct, only the headings are wrong?
[19:33:44] <MatmaRex>	 no, it doesn't. the maintenance script rebuilds the sort keys
[19:34:04] <MatmaRex>	 (and would have to be used if the ordering is wrong)
[19:34:12] <Amir1>	 order is correct
[19:34:29] <Amir1>	 how can we purge the cache?
[19:34:57] <Reedy>	 eval.php
[19:35:04] <MatmaRex>	 $cacheKey = $cache->makeKey(
[19:35:04] <MatmaRex>	 				'first-letters',
[19:35:04] <MatmaRex>	 				$this->locale,
[19:35:04] <MatmaRex>	 				$this->digitTransformLanguage->getCode(),
[19:35:05] <MatmaRex>	 				self::getICUVersion(),
[19:35:05] <MatmaRex>	 				self::FIRST_LETTER_VERSION
[19:35:05] <MatmaRex>	 			);
[19:35:21] <MatmaRex>	 so i guess either manually purge that key with eval.php, or bump the FIRST_LETTER_VERSION constant
[19:35:33] <Reedy>	 yeah
[19:35:54] <MatmaRex>	 (the latter will purge the caches for all wikis everywhere, but it's probably not a big deal, they take like a couple seconds to generate i think)
[19:36:19] <Amir1>	 which one do you prefer? If you're okay with the latter. I make the patch right away
[19:36:22] <MatmaRex>	 eval.php would be more precise, but you'd need to convince a human with server access to execute it by hand
[19:36:35] <Reedy>	 well, aren't we only talking about labs atm?
[19:36:43] <Amir1>	 I think I have access and I can do it both for prod and beta
[19:36:51] <Amir1>	 but preferably not 
[19:36:55] <MatmaRex>	 i imagine you'd need to do the same in production (or just wait a week)
[19:37:29] <Amir1>	 we have this issue in all Persian Wikis (just someone contacted me today in Persian Wikiquote) 
[19:37:35] <Amir1>	 so I prefer the latter
[19:38:33] <Reedy>	 well, shall we purge it on beta, and test it works first?
[19:38:47] <Amir1>	 okay
[19:38:49] <Amir1>	 that's easy
[19:45:51] <Amir1>	 MatmaRex: I tried to figure out what should I put in eval.php but couldn't find it :D
[19:46:51] <MatmaRex>	 Amir1: something similar to code in IcuCollation::getFirstLetterData. hmm
[19:47:02] <Reedy>	 yeah, you'll need to work out the various bits
[19:48:53] <MatmaRex>	 $cache = ObjectCache::getLocalServerInstance( CACHE_ANYTHING );
[19:48:54] <MatmaRex>	 $cacheKey = $cache->makeKey( 'first-letters', 'fa', 'fa', IcuCollation::getICUVersion(), IcuCollation::FIRST_LETTER_VERSION );
[19:48:54] <MatmaRex>	 $cache->delete( $cacheKey );
[19:48:54] <MatmaRex>	 Amir1: probably something like this? ^ untested
[19:49:33] <Amir1>	 thanks
[19:50:13] <Amir1>	 I'm not sure If I purged the caches correctly but still we have the issue
[19:57:42] <MatmaRex>	 Amir1: sorry, i've just gotten disconnected :/
[19:57:43] <MatmaRex>	 [21:46]	<MatmaRex> Amir1: something similar to code in IcuCollation::getFirstLetterData. hmm
[19:57:44] <MatmaRex>	 [21:48]	<MatmaRex> $cache = ObjectCache::getLocalServerInstance( CACHE_ANYTHING );
[19:57:44] <MatmaRex>	 [21:48]	<MatmaRex> $cacheKey = $cache->makeKey( 'first-letters', 'fa', 'fa', IcuCollation::getICUVersion(), IcuCollation::FIRST_LETTER_VERSION );
[19:57:44] <MatmaRex>	 [21:48]	<MatmaRex> $cache->delete( $cacheKey );
[19:57:44] <MatmaRex>	 [21:48]	<MatmaRex> Amir1: probably something like this? ^ untested
[19:58:10] <Amir1>	 I tested it, still not working
[19:58:20] <Amir1>	 not sure if we didn't purge it correctly 
[19:58:26] <Amir1>	 or my patch is not fixing it
[19:58:55] <Amir1>	 I'm trying to find out if the locale key is correct, not sure it should 'fa'
[19:59:16] <Amir1>	 MatmaRex: ^
[20:01:00] <MatmaRex>	 Amir1: hmm, it actually looks like both of the characters you added exist in /serialized/first-letters-root.ser
[20:01:46] <MatmaRex>	 so it should not be necessary to add them to $tailoringFirstLetters
[20:02:08] <MatmaRex>	 although on a closer look… all five characters for 'fa' exist there. so i'm not sure why we ever needed this
[20:03:10] <Amir1>	 MatmaRex: one strange thing is that this issue started in about a month
[20:03:20] <Amir1>	 but this list is around for years
[20:04:12] <MatmaRex>	 Amir1: ICU was updated on WMF servers recently
[20:04:32] <Reedy>	 yeah
[20:04:47] <Amir1>	 that could be it, fixing old issues, opening up new ones
[20:05:16] <Reedy>	 yup, very likely
[20:09:31] <MatmaRex>	 Amir1: i added pages with just the two characters as their titles to http://fa.wikipedia.beta.wmflabs.org/wiki/رده:صفحه‌های_ابهام‌زدایی , so that we can see what sortkeys they get
[20:09:40] <MatmaRex>	 http://fa.wikipedia.beta.wmflabs.org/wiki/ویژه:ApiSandbox?uselang=en#action=query&format=json&prop=categories&generator=categorymembers&utf8=1&clprop=sortkey&clcategories=%D8%B1%D8%AF%D9%87%3A%D8%B5%D9%81%D8%AD%D9%87%E2%80%8C%D9%87%D8%A7%DB%8C+%D8%A7%D8%A8%D9%87%D8%A7%D9%85%E2%80%8C%D8%B2%D8%AF%D8%A7%DB%8C%DB%8C&gcmtitle=%D8%B1%D8%AF%D9%87%3A%D8%B5%D9%81%D8%AD%D9%87%E2%80%8C%D9%87%D8%A7%DB%8C+%D8%A7%D8%A8%D9%87%D8%A7%D9%85%E2%80
[20:09:41] <MatmaRex>	 %8C%D8%B2%D8%AF%D8%A7%DB%8C%DB%8C
[20:09:46] <MatmaRex>	 (long url eh)
[20:12:09] <Amir1>	 MatmaRex: Okay, sortkeys are numbers here
[20:14:23] <Amir1>	 heaxdecimal I guess
[20:14:47] <MatmaRex>	 yeah
[20:14:56] <MatmaRex>	 hmm
[20:16:27] <MatmaRex>	 Amir1: so, i really don't know enough about this all, but i think that the three characters (ء ا و) have only a secondary or tertiary difference in the new ICU, rather than primary as previously
[20:17:04] <MatmaRex>	 (e.g. A and B is a primary difference, Ä and Á is a secondary difference, A and a is a tertiary difference)
[20:17:26] <Amir1>	 okay, So our appending to ICU should fix it, right?
[20:17:38] <Amir1>	 like what it did with other languages
[20:17:47] <MatmaRex>	 Amir1: and they hit the "Primary collision"/"Keep whichever one sorts first in the main collator" case in IcuCollation::fetchFirstLetterData
[20:18:19] <MatmaRex>	 so only 'ء' is kept, as it's the one that sorts first
[20:19:21] <Amir1>	 yes, It's up there
[20:19:25] <MatmaRex>	 Amir1: this might be a regression (or intentional change) in ICU, and i'm not sure if we can work around it; you should poke bawolff about it, i think
[20:20:02] <MatmaRex>	 maybe it would work to special-case these letters in the "Primary collision" check (and use secondary/tertiary sortkeys for them), but i have no idea if that will work correctly
[20:21:02] <MatmaRex>	 let's see if i still remember where ICU people keep the collation tailorings data…
[20:22:29] <Amir1>	 One rater stupid question. I still can't understand why mediawiki can't fetchFirstLetterData correctly
[20:22:31] <Amir1>	 https://github.com/wikimedia/mediawiki/blob/master/includes/collation/IcuCollation.php#L106
[20:22:54] <Amir1>	 in this case it looks like it's a secondary collision too
[20:23:38] <Amir1>	 is our overwriting system failed for unknown reason thus all of them are broken?
[20:24:38] <MatmaRex>	 Amir1: i don't understand, what is a collision?
[20:26:05] <Amir1>	 MatmaRex: As you said above "Primary collision"/"Keep whichever one sorts first in the main collator" case in
[20:27:13] <Amir1>	 For example since we added "Cs" to hu: https://github.com/wikimedia/mediawiki/blob/master/includes/collation/IcuCollation.php#L106
[20:27:19] <Amir1>	 https://hu.wikipedia.org/wiki/Kateg%C3%B3ria:K%C3%B6zigazgat%C3%A1s_orsz%C3%A1gok_szerint
[20:27:46] <Amir1>	 we see "Cs" heading got separated. Why this didn't work on Persian 
[20:28:34] <MatmaRex>	 Amir1: Cs is a primary difference from C in hungarian
[20:30:50] <Amir1>	 that's why we added it to IcuCollation.php or it's something deeper. in ICU standard itself
[20:32:43] <MatmaRex>	 Amir1: no, it's in ICU code
[20:33:00] <MatmaRex>	 Amir1: the lists in IcuCollation.php only affect places where we insert the headings, they do not affect the ordering
[20:33:24] <Amir1>	 Order is okay
[20:33:29] <Amir1>	 we have heading issue
[20:34:03] <Amir1>	 "و" should not be in "ء" 
[20:34:09] <MatmaRex>	 Amir1: the ICU collation is defined in files like this: http://bugs.icu-project.org/trac/browser/icu/trunk/source/data/coll/fa.txt http://bugs.icu-project.org/trac/browser/icu/trunk/source/data/coll/hu.txt
[20:35:31] <Amir1>	 it should've been in different headings
[20:36:03] <MatmaRex>	 Amir1: right, i understand. but i really don't know what's broken or how to fix it :)
[20:36:34] <Amir1>	 hmm
[20:36:48] <Amir1>	 thanks for the help
[20:36:58] <Amir1>	 I try to investigate this issue
[20:37:30] <Amir1>	 your explanation was indeed super helpful 
[20:42:18] <MatmaRex>	 Amir1: i'm actually looking at http://bugs.icu-project.org/trac/browser/icu/trunk/source/data/coll/fa.txt and i think it actually defines ا to go before ء … so either i am confused about how the sorting works, or i am confusde about the format of these files
[20:42:35] <MatmaRex>	 Amir1: you should get bawolff on the case. he's the authority, i'm just the guy who wrote some code ;)
[20:43:16] <Amir1>	 Since fa is RTL probably ء is before آ
[20:43:20] <Amir1>	 *ا
[20:44:08] <MatmaRex>	 Amir1: i'm intentionally viewing them in an editor that does not support RTL text at all. :)
[20:44:47] <Amir1>	 nice :D
[20:45:29] <Amir1>	 I'm trying to get an instance of IcuCollation and play with its methods
[20:45:35] <Amir1>	 and attributes 
[20:45:42] <Amir1>	 maybe there is something missing
[22:22:53] <Krenair>	 Okay, so
[22:23:02] <Krenair>	 Who here has been running MW on PHP 7?
[22:23:14] <Krenair>	 I ask because I just updated to Xenial and of course it has PHP 7
[22:23:53] <Reedy>	 Krenair: I am
[22:24:04] <Krenair>	 Changed db type to mysqli, installed php7.0-mbstring, php7.0-mysql, libapache2-mod-php7.0
[22:24:07] <Krenair>	 restarted apache
[22:24:10] <Krenair>	 but now I can't log in
[22:24:19] <Krenair>	 "There seems to be a problem with your login session; this action has been cancelled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."
[22:24:44] <Reedy>	 you'll probably need a few more packages than that
[22:24:56] <Krenair>	 yeah well MW is loading at this stage
[22:24:59] <Krenair>	 I just can't log in
[22:25:14] <Reedy>	 how are your sessions setup on your devwiki?
[22:26:19] <Krenair>	 Pretty sure I have all the defaults for those sorts of settings
[22:28:58] <Krenair>	 I do have wgMainCacheType set to CACHE_ACCEL
[22:30:42] <Reedy>	 APC went bye byes
[22:31:16] <Reedy>	 php-apcu
[22:31:23] <Reedy>	 But MW doesn't know how to work with that yet
[22:31:40] <Skizzerz>	 did apcu change on php 7?
[22:31:42] <Reedy>	 I have maincache type set to memcached-pecl
[22:31:42] <bawolff>	 Are you sure? I thought it did
[22:31:51] <Skizzerz>	 if no, apcu has exactly the same api as apc
[22:31:55] <Skizzerz>	 so mw works with it unchanged
[22:32:00] <Reedy>	 They renamed all the functions?
[22:32:05] <Skizzerz>	 nope
[22:32:10] <Skizzerz>	 (unless they did in php 7)
[22:32:17] <Reedy>	 https://secure.php.net/manual/en/book.apcu.php
[22:32:21] <Skizzerz>	 but the php 5 versions are still all named apc_*
[22:32:55] <Reedy>	 See https://phabricator.wikimedia.org/T140587
[22:33:32] <Skizzerz>	 ok yeah
[22:33:38] <Skizzerz>	 they renamed them all for the php 7 version
[22:34:06] <Skizzerz>	 but kept the old php.ini settings
[22:34:08] <Skizzerz>	 sigh
[22:34:15] <Reedy>	 lol
[22:34:24] <Krenair>	 seems to be authform-wrongtoken
[22:34:37] <Reedy>	 well, your apc setup is gonna be busted Krenair
[22:34:45] <Reedy>	 I do have a WIP patch for that T140587
[22:34:45] <stashbot>	 T140587: web configuration does not properly detect apcu - https://phabricator.wikimedia.org/T140587
[22:34:55] <Krenair>	 Might that be why sessions are broken?
[22:34:55] <Reedy>	 But I think I need to create an APCuBagOStuff
[22:35:01] <Reedy>	 Krenair: Almost certainly
[22:35:09] <Krenair>	 I vaguely recall session handling being related to that code
[22:35:17] <Reedy>	 $wgSessionsInObjectCache = true; too?
[22:35:21] <Krenair>	 which is why I brought CACHE_ACCEL up
[22:35:40] <Krenair>	 yep
[22:36:11] <Krenair>	 there we go
[22:36:15] <Krenair>	 changed it to CACHE_NONE :/
[22:36:21] <Krenair>	 log in works again
[22:36:30] <Reedy>	 As above
[22:36:37] <Reedy>	 apc_fetch et al no longer exist in PHP 7
[22:36:41] <Reedy>	 it's apcu_fetch
[22:39:07] <Reedy>	 I'll finish up https://gerrit.wikimedia.org/r/#/c/299498/ if someone tells me if apcubagostuff is the right way to do it
[22:39:14] <Reedy>	 it seems, either way alone isn't gonna work
[22:39:29] <Skizzerz>	 Krenair: try installing php7.0-apcu-bc
[22:39:31] <Reedy>	 due to the versions we support of zend php
[22:39:40] <Reedy>	 Skizzerz: ubuntu doesn't package it
[22:39:44] <Skizzerz>	 bleh
[22:39:46] <Reedy>	 so you've gotta install via pecl directly
[22:39:50] <Skizzerz>	 then that
[22:39:58] <Krenair>	 yep: N: Unable to locate package php7.0-apcu-bc
[22:39:59] <Skizzerz>	 but apcu-bc provides the apc_* versions of the functions
[22:40:16] <Reedy>	 telling people to pecl install that..
[22:40:20] <Reedy>	 Isn't a long term solution
[22:40:26] <Skizzerz>	 correct
[22:40:33] <Skizzerz>	 but short term fixes until we fix mw to use apcu_*
[22:41:05] <Reedy>	 If someone confirms my desired approach, I'll do it
[22:41:16] <Reedy>	 considering we apparently support PHP 7 on 1.27
[22:41:20] <Reedy>	 So it's gonna be broken for a few people
[22:41:24] <Skizzerz>	 making a separate apcu cache type?
[22:41:34] <Reedy>	 yeah
[22:41:34] <Skizzerz>	 er, bagostuff and the like
[22:41:39] <Reedy>	 That's about all we can do
[22:41:51] <Reedy>	 otherwise we're function_exist-ing
[22:41:54] <Reedy>	 possibly caching it
[22:42:19] <Reedy>	 Oh, and _inc and _dec have behaviour changes
[22:42:22] <Reedy>	 https://gerrit.wikimedia.org/r/#/c/299498/1/includes/libs/objectcache/APCBagOStuff.php,unified
[22:42:24] <Reedy>	 See the bottom of that
[22:42:57] <Skizzerz>	 imo function_exist in the installer to detect what version of apcu is installed, and select the correct bagostuff from that
[22:43:03] <Reedy>	 yeah
[22:43:06] <Reedy>	 which works for most of it
[22:43:20] <Reedy>	 but then in other code, we have apc_* hardcoded for some reason
[22:43:28] <Azhure>	 Have there been any reports regarding Categories not populating from pages in 1.27?
[22:43:38] <Reedy>	 MemoizedCallable
[22:45:19] <Skizzerz>	 is there a reason MemoizedCallable exclusively uses APC?
[22:45:26] <Reedy>	 Ask Odysimus
[22:45:27] <Reedy>	 ffs
[22:45:29] <Reedy>	 Ask ori
[22:45:46] <ori>	 as opposed to?
[22:45:58] <Skizzerz>	 going through the other mw caching mechanisms?
[22:46:10] <Skizzerz>	 (e.g. so it can use memcached or whatnot instead, if configured)
[22:46:12] <Reedy>	 I guess with it being in libs, it's supposed to not be MW dependent
[22:46:26] <Skizzerz>	 hmm, that would make sense
[22:46:32] <ori>	 that, plus
[22:46:44] <ori>	 the bottleneck in modern web applications is usually the network
[22:47:11] <ori>	 memoizing a function to apc can make sense, to memcached usually not
[22:48:12] <Skizzerz>	 so I guess 2nd question is: given two (incompatible) apc(u) implementations, do you care that apc is always used if available, or do you only care about the most recent?
[22:48:59] <Skizzerz>	 I guess if  you move function_exists to the constructor, you won't have the overhead of 2 calls every time you want to store/load something
[22:49:02] <Skizzerz>	 so supporting both is easier
[22:51:12] <bawolff>	 Apc and apcu cant be installed together
[22:51:23] <bawolff>	 so that should be moot point i think
[22:52:01] <Reedy>	 just the back compat wrapper
[22:52:20] <Skizzerz>	 bawolff: I was referring to if ( function_exists( 'apcu_store' ) ) { ... } elseif ( function_exists( 'apc_store' ) ) { ... } constructs all over the place
[22:52:41] <Skizzerz>	 (all over the place = in two places)
[22:52:44] <Skizzerz>	 :P
[22:53:26] <bawolff>	 Oh. I thought you meant autodetect for which class to use
[22:54:21] <Skizzerz>	 depending on the version of apcu installed, it either has apc_* functions or apcu_* functions (php 7 version of apcu is apcu_*, php 5 version is apc_*)
[22:54:57] <Skizzerz>	 I'm trying to find if the php 5 version also has apcu_*
[22:55:01] <Skizzerz>	 which would make life a lot easier
[22:55:23] <Reedy>	 Depends what version of the pecl extension..
[22:55:27] <Skizzerz>	 but I'm having a heck of a time finding an older version of the docs
[22:55:48] <Reedy>	 apc_fetch says (PECL apc >= 3.0.0)
[22:55:57] <Reedy>	 apcu_fetch says (PECL apcu >= 4.0.0)
[22:56:07] <Skizzerz>	 PECL apc is the full-fat version
[22:56:17] <Skizzerz>	 (e.g. with opcode cache)
[22:56:23] <Skizzerz>	 I think
[22:56:38] <Reedy>	 should be
[22:58:30] <Skizzerz>	 ah
[22:58:42] <Skizzerz>	 Reedy: I think this is going to be simpler than I initially thought
[22:58:49] <Reedy>	 oh?
[22:58:59] <Skizzerz>	 apcu 4 is the PHP 5.5 version, apcu 5 is the PHP 7 version
[22:59:11] <Skizzerz>	 apcu 4 provides *both* the apc_* and apcu_* variants of functions
[22:59:36] <Skizzerz>	 and since as of 1.27 we require PHP 5.5+ where original APC no longer works, we can just drop that entirely I think
[22:59:52] <Skizzerz>	 e.g. use apcu_* exclusively and not have to care about whether or not apc_* exists
[23:00:31] <Reedy>	 Ah, so my initial patch was alright
[23:00:38] <Reedy>	 Bar the fact of hte inc/dec changes?
[23:01:05] <Reedy>	 hmm, yup
[23:01:07] <Reedy>	 5.5.9
[23:01:09] <Reedy>	 > var_dump( function_exists( 'apcu_fetch' ) );
[23:01:09] <Reedy>	 bool(true)
[23:01:32] <Reedy>	 Skizzerz: Though, it doesn't help us for hhvm
[23:01:38] <Skizzerz>	 hmm
[23:01:38] <Reedy>	 Which doesn't support apcu_ ye
[23:01:39] <Reedy>	 t
[23:01:43] <Reedy>	 https://github.com/facebook/hhvm/issues/6784
[23:01:52] <Reedy>	 brilliant, eh?
[23:02:20] <Skizzerz>	 yeah
[23:02:26] <Skizzerz>	 could make a shim/wrapper library?
[23:02:46] <Reedy>	 indeed
[23:02:57] <Reedy>	 I'm not sure if that's better or worse
[23:03:12] <Skizzerz>	 idk either
[23:03:51] <Reedy>	 we do do this in globalfunctions
[23:03:51] <Reedy>	 if ( !function_exists( 'hash_equals' ) ) {
[23:03:52] <Reedy>	 etc
[23:04:02] <Reedy>	  * Re-implementations of newer functions or functions in non-standard
[23:04:02] <Reedy>	  * PHP extensions may be included here.
[23:04:16] <Skizzerz>	 I'm not exactly the best person to determine if "hacky" code is good or not, because I tend to write a ton of it >_>
[23:04:24] <Reedy>	 ori: thoughts?
[23:04:31] <Reedy>	 apcu wrappers in GlobalFunctions?
[23:04:50] <Reedy>	 Or APCuBagOStuff and various function_exists apcu?_ where appropriate
[23:05:29] <ori>	 Not sure, off the top of my head. It seems like they wouldn't just rename apc_* unless there were some significant changes
[23:05:47] * ori has g2g
[23:05:53] <Reedy>	 PleaseStand suggests it was "only" in dec/inc
[23:15:40] <Reedy>	 I filed https://phabricator.wikimedia.org/T140961
[23:20:48] <Azhure>	 Since the conversation has died down some-- I just upgraded to 1.27 a few days ago, and pages are not populating into their respective Categories. It's not a syntax error, I've checked. I tried to run the maintenance script, but it didn't resolve the issue. I've just gone through the Category tag on the bug repository, but I didn't find anything. Is anyone else having this problem?
[23:28:10] <Krenair>	 Thanks for your help Reedy, Skizzerz 
[23:28:34] <Krenair>	 next thing for me to figure out: restbase :/
[23:29:16] <bawolff>	 Azhure: Probably a job queue issue
[23:30:06] <Azhure>	 Ah. Thank you. I'll look into it.
[23:30:56] <bawolff>	 Try running runJobs.php
[23:31:24] <bawolff>	 If that fixes it, then there is another config option to disable async job queue you should enable, but i can't remember its name
[23:33:19] <Reedy>	 $wgRunJobsAsync
[23:34:22] <Azhure>	 Aha! that DID fix it
[23:34:50] <Azhure>	 I'll look up that
[23:34:54] <Azhure>	 Thank you very much, bawolff
[23:39:16] <Azhure>	 Awesome, I think I've got that sorted out. Thank you again, bawolff, Reedy :)
[23:39:18] <Azhure>	 I appreciate it.
[23:39:21] <Azhure>	 Take it easy folks!