[14:24:39] <kh0ver>	 Hello is it possible to make some pages that are made in MediaWiki only visible for selected logged in users of the wiki? And how?
[15:01:23] <Vulpix>	 kh0ver: Unless the entire wiki is made private, no, this is not possible
[15:01:42] <Vulpix>	 !cms
[15:01:43] <wm-bot>	 Wikis are designed for openness, to be readable and editable by all. If you want a forum, a blog, a web authoring toolkit or corporate content management system, perhaps don't use wiki software. There is a nice overview of free tools available at <http://www.opensourcecms.com/> including the possibility to try each system. For ways to restrict access in MediaWiki, see !access.
[15:03:21] <kh0ver>	 !access
[15:03:22] <wm-bot>	 For information on customizing user access, see <http://www.mediawiki.org/wiki/Manual:User_rights>. For common examples of restricting access using both rights and extensions, see <http://www.mediawiki.org/wiki/Manual:Preventing_access>.
[15:10:10] <kh0ver>	 ok thank you
[15:43:53] <grayanone>	 Hi. Am having an odd problem: seeing different page content depending on whether I'm logged in or not. The wiki is updated nightly via a script which select only the latest revisions (to keep transfer size down).  Am thinking there's an issue w/my sql. Would appreciate an sql whiz eyeballing my queries.
[15:57:50] <Reedy>	 grayanone: That sounds more like caching...
[16:06:57] <grayanone>	 Reedy: I've emptied cookies, cache, etc etc etc.  Same result.
[16:07:08] <grayanone>	 Just got my bro in Prague to double-check; same result
[16:07:44] <Reedy>	 I don't see how it could be SQL unless you were putting some variance in for users
[16:17:11] <grayanone>	 not afaik.
[16:26:13] <grayanone>	 Reedy: I commented out the foll. in localsettings.php and it now shows the same contents irrespective of being logged in or not.  $wgGroupPermissions['*']['edit'] = false;  $wgGroupPermissions['*']['createaccount'] = false;
[16:26:54] <grayanone>	 plus also function NoLoginLinkOnMainPage( &$personal_urls ) { ...}
[16:30:39] <Reedy>	 the foll?
[16:34:50] <grayanone>	 Reedy: foll = following
[16:37:59] <Vulpix>	 grayanone: do you have "file cache" enabled on the wiki?
[16:43:10] <grayanone>	 Vulpix: yes. I have: $wgUseFileCache = true; $wgCacheDirectory = "$IP/cache"; $wgShowIPinHeader = false; $wgEnableSidebarCache = true;
[16:43:47] <Vulpix>	 The file cache is for anons only. Depending on how do you make those edits, the file cache may not be purged
[16:44:19] <Vulpix>	 Editing LocalSettings.php, depending on your settings, causes CacheEpoch to be bumped
[16:47:02] <Reedy>	 [16:57:35] <Reedy> grayanone: That sounds more like caching...
[16:47:03] <Reedy>	 ;P
[16:48:25] <grayanone>	 Vulpix: (feeling stupid) where is the cache stashed? can't seem to find it
[16:49:00] <grayanone>	 Reedy: assumed you meant browser cache. apologies. 
[16:49:09] <Vulpix>	 !wg CacheEpoch
[16:49:09] <wm-bot>	 https://www.mediawiki.org/wiki/Manual:%24wgCacheEpoch
[16:49:47] <grayanone>	 Wulpix: yes just read that page after you posted. but doesnt tell me where it lives.
[16:50:24] <Vulpix>	 the cache of the pages? on $wgCacheDirectory
[16:50:47] <grayanone>	 Vulpix: urrr... I give up. Tell me the answer in words of < 1 syllable
[16:51:41] <grayanone>	 Vulpix: no such dir as $IP/cache that i can find
[16:52:09] <Vulpix>	 $IP means the directory where MediaWiki resides
[16:53:08] <grayanone>	 Vulpix:  ok got it. now am feeling even stupider. thanks
[16:53:39] <Vulpix>	 np
[16:58:25] <grayanone>	 Vulpix: would "touch -m LocalSettings.php"  on a db update suffice to force a cache update?
[16:58:45] <grayanone>	 Vulpix: sorry, "on" should read "after"
[17:05:32] <Vulpix>	 yes
[17:07:22] <grayanone>	 great. thank you very much indeed. although I still can't figure out why different content should be served if logged-in -vs- logged-out
[17:08:15] <Reedy>	 logged in users can customise stuff, logged out users can't
[17:09:09] <grayanone>	 yes... but serving diff content??  I don't understand that
[17:09:46] <grayanone>	 After logging in, I could see the db update version.  Logged out, I could only see the pre-db update version
[17:11:24] <grayanone>	 which implies there are diff caches for diff user groups
[17:50:44] <apa>	 Does anyone know why InterWiki links sometimes add additional underscore to the end of the link. For example i have an entry for freebsd man pages with prefix "man" and url https://www.freebsd.org/cgi/man.cgi?query=$1 when linked from wiki page [[man:man]] the generated link is https://www.freebsd.org/cgi/man.cgi?query=man_ 
[17:52:48] <apa>	 i noticed that the problem occurs with every iw_url with a dot in the url (excluding dots in the domain). There is 3 entries in my interwiki table with that kind of url: man.cgi, wiki.pl and intex.php. all of them works incorrectly and all other interwiki links works as should.
[18:01:55] <Vulpix>	 grayanone: actually, logged-in users aren't served cached content, or at least not from the same layer. There's also the parser cache, but that one is generally purged correctly with edits while the file cache (which is only for anons) is not
[18:19:34] <apa>	 never mind. there was trailing whitespaces in the url.
[18:57:42] <grayanone>	 Vulpix: is there some way to force the caches to flush and update the db b4 dumping? that might solve the problem.
[19:17:56] <DennisRoczek>	 apa: well moreover this channel is about mediawiki and the freebsd folks do not use mediawiki... at least not the links you have provided
[20:12:41] <jorm>	 I feel this bug needs escalation: https://phabricator.wikimedia.org/T220923
[20:16:47] <harmaahylje>	 jorm: does it really work like that, can you log an user out with a get request?
[20:16:57] <jorm>	 yes.
[20:17:04] <jorm>	 i'm opening a DIFFERENT bug for that.
[20:17:20] <harmaahylje>	 :P
[20:18:47] <jorm>	 https://phabricator.wikimedia.org/T220924
[20:19:32] <harmaahylje>	 good catch
[20:21:22] <Vulpix>	 I though this was already a well known popular prank
[20:23:50] <jorm>	 it just got closed as a dupe so i guess so
[20:28:45] <Vulpix>	 URL Shortener could make it more viable for those of us that look at the URL before clicking it :P
[20:42:07] <legoktm>	 hello
[20:47:51] <legoktm>	 URL shorteners suck
[20:48:22] <legoktm>	 jorm: thanks for reporting/testing stuff
[22:50:16] <also_uplime>	 Hello! I installed the mailgun extension for mediawiki, and confirmed it is present in Special:Version, but when I try to use it, I get an error Class 'Http\Adapter\Guzzle6\Client' not found
[22:50:47] <Reedy>	 !composer
[22:50:47] <wm-bot>	 Composer is a dependency manager for PHP. MediaWiki uses it to include certain external libraries. See https://www.mediawiki.org/wiki/Composer for more details. For information on how to install MediaWiki dependencies with composer see https://www.mediawiki.org/wiki/Download_from_Git#Fetch_external_libraries
[22:50:54] <also_uplime>	 sorry, hit enter too early. It looks like I need to add something to autoload.php, but I'm not sure what (haven't used php in a long time)
[22:50:57] <also_uplime>	 Oh, thank you
[22:51:15] <Reedy>	 Third party libraries are mostly brought in via composer
[22:51:46] <also_uplime>	 makes sense, thanks