[02:31:14] <WaterRatj>	 Hello is there a seperate channel for extension help or same channel as this?
[02:35:17] <Krenair>	 depends on the extension really
[02:36:21] <WaterRatj>	 well i just installed the Comments extensions and gives me an database error
[02:36:27] <WaterRatj>	 says it support latest mediawiki
[02:37:49] <Krenair>	 ashley, ^
[02:38:21] <WaterRatj>	 And i don't see any other reportings on the page its strange
[02:39:07] <GEOFBOT>	 you ran update.php ?
[02:39:16] <WaterRatj>	 yep
[02:39:30] <WaterRatj>	 i seee some comment about bug with missing tables but don't see an solution
[02:39:51] <GEOFBOT>	 someone involved with that bug will probably have to comment
[02:41:00] <WaterRatj>	 guess ill need to wait till someone fixes it
[07:38:56] <wicktt>	 Is there any 'Best practices' for translating category links?
[07:47:21] <MakeShift>	 I'm looking to overlay an image on top of another image, to make it appear as if the image is in a certain shape, but I'm unsure whether it's actually possible. Might someone be able to help?
[09:16:17] <Srdjan_m>	 Hi, not sure if this is the right place to ask, but - I can't seem to get the gadget RefToolbar from the enwiki project ported over to a wiki. I got a sysop to copy over MediaWiki:Gadget-refToolbar.js, the messages and MediaWiki:RefToolbarConfig.js but it's still no showing up. Would anyone be willing to see what's missing?
[09:41:49] <hypergrove>	 I'm having trouble with my image directory for wikis in a farm. My log says ... GET /images/MyOffice_Logo_200x142.jpg HTTP/1.1" 301 ... and then ... GET /Images/MyOffice_Logo_200x142.jpg HTTP/1.1" 404
[09:43:08] <hypergrove>	 my apache conf for the virtual host has ...  Alias /images/ "/home/demo.myoffice.wiki/wiki/images/"
[09:45:50] <Vulpix>	 there's some redirect issue there, apache is forcing that first letter of "images" to be uppercase somehow
[09:47:34] <hypergrove>	 vulpix, hello friend. The rewrite directives I've used yield this in the log ... rewrite '/images/MyOffice_Logo_200x142.jpg' -> '/var/www/w2521/index.php', referer: http://demo.myoffice.wiki/Special:Version
[09:48:10] <hypergrove>	 which is totally wrong. I believe my rewrites are based on shorturl rewrites from mw.org
[09:54:04] <Vulpix>	 hypergrove: could you paste your rewrite rules and aliases on dpaste so we can take a look?
[09:54:06] <hypergrove>	 reviewing the rewrites vs https://www.mediawiki.org/wiki/Manual:Short_URL/Apache suggests some change there
[09:54:47] <hypergrove>	 https://dpaste.de/oGjY
[09:56:18] <hypergrove>	 this has the aliases... https://dpaste.de/NMhJ
[09:56:22] <Vulpix>	 well, the first set of rulles will match everything that doesn't exist, pointing that to index.php. The next 2 set of rules won't do anything
[09:57:39] <Vulpix>	 ideally, the index.php rewrite should go last
[10:00:50] <hypergrove>	 i drafted https://dpaste.de/Ebkt last night to replace the other
[10:03:18] <Vulpix>	 also, the alias seem to not work because rewrite rules take precedence: those /images, /site, /test etc folders doesn't exist and rewrites bring them to index.php / thumb.php and doesn't seem to hit the alias thing
[10:03:51] <hypergrove>	 what do you mean they dont exist? they do
[10:04:08] <hypergrove>	 well, /site is a virtual folder
[10:04:36] <Vulpix>	 but does it exist on filesystem?
[10:04:40] <hypergrove>	 i'd think the aliases are applied after the rewrites
[10:04:58] <Vulpix>	 yes, that's the problem
[10:05:44] <Vulpix>	 RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d --> that checks if the file/folder exists on the filesystem
[10:05:55] <hypergrove>	 so i need to pass the /images /site urls through
[10:06:07] <hypergrove>	 so i need to pass the /images /site and other virtual urls through
[10:06:44] <Vulpix>	 that configuration is overly complicated because you don't want to use /wiki for short urls...
[10:07:31] <hypergrove>	 oh, anything that does not exist is passed through
[10:08:30] <hypergrove>	 slah-wiki is not in the url... /site is .... tho /site is aliased to /home/wikiname/wiki
[10:08:36] <hypergrove>	 slash-wiki is not in the url... /site is .... tho /site is aliased to /home/wikiname/wiki
[10:09:30] <Vulpix>	 apparently, not: http://demo.myoffice.wiki/site/ is intercepted as the [[Site/]] wiki page
[10:10:19] <Vulpix>	 of course because of rewrite rules. You're rewriting everything from the hostname to the end, not from /site
[10:10:29] <hypergrove>	 the first rule in https://dpaste.de/Ebkt is ... RewriteRule ^/(index|load).php$ %{DOCUMENT_ROOT}/$1.php [L,QSA,B]
[10:11:01] <Vulpix>	 but you have     RewriteRule ^/*(.+)$ %{DOCUMENT_ROOT}/index.php?title=$1 [L,QSA]
[10:11:36] <Vulpix>	 and the rewrite you mention only matches index.php at the start of the url, not in /site/index.php
[10:12:25] <hypergrove>	 https://dpaste.de/Ebkt  are the rules for a different wiki: http://hub.myoffice.wiki ... I am having similar problems
[10:13:56] <hypergrove>	 http://hub.myoffice.wiki/images/MyOffice_Logo_200x142.jpg yields a 404 also
[10:14:48] <Vulpix>	 well, that 404 hasn't been handled by MediaWiki, so it definitively doesn't exist
[10:17:19] <hypergrove>	 if there is a [L] on a rewrite rule that a url matches, will it then be subject to aliasing?
[10:17:50] <hypergrove>	 I haven't been able to find out how to log aliasing, yet, so I can't see apache's processing in that regard
[10:18:15] <hypergrove>	 or is aliasing only applied to urls that don't match a rule?
[10:25:13] <hypergrove>	 any thoughts about whehter aliasing is only applied to urls that don't match a rule?
[10:32:09] <Vulpix>	 hypergrove: apparently after and before, see http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html#rewritebase
[10:32:55] <hypergrove>	 reading...
[10:38:53] <hypergrove>	 if the aliasing is done before rewrite rules then rewrite rules need to [L] those urls.. is that right
[10:39:10] <hypergrove>	 if the aliasing is done before rewrite rules then rewrite rules need to [L] those urls that are aliased.. is that right
[10:40:47] <hypergrove>	 it seems the process is faster if apache doesnt have to check the filesystem for every url .... particualrly for those urls with index.php or load.php specified
[10:42:41] <hypergrove>	 ah, so I should be checking  for /home urls in the rewrites not the aliases (eg /site, which is to the /home/wikiname/wiki directory)
[10:44:33] <hypergrove>	 so i had it backwards... i'm reading that aliasing is done before the rewrite rules, and then done again after the rewrite rules.
[11:00:54] <hypergrove>	 maybe I should forget the aliasing, instead creating within a <VirtualHost> declarationan apache variable containing the wikiname, and then do rewrites using that variable to the /home directory?
[11:04:14] <hypergrove>	 i've tried adding home to the rewrites (https://dpaste.de/NwUm), and added a final rule for ^/?$ to index.html per mw.org, but still the 404 for http://hub.myoffice.wiki/images/MyOffice_Logo_200x142.jpg -- the file does exist btw
[11:06:53] <Vulpix>	 hypergrove: I think the problem here is that you don't seem to know what kind of URL scheme you want, really. You pretend to have your wiki at alias like /site, but your rewrite rules expect it to be in the document root (/)
[11:07:28] <Vulpix>	 so the configuration rules you've made are failing as a result
[11:13:07] <hypergrove>	 I'm trying to accommodate having wiki resources located in wiki's /home directory. If a user has an icon in the wiki's home directory, the intention is for apache to map /site/myicon.ico to /home/wikiname/wiki/myicon.ico
[11:15:06] <Vulpix>	 what's wiki's /home directory? the installation path (where LocalSettings.php reside)? I don't see what icons have to do with MediaWiki
[11:17:59] <hypergrove>	 theres $wgLogo    = "/images/MyOffice_Logo_200x142.jpg"; ... and ... $wgFavicon = "/site/favicon.ico";
[11:18:33] <hypergrove>	 the former is what is ultimately failing
[11:19:08] <Vulpix>	 I'd say that all images are failing and not just the logo
[11:19:20] <hypergrove>	 yes i'd agreee!
[11:20:30] <hypergrove>	 in the axample, /special:version, it's the logo that is being loaded
[11:21:05] <Vulpix>	 so you've concluded that your wiki URLs should be in /PAGENAME and not /site/PAGENAME ?
[11:22:49] <hypergrove>	 i am trying do implement short urls, yes
[11:25:45] <Vulpix>	 I still don't see the need of those aliases... all wikis seem to have their own domain name. The alias seems redundant
[11:26:02] <Vulpix>	 are you saying the alias is only for the favicon?
[11:31:22] <hypergrove>	 thinking also of css files provided by a user
[11:31:57] <hypergrove>	 and images called for by the css
[11:40:44] <hypergrove>	 here's what's killing me: rewrite '/images/MyOffice_Logo_200x142.jpg' -> '/var/www/w2521/images/MyOffice_Logo_200x142.jpg', referer: http://hub.myoffice.wiki/Special:Version
[11:42:11] <hypergrove>	 this should be aliased to /home/hub.myoffice.wiki/wiki/images/MyOffice_Logo.jpg
[11:43:02] <hypergrove>	 per  Alias  /images/ "/home/hub.myoffice.wiki/wiki/images/"
[12:58:37] <Nemo_bis>	 Ugh 240 "Flow talk page manager‎" items in my watchlist for last day. No idea how people not using enhanced RC can survive. :)
[13:35:58] <Betacommand>	 anyone know why move subpages fails when moving cross namespace? Root page is moved but subpages are ignored
[13:47:20] <Betacommand>	 never mind, goofed with the ns settings, defined the subpages before defining the namespace
[15:11:52] <tuxcraft1r>	 im trying to find two things
[15:12:06] <tuxcraft1r>	 1: the setting to disable user creation
[15:12:34] <tuxcraft1r>	 only manual by wikisysop 
[15:12:49] <tuxcraft1r>	 and i want to revert all changes and delete all users created the past 7 days
[15:13:01] <tuxcraft1r>	 without using a database backup
[15:31:27] <tuxcraft1r>	 i will place back an backup, so only searching how to disable all account creation
[15:31:36] <tuxcraft1r>	 except by wikiops
[15:43:59] <Betacommand>	 tuxcraft1r: one sec
[15:44:06] <Betacommand>	 !account
[15:44:07] <wm-bot>	 There is no such key, you probably want to try: !autoconfirmed, !blacklist, !centralauth, !cookies, !git, !gitaccount, !renameuser, !userapproval, 
[15:44:26] <Betacommand>	 !rights
[15:44:27] <wm-bot>	 For information on customizing user access, see < http://www.mediawiki.org/wiki/Help:User_rights >. For common examples of restricting access using both rights and extensions, see < http://www.mediawiki.org/wiki/Manual:Preventing_access >.
[15:46:12] <Betacommand>	 tuxcraft1r: $wgGroupPermissions['*']['createaccount'] = false;
[15:52:10] <Betacommand>	 anyone have a few seconds to help me with a stupidly easy javascript request?
[15:52:49] <Betacommand>	 Looking to add a short snippet to the bottom of a  page and auto save
[17:10:19] <Fenhl>	 any ideas regarding this error? https://phabricator.wikimedia.org/T43609#1445627
[17:59:00] <tuxcraft1r>	 Betacommand: thx!
[19:29:43] <hypergrove>	 In a vhost declaration, I setenv HTTP_WIKI_HOME and then try to use this environment variable in the target of a rewrite rule, but HTTP_WIKI_HOME is empty... So, how do I do this relatively simple thing?
[19:29:43] <hypergrove>	 [12:23] <hypergrove> i'm using apache 2.4 on ubuntu
[19:30:27] <hypergrove>	 The rule is ..... RewriteRule ^/images/(.+)$ %{ENV:HTTP_WIKI_HOME}/images/$1 [L]
[19:32:32] <hypergrove>	 Any comments are very appreciated, thanks
[19:33:25] <hypergrove>	 oh, within the wiki's <VirtualHost> I have.... SetEnv HTTP_WIKI_HOME "/home/demo.myoffice.wiki/wiki/"
[19:38:18] <hypergrove>	 and in the rewrite log I get .... local path result: /images/MyOffice_Logo_200x142.jpg ... and then the docroot is prepended
[19:39:51] <hypergrove>	 The vhost declaration for the wiki also has ... Alias /images/ "/home/hub.myoffice.wiki/wiki/images/" ... to no avail
[20:05:44] <hypergrove>	 ok, here's a related question. Is it recommended instead to do something like this  in LocalSettings.php..... $GLOBALS['wgUploadPath'] = "/home/{$sitename}/wiki/images"
[20:12:44] <hypergrove>	 No images are displaying in my wiki :( :(
[20:14:15] <hypergrove>	 fwiw, phpinfo does show that I'm setting the HTTP_WIKI_HOME environment variable correctly.... I merely wish to use that variable in my RewriteRule
[20:14:43] <fhocutt_>	 hi valhallasw`cloud, quick question
[20:14:54] <valhallasw`cloud>	 fhocutt_: hey!
[20:15:38] <fhocutt_>	 I'm running a workshop at Wikimania where participants can contribute to api client library evaluations: https://phabricator.wikimedia.org/T101588
[20:16:00] <fhocutt_>	 two questions:
[20:16:32] <fhocutt_>	 it's scheduled for 1 h now, but I'm thinking it might need 2 h for people to get started and make concrete progress
[20:17:13] <fhocutt_>	 thoughts on that? I'm going to start off by talking for ~15 min on the gold standard and what we use the libraries for
[20:17:35] <fhocutt_>	 second question, are you going to be there? 
[20:18:09] <valhallasw`cloud>	 It depends a bit on the audience, I guess, but 1h to get to know roughly how the library works and 1h to evaluate things might be doable.
[20:18:19] <valhallasw`cloud>	 but 2h actually still sounds really short
[20:18:29] <fhocutt_>	 hm, ok
[20:18:39] <valhallasw`cloud>	 and no, I won't be attending wikimania this year
[20:19:28] <valhallasw`cloud>	 but for someone who knows a language well, 1h to get started with the library and another hour to evaluate should be OK, I think
[20:20:01] <valhallasw`cloud>	 I think it's probably easy to get a 'feeling', but harder to really get specific 'x and y should be better' comments
[20:20:04] <fhocutt_>	 I figure that people who know the language can evaluate that, and newer people can test installation, docs, etc
[20:20:18] <valhallasw`cloud>	 that sounds reasonable, yes
[20:20:49] <fhocutt_>	 cool!
[20:21:15] <fhocutt_>	 ty, and sorry I won't be seeing you there
[20:21:17] <valhallasw`cloud>	 specifically for pywikibot, having people tell us 'hey, this is too hard' would be helpful. But that's more pywikibot-as-a-tool (like AWB) than pywikibot-as-a-library (like pymediawiki)
[20:21:28] <valhallasw`cloud>	 Thank you for organizing the session :-)
[20:21:32] <fhocutt_>	 np.
[20:21:35] <valhallasw`cloud>	 and I hope it'll be fun!
[20:21:46] <fhocutt_>	 has pwb made installation any easier in the last year? :P
[20:22:20] <valhallasw`cloud>	 for people using it as a library: yes (now pip installable)
[20:22:25] <hare>	 I installed it earlier this year, did not find it any harder to install than any other Python library
[20:22:26] <valhallasw`cloud>	 for people using it as a tool... not sure
[20:23:57] <fhocutt_>	 cool! So you don't have to run the setup script and the cheat codes? :)
[20:24:15] <fhocutt_>	 does it work out of a virtualenv now?
[20:24:47] <valhallasw`cloud>	 I think a venv should work now, but generate_user_files.py is still necessary
[20:24:47] <fhocutt_>	 (without a file in home/ ?)
[20:25:41] <fhocutt_>	 nice to hear it works with pip now!
[20:36:59] <hypergrove>	 Please see http://apaste.info/JSZ for my code and error log info -- I simply need to know how to properly use apache's environment variables with the target spec of a RewriteRule. Hints appreciated!
[20:51:08] <hypergrove>	 oh darn needed to correct the pasted code: please see http://apaste.info/O8I
[20:51:46] <hypergrove>	 Please see http://apaste.info/O8I for my code and error log info -- I simply need to know how to properly use apache's environment variables in the target spec of a RewriteRule. Hints appreciated!
[20:59:47] <hypergrove>	 No images are displaying in my wiki  .... $GLOBALS['wgUploadPath'] = "/image";
[21:12:29] <hypergrove>	 A question about URLs. Is there a method to impose short-urls on generated URLs, eg I see http://demo.myoffice.wiki/index.php?title=WIP_21421A&action=edit ... I'd rather the user see: .... http://demo.myoffice.wiki/WIP_21421A&action=edit
[21:12:37] <hypergrove>	 A question about URLs. Is there a method to impose short-urls on generated URLs, eg I see http://demo.myoffice.wiki/index.php?title=WIP_21421A&action=edit ... I'd rather the user see: .... http://demo.myoffice.wiki/WIP_21421A?action=edit
[21:34:09] <hypergrove>	 I've been waiting 90 minutes for a helping hand -- any hints are much appreciated
[21:51:04] <onei>	 I guess it's a setting somewhere hypergrove, not sure what exactly though
[21:52:17] <onei>	 having said that I'm not convinced it's not done with a hack
[22:10:08] <hypergrove>	 it works fine by using setenvif not setenv ..... now getting 403 however
[22:11:08] <hypergrove>	 determined that setenv occurs AFTER rewriterule.... setinvif occurs prior ... so am looking at permissions
[22:11:50] <hypergrove>	 onei, thank you for replying!
[22:14:54] <hypergrove>	 the only 'hack' is that setenvif requires a predicate, so it's formulated as.... SetEnvIf Host "hub.myoffice.wiki" HTTP_WIKI_HOME=/home/hub.myoffice.wiki/wiki
[22:15:45] <hypergrove>	 the 403 for the resource is due to permissions... even though ... sudo chmod 777 /home/hub.myoffice.wiki/wiki/images/MyOffice_Logo_200x142.jpg .... and added allowed-all for Directory /home/hub.myoffice.wiki/wiki/images
[22:17:30] <hypergrove>	 i suppose i could set 777 on the /home/.../wiki/images directory
[22:18:31] <hypergrove>	 no that doesnt eliminate the 403 :(
[23:02:26] <hypergrove>	 fwiw my 403 was occurring because I was using 2.2 auth directives in a 2.4 system, specifically I was not using "Require  all granted"