[10:39:42] anyone got recommendations for the best value webhosts to have: with php7.1+/mysql 10gb space and cpanel access, bonus if it give ssh access too [13:10:11] Is there any way of generating a code coverage report that includes the parser tests, rather than just the phpunit tests? [14:18:24] Sorry guys, but I did not see an answers. I'm trying to add google tag manager to my wiki site using timeless skin. Any suggetion? [14:18:47] Common.js doesnt seem to work with that. Probably doing something wrong [15:47:37] Hey all, I have an odd question. I now have my dev wikis running on nginx but I'm still tuning and tweaking stuff before moving on to a live deployment procedure. My configs are working fine and initially came from a variety of sources to get things working as needed, but I still have one location block from [15:47:37] https://www.nginx.com/resources/wiki/start/topics/recipes/mediawiki/ that I doubt I need, but wondering why it's even there: [15:47:47] location = /_.gif { [15:47:57] What's the point of that wrt mediawiki? [16:05:26] justinl: that defines a path that returns an empty gif. That's not needed for MediaWiki. This is often used for tracking scripts or similar [16:06:29] the 1px gif image inserted on a page that tracks visits [16:09:07] I hoever prefer this approach https://www.mediawiki.org/wiki/Manual:Short_URL/Nginx [16:09:50] Explicitly enable entry points, instead of "allow everything and manually forbid /cache and /maintenance" [16:14:46] Vulpix, ok thanks, I'm aware of the use of empty gifs for tracking, just wasn't sure if there was some other reason I wasn't seeing for explicitly putting it in a basic MW nginx config. [16:16:04] I'm also working towards eventually changing my directory structure to move the MW code and config below the top-level directory, as the link you provided shows (it was one of my references during my nginx config) but one step at a time, I just wanted to get nginx working as essentially a drop-in replacement for apache with no other changes at this [16:16:05] stage in my overall MW overhaul project. [16:17:33] I'm also planning on moving nginx + php-fpm off their current servers where varnish runs to give them their own dedicated servers so I can better tune varnish and nginx/php on their own servers to better optimize server resource allocation and usage as best fits each application. [16:19:39] thanks for help Praxidicae [16:19:54] i wasn't sure at first if he was legit but then i looked at en contribs [16:20:41] the moves don't even make any sense, especially moving a Page to Page/ [16:20:47] it's basically just nonsense [16:21:23] yah [16:21:28] but sometimes on mw i can't tell [16:26:31] justinl: I have mw on the top level directory, this is not problematic. That config is basically mimicking WMF URL structure [16:30:48] Ah. I've had it recommended to me multiple times that MW shouldn't be at the top level, though I've had it that way for years. Since I'm doing such a major overhaul of wiki stuff this year, I've been considering doing that as well, but it sounds like you don't think there's a compelling reason for that layout? [16:47:58] justinl: the main reason mw as top level is discouraged is that it prevents you from having wiki pages that are named the same as actual files and directories [16:48:21] assuming you're using some form of Pretty URLs as well [16:49:35] Yeah our stuff is under /wiki, so there are only a few legit names directly under /, e.g. index.php, api.php, robots.txt, etc. [16:56:31] Here's the general gist of my mediawiki nginx config: https://gist.github.com/justinclloyd/d8c03ecdccef759fff9791960b4a2ac3 [16:57:34] Ah, I thoug "mw as top level" as "/index.php" but "/wiki/Pagename", not "/Pagename" [16:58:39] as long as index.php and the virtual directory for page names are different I can't imagine many issues [16:58:46] I assumed "top level" as both /index.php and /Pagename [16:58:58] Ah gotcha. I'm just trying to use this major overhaul work to take advantage of it being a good time to review and consider everything about my configuration and system architecture. So trying to determine if there are better practices than what I've been doing. [16:59:18] (I have a wiki set up that way, it really doesn't cause any issues in terms of wiki operation, just means certain page names are unavailable to be used) [17:01:46] Skizzerz, gotcha. It's not been a problem for us in the 8 years of these wikis so if there doesn't seem to be a compelling reason, then I won't worry about it. I am, however, thinking about moving the docroots from /var/www/sites to something under /srv/www, including my upload directory nfs mount, just to get them out from under /var since it's [17:01:47] typically meant for other stuff and /srv is used generally for stuff that gets served out. Then I also don't have to worry so much when investigating filesystem disk usage issues, e.g. logging gone wild, having wiki content and an nfs mount underneath /var. [17:03:18] surprised you haven't run into any issues with nfs for your upload directory in 8 years [17:05:08] Typically the only real issue I've had there is occasional nfs timeouts. Used to be on a local nfs server when in our datacenter but after our AWS migration, it's an EFS mount. I didn't really have any other approach to handling the upload directory with a set of load balanced web servers, so I've had to use NFS despite my general dislike of it. [17:10:49] justinl: mw natively supports fs-based and Swift (OpenStack) file backends. https://www.mediawiki.org/wiki/Extension:AWS lets you store uploaded images in S3 [17:11:47] just as something to consider :) [17:13:09] Anyoen know what this means? [17:13:10] 00:01:54.729 [17:13:13] https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Flow/+/601869/4/container.php [17:13:30] I don't see any phan-related suppressions there, nor in .phan/config [17:13:45] You suppression might just no longer be needed [17:13:51] ie it's not doing anything/suppressing anything [17:14:31] oh i'm looking in the wrong container.php file [17:14:33] there is another one [17:14:48] got it :) [17:15:35] Skizzerz I'd seen an older S3-based extension but I don't recall seeing that one before. However, given that we currently have about 300k uploaded images across all of our wikis, totalling over 3.1 million inodes on that efs filesystem (files and directories, due to tons of thumbnails, etc.) I'd be highly reluctant to go through the headache of [17:15:35] converting from the NFS structure to S3, especially for a MW feature that is part of an extension rather than a core feature. [17:16:35] yeah I get you [17:17:05] although "feature that is part of an extension instead of core" shouldn't be an automatic exclusion; a *lot* of extensions are almost necessary for advanced use cases [17:17:20] it's something you should evaluate on a case-by-case basis rather than a blanket exclusion [17:17:49] but yeah with that quantity of images I don't blame you, migrating that to S3 would not only take ages, but be massively expensive [17:18:06] since AWS will happily charge you for exporting the data out of EFS and then again for importing it into S3... [17:18:53] Sure and we rely heavily on extensions, especially (I know...) Semantic MediaWiki. I think we have around 40 extensions in use across all of our wikis, so I don't mind using extensions, but as you're saying, handing off the management of so many images to that process and functionality is just really too scary to contemplate. [17:20:49] Plus I really the only admin of these wikis, so I like to keep things as relatively simple and understandable as possible, given the architectural and performance requirements for our wikis. [17:21:21] If I get hit by a bus, I want this stuff to be as easy to manage for my team and eventual successor as possible.