[09:15:02] Does anyone know where the parsoid database is supposed to be by default? On my mediawiki install, I keep getting curl error 6 with the parsoid database whenever I try to use the visual editor [12:25:23] * Reedy wonders what the parsoid database is [13:25:54] S, autowiki browser is not letting me choose taerelvari.miraheze.org/wiki/ as a site, saying "root element is missing" how do I fix? [13:27:42] BurningPrincess1: see https://en.wikipedia.org/wiki/Wikipedia_talk:AutoWikiBrowser [13:28:04] Where would I look please andre__ ? [13:28:11] the link that I pasted [13:28:22] I don't think many people here in #mediawiki know about AWB [13:29:32] Where obn the page I mean? [13:30:24] andre__, do you know how I can fix my error please? [13:31:09] BurningPrincess1, did you read what I wrote? [13:31:40] This isn't a channel for AWB questions, so I pointed to a place where you can ask AWB questions, basically. :) [13:31:48] Okay, thank you [14:52:16] andre__, #autowikibrowser ;) [14:53:23] Lcawte: if that's linked on the wiki page that I linked too: good. :) [14:54:28] Uhh, its in the lead section of the project page, not sure about the talk. [14:56:01] Hello, everyone. I’m Yashi Vijay. New to Wikimedia but willing to contribute and improve my skills by being a part of this community with some helping hand from your side. Looking forward to you all! :) [14:56:30] yashi_vijay, hi and welcome! [14:58:51] thankyou , just wanted to get some links of where to get started contributing. [15:04:13] yashi_vijay: in which area? [15:04:32] yashi_vijay: in general: https://www.mediawiki.org/wiki/How_to_contribute . When it comes to working with code: https://www.mediawiki.org/wiki/New_Developers [15:33:21] I am trying to upgrade mediawiki and get "Wikimedia\Rdbms\Database::getClass no viable database extension found for type 'mysql'" Where do I find the extension that needs to be installed? [15:34:06] You're missing the php mysql/mysqli extension [15:34:58] how do i access to Apache environment variables in mediawiki? [15:37:53] Reedy: this gets me one step further. But why would update.php throw: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? [15:37:53] Isn't this what update.php should do? [15:38:34] Table 'wikidb.xywikirevision_actor_temp' doesn't exist [15:44:45] There is a script /maintenance/archives/patch-revision_actor_temp-table.sql shouldn't that be invoked by update.php if the table is missing? [15:46:26] Yes. But depending on what version you're upgrading from and what you're upgrading too... There's been a few edge cases [15:47:17] nah, got it. [15:50:55] Reedy what would /*i*/ have to be replaced by when indexes are created? [16:42:12] Reedy: with first migrating to 1.31.1 and then to 1.35.1 I got it working. [19:11:23] is the undoafter parameter required for a single-edit undo? the API docs imply it isn't (the index.php docs aren't explicit) but if you leave it out, it doesn't work. the popups gadget doesn't use the undoafter parameter, so it doesn't work there [20:21:15] Skizzerz: o/ hello :) [20:25:31] Jdlrobson: hi! [20:26:31] so, I'll preface this by saying I haven't really looked into vue that much yet. I knew it was being a thing to replace OOUI but didn't really think of it in the context of skins using it for their base templating [20:28:53] understood [20:29:54] my concerns mostly lie around extensibility and how easy it is to customize a skin. Right now the status quo (speaking in the viewpoint of someone who isn't already very experienced in making mediawiki skins) is that you cry in terror when looking at the skin implementation, fork it, throw random changes at the wall to see what sticks in order to get whatever visuals you're going for, and call it a day. Then cry some more when you update the wiki [20:29:54] again and everything breaks horribly [20:30:58] In my experience, a lot of changes are pretty simple reskins of existing skins -- changing color schemes, adding fancy background images, etc. I feel we should support such customizations natively in the skins mediawiki ships so that those people don't *have* to fork a skin to make said customizations [20:31:46] however, the Hooks system isn't particularly great for that. It still requires some dev knowledge, and there's no guarantee that all of the skins implement the same hooks in the same way (this has been an issue in the past) [20:32:58] so I wanted the templates themselves to be extensible, where extensions and sysadmins can manipulate them in a fashion that's as future-proofed as possible [20:33:46] same with RL modules, so that e.g. a sysadmin can override some core LESS variables to define color schemes, and then the skin RL modules process those modified variables [20:34:58] if implemented properly, I believe this system could also be useful for the development of entirely new skins as well -- if we break down common things into component templates, and skins just reference those templates and lay them out in the way they want, then implementing a new skin can be as simple as just changing the order those components are included in [20:35:38] this is where Mustache fell apart -- sub-templates in Mustache are evaluated at runtime and it's not possible to pass input into them (they inherit any template variables passed into the main template) [20:36:07] But this still suggests a knowledge of CSS / JS ? [20:36:12] which led to two issues: 1) poor runtime perf compared to pre-compiling everything, and 2) components cannot be re-used easily multiple times in a single template [20:37:21] The hooks issue however is fixed [20:37:25] Jdlrobson: for most things, probably. We can expose color schemes or the like in particular via some easier to use UI that doesn't require such knowledge. Like a special page that defines the general color scheme for the site. Plug in the colors you want (via a color picker) and it gets applied [20:37:28] All skins run the same hooks consistently now [20:37:36] all core skins do, yes :) [20:37:49] Sure... working on the latter, but getting there ;-) [20:38:06] yeah this is definitely an epic, and I don't anticipate a single RFC doing all of these things [20:39:04] so one example that may be illustrative: injecting ad blocks [20:39:50] have you read the revised https://www.mediawiki.org/wiki/Advertising for 1.36? [20:40:10] Provided skins are not using deprecated methods and thus throwing warnings those should be supported out of the box [20:40:46] let's say a sysadmin is totally fine with vector or timeless or whatever default skin, but wants to place some ads somewhere on the page to help increase site revenue and offset costs. Current extensions that do that are pretty fragile [20:41:01] No extensions should be needed [20:41:17] I looked at the page, and what I was proposing in my vision would be a lot more flexible: the sysadmin could (without using an extension) add the ad block *anywhere* on the page in a way that is robust against future updates [20:41:31] If an extension is needed a bug should be filed against the skin telling it to update itself as its using deprecated methods [20:41:37] bbiab i need to break for my lunch [20:41:39] and without us needing to pre-emptively think of all the places that would be an add appropriate hooks [20:41:48] np [20:44:28] (gives me some time to research vue) [20:57:20] Am also interested in whether you have tried building a skin with https://skins.wmflabs.org/#/add [20:57:45] not yet, will try it out later though! [20:57:47] Anything that /extends/ an existing skin is not sustainable and will require updates with new mediawiki releases no matter what you do [20:58:03] doesn't necessarily have to! [20:58:33] in some cases yes that's unavoidable, but breaking the skin templates into re-usable components should help with that -- if that particular component wasn't modified between MediaWiki versions, then chances are your modifications to it are also fine [20:58:55] I think for sys admins taking that approach something like the above tool or https://www.mediawiki.org/wiki/Skin:Schulenburg (with tweaks ) might be useful [20:59:15] A skin could be made that reads from MediaWiki templates in the same way that MediaWiki:Common.css is used [20:59:56] so e.g. in my vision core would ship (using .tpl to represent whatever template language we settle on) a sidebar.tpl, footer.tpl, content-actions.tpl, ... [21:00:22] the skin itself would include those templates in the appropriate spot and put its own DOM and CSS/LESS (and maybe JS) around it [21:01:44] the existence of those sub-templates provides extensibility points more general than the current skin hooks we have -- we can have a hook on template load that lets sysadmins or extension authors scope their changes to a particular template [21:02:52] and as a bonus, if most skins re-use the DOM from those templates, it makes it easier for Gadget authors to write skin-agnostic gadgets [21:05:27] Jdlrobson: looking at your wmflabs site, I see you're already largely doing what I propose in terms of breaking it into components, so I think we're actually mostly aligned with each other [21:06:54] Yeh the components bit still needs to be defined, as skins use different components, but as we build out the Vue.js component library, we should be able to draw from there for common ones [21:07:24] The standardized data used by the templates ensures things like consistent IDs for gafgets [21:07:43] yep, that's a huge benefit of shipping re-usable components in core [21:09:06] one thing I'd like to offer that your skinomatic tool doesn't is the ability for sysadmins to e.g. customize those LESS variables *without* having to build a separate skin (that would then need to be re-built on upgrade) [21:09:50] I don't believe that should block any work of standardizing and cleaning up the existing skin system, but it's a good next step imo [21:14:29] Jdlrobson: does that help explain what I was getting at with the RFC I wrote a while ago? [21:15:04] I can work on an example if you want; I think your RFC and mine are completely compatible with each other (mine has bigger scope, but yours fits within said scope) [21:16:54] a lot of the improvements I'm thinking of won't be feasible with Mustache as-is due to the inability to customize data passed into partials, but moving to Vue it looks like those things will be possible with sub-components. Although I'm not entirely sure how a skin built entirely in Vue works when js is disabled on the end user's browser [21:20:32] the LESS customization is something we are tackling from a different angle [21:20:45] and doesn't involve Mustache or templating [21:20:58] First we need to do the basics which is audit all the existing styles and come up with sensible defaults [21:21:07] sure, I'm not saying what I proposed as an implementation is the best or only way to do it :) [21:21:08] There is an RFC around theming [21:21:55] and https://phabricator.wikimedia.org/T122924 [21:22:52] TBH i've not thought in too much detail about this, but my opinion is that at some point in the future we need to do something to support a dark mode and that will require a dark and light theme. To start with it makes sense to focus on Vector or Minerva since that's where most of our audiences are and then work from there to provide something more generic [21:23:23] Extension:Theme has a bunch of hacks in it that won't be necessary with better LESS variable override support [21:23:24] We've introduced skin variables recently that allows skins to override defaults, but there's a long way to go for this to be practical. [21:23:54] In Vector I'd like to see configurable base variables, but that requires rearchitecturing Vector - not the skin system :) [21:23:57] (I should know, I wrote the extension originally :) ) [21:24:33] well there are some base variables that would be useful to be standardized across every skin [21:24:36] things like brand colors [21:24:43] Sure, that's definitely the purpose of skin variables [21:24:50] so that if it's customized once, it applies to every skin enabled [21:25:45] https://github.com/wikimedia/Vector/blob/master/resources/mediawiki.less/mediawiki.skin.variables.less [21:26:11] So skins can define a file like this [21:26:32] anyway I think merging my RFC into yours probably isn't a good idea since mine covers a lot more than yours does. At the same time, it's also massive in scope for an RFC and would likely require multiple actual RFCs for the implementation bits. I'm thinking maybe close mine out and just get the points I was talking about that we can all agree upon into a roadmap somewhere? [21:26:39] which overrides https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.less/mediawiki.skin.defaults.less [21:26:50] which only has 2 variables so far [21:27:20] what you'd be asking for is an additional way for sys admins to override those variables in certain situations [21:27:46] right, either via hook or on-wiki somehow [21:29:45] (or convert my RFC into a roadmap epic instead with it formatted more as a wishlist without any specific implementation details) [21:31:20] sounds good but yeh when you said "Templating" I was coming at it more from the HTML angle [21:31:33] oh, I was too, don't get me wrong :) [21:31:51] The CSS and theming concerns are still valid I just think there's a lot more to do before we can consider solutions there [21:32:36] in terms of your RFC, something I'd like to do for it is define that set of re-usable components (partials), which would make future extensibility in that regard easier. Bonus points if we can load partials from multiple directories (I'll need to investigate this) [21:33:07] where skin partials are used before core partials [21:34:50] we can build that set out based on what we see in common in porting over the core skins; I can help out with that endeavor if you'd like [22:36:14] Does anyone know where the parsoid database is supposed to be by default? On my mediawiki install, I keep getting curl error 6 with the parsoid database whenever I try to use the visual editor [22:36:51] says it can't resolve hostname [22:45:01] Has anyone worked with ServiceTemplateNode and Swagger? I am having trouble including schemas defined in external files within my Swagger spec. [22:49:43] burning: What's the parsoid database? [23:09:54] * saper was too afraid to ask [23:10:37] heh