[08:25:46] Simple question, probably only through an extention. Can I use something like VARIABLE=TEST and reuse my VARIABLE in the rest of the page? [08:28:57] !e Variables [08:28:57] https://www.mediawiki.org/wiki/Extension:Variables [08:52:41] bawolff, thanks for confirming that I need an extention. (yet I'm going to try to keep it vanilla) [08:53:20] finalbeta: The only vanilla way to do it is have it as a template on a separate page [09:12:43] worldchat [10:45:06] Would there be a way to transclude all pages in a category (without doing it individually) on a single page? [10:45:24] I need to have a single page where part of all pages of the category is visible. [11:00:32] worldchat [15:20:45] Chaos (Greek χάος, khaos) refers to the void state preceding the creation of the universe or cosmos in the Greek creation myths, or to the initial "gap" created by the original separation of heaven and earth.[1][2][3] In Hesiod's Theogony (c. 700 BC), Chaos was the first of the primordial deities, followed by Gaia (Earth), Tartarus (the nether abyss), and Eros (Love).[4] From Chaos came Erebus (Darkness) and Nyx (Night).[5] [15:23:26] hopefully Roybent stops the spam [15:34:49] royb [15:34:55] I didn't realize they left [15:35:37] shoudl have mentioned that probably :) [15:35:49] sorry [15:36:15] no worries [16:25:17] anomie: btw, looking over the db abstraction thing I have a couple of comments/changes; should I just be bold and make them (and you can undo if you don't like) or should I float on talk page first? [16:25:31] most of the changes are just clarifying open questions from your initial draft [16:28:27] Skizzerz: It's hard to say without already knowing what they are... Sure, go ahead, then I'll look and see if there's anything I object to. [16:29:16] well I can float them here too ;) [16:29:47] first was your comment about pk should be required -- why not just make it required and add pks to all of our tables as part of the RFC? [16:30:46] the order param of the actual update seems prone to merge conflicts; why not just have version number introduced instead and then hash the json object representation to get a unique key for a particular update? [16:31:28] then for the "check" thing I think each update would have individual checks; so addTable no-ops if the table already exists, and so on [16:31:41] that was about it [16:32:31] (imo the updates should be idempotent, so running the same update more than once doesn't cause anything different to happen) [16:33:11] pk: Meh. We should really do T28741 instead of just slapping a PK on oldimage, unless we need the PK to do that migration in the first place. [16:33:12] T28741: Migrate file tables to a modern layout (image/oldimage; file/file_revision) - https://phabricator.wikimedia.org/T28741 [16:34:21] I don't see why adding a pk temporarily would make the migration any easier or harder, would just be extra work in the interim [16:34:23] Re order: We probably do want to strictly order the updates within a MW version, though. [16:34:49] oldimage is big == *lots* of extra work, probably. [16:35:07] yeah, adding a pk column could likely take hours on commons [16:35:17] *adding and populating [16:37:03] re update ordering, I have an insane idea that is probably not feasible at all, but would basically eliminate updates entirely. We'd just have the base schema, diff that against what's in the db right now, and automatically generate the script to migrate from the current db to what the schema file says it should be [16:37:16] re "check": https://gerrit.wikimedia.org/r/c/437275/ is an example where a separate check would be useful. Also an update can have multiple operations, we want to be able to say "if $table exists, run $script to migrate the data then drop the table". [16:38:34] right, data migrations wouldn't work (easily) in my insane idea [16:38:39] so some updates would still be needed [16:40:54] would updatelog keep track of every update applied or would it only track the most recent? Since the updates are now strictly ordered, we can say "we left off here, so pick up here next time" [16:41:18] latter is probably all we need [16:41:28] I'm hoping to have "diff the current DB against the schema" as a maintenance script, but actually doing the schema change automatically based on the diff seems a bit risky. [16:41:35] so updatelog would basically become a key/value store of component: schema [16:42:37] e.g. core: 1.32.0-wmf12+123, MyCoolExtension: 2.4.0+12, ... [16:43:09] I haven't really considered updatelog. Currently it mostly seems to exist for running some maintenance scripts one time only, and then every such script has a --force to override it. [16:43:33] yeah, but we'll need some way to track what the last-run migration is, so updatelog seems a good place for that? [16:43:40] basically re-purposing it from what it's currently used for [16:45:23] Do we, though? At best it seems informational or an optimization like the maintenance script thing it's already used for. [16:45:48] how else do you know when running update.php which schema changes to apply? [16:46:20] you can do the above-mentioned diff, but that won't help if there are end user customizations of the db schema because then the current schema won't match any of the previous versions [16:46:51] Hello [16:46:54] and checks like "create this table if it doesn't exist" don't help if we later drop the table; you'd be doing busy work that you later discard [16:47:12] by recording, we can know for sure where to pick up [16:47:14] william_: hi [16:47:42] do you need help with something? [16:47:58] Just like you know now which to apply: check the existing schema, either in addTable or as a pre-check. [16:49:21] I'm Brazilian and I'm using the translator to talk about my doubt. Download my web server and unzip it using tar zxvf into / var / www / (change in DocumentRoot). However, to access http: /w/index.php it appears what's inside the file and will not go into the installation. [16:50:20] william_: you do not have PHP installed or set up on your web server. [16:51:47] I used the command available on the mediawiki site: apt-get install php php-apcu php-intl mariadb-server apache2 [16:52:01] Is another package needed? [16:52:21] anomie: imo it'd be cleaner to track; it gets rid of busy work (checking all past updates to see whether or not they need to be applied, and in some cases applying past updates that are now obsolete only to remove them again later), and it would standardize the oneshot nature of those certain maintenance scripts instead of each of them remembering to write to updatelog (both on install and update) [16:53:02] we can add a flag to update.php to re-run everything in that event, or re-run everything from a particular point [16:53:52] william_: sudo apt install libapache2-mod-php [16:54:40] If an updatelog is the primary mechanism of checking if something was already done, though, the "re-run everything" option seems likely to be broken constantly because nothing will check if stuff exists before trying to use it. [16:54:56] hmm [16:55:22] the alternate is to get rid of updatelog entirely, and rework those few maintenance scripts to check if they're needed and exit early if not [16:56:12] Thanks, Skizzerz. MediaWiki is ok in ubuntu 16.04.04 LTS? [16:56:13] (I've had issues with the optional nature of updatelog in the past; it causes issues if a script remembers to put it on update.php runs but forgets to insert the row on installation) [16:56:30] That may not be possible though. The work is sometimes "look through the whole table for entries like X and change them to Y". If there's no good index to find X, checking will take as long as just doing the update. [16:57:55] That problem, at least, has a potential solution: I'm thinking of a unit test that creates the DB from the latest schema, then runs the equivalent of update.php and fails the test if anything actually tries to write to the DB. [16:58:36] hmm yeah [16:58:40] that would work [16:59:32] for the runMaintenanceScript() update operation, should we automatically assume that maintenance scripts are oneshots (data migrations and the like)? [17:00:01] we could then move the writing to updatelog and checking against it before running the script into common framework rather than repeating boilerplate across every script [17:00:36] The boilerplate is already just "subclass LoggedUpdateMaintenance instead of Maintenance", isn't it? [17:00:36] william_: yes, MediaWiki will work just fine in Ubuntu 16.04 [17:00:41] oh is it? [17:00:51] I haven't looked at this in a while [17:00:56] in that case that's fine [17:01:23] Then instead of implementing execute() you instead implement doDBUpdates() and getUpdateKey(). [17:01:57] (and IMO getUpdateKey() could probably be made optional, defaulting to returning static::class) [17:02:16] yeah, now that we can use LSB [17:05:39] hello all [17:06:29] I'm also considering putting a version of Maintenance into Wikimedia\Rdmbs\, so runMaintenanceScript() can be less MediaWiki-bound (or less "you have to reinvent maintenance scripts from scratch" for any non-MW reuser). [17:07:08] Thanks, Skizzerz [17:07:59] 01001000 01100101 01101100 01101100 01101111 [19:09:07] Hi [19:09:31] Is there a way of finding out in CSS internals if a page is being displayed on mobile or not? [19:09:38] Or in print? [19:10:15] what's "css internals"? [19:10:46] as in style=" " in an HTML tag [19:11:22] Well I want to be able to change a templates behaviour depending on what layout is used [19:11:29] be it desktop/print or mobile [19:12:00] Threre being certain navigation content that's inapplicable to print [19:23:22] ShakespeareFan00: you could wrap that content in a
[19:23:49] well a class="noprint" at any rate [19:23:58] I assume theres a "onlyprint" as well? [19:24:24] ShakespeareFan00: don't think so [19:25:06] Thanks anyway [19:25:47] On something else [19:25:50] https://en.wikisource.org/wiki/Template:Sanenull [19:25:59] ShakespeareFan00: it will probably be possible with the upcoming TemplateStyles extension: https://www.mediawiki.org/wiki/Help:TemplateStyles [19:26:06] Hmm [19:26:28] I assume TemplateStyles will still permit inline styles? [19:26:43] Wikisource uses them quite extensively [19:27:53] MatmaRex: I was going to ask if there are plans to have "tablestyles" as well [19:28:10] Wikisource uses an extensive template called TableStyle to have short codes [19:28:20] The current implementation isn't ideal [19:29:16] And it would be nice longer term to have an option for formatting using short codes where lengthy style="" clauses would be needed when coding tables [19:29:47] There might be performance implications for decoding them server side though [19:30:38] In respect of templatestyles.. [19:30:48] There's plenty of styling in this https://en.wikisource.org/w/index.php?title=Template:Statute_table&action=edit [19:31:05] that given it's used extensivly should be classed I think [19:31:32] font-size:smaller ; text-align: center is used a lot [19:39:54] hi, how can I have numbered named parameters in a template? like for example if I wanted an infinite number (up to the template max argument size) of author names, specified as {{authors|first1=Adam|last1=Smith|first2=Bob|last2=Jones|first3=Cherry|last3=Garcia}}, etc... is there any way to do this other than writing out "first1, first2, first3" and so on in my template code? [19:41:07] dijong: yes - the better approach is to have a template call a Lua module which programatically handles the parameters. [19:41:13] you would need to read them with lua [19:41:14] For that you need the Scribunto extension. [19:41:19] !e Scribunto [19:41:19] https://www.mediawiki.org/wiki/Extension:Scribunto [19:42:28] Yaron: OK thank you, are there any instructions / pre-made modules on how to do that? particularly on the english wikipedia where I'm looking to do it? [19:43:12] I don't know... I bet there are a lot of examples of looping through params, but I don't know of any. [19:48:32] it seems like I can only find numbered parameters like this https://en.wikipedia.org/w/index.php?title=Template:Infobox_AFL_biography&action=edit which just list them all out :-/ [19:51:24] Yaron: looks like I just missed you with my last response, but the only way I've seen it done on en.wikipedia is like this which just lists them all out :-/ https://en.wikipedia.org/w/index.php?title=Template:Infobox_AFL_biography&action=edit [19:56:19] dijong: ah, the template that that template calls is a good example of this: https://en.wikipedia.org/w/index.php?title=Template:Infobox3cols&action=edit [20:13:53] Why does this page (https://en.wikipedia.org/wiki/Wikipedia:About), for example, not have an option to edit with the Visual Editor? Similar concept seems to apply to other pages in the Wikipedia: space. Follow up question: is there a way to edit pages in this namespace with visual editor? [20:27:36] JBwiki: it is disabled in some namespaces. i think the reasoning for the 'Wikipedia:' namespace is that it often contains discussions (e.g. AfD, RFC, and so on), which VE is not well-suited for [20:28:02] JBwiki: i think you'd have to copy the page wikitext to your sandbox, then edit it with visual editor there, then copy it back [20:28:07] MatmaRex: So it is disabled. Just wanted to make sure. I'm actually not trying to edit that page; I'm editing a less active Wikipedia page. [20:28:09] Gotcha, thanks! [20:28:36] (it's not a technical limitation, it's just configured this way) [20:29:03] slapping ?veaction=edit on the URL seems to work anyway [20:30:44] Skizzerz: hmm, interesting. i'm sure it used to not work [20:31:01] if it's disabled in config, that is most likely a bug [20:31:04] …and it still doesn't for me. that opens the new wikitext mode for me [20:31:08] huh [20:31:21] * Skizzerz tries again, just saw the loading bar and didn't let it load entirely [20:31:39] yeah, def works for me [20:32:36] I have "new wikitext mode" disabled in prefs [21:33:52] hi, theres any estimate for 1.31 ? ive saw "sometime in june" on wiki [21:34:08] That's still accurate [21:35:07] probably ^_^ but im asking if there is more accurate date ?:) [21:35:21] Nothing confirmed