| 23 Feb 2021 |
 hexmode | * Dokuwiki is not MediaWiki. Much different.
| 16:38:23 |
| 24 Feb 2021 |
 SeriousFun01 | In reply to @maxhryhoryev:matrix.org
Dokuwiki and MediaWiki are the same? They both have wiki in the name (and php in the code) but that is where similarities end :-). Dokuwiki is simpler (eg file based, no db backend) | 08:08:22 |
 richardheigl | I think we've touched on this here before: Elasticsearch is changing its licensing system with version 7.11. After that, there will no longer be a recognized open source license for Elasticsearch.
We are monitoring the situation. Amazon and Logz.io have announced forks, but so far there is nothing to be seen.
Is the Wikimedia Foundation already thinking about this? I assume that all MediaWiki organizations will agree on the same solution and that will depend on the WMF. | 11:48:04 |
 cicalese | Yes, they are indeed already thinking about this, but I do not know the current thoughts. I will ask. | 11:54:11 |
 tgr | https://phabricator.wikimedia.org/T272111 | 12:22:27 |
| cicalese | Thank you, @tgr. I was just looking for that! 😁 | 12:27:36 |
| 25 Feb 2021 |
 justinl | Hey all, I'm testing MW 1.35 for an upgrade from 1.34 and running into a Varnish problem. It seems like with 1.35 it's always setting a session cookie named <dbname>mwuser-sessionId, which is causing Varnish to never cache anything since a standard VCL block recommended for MW Varnish config is | 18:05:40 |
| justinl | if (req.http.Authorization || req.http.Cookie ~ "session" || req.http.Cookie ~ "Token") { return (pass); } /* Not cacheable by default */ | 18:05:42 |
| 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 |
