[02:45:02] Is there a 
 block that I can use templates in
[02:45:04] 	 Specifically I'd like
[02:45:05] 	 
[02:45:08] 	 {{/page}}
[02:45:11] 	 

[03:17:19] 	 OD: try putting a space at the start of the line
[03:17:46] 	 That'll transclude the page with that formatting?
[03:20:21] 	 I can't remember, to be honest. I know it lets you do html tags that would otherwise be nowiki'd https://meta.wikimedia.org/wiki/Help:HTML_in_wikitext#Pre
[09:07:49] 	 Any way to get contribs for an IP range?
[09:07:52] 	 (using the API)
[09:28:07] 	 (Assuming you cant query checkuser which does have better range support ;)
[09:28:12] 	 (I thought ucuserprefix might be usable here, but no)
[09:28:18] 	 unfortunately I can't, haha
[09:28:50] 	 I could phone a friend but at that point I'd rather just HTML-scrape
[09:30:48] 	 Huh do we do ipv6 in canonical notation. I think you would have to make it canonical and then cut it off at the right part and then feed it to ucuserprefix
[09:31:34] 	 Also i wonder if support for new actor system will eventually kill the ucuserprefix thing, as it will make it much less efficient id imagine (maybe)
[09:39:14] 	 Oh, maybe its case sensitive
[09:39:51] 	 Yeah that is it
[09:39:54] 	 https://en.wikipedia.org/w/api.php?action=query&list=usercontribs&ucuserprefix=2601:240:E001:ABB0
[09:39:58] 	 Works
[09:44:29] 	 Seems kind of like a bug, but i guess the software cant know if you want a prefix to a username or an ip address
[09:46:07] 	 yeah, bit of a funny corner of the API
[10:04:21] 	 Hi there! Wondering if someone is willing to help and point me in the right direction. We have a (private) Mediawiki setup for documentation and we're looking for a specific extension/feature.
[10:04:38] 	 It's a features similar to the one on this page: https://cloud.google.com/compute/docs/images/managing-access-custom-images
[10:05:12] 	 It has an editable field / placeholder which you can edit to show it in text and URL's, for example
[10:06:20] 	 (if you search for "organization-id" on that page, you'll see what I mean :)
[10:17:51] 	 Do you mean restrict on which pages an image can be embedded?
[10:35:10] 	 Not exactly, I think. We're looking for an editable field/string/placeholder of some sort. Let's say we have a page which contains a few paragraphs containing a "project name" (e.g. Project X). We'd like the project name to be editable (on the fly). This way, we'd have the same piece of text for different "projects"
[10:36:01] 	 We have found this ( https://www.mediawiki.org/wiki/Extension:UrlGetParameters ) which kind of does the trick
[10:37:02] 	 But we'd like to do it "on the page" (like the example link from Google) instead of using GET parameters
[10:45:52] 	 Since a picture says more than a thousand words; https://imgur.com/a/C27OzKE
[11:00:18] 	 Do you mean rename pages? Page renames are a core feature, no extension needed
[11:05:41] 	 Also, there are templates
[11:05:45] 	 !templates
[11:05:45] 	 For more information about templates, see . See also: !templateproblems , !wptemplates
[11:11:37] 	 We don't mean renaming pages (we're aware that's a core feature) and I'm not sure if a template is going to help us out, but thanks for the suggestion! :)
[11:13:40] 	 I know we're having difficulties describing what we want and that's probably the reason we haven't found what we're looking for (yet)
[11:14:41] 	 * want = would like to have
[15:00:31] 	 Hey, any idea, why the sidebar languages list is appending /en to the English item, example: https://wiki.documentfoundation.org/UserProfile
[15:02:10] 	 I skimmed the config options but there does not seem to be anything relevant https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Translate/+/refs/heads/master/extension.json#859
[15:09:00] 	 it seems that this is not the case on mediawiki.org for example. so it seems that we do miss some configuration or whatever
[15:28:24] 	 buovjaga: what's the wiki language?
[15:47:56] 	 Platonides: English
[15:49:34] 	 :/
[15:50:04] 	 I don't think this would be expected
[15:50:21] 	 Nikerabbit: maybe you have an idea?
[15:50:48] 	 Yeah. Our sysadmin very recently upgraded to 1.35.1 from the previous LTS
[15:51:37] * DennisRoczek has access to the server for the case you want to know a particular config
[15:55:38] 	 Platonides: oh me again (I was just talking with buovjaga about another thing) :D
[15:57:28] 	 buovjaga: Hmm I have vague memory thinking that way is better. It may not be though until the access to the primary version is made easier.
[15:58:41] 	 buovjaga: the setting for sidebar languages is not fully "production ready", though I am using it at translatewiki.net, the behavior is the same there so it's not a "bug" in that sense
[15:59:10] 	 aaah, it was so shiny that I was attracted to it :)
[16:02:17] 	 buovjaga: well it's not your fault if it is not clearly documented as such
[16:03:06] 	 Nikerabbit: so if we throw it back into its original place, it will no longer append /en to English?
[16:03:19] 	 buovjaga: yes
[16:03:30] 	 buovjaga: I am not locked into that behavior, so if you make a compelling case I can change it or try to improve it in other ways
[16:04:36] 	 well, it's just a bit unexpected as the average user will probably not want to access the page
[16:06:50] 	 buovjaga: hmm in my mind average user (=reader) would be content with that page
[16:06:59] 	 only editors would like to see the primary page
[16:08:31] 	 Nikerabbit: see https://wiki.documentfoundation.org/UserProfile/en Doesn't play well with the translation template suffix
[16:14:32] 	 buovjaga: that will be solved by https://phabricator.wikimedia.org/T47096 in the future
[16:16:38] 	 ah, I get notifications of that in my inbox already :)
[16:17:00] 	 DennisRoczek: see above
[16:17:20] 	 yeah, just read
[16:19:00] * DennisRoczek subscribes to that ticket
[16:20:33] 	 I just updated the status summary at the top, FWIW
[16:22:28] 	 Nikerabbit: I'm not sure, but just reading the ticket: is it the correct one? I mean is it really such a big difference having the language menu list "in the content area" instead of in the sidebar?
[16:23:37] 	 DennisRoczek: the last ticket I linked will solve the issue of not showing the templates correctly on /en page.
[16:24:08] 	 Whether the link should go to "" or "/en" is still debatable, of course
[16:27:48] 	 Hello everyone !
[16:28:10] 	 hello there
[16:28:30] 	 I have a question regarding mediawiki. I am looking to migrate an existing mediawiki site to another server and change the operating system
[16:29:22] 	 The operating system will be from Centos 7.4 -> ubuntu 20.04 / RedHatEL / Amazon Linux 2
[16:29:32] 	 How can i achieve this
[16:32:20] 	 justin92: basically you take a backup of the current wiki and restore it on the new server. See https://www.mediawiki.org/wiki/Manual:Moving_a_wiki
[16:32:45] 	 okay i will look into this, thanks vulpix
[16:33:13] 	 I am not sure how to transfer the files to the correct location
[16:33:44] 	 once you sftp the files using FileZilla. i am not sure how to manually configure them to the correct places
[16:34:14] 	 such as db, application files, dynamic pages, etc
[16:39:40] 	 If everything is on /home/www/wiki on the original server, be sure to put everything on /home/www/wiki on the new server
[16:40:33] 	 Configuring database servers, file permissions and web servers is beyond the support I can give you at this moment
[16:40:51] 	 okay, do i also have to manually move everything from the centos httpd to apache as well as any other configurations
[16:41:00] 	 to ubuntu
[16:42:00] 	 it might be in completely different locations
[16:48:03] 	 it doesn't really matter much
[16:48:40] 	 as long as the target wiki is not older than the original one, it should work
[16:48:55] 	 you may need to change some entries on LocalSettings.php to the new location
[16:49:09] 	 oh okay, but if the mediawiki is an earlier version upgrade it first ?
[16:49:40] 	 if you move from an earlier mediawiki to a later one
[16:49:46] 	 you can perform the update in the final system
[16:49:51] 	 after restoring the database
[16:50:08] 	 okay thank you
[16:50:27] 	 do note that apart of the database you will need to move the uploaded files
[16:50:45] 	 so once you get everything uploaded to new OS you can update everything
[16:50:49] 	 yes
[16:50:54] 	 just run maintenance/update.php
[16:51:12] 	 okay, but it wont be moved to the correct places automatically
[16:51:29] 	 i will have to look at the configuration and manually configure
[16:51:35] 	 uh? no. What's "the correct places"?
[16:52:16] 	 so if i use filezilla to sftp all the files from Centos -> Ubuntu /RHEL it will go to a /tmp folder
[16:52:44] 	 that /tmp folder holds all the other database info, i have to scp that to the correct locations ?
[16:53:49] 	 generally everything related to mediawiki is contained within its own folder (most typically a subdirectory of /var/www)
[16:53:55] 	 I would probably use the move to upgrade mediawiki, rather than copying the old files
[16:54:27] 	 it may store some things such as caches or sessions in /tmp, but these are not required to be kept (they will be regenerated as necessary)
[16:54:30] 	 basically, you would keep localsettings, the uploads, plus some additional extensions
[16:54:42] 	 yeah mostly everything, i will have to update some other changes in the /var/apache2 sites-available and sites-enabled
[16:54:55] 	 sorry etc/apache2
[16:55:13] 	 yes, you need to install mediawiki in the new server in a way it is found by apache (or the web server of your choice)
[16:56:43] 	 okay, is there a way to get in contact with someone that knows more.
[16:56:52] 	 and will help guide me, or remote desktop and help me
[16:56:58] 	 is that possible
[16:59:56] 	 I'm not exactly sure what part you're stuck on
[17:00:06] 	 it seems like you don't even know what OS you're migrating to
[17:00:07] 	 no not right meow, just in the future
[17:00:17] 	 yeah that might be true too
[17:00:20] 	 i will find out later today
[17:00:32] 	 See also https://www.mediawiki.org/wiki/Professional_development_and_consulting
[17:01:12] 	 ahh okay, big list of people to contact, im guessing they are able to help more
[17:01:21] 	 I would have to pay them too ?
[17:01:43] 	 k, well general strategy is going to be 1. back up the files and databases from old site, 2. upload a FRESH COPY of mediawiki and relevant extensions to new site, 3. restore database backup on new site, 4. copy over localsettings, favicons, and your uploads directory from old to new site (nothing else), 5. run the update.php maintenance script to update the mediawiki installation to latest
[17:01:56] 	 if you want someone to do it for you, chances are you will need to pay them
[17:02:10] 	 ahh okay, got it
[17:02:49] 	 my general strategy above excludes setting up your webserver, database server, etc. because that's outside the scope of this channel
[17:03:17] 	 okay thank you skizzerz i will look more into that
[17:04:31] 	 There are guides to follow, tutorials, etc on the internet, including the page about moving a wiki I gave you already. If you don't have the time to read the docs or you don't have the sufficient background knowledge to understand and follow the steps, hiring a professional to do the work for you may be an option
[17:05:45] 	 it might be vulpix
[17:05:52] 	 tbh this is tuff
[22:01:21] 	 Hi there--an update on the broken 1.33+ conversion I had mentioned in this channel yesterday: it seems that doing an import of revisions does not solve the issue, either--the content still fails to load. :/
[22:18:40] 	 Also, I think I've finally found what might be the problem: it looks like data is missing out of revision_actor_temp. How would I repopulate this table?
[22:27:30] 	 Blackwire: is it also missing from your old MediaWiki installation?
[22:28:28] 	 maybe you were running the old version with some migration compatibility setting that wasn't populating it, but the migration script was marked as completed
[22:31:11] 	 It's not, but that's because I chose to use the legacy schema after the first time I attempted this on 1.33.0 and it went awry
[22:34:12] 	 You should restore the database from backup, and run migrateActors.php --force to populate it completely before running update.php
[22:34:53] 	 Since update.php on 1.35 will be dropping old fields needed by this script to successfully perform the migration
[22:38:34] 	 Received "Completed migration, updated 0 row(s) with 0 new actor(s), 1306 error(s)" upon running; any way to get verbose output? Running cleanupUseresWithNoId.php with a force flag doesn't seem to change anything.
[22:39:18] 	 1306 errors?
[22:39:33] 	 Did you restore the database to pre update.php like Vulpix said?
[22:40:14] 	 I have no pre-1.33 migration backup, thus my bind
[22:40:28] 	 You know the big warning?
[22:40:38] 	 Oh, I do, but it's a bit late now
[22:41:08] 	 There's a reason it's there
[22:41:18] 	 Again, not disputing that
[22:41:58] 	 No one will have an actor ID then now will they
[22:43:20] 	 I have an actor table with IDs, and when I make a faux record into revision_actor_temp, I can in fact restore the revision being shown with a proper actor in the history.
[22:43:31] 	 It pulls in the revision comments, etc.
[22:43:56] 	 That's not too bad then
[22:44:17] 	 (Granted, that doesn't restore it showing as the most common revision, but it's better than nothing.)
[22:44:24] 	 *current
[22:44:31] 	 It must be recoverable to some degree
[22:44:42] 	 Blackwire: there's no need for a pre-1.33 migration backup. You only need a pre-1.35 migration backup here
[22:44:54] 	 OK, yeah, I've got that
[22:45:48] 	 If you've got that then just restore that
[22:46:58] 	 A common problem is caused by imports on old versions, that insert revisions with valid user names without a corresponding ID, or an ID from the external wiki that doesn't exist on the local one. The migration script doesn't seem to handle this scenario
[22:48:09] 	 I haven't faced this situation myself. But the solution is not other than manual fixing the database
[22:50:30] 	 I guess the best you can do is run the migrateActors.php script and see on what revisions it fails, and see what values are on the rev_user and rev_user_text fields. If rev_user has an ID that's not on the user table, ideally those rows should be updated with rev_user = 0 and *prepend* "external>" (or similar, with the > character) to rev_user_text
[22:51:17] 	 That will indicate the user is not from the local wiki, and will not try to assign it a local user id that doesn't exist
[23:24:05] 	 Hello! I have just joined the Wikimedia Foundation staff. It's been suggested that I have my GitHub account (@flosincapite) added to the Wikimedia organization on GitHub. What is the best way to achieve that?
[23:53:50] 	 hi apine!
[23:54:14] 	 what's your github username?
[23:56:11] 	 apine: I would recommend filing a task in the https://phabricator.wikimedia.org/project/view/1524/ project
[23:56:20] 	 I'm not sure there's a normal process for this otherwise