[03:49:04] Hi there. I've asked at the Cite extension talk page but I'm kind of anxious lol :P Is there any way to restrict access to the Cite functions to non-registered users? Or prevent the Reflist template from showing up to unregistered users? [03:59:52] what's your usecase? [04:00:06] bedivere: You should be able to use CSS to hide it, see [[w:MediaWiki:Group-user.css]]. You could also use [[Extension:UserFunctions]] or [[Extension:RightFunctions]]. This wouldn't stop editors from bypassing it if they really wanted to though. [04:01:14] hi AntiComposite, I have a wiki and people keep on copying the sources without giving attribution, so I kind of want to force them referencing the website while retaining access to sources for registered users. [04:01:27] chrs, thanks, will have a look into them [04:01:46] So far I've tried AccessControl but it didn't work [04:01:53] yeah, CSS would probably be sufficient for that, [04:03:33] in MediaWiki:Common.css set `.references {display:none;}`, then in MediaWiki:Group-user.css set `ol.references {display:block;}` [04:04:10] they'd still be included in the page source, just not visible [04:07:42] thanks guys, it has worked :D [04:08:06] they may still be "found-able" but it's not going to be easy for everyone lol [10:46:05] Reedy, taavi: can I bribe someone into merging https://gerrit.wikimedia.org/r/c/mediawiki/core/+/763978 [13:10:17] Hi guys! I'm trying to upgrade from 1.31 to 1.37. I tried the direct upgrade, I upgraded the database, but mediawiki says "Error 1054: Unknown column 'ipb_sitewide' in 'field list' (localhost)" [13:10:25] What can I do? [13:28:11] Looks like I solved the issue [13:28:25] another issue: I get the warning: Use of InternalParseBeforeSanitize hook (used in VariablesHooks::onInternalParseBeforeSanitize) was deprecated in MediaWiki 1.35. [Called from MediaWiki\HookContainer\HookContainer::run in /var/wwwc/cathopedia.org/mediawiki-1.37.1/includes/HookContainer/HookContainer.php at line 137] in /var/wwwc/cathopedia.org/mediawiki-1.37.1/includes/debug/MWDebug.php on line 375
[13:34:36] InternalParseBeforeSanitize was deprecated <-- [13:34:40] thats ipb_ [13:35:30] hehe weird, it got introduced in 1.32 and removed in 1.35 again? :D [13:36:06] if you have backups, you could try going 1.31 -> 1.32 -> 1.35 -> 1.37 to get through that ipb_ add&removal? [13:36:18] but honestly, we just did a 1.27 to 1.37 , worked fine [13:37:17] paolob: have you updated extensions too [13:37:33] buZz: cannot I remove the deprecated warning? [13:37:54] RhinosF1: yes, it must be Variables [13:38:21] buZz: the ipb_ prefix refers to the ipblocks table and not the InternalParseBeforeSanitize hook [13:38:53] paolob: i would highly not advice to ignore errors [13:38:54] taavi: I know they are different issues [13:39:00] taavi: ah, til [13:39:02] ty [13:39:12] I got the ipb_sitewide solved [13:39:28] looks like that deprecation warning is https://phabricator.wikimedia.org/T250963 [13:41:07] so some extension is causing it [13:41:44] it might be the 'Variables' extension if you have that [14:09:49] zabe: hey, https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AJAXPoll/+/759923 is fataling [14:09:59] buZz: Deprecation errors should generally be ignored unless you're a developer capable of fixing those. In any case, they should be disabled in production websites [14:10:12] *Deprecation warnings, actually, not errors [14:10:59] Vulpix: i do not agree [14:11:22] ok [14:11:26] building fragile houses makes for grumpy inhabitants [14:12:08] Yeah, devs build houses. Wiki operators don't [14:12:30] you dont have users on your wiki that use actual wiki functions? [14:12:39] -like- that variables plugin? [14:12:55] Yes, but those functions are working right now. What do you suggest? [14:13:10] they will be deprecated , why let users use them today? [14:13:23] only to destroy all their work tomorrow [14:14:53] The Variables extension is a particular case of something that will probably break in the future, yes, but my advice to generally ignore deprecation warnings still stands [14:15:21] thats literally what the error is telling you [14:15:40] * buZz happy that Vulpix isnt a sysadmin on a system i use , lol [14:15:49] zabe: https://phabricator.wikimedia.org/T302223 [14:15:56] 'hey this wheel might fall off some day, but go race on it now!' [14:17:25] RhinosF1, lemme take a look [14:17:40] I don't think this should be taken so dramatically. The wheel is working now. Why not use it today and start thinking of alternatives, until the time it breaks arrives? [14:18:29] Vulpix: how many users and setups -are- you supporting? :D [14:18:38] Are you removing the wheel today and stop using the car because it will break in 3 weeks? [14:18:42] 2 users on 1 setup? then by all means , go nuts [14:18:57] 2000 users on 10 setups? yeah dont ignore warnings [14:19:14] Vulpix: 'do you prepare for known future issues?' yes i do [14:19:28] because i dont like calling the firebrigade every time i cook [14:19:48] Me too, but I don't let my readers see deprecation notices on production :) [14:20:13] ty zabe [15:39:34] can https://gerrit.wikimedia.org/r/c/mediawiki/extensions/BlogPage/+/764387 be merged asap pls? [15:40:21] zabe: ^ [15:48:35] Krinkle: ^ [19:35:54] well I gotta say I'm eternally fascinated by commits just...landing like that with zero input from the maintainer (me) [19:36:15] just partially reverted/fixed a similar patch against PollNY recently [19:36:44] but thanks for the patch & +2, RhinosF1 and Krinkle, much appreciated :) [20:19:00] ashley: it gave me quite a shock seeing my deployment tool error out with an exception saying blog page isn't compatible with your mediawiki version [20:40:10] Is it possible to create new groups and page protection levels so e.g. only sysops and members of the "Events committee" group or can edit "Field Day"? [20:41:38] yep [20:41:51] Okay thank you! [20:42:01] kj7rrv: https://www.mediawiki.org/wiki/Manual:$wgRestrictionLevels [20:42:02] A user can be in multiple groups, right? [20:42:05] also yes [20:42:15] note: you restrict things by permission, not group [20:42:20] Okay thanks! [20:42:23] Oh okay [20:42:34] (a permission can be assigned to an arbitrary number of groups) [20:42:44] So I could create an "edit-events" permission? [20:42:48] yes [20:42:56] Okay thanks [20:43:14] the link I gave has an example of defining a new permission and assigning it to groups [20:43:28] Oh okay thank you, I'll read thag [20:43:32] S/thag/that [22:14:30] Hi guys! anyone could help me with https://stackoverflow.com/questions/71213107/mediawiki-circular-dependency-when-creating-service ? [22:14:37] thank you fro your help! [22:17:59] paolob: show us how you are calling that function [22:21:43] paolob: if you need to global $wgParser you are doing something horrifically wrong (typically, using the wrong hook) [22:22:02] for modern code, never bring in parser, user, title, etc. via global statements [22:28:53] What's the difference between `pagelanguage` and pagelanguagehtmlcode`, in e.g. https://www.mediawiki.org/w/api.php?action=query&prop=info&titles=Main%20Page ? [22:31:56] Tamzin: htmlcode is passed through https://gerrit.wikimedia.org/g/mediawiki/core/+/c85a2a8c24fa189ff28493478845306d2f903752/includes/language/LanguageCode.php#165, I assume it's intended for the html lang attribute [22:43:08] moonmoon: It's code that worked in earlier mediawiki [22:43:20] how would I adapt it to modern mediawiki style? [22:49:35] use the objects the hook passes to you [22:50:05] if it isn't passing you a parser or a means to obtain a parser, you're using the wrong hook [22:50:56] the developer documentation on creating new magic words has some more info on which hooks to use, and you can always look at other extensions for example code as well