[06:47:03] JD|cloud: around? [06:47:08] Need a deletion [06:47:12] yes [06:47:52] RhinosF1: do you still need it? [06:48:05] JD|cloud: see pm [10:46:45] The extensions "WikiEditor" and "CodeEditor", which I have installed on my wiki, appear correctly in "Special:Version", instead they don't work. [10:51:13] The extensions "WikiEditor" and "CodeEditor", which I have installed on my wiki, appear correctly in "Special:Version", instead they don't work. [11:54:58] I am having problems with the extensions "WikiEditor" and "CodeEditor", which I have loaded in LocalSettings.php. They display correctly in "Special:Version", but they don't work. [12:03:35] slsisksjs: Check your browser console for any javascript error [12:11:51] No. There are not errors. [12:19:58] It may not be enabled in your preferenc... he left [14:24:10] Hi - does anyone know how to make a red ("destructive") OOUI icon in PHP? [14:24:28] I can make a regular black icon with code like this: new OOUI\IconWidget( [ 'icon' => 'notice' ] ) [14:25:12] However, I don't know how to make a different color/family. I tried this, but it still produced a black icon: new OOUI\IconWidget( [ 'icon' => 'notice', 'flags' => 'destructive' ] ) [14:43:55] I think destructive is for buttons and not icons [14:44:07] ugh he left... [14:54:15] Vulpix: I'm back! And I checked the channel logs, so I saw your response. [14:54:40] Does that mean that there's no way to just display a red icon by itself? [14:55:36] Does it make sense in the absence of an action button? [14:56:52] I guess not. :) [14:56:57] Looks like some of them accept the destructive flag but others render with the same color https://doc.wikimedia.org/oojs-ui/master/demos/?page=icons&theme=wikimediaui&direction=ltr&platform=desktop [14:58:05] That would explain the combinations of icons - I didn't really understand how the combination of icon (info, notice, warning, error, alert) and color (black, yellow, orange, red, blue) was decided. [14:58:53] I still don't fully understand, to be honest - though I guess the color red is only used as part of a button that does a potentially destructive act. [15:02:09] Vulpix: thanks - I had clicked on that "Destructive" tab before, but didn't understand why it was a smaller subset of icons that had turned red. [15:03:49] I don't understand it neither. Maybe those icons are separate and not just the originals with some color filter to change the colors, and they decided to not invest time in recoloring all of them :) [15:04:07] Recoloring all of them shouldn't take much effort however [15:05:39] Well, your explanation makes sense - that most of these should always be black, unless they're part of a button. [15:06:27] If I understood you correctly before. [15:08:10] Yes. Destructive is an action, then you'll flag a button as destructive, not a descriptive icon or similar [15:12:02] Yes, okay. That still doesn't explain the orange ("warning") or yellow (no description) colors for icons... (https://commons.wikimedia.org/wiki/Category:OOUI_icons) [15:13:49] It would be great if there were some single document that explained all the combinations, and when to use each one - some of it is explained in different places, but it doesn't look like there's any one place that explains all of it. [19:54:12] bd808: Hm.. I just realised, the new toolforge domain means language preferences will no longer be shared/central for Intuition-localised tools. So the idea of this "preferences" page will likely no longer have any place. https://tools.wmflabs.org/intuition/ [19:54:34] Right now the minimum ways tools integrate is by having their "Change language" button go to /intuition/?redirectto=mytool [19:54:44] so it bounces back to their tool after choosing a language [19:55:09] or maybe it could work as a *.toolforge.org cookie if we allow those [22:03:33] Krinkle: we don't have anything explicitly setup to disallow setting a cookie with "domain=.toolforge.org;path=/", so at least until we find that we have to do that it should work. [22:09:02] bd808: ah okay, I thought that was one of the motivations for it. I suppose the main benefit isn't per se that cookies can be shared, but rather that they no longer /have/ to be shared. [22:09:43] I suppose that was previously possible with path=/mytool/ but certainly harder depending on the abstractions in use. More easily messed up. [22:10:18] another thing is that they'd have their own localStorage area now. [22:10:27] which is neat (and no longer allows sharing) [22:11:07] oh wait. didn't we sign up for it to be recognised as a public suffix? That means cookies can't be shared, in the same way that you can't set a cookie for .com, .co.uk or .github.io [22:11:30] I guess not then :) [22:11:39] ah, yeah once browsers pick up the public suffix that should close the hole [22:12:33] breaking your functionality is not awesome, but you may have the single legitimate use of the shared host :) [22:12:59] requiring users to set their preference for each tool isn't great, but I suppose not too bad (most people use only a handful of tools). The main bit I'm pessimistic about is rendering the UI within each tool. [22:13:47] I have to admit that I know Intuition exists, but I have never looked into what it can do and how it does the work [22:14:21] bd808: by when will *.toolforge.org access be canonical/redirected for the long tail? [22:14:55] Krinkle: 2020-06-15 is the semi-arbitrary date we picked [22:14:58] also, it would help avoid confusion by allowing tool to canonicalise in both directions for now. [22:15:06] e.g. intuitoin doesn't work for https://guc.toolforge.org/ right now [22:15:11] as the cookie is not there [22:15:27] I mean it works in so far that it is always English [22:17:46] Krinkle: you can manually setup the ingress object for guc.toolforge.org to redirect back to tools.wmflabs.org/guc, but I don't really want to add that as a proper "feature". The manual fix would be very similar to what I documented at https://wikitech.wikimedia.org/wiki/User:BryanDavis/Kubernetes#Redirect_requests_for_tools.wmflabs.org/my-tool_to_my-tool.toolforge.org [22:18:21] Krinkle: I can write up the exact thing that would be needed if that would be helpful to you. [22:18:58] bd808: oh I see. Hm.. not sure yet. I'm not too worried about my own tools. For those I can just set PHP to normalise if on the wrong host. [22:19:08] more worried about downstream users and end-users "finding" tools on the new domain [22:19:59] but yeah, the k8s approach for those would be easy I guess, especially if some tool admins could add those to any intuitoin tools without the maintainer's involvement [22:20:07] I'll file a task next week and track down affected tools [22:20:44] things are less flexible for grid engine webservices, but that also doesn't make me too sad [22:23:09] I don't have hard evidence, but I believe that there are numerically few tools which can't use Kubernetes for their web UI. Pretty much only things that are a) mixed runtime like php + python in the same tool; b) need to shell out to some system binary for graphics or similar processing; c) need a big library that we haven't put into the Docker container are trapped on the grid right now [22:24:18] a) can be fixed by splitting the tool into multiple tools. b) and c) are things that we are in the early prototype stage of finding a fix for (custom Docker images) [22:47:51] bd808: yeah, just to clarify though, for Intuition specifically, the concern about the UI is mainly because the tool author would need to either make their own UI or somehow call into Intuition's vendor code to present it and then make their own links to/from etc. [22:48:11] I'm hopeful that indeed grid vs k8s won't be an issue [22:51:37] Is there anything I have to do to use Less on mediawiki (running 1.34.1)? Or can I just drop the Less onto MediaWiki:Common.less? [22:57:18] https://phabricator.wikimedia.org/T56864 [22:57:23] This oesn't seem to be a core feature.. [22:58:31] I'm guessing other wikis are possibly using the Less extension() [22:58:33] (?) [22:58:50] Oh, I was reading through https://www.mediawiki.org/wiki/Requests_for_comment/LESS and figured it was a thing for mediawiki namespace, maybe it's only for the backend css [22:59:20] And https://runescape.wiki/w/Special:Version , but it looks like that's added through an extension [22:59:49] Yeah, I think less is fine for skins/extensions.. but not the onwiki stuff [23:00:42] gotcha, thanks for the answers