| 25 Feb 2021 |
 justinl | I can certainly tweak that to look for cookies like <dbname>UserName and/or <dbname>UserId instead of just session. Has anyone else dealt with this? | 18:08:21 |
| justinl | FWIW I also use Basic Auth on my dev wikis for reasons so that currently prevents the dev wikis from caching as well. Probably need to just remove that. | 18:08:56 |
| justinl | FWIW Right now I'm testing the Varnish caching with just if (req.http.Cookie ~ "_session=") { return (pass); } since a logged out user may still have a UserName and/or UserId cookie, but I'm thinking since they're logged out, content they view shouldn't be treated as user-specific. | 22:09:21 |
| 26 Feb 2021 |
| justinl | Another question about the $wgUploadDirectory where images are kept. I use the hashed directory, which I know MW manages everything, but are there any best practices regarding maintenance/cleanup of that directory? FWIW, mine is an AWS EFS filesystem, hosting image contents for 6 wikis, one top-level subdir per wiki, about 132 GB in almost 3.2 million total files (2.6 million under images/thumb, 540k everywhere else). Since the wiki really never deletes anything, the filesystem just grows over time. I've noticed a lot of stuff in temp, deleted, and even some old .nfs* files from when the wikis were in an on-prem DC with a physical NFS server. I know I can safely delete the .nfs files, just wondering if there is anything else that should be done periodically. | 15:28:43 |
| 27 Feb 2021 |
 revansx | (mw 1.34.4) How do I get delete a page in a custom extension with a non-standard content model? | 00:34:06 |
| revansx | * (mw 1.34.4) How do I get delete a page in a custom namespace with a non-standard content model? | 00:34:25 |
| revansx | * (mw 1.34.4) For a user with root access to the server, what is the right way to delete a page in a custom namespace with a non-standard content model? | 00:44:23 |
| revansx | * (mw 1.34.4) For a user with root access to the server, what is the right way to delete a page in a custom namespace with a non-standard content model? (Background - the custom namespace was added from an extension I no longer have installed, but I discovered the residual pages (non-standard namespace and content model) only after I deleted the extension. I have no desire to re-install the extension in order to delete the page from within the wiki. | 00:46:26 |
| 1 Mar 2021 |
| justinl | I just downloaded the latest MW code from GitHub (I have a script that handles the base code, extensions I need, etc.) and this patch (https://phabricator.wikimedia.org/T246594) completely breaks installation of MediaWiki 1.35 on Ubuntu 20.04 (focal) since focal has PHP 7.4.3 in its repo. Fortunately my previous MW download is from Feb 8, prior to the aforementioned patch, so it works and I can use that, but that prevents updating MW for security, etc. This is an unacceptable situation. I can comment on the patch or submit a new bug report, but I wanted to get advice here first. I need to implement my upgrades within the next month or so, so this is an urgent issue for me. | 13:20:52 |
| justinl | I went ahead and submitted a message to the issue. | 13:23:08 |
 hexmode | justinl: Looks like the culprit is https://phabricator.wikimedia.org/T270228 | 15:51:29 |
| hexmode | which leads to https://bugs.php.net/bug.php?id=79487 | 15:52:11 |
| justinl | I was getting the PHP version error that is added in the patch I linked. | 15:52:55 |
| hexmode | yes, but that patch was updated in the bug I linked | 15:55:17 |
| hexmode | looks like Tim has done work to address your issue | 15:55:31 |
| hexmode | see last comment on that bug from today | 15:55:42 |
| hexmode | he mentions focal | 15:55:47 |
| justinl | Hopefully it will be updated in GitHub soon, then. | 15:55:48 |
| justinl | For the time being I'm running the MW code I'd downloaded on Feb 8. | 15:56:04 |
| hexmode | https://gerrit.wikimedia.org/r/c/mediawiki/core/+/667426/ | 15:56:20 |
| justinl | That is, in my new test dev and live environments I'm building to deploy in the next few weeks. | 15:56:24 |
| hexmode | should fix you | 15:56:26 |
| hexmode | trying that patch and commenting on it would help your case and Tim | 15:56:55 |
| justinl | Cool, thanks. I'm definitely still going to wait to go live until after that's been applied and available in the GitHub master branch. | 15:57:17 |
| justinl | * Cool, thanks. I'm definitely still going to wait to go live until after that's been applied and available in the GitHub REL1_35 branch. | 15:57:25 |
| hexmode | of course, but could you test and comment so there is some visibility? | 15:58:02 |
| justinl | Sure. I'm still finishing getting my new live environment working so once that's confirmed, I'll try the new code, hopefully within the next couple of days. | 15:58:42 |
| justinl | Still have to run the MW update.php script and the new SMW updateEntityCountMap against my wikis' databases and that takes a few hours. | 16:00:07 |
| 2 Mar 2021 |
 richardheigl | Hi all. Bernhard has published some interesting numbers about the last SMWCon here: https://mediawikiexperts.blog/smwcon-2020-good-experience-with-the-largest-smwcon-ever/
Feel free to share. :-) | 17:37:21 |
 rundg | For MediaWiki developers working in a corporate environment where you might be handed a SASS or SCSS style implementation, it's nice to know that Jeroen De Dauw created a library for that (on GithHub/Packagist), and the Chameleon Skin can handle 'imports' of SCSS files. | 22:59:39 |
