[00:32:21] Reedy: how on earth does one rebase a cherry pick ... [00:32:30] click edit [00:33:25] I mean on the command line. I did "git rebase" and nothing happened" [00:33:38] you probably need to tell it what to rebase against [00:33:53] It's often easier to just checkout hte branch you care about, and then use git review -x 12345 [01:02:23] You win Reedy. Rightfully so :) [08:58:45] So I just got caching working on my wiki and had a question [08:59:26] I set up APCu on a shared host, and set CACHE_ACCEL [09:00:29] I set my $wgCacheDirectory to /home/user/cache with 755 permissions [09:00:55] It's faster now, but the wiki accidentally logs you out a LOT [09:01:16] If I change pages quickly (before loading is complete) it sends me back to the "Please log in" page [09:01:33] Any idea what could be causing that? The 755 permissions maybe? [09:14:27] kwnmwn: Be sure you set https://www.mediawiki.org/wiki/Manual:$wgSessionCacheType to CACHE_DB [09:23:22] Thanks for that! Working much better now [09:25:00] Any other caching settings I should watch out for? [09:27:51] Is it either an absolute vs relative path to the cache directory better? [09:28:35] e.g. Will "$IP/../../cache" work as well as "/home/user/cache"? [09:43:18] It depends. If the cache directory won't change, you can use absolute. If you expect your wiki and cache directory to always be tied to the same structure (e.g. you can relocate your wiki and cache directory to a new mount point), use relative [09:45:36] Your APCu may be of low capacity (that's why sessions evicted quickly) [09:46:10] In https://www.mediawiki.org/wiki/Manual:$wgMainCacheType you can see the different caching options, and related configuration settings [09:49:02] You may want to set https://www.mediawiki.org/wiki/Manual:$wgParserCacheType to CACHE_DB too [09:59:15] Yeah I'm thinking of changing usernames on my host, so a relative "$IP/../../cache" seems preferable as long as it doesn't affect performance [10:17:57] Thanks for all the help [10:18:14] is performing super fast now and I couldn't recreate the login issue after setting $wgSessionCacheType to CACHE_DB [10:18:25] *my wiki is [10:19:06] Super appreciated, thanks Vulpix [10:19:25] yw :) [12:04:09] I currently have two remotes for my extension, one on Gerrit (https://gerrit.wikimedia.org/g/mediawiki/extensions/WSOAuth) and one on GitHub (https://github.com/WikibaseSolutions/WSOAuth/). Both these remotes have branched commits and I would like to merge both remotes and start using Gerrit exclusively. There are not merge conflicts, but I do not [12:04:09] know enough about Git to merge them. Can someone help me? [12:37:52] where does MW get the domain name to use in email motifications? For some reason my wiki's notifications are somehow using another domain hosted on the same server. [12:38:28] Which domain name? [12:38:36] The address the email is sent as? [12:38:55] no, the content of the email [12:39:00] https://www.mediawiki.org/wiki/Editor_engagement/Email_notifications [12:39:19] those emails, the content is full of some other domain [12:39:38] I'm assuming my host has misconfigured the email setup somehow [12:42:35] I believe the from domain in the email header is wrong too [12:44:49] So... $wgPasswordSender has a default that could get confused like that [12:44:53] * Defaults to "apache@$wgServerName" (in Setup.php). [13:04:15] wmat: do you mean links inside email body? That should be $wgServer or $wgCanonicalServer [13:16:03] there's no instance of the wrong server name anywhere in my config [13:17:07] both domains return the same host when pinged [15:28:39] hi, on my wiki I have a small problem. some pages with content generated by Lua templates/modules don't change after modyfing the module, purge doesn't work, even the purgeList.php maintenance script doesn't do anything, just stalls... [15:35:27] maybe the problem is that it deals with some pages deleted via deleteBatch maintenance script as if they were existing [15:37:34] well, after I restored the page manually and deleted it manually, it works ok... [15:37:54] strange [21:07:35] is there anyy kind of tool to auto block users using a vpn like any kind of filer [21:07:37] filter [21:16:27] Cocopuff2018: nope. You "can" detect if a user is connecting through a proxy, but not through a VPN. That's the point of an VPN after all [21:46:23] hmm [21:46:37] well, you could check them against a dns blacklist [21:46:55] it'd be up to the blacklist to properly detect vpns, though [21:57:32] That's true. Some VPN are well identified with a whois of the IP, but others would require manual inclusion