Community noticeboard

Archives:
 * Archive 1 (23 July 2017 - 25 November 2017)
 * Archive 2 (1 December 2017 - )

Navbox show/hide buttons not functioning properly
I was wondering if I could appeal to someone's knowledge regarding the show/hide buttons on the Navbox template. I don't know if anyone else uses it but I'm going to throw this out "out there" in the hope that someone can shed some light on it. Whenever i create a new page with the navbox, or edit and save an existing page with a navbox, the show/hide buttons appear (most of the time). However, when I refresh the page the buttons disappear, for which reason I have no idea. If I follow a link from a page with a navbox and follow a link back to it the buttons have disappeared. And then sometimes they just appear. Does anyone know why this odd behaviour is happening? As far as I know I have included all the relevant templates and modules associated with it. Currently I have The Great War wiki set to private so I am guessing only admins etc. can access to have a look. Any help, as always, most appreciated. Thanks. 11:53, 12 January 2018 (UTC)
 * I can't explain why the buttons should disappear entirely. I did work with an Infobox once where the author chose a color that was identical to the links, but this made them disappear entirely all the time.  You're aware that Infoboxes require special JavaScript to work?  (See FAQ)  I don't believe that Infoboxes use cookies or any other way of maintaining internal state, so they would not retain their show/hide status if you reloaded or refreshed the page.


 * The first step in diagnosis would be to point the cursor to where the buttons should be and see if it changes form, indicating that there is a link to be clicked on but you simply can't see it. At that point, Firefox Object Inspector could point out the link and even show you the style rules responsible for rendering it invisible.   12:48 12-Jan-2018
 * I have worked with both infoboxes and navboxes before and most of the time I find they have been built too over-complicated, so I sometimes use my own (basic) infoboxes. The navbox has been copied from Wikipedia and for all intents and purposes it works. The show/hide buttons work but only after the initial page save. So, whatever is driving the buttons to show works to a degree. After that it gets sketchy. They are the standard blue link colour and hovering the mouse over the area does nothing - there is nothing there so the mouse can't respond to any action. As far as I can tell I have all the relevant code in the Commons.js page as well, so for now it's a bit of a mystery. Sometimes they show but most of the time they don't. 13:34, 12 January 2018 (UTC)
 * Just as I thought, it's a scripting error related to unloaded dependencies. I've resolved the issue on both The Great War wiki and The Lonsdale Battalion wiki by ensuring that all dependencies used by MediaWiki:Common.js are loaded before anything attempts to use them. -- Void  Whispers 21:49, 12 January 2018 (UTC)
 * Thanks for the fix, all working properly now. I never would have worked that out. Cheers pal. 22:53, 12 January 2018 (UTC)

Problems with wiki on mobiles
The problem is, that my Wiki at https://fuchsia.miraheze.org/wiki/Main_Page works not with mobile browsers. On desktop browsers it works fine. You can see and read there all. But if anyone wants to see it with an smartphone (for example with Android), then only the topics are shown. If you don't have an Android smartphone, you can test it also online on https://www.browserling.com/
 * What do you mean by "only the topics are shown"? Would it be possible to maybe provide a screenshot? Reception123 (talk) ('C' ) 12:17, 13 January 2018 (UTC)
 * Section headers never seem to work on mobile for the main page. We may want to add that to the FAQ, because this is at least the fifth time this has been reported. On regular pages, the display should be fine (if you're not seeing anything, simply tap on the section headers). But on the main page, the content below headers can never be made to display without some meddling. The easiest fix is probably to remove section headers from the main page. -- Void  Whispers 17:03, 13 January 2018 (UTC)
 * My guess was headers too. We do need to do something about this issue, which is very likely something to do with the MobileFrontend extension. Reception123 (talk) ('C' ) 18:26, 13 January 2018 (UTC)

Navigation popups
I noticed added the navigation popups to Meta and thought I'd try them out on my second wiki. All seems to be good so far. I was wondering how you stylise it so it looks more like the Wikipedia one with a simpler look. 18:00, 14 January 2018 (UTC)
 * Miraheze meta one just uses English Wikipedia code, so it should be identical. (Your ping doesn’t work.) &mdash; revi  18:55, 14 January 2018 (UTC)
 * It looks quite a bit different, maybe the "Page preview" link (at the very bottom of Wikipedia next to "mobile view") links to a different type of popup. I did notice the css for it is called MediaWiki:Gadget-navpop.css on Wikipedia but on Meta is is MediaWiki:Gadget-popups.css. Does this make a difference? 19:30, 14 January 2018 (UTC)
 * Regarding "look[ing] different", CSS (Cascading Style Sheets) governs how page elements look, so yes, having different CSS has unlimited ability to make elements look different. If you point to the relevant CSS on your site and describe how you want it to look, I'll advise.   19:33 14-Jan-2018
 * My point here is that if Meta is using the same css code as Wikipedia and I am using the code from Meta, my popups should look the same as they do on Wikipedia, but they don't. So, I am wondering if they are the same popups at all. I am happy to experiment with css, I was just hoping to save some time as my Great War project is already very time-consuming. 22:06, 14 January 2018 (UTC)
 * The Firefox Web Console can show you, when you reload a page, what files your browser is requesting, and thus what .CSS files are controlling display of the page. The Object Inspector (display the pop-up and right-click on it) can tell you what the specific styles are, and let you un-tick each one).  Also, look for comments in the .CSS file.  Code for a pop-up will have an HTML tag including it in a class of object (such as  name...) and the .CSS file will have a range applying to objects of that class (such as  name  display attributes .   23:16 14-Jan-2018
 * That screenshot is not Navigation Popup. That is likely Page Previews. It is not installed on Meta. &mdash; revi  09:32, 15 January 2018 (UTC)
 * That will be why they look so different, thanks for spotting that. As the extension is in beta release at the moment, would I have to wait for it to be a stable release before Miraheze considers installing it for users? 12:04, 15 January 2018 (UTC)
 * Extension is deployed on Wikimedia Foundation wikis, so it does not require any additional step. Request at Phabricator as usual, thanks! &mdash; revi  12:06, 15 January 2018 (UTC)

Miraheze on MediaWiki.org
I was searching for "independent third-party" references to Miraheze, stumbled on our description at MediaWiki, and made some corrections to the article's Intro. 05:10 15-Jan-2018
 * I noticed, thanks :) Only of course, Wikipedia doesn't treat MediaWiki.org as a "reliable" source. Reception123 (talk) ('C' ) 05:42, 15 January 2018 (UTC)

Yes, and my edit doesn't change that. They didn't list us because they found us notable but because we use their product. I found nothing else in the first two pages of a DuckDuckGo search that isn't from one of our wikis, except a page on Wikiversity that is a clone of the Draft that is not being let into Wikipedia. 13:43 15-Jan-2018

Is this a game changer for Wikiversity/Miraheze?
Let me be bold and suggest that this development on Wikiversity has important implications for Miraheze. My contention is that in many ways Miraheze is configured the way Wikiversity and Wikibooks should have been configured. While the Great Wikipedia has dominated Google searches, and deserves its primary spot, something is missing. And that "something" is diversity. There needs to be more than one wiki article per subject. Wikiversity and Wikibooks were attempts to fix that problem. Both failed because they lacked the ability to partition diverse points of view. An article was either on Wikiversity or off Wikiversity. If it was on, it was muddled with all the other efforts from the perspective of a Google search. Miraheze realized that the various "viewpoints" of human thought needed to be placed on separate wikis so that Google could treat them differently.

The extermal link above refers to Wikiversity's decision to create a Draft space that apparently hides all its pages from Google. I don't know the details, but try to find "Wikipedia Draft:Miraheze" using Google. This page on Miraheze is invisible to Google. So is that page. The format of "this" and "that" represent the two extremes Wikiversity might use to display Wikiversity's low quality articles in Draft space. But, while "Draft" space seems to be invisible to Google, all of the Miraheze wikis are independent, and (I hope) will be treated differently by Google.

Miraheze has wisely chosen not to be the judge of a wiki; not to distinguish between the sublime and the ridiculous (that is Google's job.) If this decision to create a Draft space on Wikiversity goes as I hope, then the authors of low quality Wikiversity articles will be faced  with a delima:  either (1) stay on Wikiversity in draft space and be "invisible" to Google, or  (2) put their crap on Miraheze.

But Miraheze should not be offended by this because Miraheze can also host our best work. Miraheze can host the coordination of educational private student wikis wright.miraheze, as well as private collaboration by scholars on wikis like wikiversity.miraheze. The significant feature of both links is not their quality, but the prospect that others will use Miraheze in the same fashion. At least that is my hope and my dream. --Guy vandegrift (talk) 01:12, 16 January 2018 (UTC)


 * COMMENT: For evidence that Draft space is invisible to Google, see this screencapture of a Google search for (Wikipedia Miraheze). It is possible that enough attempts to find the page in Wikipedia draftspace will "train" Google to find it.  But at the time of writing, Google did not know about wikipedia:Draft:Miraheze.--Guy vandegrift (talk) 01:13, 16 January 2018 (UTC)


 * It is not surprising that Google can't or won't find the Wikipedia Draft namespace, as it is formally not a part of Wikipedia. Google could do its job better if its searches extended to Drafts; also if it knew MediaWiki and combed through the history so you could search for something that used to be on a page.  But it doesn't, I guess.  If that's the case, then being consigned to Draft space is comparable to getting your page deleted, in terms of search hits.  Sure, Miraheze remains an option for those treated badly elsewhere.  But moving to Miraheze won't, by itself, result in your page getting read.
 * Separately, I reject the false dichotomy above, as https://TheMirror.miraheze.org is both sublime and ridiculous.  04:55 16-Jan-2018
 * The issue is, it still would be hard for users on Wikiversity to find out about Miraheze. So unless someone makes a proposal that says if they need a place to write their articles, etc. they can use Miraheze, I'm not sure many users will find it. Reception123 (talk) ('C' ) 06:20, 16 January 2018 (UTC)
 * I agree that the obscurity of Mirhaheze is a major impediment to my proposal. Apparently that will take time to fix.  I hope you folks stay healthy in the meantime. One thing is certain, as I see it:  We need the kind of diversity that Miraheze is trying to offer. Top-down organizations like the WMF can't handle too much diversity, not because they are rigid or closed minded, but because the way their wikis are configured.--Guy vandegrift (talk) 13:48, 16 January 2018 (UTC)
 * We are back to the chicken-and-egg problem on view at any American baseball stadium: You don't draw fans until there is word of mouth, nor signs on the outfield wall, to pay for the word of mouth, until there are fans to view them.  Again, the usual solution is to pay to advertise the institution, but that is money on a much larger scale than we are used to, plus dealing with specialists in false claims, plus no guarantees of good results.
 * By the way, Guy, the lesson I take from your pointers to Wikiversity — that they too are creating a Draft namespace — suggests that, in the long term, their rulemongers will want to harmonize their Draft policy with that of Wikipedia, and their article on Miraheze (which again, is a copy of an old draft from Wikipedia) will be moved to Draft too, one more reference site where, officially, we are not mentioned.  14:24 16-Jan-2018
 * As one of the rulemongers I can assure you that the Miraheze article will stay out of draft space. But there was a Volleyball site that didn't bother me on Wikiversity, but some of the others thought it was not sufficiently academic for Wikiversity.  Simply by writing policy guidelines that  direct authors to Miraheze would bring in business.  Also, I would pin more of my hopes on seeing the Wikiversity WikiJournals thrive, because that would encourage people to compose their work in wikitext, often on Miraheze where they can work free from prying eyes.  --Guy vandegrift (talk) 22:17, 16 January 2018 (UTC)
 * In that case, Wikiversity may want to grab the updated text from the Wikipedia draft.  22:47 16-Jan-2018
 * Goo idea, Miraheze could use a makeover.--Guy vandegrift (talk) 04:24, 17 January 2018 (UTC)
 * PS: WMF config is explicitly telling search engines 'not to crawl' Draft: and Draft_talk: namespaces. It cannot be changed by using . Thank spammers and SEO people for it. &mdash;  revi  11:43, 17 January 2018 (UTC)
 * Here is why this might be a game-changer for Miraheze: Look at the bottom of this permalink: wikiversity:special:permalink/1806926--Guy vandegrift (talk) 17:47, 17 January 2018 (UTC)
 * I told Coolie Coolster his recent efforts to aggregate podcast websites at his Podpedia likewise make us more of a go-to site than individual efforts would. Synergy.   19:12 18-Jan-2018

Bordering the ridiculous
Having read this I can see why the draft submission was declined but at the same time it's just another kick in the teeth for minorities wanting to get information published on the Holy Grail that it Wikipedia. To be honest I hadn't done a search for Miraheze on Wikipedia but to have a draft declined simply because there isn't enough public visibility of the subject that can be readily verified is bordering the ridiculous. Again, I understand the need for visibility and for sources, but conversely, what about the multitude of pitifully small (one short sentence or so), non-referenced articles that have made it through the submission process. I am sure some of the really obscure subjects that do crop up as an official article have little-to-no immediately verifiable sources, otherwise someone would have included them. So, what separates those crappy little articles from the Miraheze draft? I like Wikipedia but at the same time I find it extremely overburdened with policies, guidelines and conventions and quite frankly many of the users are full of infallibility and self importance.

But I digress. I think the Miraheze draft certainly has issues and could be improved. If staff and members want to get Miraheze "out there" more the issues in the draft need to be addressed otherwise it will never be accepted. Spreading the word seems to be key here and how that is done is limited only by imagination. I was once interviewed on radio once for an old website of mine (which is now the current version of my Lonsdale Battalion site) as a radio boss found a poster in a local library and thought it interesting to speak to me about it. I chatted on forums as well and word got out. But I am sure collectively between the community there are many other ways Miraheze can be published in solid, verifiable sources that can be used to strengthen it's visibility in the world.

All regular users who actually have a workable website could also write a piece about it in the project page space and link back here. It would be a shame for everyone who has worked hard over the last two or three years in getting Miraheze into a well-oiled machine only to have it hindered by lack of global visibility other than its community of websites. 02:10, 19 January 2018 (UTC)


 * As far as visibility is concerned, advertising Miraheze might help. I noticed that Google has an offer that they sometimes give to people that if you spend $25 you can get another $100 in advertising credit. If four people each spend $25, that would be $600 in advertising value for Miraheze. CoolieCoolster (talk) 03:24, 19 January 2018 (UTC)


 * It isn't ridiculous, it is their rules, meant to resist vanity articles. And Borderman's main argument is essentially two-wrongs-make-a-right.  In fact, in my experience, I have run into tons of rulebook lawyers, most recently when one of those charming people who go around slapping templates on articles for other people to do work hit my Violation (basketball), which does nothing more than guide the reader to other articles, but he had several rules that allegedly proved it needed footnotes, and which I did not care to read.


 * Borderman, please follow the links to our previous discussions on this, one of which is archived. There is a difference between notable wikis being hosted on Miraheze, and Miraheze being notable.  To repeat an analogy I gave Reception123 by email last week:  Someone posts something on a bulletin board at Walmart, and the press carries a photo of that thing, by which you can tell it was at a Walmart.  That doesn't necessarily say anything about Walmart nor necessarily make Walmart notable.


 * Assuming our wikis became notable, I think a sentence in the Intro that said, "Miraheze is the site that hosts wikis such as Lonsdale Battalion (wiki), The Great War (wiki), and The Mirror (wiki)." would go a long way toward convincing the reader he wasn't merely reading a vanity article. But it would make no headway against the notability rule.   03:55 19-Jan-2018


 * PS--Regarding "write a piece about your wiki," we have Gazetteer of wikis, though I have tried to ensure that people merely write one line about their wikis. One thing Uncyclopedia does to encourage community, cross-pollination, and awareness about what's been written, is "feature" an article on the main page; formerly, one a day but lately less than one a week and sometimes poring through the archives.  They use a voting process, which has been a huge magnet for drama; during the years when you could not nominate your own article, it also led to cliques.


 * Surely the Stewards are aware of what is being done throughout Miraheze; if such an additional use of the Meta Main Page appeals to them, they should periodically grab a copy of part or all of an attractive page on one of the wikis, pointing the reader there to finish the page.  04:04 19-Jan-2018


 * PPS--Related: Trump snubs The Mirror on Fake News awards   04:32 19-Jan-2018

Another effort to "advertise" for a Miraheze-Wikiversity connection
I am uploading OpenStax slide presentations to Wikiversity and calling for collaborators in an effort create materials for OpenStax Astronomy. See Wikiversity:Category:Openstax file/Astronomy --Guy vandegrift (talk) 15:14, 25 January 2018 (UTC)
 * I checked it out, looks good :) Hopefully it gets attention from people. Reception123 (talk) ('C' ) 18:58, 25 January 2018 (UTC)

Breadcrumbs for Main namespace
I've started using quite a few subpages on thegreatwar wiki and noticed that there doesn't seem to be any breadcrumbs for Main namespace subpages. Is there an admin setting that turns these on for individual sites or is extension-based? No mention of it in Extensions so hoping it is a simple matter or something I have overlooked. Thanks. 02:35, 17 January 2018 (UTC)
 * Yeah, it's pretty simple. For some reason the default settings for wgNamespacesWithSubpages does not include the main namespace. Therefore pages are not treated as subpages and do not have breadcrumbs. It's easy enough to fix with a quick visit to phab. -- Void  Whispers 04:37, 17 January 2018 (UTC)
 * Ok, thanks. I have put a request in. 17:17, 17 January 2018 (UTC)

Parser functions...again. Help needed to understand them.
As mentioned in a previous posting I am going to have to use parser functions again but this time to remove whole row/s in a table (with a colspan of 25) if those rows are empty, not just have empty cells in the table. Before I go any further, is this even possible? Because if not I'm going to have figure something else out. If it is possible, them I am going to need a little re-educating on the subject and both and  helped a lot last time. If it is doable I will explain further after confirmation. Thanks. 17:27, 17 January 2018 (UTC)
 * Parser functions can keep stuff from being generated, provided that you are able to describe it at page-generation time. Removing entire rows that you have already generated would have to be done by (gasp!) JavaScript.  Pointer and details, please?   17:40 17-Jan-2018


 * PS--Colspan is 25? Are you saying you want to remove the row of a table that constitutes a sub-heading, in the case that it is a subheading of nothing?  This suggests JavaScript would be required.  To simply remove rows of data, in the case that there are no data, imagine a template, called repeatedly, that generates one row of the table.  Parser functions would easily inspect the data and, if null, output the null string rather than a row of empty columns.   17:46 17-Jan-2018
 * I would like to be able to remove entire rows (plural) if need be, not the data inside the cells (because in some cases there won't be any and the cells will be blank) but to remove the actual rows themselves. To break it down, I am transcribing an old book which has 640 pages. I have created a table with space for 700 pages (so I can use the same template for other transcriptions of a similar length). However, I don't want the last two rows to be visible - there's no point in having so many empty cells visible. Each row consists of a colspan of 25. I chose this number because it's easy to work with in sections on large tables. So there will be at least 50 cells over two rows that I would like to remove on the transcluded page. Other projects might require further rows to be removed. This is what I am after and I have a feeling it might be too much work to implement. 18:21, 17 January 2018 (UTC)
 * Currently, the thegreatwar wiki is set to private but I have changed permissions for you so you should be able to access the site. Let me know if you can't. I'll point you to the corresponding template and transcluded page where the template is still being built....slowly. 18:24, 17 January 2018 (UTC)

A question about extensions
I am having an extension created for Podpedia that I don't want to publish to MediaWiki. Will it be possible to add it to Podpedia without first publishing it to MediaWiki once the extension is complete? CoolieCoolster (talk) 22:40, 20 January 2018 (UTC)
 * The extension will have to be open-source and published on GitHub for us to be able to add it to our current list. You don't need to list it on MediaWiki.org if you don't want to. It will also naturally have to pass a security review, like all other extensions. Reception123 (talk) ('C' ) 06:29, 21 January 2018 (UTC)

P.S.: I also moved this to Community noticeboard as Stewards have nothing to do with extensions. Reception123 (talk) ('C' ) 06:29, 21 January 2018 (UTC)
 * I only want Podpedia to be able to use it, so could is there a way to publish it on GitHub where it is only viewable by people who have a link to it? CoolieCoolster (talk) 13:37, 21 January 2018 (UTC)
 * Or is there a way to disable downloads of it for most people? CoolieCoolster (talk) 13:39, 21 January 2018 (UTC)
 * Details? What effect do you want to achieve?  Is there another way to achieve it without importing mysterious code?   14:27 21-Jan-2018
 * Extensions are added a submodule to the MediaWiki repository on GitHub. Anyone would be able to view the source code just by opening the submodule. MacFan4000 (Talk Contribs) 15:18, 21 January 2018 (UTC)
 * The extension will make it very easy for anyone to create a podcast wiki, so if anyone can use it on their own websites, they have no reason to use Podpedia. That is why I want to make sure only Podpedia has access to the extension. CoolieCoolster (talk) 15:22, 21 January 2018 (UTC)
 * Coolie, it is a good idea to make Podpedia a directory of podcast wikis, but you should achieve that by continuing to persuade other users, not by working to give it tools unavailable to others unless they play ball with you.  15:47 21-Jan-2018
 * I'm paying for an extension, so shouldn't I be able to have exclusive access to it? CoolieCoolster (talk) 15:53, 21 January 2018 (UTC)
 * I am not an expert on what your rights are on Miraheze. You might not be able to upload porn to certain wikis, nor store weapons in your apartment, even if they are unquestionably yours.  But it would be better to proceed as a collaborator and not a monopolist.   16:35 21-Jan-2018
 * Collaboration is exactly what I do want! Having such an extension available to anyone simply encourages people to set up their own websites instead of collaborating on one website together. Is it not better to have one wiki with ten people than ten wikis with one person each? CoolieCoolster (talk) 16:49, 21 January 2018 (UTC)
 * This is a tough situation. As MacFan mentioned above, we use extensions by adding them to our MediaWiki repo as submodules. Therefore, your extension would have to be open-source in order to be added, or else anyone would have access to it anyway. I'm not sure what elements you're thinking of that would require to be private, and not open sourced? Anyway, unless someone has experience, it wouldn't be that easy to get to the source code, and understand what it does. Reception123 (talk) ('C' ) 17:32, 21 January 2018 (UTC)
 * Alright. CoolieCoolster (talk) 18:10, 21 January 2018 (UTC)
 * At least, (while this is my personal opinion) the source code of extensions should be compatble with MediaWiki's license, GNU General Public License v.2 or later. &mdash; revi</tt>  09:44, 22 January 2018 (UTC)

Stats and analytics
I want to collect traffic stats on my wiki. I saw the page saying it was a work in progress involving Piwik. But I was wondering if there is a short-term fix: can I use Google Analytics or FireStats or something similar? Abundance (talk) 01:19, 24 January 2018 (UTC)
 * I think I remember someone saying that Google Analytics was disallowed for privacy reasons. CoolieCoolster (talk) 12:00, 24 January 2018 (UTC)
 * ^ is correct. We do not allow Google Analytics because it connects to 3rd party and provide potentially personally identifying informations, (then use it for ads). &mdash; revi</tt>  12:12, 24 January 2018 (UTC)

Suggestions for Miraheze
I had two ideas that could potentially improve Miraheze:

Suggestion #1: Use Patreon as a source of monthly income. Currently Miraheze only receives funding whenever someone makes a one-time donation, however Miraheze pays monthly costs, which are only increasing. Having people make monthly donations would offset the monthly costs, and people could be given rewards for supporting Miraheze. One possible reward for donating could be someone's name or the name of their wiki on a "donor board" depending on how much they donate to Miraheze per month.

Suggestion #2: Switch Miraheze's real-time chat system from IRC to Discord. IRC is more outdated and complicated to manage than Discord. Discord has features such as multiple chat channels, voice chatting, and a chat moderation system that makes Discord better than IRC. To connect to my first idea, you can also give Patreon donators "donor ranks" in the Discord chat to encourage more people to donate.

CoolieCoolster (talk) 23:29, 28 January 2018 (UTC)