[00:58:56] I'm having trouble displaying svg math formulas with the latest version of mathoid and restbase from the github repositories. [00:59:03] I'm getting these errors: [00:59:07] http://joshuarosales.com/wiki/index.php/Quadratic_Formula [00:59:18] Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("Math extension cannot connect to Restbase.") from server "/mathoid/local/v1/":): {\displaystyle x=\frac{-b\pm \sqrt{b^2-4ac}}{2a}} [00:59:33] Can anyone help with that? [01:00:43] I'm getting this error the special page "MathStatus" [01:00:48] http://joshuarosales.com/wiki/index.php/Special:MathStatus [01:01:03] [21ea6ec814f4d15db4bf0419] /wiki/index.php/Special:MathStatus MWException from line 103 of /var/www/html/wiki/extensions/Math/MathRestbaseInterface.php: TeX input is invalid. [01:01:06] Backtrace: [01:01:08] #0 /var/www/html/wiki/extensions/Math/MathRestbaseInterface.php(399): MathRestbaseInterface->calculateHash() [01:03:54] The mathoid server seems to work when I test it using curl, but it doesn't work when I try it through RestBase. [01:04:20] This is the link to RestBase on my server: http://joshuarosales.com:7231/localhost/v1/ [02:43:37] What could be the reason for a block appearing on CentralAuth but not in the local wiki's contribs page or block log? [02:44:30] e.g. it says blocked on https://meta.wikimedia.org/wiki/Special:CentralAuth/David_Gerard_and_Michael_Jackson_have_something_in_common [02:44:34] but not on https://en.wikipedia.org/wiki/Special:Contributions/David_Gerard_and_Michael_Jackson_have_something_in_common [02:46:37] is this a bug? [02:49:35] looking at the API, it seems that the block is from 2005. could that have anything to do with it? [02:49:37] https://en.wikipedia.org/w/api.php?action=query&list=blocks&bkprop=id|user|by|timestamp|expiry|reason|range|flags&bkusers=David_Gerard_and_Michael_Jackson_have_something_in_common [03:01:24] Hi irrationalist. [03:01:34] I thought you were a troll at first, just seeing the link. [03:01:34] Hi Max. [03:01:42] I'm not a troll [03:01:43] Who's Max? [03:01:48] Max made me put this here. [03:01:57] And how. [03:02:16] what? [03:02:41] Old blocks might be weird, sure. [03:03:04] so why is the CentralAuth showing the block but not the contributions page? [03:03:20] You noted the block log is empty? [03:03:26] https://en.wikipedia.org/w/index.php?title=Special:Log/block&page=User%3ADavid+Gerard+and+Michael+Jackson+have+something+in+common [03:03:28] if it were revdel'ed would it be in centralauth? [03:03:35] I think Special:Contributions queries the log. [03:03:39] oh [03:03:45] While CentralAuth queries the actual blocks. [03:03:50] And old blocks may not have been logged? [03:03:55] But that sounds a bit wrong. [03:04:00] Since surely we logged blocks... [03:04:00] that sounds possible [03:04:51] Hmmm. [03:05:10] also Oversight wasn't created until 2006 [03:05:51] So the blocking admin was renamed. [03:05:56] Stephanie is now Lexi Marie. [03:06:16] Ah, yeah. [03:06:21] would that affect the log? [03:06:29] Yes, but not in this way. [03:06:30] doesn't the log use the user id? [03:06:36] and the page title [03:07:18] The admin rename explains why https://en.wikipedia.org/w/index.php?title=Special%3ALog&type=block&user=Stephanie&page=&year=&month=-1&tagfilter=&subtype= is empty. [03:07:25] But there is a log entry. [03:07:30] And it is rev-deleted. [03:07:34] Suppressed, whatever. [03:07:40] Not really a revision, per se. [03:08:32] oh that explains it [03:08:54] but how can you tell? you're only extendedconfirmed on enwiki [03:09:12] You're awfully fixated on identity. [03:09:16] For someone who's masking their own. [03:09:26] what do you mean masking? [03:09:32] What's your username? [03:09:58] https://en.wikipedia.org/w/index.php?title=Special:Log&offset=20051010160449&type=block&user=Lexi+Marie&page=&tagfilter=&subtype=&month=11&year=2005&limit=10 [03:10:24] Is the log you're after. [03:10:36] There may be a data leak in CentralAuth, Idk. [03:10:54] If it's just exposing that the user is blocked, that's not really an issue, since the user is. [03:10:56] ah, thanks, dunno why i didn't think of that [03:11:37] The logs are a bit tricky here because the page title field won't work. [03:11:47] And neither will the performer field with the original blocking name. [03:12:02] So I had to look at all blocks by the admin and then filter to October 2005. [03:12:14] Anyway, there we go. :-) [03:12:29] thank you very much - that was bothering me [03:12:36] There are a few underlying issues that could be filed as bugs, maybe. [03:12:54] Like Special:Contributions not showing the log excerpt. But that's probably expected-ish behavior due to the suppression? Dunno. [03:12:55] btw, the only reason I even found this was that I was looking up David Gerard's contribs and saw that autocomplete, then was amazed it wasn't blocked [03:13:20] So we have revision deletion/suppression, right? [03:13:26] But I think there's a separate "hide username" feature. [03:13:29] Maybe that wasn't used. [03:13:53] I think we use it to make Special:ListUsers less awful. [03:14:02] So you could request that if you care. [03:14:17] Another possible bug is the admin name not being changed when the user is renamed. [03:14:22] Maybe that's been fixed or maybe that's intentional, who knows. [03:14:55] kinda surprised that isn't fixed automatically by some maintenance script [03:15:16] i guess admin name changes are rare enough [03:15:22] Well, unless you do it at rename time, you gotta go back and try to figure out when the rename was. [03:15:25] And if that's still the current name. [03:15:32] It can be messy. [03:15:44] And you're messing with logs of past actions, which is morally and philosophically risky as-is. [03:16:05] I see what you mean about autocomplete. [03:16:21] You can ask a local oversighter(?) to suppress that username, I'm fairly sure. [03:18:05] https://en.wikipedia.org/wiki/Special:ListGroupRights yeah, here we go. [03:18:10] > Block a username, hiding it from the public (hideuser) [03:18:25] Dunno if that works with CentralAuth. Maybe stewards do it these days. [03:18:59] I know that when using the global hiding feature it says "account does not exist" on CA [03:19:43] local hideuser just hides it from local listusers and stuff? [03:19:55] Probably. [03:20:02] I think you were on the right track by asking in #wikimedia-stewards [03:26:17] yeah it just queries the log https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialContributions.php#L299 [03:26:44] i can't figure out what centralauth is doing but maybe local blocks are stored in the centralauth database? https://github.com/wikimedia/mediawiki-extensions-CentralAuth/blob/master/includes/specials/SpecialCentralAuth.php [03:28:44] or maybe it's just querying the local database/api. i can't really figure out where the data is coming from [03:28:51] anyway, thanks, bye! [03:29:00] No problem. [03:29:59] That username has now been hidden, fwiw. [03:58:04] good morning guys [04:02:44] Morning, Combined2857. [07:18:59] 'sup! [08:51:45] Goodmorning! I'm running my mediawiki on the latest debian release, I'm having trouble to find the php.ini file (uploads are not working) [08:52:08] its not under /usr/local/apache [08:54:20] https://stackoverflow.com/a/17185370 ? [08:55:33] found it! [08:55:34] :d [08:55:37] thx [10:30:22] i have a problem [10:31:42] i´m the admin of our mediawiki but since a long time i cannot change or edit in mediawiki [10:32:40] what could be the problem or where could i check the settings besides LocalSettings.php `? [10:34:02] myi: what error are you getting? [10:34:54] nothing. There es a white Site when i change or edit something and want to save [10:36:13] I have the the MediaWiki-version 1.28.2-0122 [10:36:47] PHP-version 5.6 [10:37:40] and phpmyAdmin version 4.6.2-0170 [10:37:58] !blank [10:37:58] A blank page or HTTP 500 error usually indicates a fatal PHP error. For information on debugging (including viewing errors), see . [10:38:47] A blank page [10:49:40] is it a known problem? Is there somebody who can help me,please? [10:59:10] myi: Do as wm-bot suggests. How to debug. [11:13:32] ok i have now activated it and it shows me a error like Strict Standards: Declaration of GadgetResourceLoaderModule::getDependencies() should be compatible with ResourceLoaderModule::getDependencies(ResourceLoaderContext $context = NULL) in /volume1/web/MediaWiki/extensions/Gadgets/Gadgets_body.php on line 420 Fatal error: Call to undefined method Title::newFromRedirect() in /volume1/web/MediaWiki/extensions/TitleBlacklist/TitleBlack [11:16:46] Sounds like the version of the extension TitleBlacklist is not compatible with your version of mediawiki maybe? Make sure you're on the right branch of it for your version. [11:28:48] but i didn´t change anything [11:46:35] any other ideas? [12:41:37] Hello [12:42:08] I am getting Could not create directory "mwstore://accountcreds-backend/accountcreds-public/m/my/my error. I use ConfirmAccount [12:57:04] :Join [12:58:22] ANY OTHER IDEAS? [13:17:38] myi: no need to yell. [13:17:50] myi: which exact version of MediaWiki and which exact version of the TitleBlacklist extension? [13:28:01] I have the MediaWiki-version 1.28.2-0122 PHP-version 5.6 and phpmyAdmin version 4.6.2-0170 [13:29:50] @andre whrere can i find the version of the TitleBlacklist extension? [13:30:03] myi: on Special:Version [13:31:57] @andre and where can I find information about Special:Version [13:32:04] on Special:Version [13:32:06] on your wiki [13:32:09] it's a wiki page. [13:32:35] http://mywikiaddress/whateverpathyouhaveset/Special:Version [13:36:31] @andre thanks... i´m now on the Special:Version but i didn´t have a TitleBlacklist on Special:Version Site [13:37:29] myi: sounds like it's not properly installed then [13:37:39] see e.g. https://www.mediawiki.org/wiki/Special:Version listing "TitleBlacklist", for comparison [13:39:52] @andre could it be that after upgrade of Mediawiki TitleBlacklist is not installed? [13:41:59] what upgrade? [13:42:19] update of MediaWiki version [13:42:30] sure. [13:42:38] you have not mentioned any upgrade before. [13:42:52] maybe you would like to explain what you did, before anyone else here has to continue guessing :P [13:42:53] see the comment from 2 and 1/2 hours ago: Sounds like the version of the extension TitleBlacklist is not compatible with your version of mediawiki maybe? Make sure you're on the right branch of it for your version. [13:43:50] so, how did you upgrade? from what to what? only MediaWiki itself? Did you also upgrade your installed extensions? If not, why not? :) [13:44:15] see https://www.mediawiki.org/wiki/Manual:Upgrading#Upgrade_extensions [13:44:55] the update was just for a long time and i´m not sure if it was working after upgrading or not [13:45:05] what was "the update"? [13:45:18] you need to answer questions, otherwise noone can help you. [13:47:23] Hey Everyone. A year ago I upgraded our mediawiki on a fairly old version (1.17) to the latest, and have since been able to keep it up-to-date, so am currently on 1.28.2 -- We've realized recently that our search results are not complete. So, looking around, it seems that CirrusSearch with Elastica/Elasticsearch is the way to go. [13:47:41] I've got it installed, and am successfully searching. [13:48:15] However, it only seems to be returning results where the term searched is in the Category of the article [13:49:23] @andre Let me explain you.MediaWiki is working on a Synology. For a long time i take an update to the latest version called 1.28.2-0122. I Think i did also an update of PHP and PhPMyAdmin [13:49:46] Prior to testing the Elasticsearch route, we were using SphinxSearch. This search seemed to not be indexing content that was created within the past year. [13:50:13] I have also tried removing Sphinx and using the default search [13:50:38] The default search returns the most results for the same term, sphinx returns maybe half as many results, and Cirrus returns barely any results [13:50:58] @andre I don´t know if it also take an update of the instaleld extensions [13:51:20] myi: then you should find out. [13:51:30] We have nearly 10,000 pages. I'm testing with terms that would be in loads of our pages. Elasticsearch returns ~113 results for the same term the default search returned 6k+ results. [13:52:00] GFXDude: have you populated the index by running forceSearchIndex? [13:52:45] @ i find the installed TitleBlacklist Version. It is version 1.5.0 [13:53:58] @myi: all extensions should have a version file, with a REL1_xx in them. [13:54:54] @andre should i update the TitleBlacklist version? If yes how can i do this? [13:55:20] @dcausse: Is that something done in general, or specific to one of the search methods I mentioned? [13:55:41] GFXDude: it's a maint script for CirrusSearch [13:55:43] myi: 1) see what was written here two and a half hours ago. 2) see what was written here 11 minutes ago. [13:55:55] @dcausse: I've done all of this: https://www.mediawiki.org/wiki/Extension:CirrusSearch [13:56:02] And followed the instructions in the CirrusSearch README [13:56:08] https://phabricator.wikimedia.org/diffusion/ECIR/browse/master/README [13:56:24] Oh, yes, I did do the forceSearchIndex [13:57:04] I forgot that step, but yes, did that in the order outlined in the README. It indexed 9k+ pages [13:57:54] GFXDude: out of curiosity do you get much more results if you search for all:your_search_term ? [13:58:07] adding a prefix all: to your search query [13:58:10] This wiki has been around for 10+ years, way before my time working on it, and it's had many hands touching it without knowing what they're doing. I see attempts to create custom article templates, attempts to use categories, etc, but there's no uniformity to it [13:58:22] Same # of results with cirrus [13:58:59] @andre OK but how / where can i find the correct TitleBlacklist version to the MediaWiki version i have=? [13:59:14] So I am under the impression the format being used in the pages may be causing bad indexing. Some use a custom template, some use standard wiki markdown, and others have rawhtml [13:59:19] GFXDude: I fear that the index you populated with the maint scripts is not the same than the one used php running behind apache [13:59:43] @myi: https://www.mediawiki.org/wiki/Special:ExtensionDistributor/TitleBlacklist [14:00:44] @myi: if you want to find out which version you have installed locally, check the "version" value in the "extension.json" file in the TitleBlacklist folder [14:01:07] but even that is... not helpful I'm afraid. Git revision might be more useful [14:02:06] @dcausse, I'm not sure I follow what you mean by that. Should I execute the forceSearchIndex as the apache user? [14:02:47] GFXDude: no you should check that running curl http://elastic_host:9200/_cat/indices returns something meaningful [14:02:55] e.g you should have 2 indices per wiki [14:02:56] not more [14:03:51] something weird can happen if for e.g. you set wgDBname after loading the cirrussearch extension [14:04:38] Also, I'm just noticing that my Elasticsearch config's data directory is default, which should correlate to /var/data/elasticsearch, but that path doesn't exist. Maybe the idexes aren't actually getting created. [14:04:52] ok i have donwloaded the version and have extracted it in MediaWiki and now it is just restarting the synology [14:05:27] GFXDude: elastic would have refused to load, default should be /var/lib/elasticsearch [14:06:29] Hmm [14:06:35] Their docs say /var/data/elasticsearch [14:06:36] https://www.elastic.co/guide/en/elasticsearch/reference/2.3/setup-configuration.html#paths [14:07:32] I'm using Elasticsearch 2.3.3 as recommended on the README: https://phabricator.wikimedia.org/diffusion/ECIR/browse/master/README [14:08:41] But, I do see /var/lib/elasticserch with a sub-dir for my wiki [14:09:44] Your curl suggestion returns: https://gist.githubusercontent.com/BAGELreflex/7d48b4aedc08c7016b15c9a38f6d70b6/raw/273fcd34824f99760752b438b660a70d6b6093ae/gistfile1.txt [14:10:02] Which seems like way not enough data [14:13:45] it works.... great, thanks [14:31:36] @dcausse, I ran the commands outlined in the README again. Now the same term returns 119 results instead of 113... [14:37:53] GFXDude: my best guess is that there's an index mismatch, try to see where you set $wgDBname in your config then try to determine if CirrusSearch is loaded before this statement [14:38:36] CirrusSearch loading is the last thing in my config [14:39:50] I'm doing it conditionally, but I dont' think that's got anything to do with it: https://gist.githubusercontent.com/BAGELreflex/5ea7cd284243852cc95d8db67e2855a3/raw/f9ecbc9576bde2777c30676aeff52895791a2e6a/gistfile1.txt [14:40:11] GFXDude: append '&cirrusDumpQuery' at the end of a search result page url and look at the 'path' json entry [14:40:51] "path": "devkb\/page\/_search" [14:41:36] Here is full output: https://gist.githubusercontent.com/BAGELreflex/ccbb956062cded05321155f82bc3e1c9/raw/cfca1338ffa59cac4692c56de7d7f2fc7657d58b/gistfile1.txt [14:42:09] GFXDude: curl http://elastic_host:9200/devkb_content/page/_count | jq . [14:43:06] the number should correspond to the number of pages in the content namespace [14:43:08] Hmm, jq is neat [14:43:17] Nah, count is only 131 [14:43:33] so the index is not fully populated [14:44:09] curl http://elastic_host:9200/_cat/indices check if you have an index named liake wiki_content with the expected number articles [14:44:30] green open devkb_content_first 4 0 131 0 1.9mb 1.9mb [14:44:31] green open devkb_general_first 4 0 34 0 126.8kb 126.8kb [14:44:53] There is also a green mw_cirrus_metastore_first and yellow tutorial [14:45:14] But I figure those are added by default [14:45:32] mw_cirrus_metastore_first is from cirrus but tutorial is not [14:45:54] GFXDude: so basically forceSearchIndex did not run properly [14:45:54] yellow open tutorial 5 1 1 0 3.7kb 3.7kb [14:46:21] let me re-run, it looks like $wgShowExceptionDetails was commented out when I ran it last time [14:46:27] Well, no, I just commented that... [14:52:09] Hmm [14:53:09] @dcausse, so the README instructions say to run the second phase with --skipParse. Per forceSearchIndex.php, that option will "Skip parsing the page." [14:54:53] GFXDude: this is populating the number of incoming links [14:55:08] the first pass should already populate the index [14:55:34] GFXDude: perhaps check elasticsearch logs? [14:55:36] Hmm, ok I see that now [14:57:07] Only thing written to logs today was from a reboot and elasticsearch starting back up [14:57:13] Are there supposed to be duplicate shards? [14:57:34] GFXDude: yes if you have multiple servers you'll have replicas [14:57:43] I don't [14:57:55] so you don't need replicas it's pointless [14:57:57] This is a single server running elasticsearch and mediawiki on the same box [14:58:28] so that could be part of my issue [14:58:52] https://gist.githubusercontent.com/BAGELreflex/59b2c24c10c435deab45f468d9634623/raw/0b9ba33357dcba3834aa3f5ed11a770df6a6dd6b/gistfile1.txt [14:59:46] GFXDude: as you can see, there's only 'p' shards which means primary shards you don't have replicas [15:00:03] the index is partitioned it's why you see multiple shards [15:00:44] my mediawiki now seems to need me to manually run refreshLinks.php to update category membership. This has never been true before. MW1.28.2 https://www.snpedia.com/index.php/Special:Version no recent changes to my LocalSettings. any plausible reason for a behavior change? [15:00:46] except your tutorial and that explains why this index is yellow, replicas won't be assigned to the same node [15:01:09] I'm not sure where this "tutorial" came from [15:01:54] GFXDude: try to spend some time on forceSearchIndex it's most probably the cause of your issue [16:35:04] Hello guys. When I was editing my Mediawiki:Sidebar I got some trouble with editing. Is there anyone helps me? [16:35:56] No new changes are applied at all. [16:37:37] Even I remove all the contents, it isn't applied so still all contents are alive [17:33:00] @dcausse, I think after running this script a bunch of times it's finally picked all of the info... I've been adding a ton of debugging to forceSearchIndex and seeing what all it's gathering, to make sure it's getting every page. Now that I've run it maybe 30+times my search is now returning more appropriate results. [17:33:42] GFXDude: good to know :) [17:33:53] It's returning results not found with both default and Sphinx, which was my goal, as anything created int he past 1-1.5 years was not being found... [17:34:12] Now, my question is, does this forceSearchIndex need to run on a scheduled basis? [17:34:28] sphinx needed a cron to re-index every so often [17:34:53] Or does CirrusSearch handle this on its own somehow? [17:35:48] GFXDude: forceSearchIndex is only needed for populating the index after installing cirrus [17:36:14] you need enable SearchIndexUpdates after that otherwise live updates won't show up in the results [17:37:38] @dcausse, Where is this SearchIndexUpdates? I haven't seen that mentioned in any of the docs I've read, and can't find any reference in mediawiki search [17:38:02] Is it this? https://www.mediawiki.org/wiki/Manual:UpdateSearchIndex.php [17:38:52] It's gotta be [17:40:39] GFXDude: the one you explicitly set to false in your config related to cirrus [17:43:02] I'm trying to display an image over all pages. Using a watermark isn't 100% effective because of how browsers ignore them when printing byu default. [17:43:17] What's the easiest way to do this? [17:48:12] @dcausse Ohh, I see what you mean, $wgDisableSearchUpdate. Yeah, I have that removed. So, that's it? There's no need for cron? That's neat [17:48:57] @cwre, are you wanting the image to be a background? or like magically overlayed over the entire page in the foreground? The latter seems silly [17:49:17] GFXDude: I want it overlayed on the entire page. [17:49:51] It's not silly, because printing a background with chrome or firefox is obnoxiously unstable. [17:50:09] And we can enforce it at a user level, and we need watermarks for ISO auditing. [17:50:13] *can't [17:51:02] RainbowSprinkles: I just noticed that 71df44bf9bf4f49 isn't in REL1_29. Is it too late for me to backport it? I know this is last minute [17:51:06] Can you provide an example screenshot of what you're looking to achieve? I feel like you're going about it the wrong way. You want it overlayed over the menu/search/header/footer/etc ? [17:51:10] or just page contents? [17:51:32] GFXDude: Just page contents. [17:51:41] It's need to be easily visible over page contents [17:52:13] Unless theres another way to do this on print that doesn't involve a background-image: CSS rule, there isn't another option for me. [17:52:35] But what is the final objective? You're just wanting a watermark on every page, right? [17:52:42] Yes [17:52:49] And printing isn't including the watermark when doing it as css background [17:52:57] It "does" [17:53:06] But chrome sucks at printing backgrounds [17:53:15] And we can't enforce "only firefox" [17:53:55] Chrome will print the background, but even with the "PRINT BACKGROUND" radio checked, you have to uncheck it and check it again to work. [17:54:17] Which 1. is a fucking hassle, and 2. not something sysadmins can work around. [17:54:38] Sorry, I'm quite frustrated by this. [17:56:16] You've reproduced the "have to toggle/untoggle/toggle" on a machine other than your own? That would seem like a Chrome bug if that's the case... [17:56:24] Basically, I have to be responsible for people being stupid, so I need to make this stupid-proof, and it's not stupid-proof with background-image: GFXDude [17:56:28] overlaying an image in the foreground would make text not be selectable [17:56:40] I feel you on stupid-proof [17:56:47] GFXDude: well this would only be overlayed on print... [17:56:55] Would that still break clicking? [17:57:07] *selecting [17:57:18] if you display:none in normal stylesheet, then position:absolute in print.css, it should be fine [17:57:27] Is this a public wiki? If you can allow raw html then you could trick it to work with a wrapper div [17:57:46] It's not public, hence the ISO 9001 garbage. [17:58:04] Ugh... Trying to force MW into this role is aggravating. [17:58:06] bawolff: should probably use fixed to make the image rep[eatr on every printed page [17:58:19] *repeat* [17:58:27] Yeah. [17:58:33] What do you mean by normal stylesheet? [17:58:43] common.css? [17:59:26] Can you give me a snippet of what you mean? Is this like a mixin? I don't really know how to edit css o.o [17:59:35] cwre: yeah, I mean the page MediaWiki:Common.css for normal, and MediaWiki:print.css for print [17:59:43] bawolff: mmmmm okay. [17:59:56] And what FoxT said is correct, fixed is the right positioning [17:59:57] So you want me to try doing mediawiki-body [18:00:05] On common.css [18:00:19] And then make it visible on print.css [18:00:33] you want something like #watermark { position: fixed; width: 200px; height: 200px; top: 50%; left:50%} in print.css [18:00:37] But how do I make it an image instead of a background image? [18:00:44] and #watermark { display:none; } [18:00:57] Would you not want to do that at the theme level? [18:01:00] So it's not broken on upgrade [18:01:11] What does # mean for css?\ [18:01:21] GFXDude: shouldn't be broken on upgrade? [18:01:28] # for CSS is an ID [18:01:29] And add something like

in mediawiki:copyright [18:01:44] Does a MW upgrade reset .css? [18:01:58] No mw upgrade does not reset the pages mediawiki:Common.css [18:02:07] you could also alternatively make a custom theme [18:02:12] you should not edit the built in theme [18:02:15] * bawolff has to go to meeting [18:02:24] Mw upgrade doesn't overwrite css? [18:02:31] I guess it depends on how you upgrade really [18:02:43] Oh, is that in db? [18:02:59] GFXDude: yeah I'm pretty sure it is [18:06:13] cwre: Try this in MediaWiki:Print.css: body.mediawiki:before {content: url("https://lh3.googleusercontent.com/mvHbePT-FyB8YpsjecAdCSvK7XoqOcsa4rqpCksWUDZ1koC_2cOfzvt2QU6rPsk5Yuri=w300"); position: fixed; top: 40%; left: 40%;} [18:09:09] FoxT: trying [18:12:21] cwre: Of course, depending on who your users are and what their intention is, they can always hit F12 and just turn off any CSS rule and print it without watermark anyway [18:12:41] Very true. [18:12:52] But we're assuming they're stupid and lazy, not evil and smart. [18:13:11] Otherwise we wouldn't have hired them. [18:13:19] (The evil part not the smart part) [18:13:20] Ouch. :) [18:13:32] :P [18:13:36] ' [18:13:46] 'tis the conundrum of sysadmin. [18:14:05] Assumptions are bad but how do you make decisions without assumptions. [18:14:14] And then how do you know those assumptions are the right assumptions. [18:17:02] bawolff: That's fine, I'm gonna tag as soon as I'm done with lunch [18:17:13] ok [18:47:50] bawolff: it worked with your image, but my image isn't displaying for whatever reason... [18:48:18] cwre: you mean FoxT's image? [18:48:21] AH [18:48:23] Yeah, sorry [18:48:24] I didn't give you an image [18:48:35] My apologies [18:48:52] cwre: Umm, check for typos and what not [18:49:05] I just changed the url D: [18:49:09] make sure you can directly go to the image if you type it into the url bar [18:50:33] bawolff: I figured it out, the position was all wrong. [18:50:52] What do I do if I want it to repeat? [18:53:10] GOT IT [18:55:29] really, how? I have no idea how to make replaced content repeat [18:56:17] background-repeat .... [18:57:37] I don't think that would work with content: [18:57:50] Hey everyone. I just installed MediaWiki and everything has been very easy so far. However, I am having a total brain block trying to figure out how to set up permissions so that I can give only certain users edit and create page access. [18:58:13] plex_dave: ok, so this is configured by $wgGroupPermissions [18:58:33] !permissions [18:58:33] For information on customizing user access, see < http://www.mediawiki.org/wiki/Help:User_rights >. For common examples of restricting access using both rights and extensions, see < http://www.mediawiki.org/wiki/Manual:Preventing_access >. [18:58:37] I saw some pages on that, and I do understand the true/false paradigm in the configuration file [18:59:00] What I am not seeing is how I put certain users in certain groups. [18:59:06] Ah [18:59:15] So on the wiki, the page Special:Userrights [18:59:41] allows you to edit which users are in which groups (provided the user has the rights to edit groups. By defaut that's beurocrats) [19:00:41] I am logged in as admin but it only shows that I am a member of Users and AutoConfirmed users. [19:01:17] plex_dave: What groups is the user shown as having in Special:Listusers [19:01:34] Just because the user is named "admin" doesn't mean its actually an admin [19:01:55] The full list of admins are on the page Special:Listadmins [19:02:02] Oh, it's the admin user I created when I installed. [19:02:16] Normally, the user created by the installer should have full rights [19:02:40] Well, it doesn't have full rights. Nothing shows up on the special:listadmins page [19:03:01] This is very likely my problem. [19:03:37] ok, so you can upgrade the user's rights from the command line [19:03:46] if you go to the maintenance directory [19:03:48] and run [19:04:15] php createAndPromote --force --bureaucrat --sysop Admin [19:04:23] assuming the user in question is named Admin [19:04:29] sorry, i mean [19:04:36] php createAndPromote.php --force --bureaucrat --sysop Admin [19:04:54] Cool. So I don't have to fish around for it, what's the default install location of the maint directory? [19:05:12] its a subdirectory of the mediawiki directory [19:05:35] oh okay. cool [19:05:37] Where that is depends on how you installed. If you installed from a tarball, that's commonly /var/www/html/mediawiki/maintenance [19:06:12] Yeah, it was a Digital Ocean 1 click install, but my understanding is that it's just a script that does the install from tar-ball so I don't have to. [19:07:12] If you used a debian pakage, it might be in /usr/share/mediawiki/maintenance [19:07:37] It is running on Ubuntu so I imagine that the latter is very much more likely the case. [19:08:28] The debian package is relatively new though, so digital ocean might not use it [19:09:06] Yeah, it's actually in neither of those places. [19:09:41] I ended up nuking and paving over an icecast install because when they had a on click for it, they put everything in weird places. They no longer have 1 click for icecast. [19:10:12] Normally it'd be wherever your LocalSettings.php file is [19:10:42] Yeah, I found it. It's var/www/html/maintenance [19:10:56] DO is great but often times they put stuff in a strange place [19:11:49] and in this case, the LocalSettings.php isn't in the same directory as createandpromote [19:12:11] I meant, the maintenance directory would be in the same directory as LocalSettings.php [19:12:24] Oh! you're right. [19:12:27] and createAndPromote would be in the maintenance directory [19:13:14] I have very little problem in the terminal, but navigating around and finding things always drives me nuts. The wifi on the train blocks my ftp client, so I can't poke around using that, I have to use bash [19:14:07] Thank you. I think I can figure it all out from here. After the permissions adjustment, do I need to restart mediawiki? [19:14:14] plex_dave: If you don't like poking around bash too much, you could try using "FISH" [19:14:29] No, it should just work after permission adjustment [19:15:03] I will look it up. I think they mentioned it on Linux Unplugged a little while ago [19:15:31]