Fandom Developers Wiki
Don't have an account?
Register
Advertisement
Register
Fandom Developers Wiki
Fandom Developers Wiki
3,145
pages

Talk: SpoilerAlert

Back to page
Revision as of 01:14, 31 October 2012 by Random-storykeeper (talk | contribs) (→‎More than one function: new section)
Sign in to edit

This is the talk page for discussing improvements to the SpoilerAlert page.

How to trigger

There's no instructions given on how to trigger this function to pop up on a window.

I'm not going to rename my pages where I want to use this to Spoiler:Pagename. That's ridiculous.

How does SpoilerAlert/Demo trigger it? It is not called Spoiler:Anything (close, but no ":" in "SpoilerAlert".

I tried copying the line from the Demo source: "<div id="SpoilerAlertDemo" style="text-align: center; height: 500px;"> </div>" as it would make sense if the code checked for some div id... but it didn't work.

Please advise,

Thanks, Dollars_small.png DarkMoonRising € talk contribs 15:33, July 14, 2012.

PS. When I didn't use the nowiki tags on the div id above, this page prompted the Spoiler Alert dialog to pop up. PPS. On both the demo and this page, clicking on No, not yet or Yes please does nothing - the dialog just stays there. I assumed for the demo it was because there was no page data to dispay, but the dialog refused to go away on this talk page. Also this text still showed below the dialog box. So I really don't think this code is working too well. Dollars_small.png DarkMoonRising € talk contribs 15:37, July 14, 2012.

You don't have to rename your pages. That was just an example. All you need to do, is provide your own isSpoiler function. That function tells SpoilerAlert whether it should display the dialog or not. If you tell me how you want to trigger SpoilerAlert I'll write an isSpoiler function for you! :)
You say, you clicked on both "no" and "yes" but the dialog did not disappear? That's strange. I just tested the demo and it does work for me. Can you tell me what other scripts you're using and where you've added them? -- pecoes 16:23, July 14, 2012 (UTC)

Cool! I was just going to try it out on: w:c:ParadiseIslandHD:Upcoming buildings and features and I don't forsee using it on any other page (our site(s) don't really have much use for it - but I happened across your code and thought I'd chuck it on). I have a {{Spoiler}} box at the top of that page, I figured it could still stay there after the dialog pop-up disappears. So how about it triggers on any page that the {{Spoiler}} template is on?

Re: What other scripts I have? I just clicked on SpolierAlert/Demo here on this site, so whatever scripts I have on other sites would be irrelevant...

I use IE9, it shows the dialog at the top of the page, the clear cache and reload underneath it, and this is a demo text below that. I just opened it in Chrome and it works properly... Dollars_small.png DarkMoonRising € talk contribs 16:34, July 14, 2012.

Okay, I've modified the template a little. Add this to your MediaWiki:Common.js:
window.SpoilerAlert = {
    isSpoiler: function () {
        return Boolean($('#spoiler').length);
    }
};
importScriptPage('SpoilerAlert/code.js', 'dev');


pecoes 16:56, July 14, 2012 (UTC)
I can confirm that SpoilerAlert is broken in IE9! I'll get back to you when I have a fix! -- pecoes 17:17, July 14, 2012 (UTC)
Correction: It does work in IE9. I had to clear my cache though. -- pecoes 17:44, July 14, 2012 (UTC)

Hi, sorry, was busy elsewhere. It works almost-perfect in Chrome, but in IE9 it just displays the dialog on top of the page, so you can still see the page unhidden, and the buttons do nothing, so the dialog won't go away.

Any reason you moved the noinclude tag, as the existing spoiler template now no longer displays its dialog box. I thought it would be cool once the Yes/No dialog disappeared if the Spoiler template still showed its box at the top. Also, like on your demo, if the user presses "No", instead of showing a blank page, it should show the "refresh cache and reload" button - perhaps integrating with the nice-looking existing Spoiler template. ie. If they press "Yes", the neat-spoiler box remains up the top as a friendly reminder, if they say "No", only that box shows with an option to reload.

In IE9 I pressed Ctrl-F5, etc, but it never worked, not even the Demo page. It will need to work for everyone first go, we can't expect users to go through some IE menu, cache-clearing just to get a Yes/No dialog to work...

But since I last looked and I got busy, now neither the Yes/No or old Spoiler Template show up...???

I just wantesd to use it because it looked really professional for our website. But if it's too complicated, just a simply Nav Box will suffice:

As in: 

 <div class="NavFrame collapsed"> <-- automatically hidden by default -->
   <div class="NavHead" style="Spoiler Alert colouring; and background; and optional border; etc;">
     Spoiler Alert Message
   </div>
   <div class="NavContent">
     [... Wrap around Page Content here - Optionally, just certain / multiple sections can be hidden...]
   </div>
 </div>

The above could even be wrapped into two templates: {{Spoiler-begin}} and {{Spoiler-end}}

I moved the include tag because I thought a double spoiler alert would be unnecessary. But that's completely up to you of course.
I do see the dialog in IE9 - both on the demo page and on the template page on your wiki. Both work fine for me. I even set up an experimental page on my own wiki and it works there as well.
But I see that your wiki has been migrated to 1.19. Given the annoying experiences I had during the last few days, I'd be willing to make any bet that the migration is responsible for this problem.
It may be a good idea to postpone the installation of SpoilerAlert until Monday or Tuesday. From what I keep hearing that's how long it takes the Wikia people to iron out the kinks.
If you'd rather do it now, use Chrome, please, and tell me if the console shows any error messages! -- pecoes 21:27, July 14, 2012 (UTC)
I've been making all these test with IE for nothing haven't I? You already decided to give up on SpoilerAlert haven't you?
pecoes 22:18, July 14, 2012 (UTC)
  1. Re: But I see that your wiki has been migrated to 1.19
    • It doesn't matter what version of MediaWiki "my" w:c:ParadiseIslandHD site is using - I see the same problem on the Demo on dev wiki. And I looked at it first a few weeks ago and saw the same problem. I've just learnt a bit more about js since then and decided to have a go at using it.
  2. Re: "It may be a good idea to postpone the installation of SpoilerAlert until Monday or Tuesday"
    1. I don't think the issue is related to the MediaWiki version...
    2. I have to postpone the installation until it works reliably. Any future testing I can do on the dummy site w:c:ParadiseIslandAndroid
  3. Re: If you'd rather do it now, use Chrome
    • I can't control what Browser a thousand other visitors use! The page needs to work for everyone regardless of browser.
  4. Re: I've been making all these test with IE for nothing haven't I?
    • Not at all, you're not expecting that I was going to be the only person to use are you??
    • Besides, for almost anything there are always alternative ways of achieving the same result, not everyone will want your method.
    1. Re: You already decided to give up on SpoilerAlert haven't you?
      • Not necesarily. I am dynamically working on many projects, pushing the bounds of wikitext. But as I said, if something's not working, I can't leave a broken page sitting there. So I found an alternative at least for now.
      • As I said, I think your dialog box looks really professional. I don't know what the problem is, you say it works with IE9 for you, but it obviously doesn't for everyone. You also said you saw the problem first before clearing the cache - hopefully that might be a clue as to what the problem is.
      • To be honest, if you sort out the problem, I don't know if I'll use it now on that page or if I'll stick with the hidden NavFrame. I accidentally made it look that way with the Show(Expand) below the header, but now that I have, I think it actually looks really great, and it just works, so I might just leave it that way.
      • But I re-iterate, you shouldn't be working on it just for me!!! I've pointed out a couple of issues for you. I first came across it a while ago but because it wasn't working I ignored it. It was only because I just learnt a little more about common.js that I queried the issue - otherwise I would have just moved on. It's entirely possible several others have come to use it but ignored it because it's not reliable. But now that anyone looking at this page knows that you are actively working on it and fantastically communicating to iron out issues, others may want to look into it again.
      • As I said, "my" site really has no need for it at all, I just wanted to use it to make it look "profressional", but get it working reliably and there will be many from all the TV-shows wikias that might find it useful! Except one issue is that it hides the whole page wheras my "workaround" can be used selectively anywhere and multiple times on one page.
  5. Even if I do stick with my workaround, I'd be glad to help with testing and feedback.
    1. Besides it not working for me on IE9 for whatever reason, the biggest issue I think is "Installation documentation".
      • Your Installation says to simply importScriptPage which will trigger if the pagename is Spoiler:pagename, but no documentation for alternatives. And then you give Options to change the text such as alternative languages, but we are unable to make those changes using importScriptPage - we'd need to change the source which will affect everyone, or copy and paste the whole js which will no longer update any changes, so the instructions contradict each other.
      • Like the ShowHide/code.js, you need to keep the import option and add the following features and document them:
        1. Add localisation languages and allow the user to add to their js a var SpoilerConfig = {en: {yes: "accept", no: "protect me!", warning: "warning message"}}; customisation.
        2. Add "trigger" options to the source instead of you customising some js for each individual- eg: Include in the source as you have a trigger to launch if the pagename is Spoiler:pagename, but add to the source a trigger if the page is in Category:Spoiler and also if there is an ID="Spoiler". ie. You want it so people can just drop in the importScriptPage line and have it work flexibly without the need for developer interaction.
  6. I'd say in developer terms, this would be at Beta Version 0.9. It needs a little more work before it gets to RTM 1.0 and I look forward to that.
  7. There are still several issues with ShowHide, in particular how the "buttons" are just plain bracketed-text and no-one can get the bracketed-text-buttons to go where they want, and pressing them changes the centering of the text around them because the text changes width, and in comparison the best thing about SpoilerAlert is the professional use of buttons.
    • What I really want to see - is a ShowHide NavFrame method of wrapping sections to show/hide with its localisation options, but with Show and Hide being real buttons like yours. (I also think ShowHide needs improving, you should not be forced to change the labels across your whole site in a var in common.js. Just like you can set the Header in NavHeader, you should be able to set NavButtons = Show|Hide / expand|collapse / reveal|hide / etc, per individual page.

Dollars_small.png DarkMoonRising € talk contribs 05:02, July 15, 2012.

Very well. My last reply was a little short-tempered. I've been getting tons of bug reports for all of my scripts in the last few days and in each and every case the culprit turned out to be the upgrade. That's aggrevating. Especially since there's ultimately nothing I can do.
And I'm still not convinced that the upgrade is not the cause of your problems. Just because you use a user-script and not a site-script doesn't mean the upgrade won't affect you. I hear that Dopp (from Wikia Staff) has admitted there are also problems with user-scripts - mostly caching problems. There must be a reason why the code works for me in IE9 in a 1.16 environment, but not for you in IE9 but in a 1.19 environment.
I've followed your suggestion to rewrite the documentation to feature the triggers more prominently and make the language customization stand out a little more. Let me know if you think it's better now!
With the upgrade MediaWiki's build-in collapsible elements become available. By default it looks almost exactly like ShowHide, but according to the manual it should be possible to create a custom button if you give it the classes mw-customcollapsible and mw-customtoggle. With that solution you'd get the best of ShowHide and SpoilerAlert: a collapsible area with nice looking buttons. It does require a bit of hand work though. If you decide to go that route and need help, let me know! I would be very interested in the outcome myself! -- pecoes 11:05, July 15, 2012 (UTC)
Re: "And I'm still not convinced that the upgrade is not the cause of your problems. ... There must be a reason why the code works for me in IE9 in a 1.16 environment, but not for you in IE9 but in a 1.19 environment."
Absolutely - I can understand some code (and have written some simple code) but I am not a programmer. All I can do is give detailed feedback as a user to assist you to assist us :-).
I am not arguing, but I am letting you know that I have jumped on other "clean" computers, with nothing cached, without logging on, with nothing to do with ParadiseIsland, and I have just gone to SpoilerAlert/Demo and it doesn't work - the page loads and the dialog box sits on top without hiding the page, and the dialog won't go away.
Re: class=mw-collapsible - I tried that in my collapsible tables the moment it came out and reverted to importShowHide's class=collapsible because mw-collapsible does not have the option to collapse by default, the buttons seemed no better, and were not customisable (at least if they are options, none of those options were documented).
Re: "I've been getting tons of bug reports for all of my scripts in the last few days and in each and every case the culprit turned out to be the upgrade." - Quite likely, its not just your scripts, even such built-in things as Tabview is completely screwed up, and my Forum bug-report has gone ignored so far; Slideshow doesn't work any more, and my Forum bug-report has gone ignored so far; and Wikitable class styles have changed and they're telling use we need to change our own css settings to work around this. We just need to know if the other issues like that are going to be fixed soon or if we need to manually implement workaround fixes on the thousands of wikis in existence. It's amazing how so many issues have come through the upgrade after all their extensive testing and progressive roll-out pre-upgrade.
Even if SooilerAlert has just worked for me straight out of the box, it's possible I might not have used it on my wiki as NavFrame seems better-suited to my purpose, but you and the ShowHide people should work together - you're buttons are so much mor professional and your cursor turns into a pointer, but the NavFrame is more customisable and flexible and can hide just certain sections of the page and it works with the upgrade.

Dollars_small.png DarkMoonRising € talk contribs 01:46, July 18, 2012.

I've been thinking the same thing about ShowHide. I don't like the text link in square brackets either. Maybe it would be for the best to do away with SpoilerAlerts dialog altogether and join the ShowHide developers to add buttons - at least as an option - to their script.
I'd love to play around with MW 1.19's collapsible elements and then rewrite SpoilerAlert and/or ShowHide from scratch - if this feature lives up to its promise. But I will wait with that until my test wiki gets upgraded so I can try this stuff "at home" - so to speak.
Forgive me if I don't look into that IE9 bug anymore. I don't think I'll further support this script in its current form.
The SlideShow and TabView never worked for me btw. I've filed bug reports for both months ago. But I made the mistake of mentioning that I use NoScript. They told me they cannot support third party software.
pecoes 02:10, July 18, 2012 (UTC)

General questions

  1. Any plans to make a version of this script that doesn't hide the entire page, rather, it only hides specific content on the page? (For context, I have w:c:dragonage:Template:Spoiler in mind.)
  2. Might be a nice touch to add a customization option for whether or not the cookie is set. Some people might want the content to be collapsed on every single page load (even if the person has read it before). — Mathmagician (message wall) 22:00, July 15, 2012 (UTC)
  1. Good idea. It's been suggested to me before, too. There's a small problem though: That would only work if people would wrap the spoiler content in a specific container. That's quite different from the current approach. My understanding is that most use a category to identify the spoiler. I don't think this script has many users, but how many, I don't know...
  2. You're the first person to mention that. Is that a general proposal or do you want to actually use this script?
pecoes 22:50, July 15, 2012 (UTC)
These are more of general ideas, rather than a personal concern. I don't think I have a use for this script at this time. — Mathmagician (message wall) 23:19, July 15, 2012 (UTC)

Script customization / repurposing

Hello! Have to request some advice on customization of this script.

As a backstory, I'm taking care of an answers wiki. Most of the activity are forum-like discussions. We endorse certain formatting traditions, which the users need to be continiously reminded of (as the community is fluid and, in a big part, anonymous). I want to repurpose this useful script into a notification about formatting practices. So far, via some hackish tweaks, I got it to work on standard question pages and forum pages, in a manner similar to the original script: page blackout and a dismissal button.

However, instead of this, I would like it to only appear in the editor window, not when browsing the pages. It's technically possible: if you remove condition checks from the original script, the notification will appear in the editor, overlapping the formatting buttons (the position is probably adjustable). To get it to work properly, I need a condition check that ensures the window is only displayed in the editor. I can think of several hackish workarounds, like checking if the page belongs to (any) category, but it would be better to accurately check for the editor.

Another part I need help with is how to make the notification disappear after a set amount of time, as opposed to having to press a button. Even better, if it faded out soon after being mouse-overed. This would also solve the problem of overlapping the formatting buttons.

Since my skills with JS are limited to common sense, any kind of help would be greatly appreciated. I also hope it'll be useful to someone else. I've seen many complaints about people not signing posts properly. It could be made a separate general-purpose script for use on other wikis. Mitranim

The editor already has a mechanism for notices. Do you really want something else entirely? -- pecoes 13:37, July 31, 2012 (UTC)
Do you mean that editor's inbuilt notification is controllable? If this is the case, please tell me how to use it. I was not aware it's possible. Of course, it would be better to use a native method instead of custom workarounds. Mitranim
I do believe so. I distinctly remember getting custom messages on certain wikis. You probably have to edit certain MediaWiki pages... but which ones, I do not know. You might want to poke around Special:AllMessages a little - especially the ones that start with "edit" should be interesting. You could also ask the Community forums. -- pecoes 14:47, July 31, 2012 (UTC)
Here's a very distinctive one. You might want to ask this admin what the trick behind it is. -- pecoes 15:16, July 31, 2012 (UTC)
And there's also Editnotices. Here's a very simple example: http://pecoes.wikia.com/wiki/NewArticle?action=edit
pecoes 15:32, July 31, 2012 (UTC)
This possibility is extremely awesome. This is a big help, thank you very much. On to try an implementation. Mitranim

It works: [1] [2]. So far, it worked on nearly every namespace I tried it on. However, I ran into a problem with the forum namespace (110). It just doesn't work on forum pages. I double checked the forum editnotice, and even checked the RC logs to ensure the forumspace on our wiki is still 110 (appears to be accurate). Any suggestions why it might be not working? Mitranim

It worked in the forum too - after I purged the page. -- pecoes 19:11, July 31, 2012 (UTC)
Haha, that was one thing I was intending to do after getting back from AFK, but you beat me to it. Thanks again! Mitranim

"Ask for support", round three. I'm trying to make parts of the edit notice work like edittools, i.e. I want ---- and ~~~ to insert this code on the cursor when clicked. I've wrapped them into <charinsert> tags, but that didn't seem to do the trick. However, I've noticed that if I include either id or class with the word "edittools" into the div properties of the edit notice, the editor will display a notification with the notice text at the top of the page, just like in the talk page example you've linked earlier. When I click on this notification, it brings up a popup window with the edit notice, and there the code is clickable and works like edit tools. But I want it to work similarly on the plain notice to begin with! I'll continue tinkering around with it, but any ideas or suggestions are very welcome. Mitranim

MediaWiki:EditTools works only with the source editor - not with the rich text editor, I'm afraid.
As for the source editor: This is (more or less) what the HTML looks like:
<section class="modalWrapper" id="EditPageEditTools">
   <section class="modalContent">      
     <div class="plainlinks" id="editpage-specialchars">
         <span id="edittools_wikimarkup">
            <a href="#" onclick="insertTags('~~~','','');return false">~~~</a>
         </span>
      </div>
   </section>
</section>


Maybe using one of these tags, classes or ids does the trick...
Personally I'd use JavaScript though. The key part is probably this:
<a href="#" onclick="insertTags('~~~','','');return false">~~~</a>


But you can neither use an a-tag nor an onclick-handler in a regular template. That's only possible in a MediaWiki page. Maybe you can use a MediaWiki page as if it were a template by prefixing it with a colon. I wouldn't know that without testing. If that doesn't work, there might be other ways... -- pecoes 21:12, July 31, 2012 (UTC)
Apologies for the delayed answer. Thanks again for the information. I've created a MediaWiki template and tested it in the user namespace. It actually works! The notice looks fine, and the tools actually insert the code when clicked, which is extremely awesome. However, it has limitations. The template looks messed up due to unsupported tags, and the yellow clickable notification that appears if the div section is tagged with edittools class/id is messed up, too, along with the pop-up window it summons. This is not a problem if I eschew the notification by excluding edittools tags, but it's not a perfect solution. Still, a step ahead. Mitranim
It's a start :) I may have one or two more tricks up my sleeve. That'll require a bit of experimentation though... Can you make me an admin for an hour or two? -- pecoes 11:28, August 01, 2012 (UTC)
I suppose I can. (*poof*) Here you go. Just be careful not to mess up anything major. :) Mitranim
While the notification is useful to grab attention to the notice, I'm not sure I want it overlapping the clickable tools. When a person opens the editor, they might want to click on the ---- tool right away to separate their post from the previous ones, and the notification might get in the way. I guess I'll roll out the experimental version wiki-wide for now, without the notification, and see how it fares. But the bugs are still there. I'll try to tinker with it later in the evening, but if you get any progress, please let me know! Mitranim
Another update: it took me a while, but I've finally noticed your note that clickable edittools only work in the source editor. I checked, and indeed, the current implementation (that works off edittools' htlm) doesn't work in the visual mode. Inspecting the html for the visual editor tools produces elements like "onclick="CKEDITOR.tools.callFunction(47, this);". I'm afraid it's completely unfamiliar to me, and I have no idea how to implement a solution that would work in both editors at this point. Mitranim
Simply put: Wikia does not have any code with which you could insert characters at at the end of the RTE's text field. You would have to write that yourself. I cannot help you with that. At least not any time soon. I do have a relatively good idea, how to do it in the source editor, but I can't seem to get the Editnotice to update
I purged:
  • MediaWiki:EditnoticeTemplate
  • MediaWiki:Editnotice-0
  • and the test article
Did I miss something? -- pecoes 14:49, August 01, 2012 (UTC)
Still the same thing. None of the changes I made to MediaWiki:EditnoticeTemplate where visible in the test article. I'm starting to think that the contents of the edit page cannot be purged. This may take a while... -- pecoes 16:24, August 01, 2012 (UTC)
Editnotices usually refresh instantly and don't require purging (that's what had confused me about the forums that time). I don't know how it's displayed to you, but to me, the changes you've made took effect as soon as I noticed the fact of edits being made. From what I've seen so far, the problem is that the bar that houses the static message (let's call it "the banner") doesn't support any wiki markup whatsoever and only supports HTML tags, while the yellow notification and the pop-up window have perfect support of wiki text but only very limited support of HTML tags. Notably, they don't support <a />. As the result, even if we build the layout through HTML, it seems that there is no way to create clickable links that would be displayed and work properly in both layouts: wiki links will be displayed as raw text in the banner, and HTML links will be displayed as raw code in the notification and in the pop-up window. To get it to work, we need to make it in pure HTML, with HTML tags that are supported in the notification etc, and make it clickable through something else than <a />. Unless of course I'm missing something crucial. Given that your code looks like arcane sorcery to me, I probably am. Mitranim

Ah. My mistake. I opened a page in the article namespace - not in the user namespace. I was able to fix it now. It only works in the source editor, of course - but at least that. -- pecoes 17:27, August 01, 2012 (UTC)

Are you absolutely sure it works? For me, it doesn't. The mainspace notice reads "EditnoticeTemplate" (and nothing else), and the userspace message is un-clickable. Mitranim
Ha. Now you are testing in the article namespace :) Yeah, I had a bit of cleanup left to do. It should work now there as well :) -- pecoes 17:38, August 01, 2012 (UTC)
Unfortunately, not for me. Here. The mouse cursor didn't quite make it into the screenshot, but it's an edit cursor rather than a pointer, and the tools are definitely not clickable. =/ Mitranim
W00t! I just figured out how to make it work in the visual editor as well :) It should work in both editors now. I purged everything too, so you should get to see it now - or hopefully soon... -- pecoes 18:27, August 01, 2012 (UTC)
Huh! I salute to your coding skills. It works indeed, but with an unexpected twist. It's not the server cache's fault. As it turns out, the solution you've implemented doesn't work if the visual editor is disabled in personal preferences. This is how I usually operate, and I use a separate browser instance to check pages in the visual mode. I've purged all the pages several times over, to no avail, then on a hunch headed to my preferences and enabled the visual editor, and this did the trick. With the visual editor enabled, the solution works for both visual and source mode, while without it, it doesn't work at all. Still, it's a step forward since the main purpose of the notification is to make casual visitors follow our formatting practices. I guess I can disable the editor and live with that knowledge. Although it would surely be better to find a solution that works for everyone. :) Mitranim
So far, it doesn't appear that the last experiments have had any effect (that's probably why you reverted the changes). I wonder if this is something we have control over, or just a bug on Wikia's side. Mitranim
Great job detecting that issue with the preferences! :) This has me stumped I'm afraid. It seems I have to subscribe to events of a different editor object. But how exactly to do that only somebody from Staff could tell me. I've send Grunny an email. We'll see...
I gotta say: This is really fascinating stuff! I've already discovered two cool things I wish I'd known months ago :)
pecoes 20:19, August 01, 2012 (UTC)
Grunny got back to me almost immediately. This solution should work now even when the RTE is disabled! :) -- pecoes 21:16, August 01, 2012 (UTC)

This is awesome. Thank you for telling me about editnotices and for taking time to work on clickability, Pecoes. Clickable tools are very cool, and add extra convenience, raising the likeness of the code being used. The notification was extremely effective on MEA during the last two days: all of a sudden most anons started using ---- lines and signing their posts. It's potentially useful for other wikis, too. Even if they don't employ specific formatting traditions, it can be used to emphasize the need for ~~~~ on talk pages and conversations, and serve as an easy signature button for lazy ones (who're the problem to begin with). Afaik, there's some kind of code repository here on DW. Maybe a template for the code should be included there? Mitranim

Good point. I should consolidate this into an article or some other form of recipe. -- pecoes 08:28, August 02, 2012 (UTC)
Oh, and feel free to revoke my adminship now! :) -- pecoes 08:40, August 02, 2012 (UTC)
I suppose I can. Although, I got another idea about the tool that I'm afraid I have no idea how to implement. I've noticed that some users click the ---- tool right after positioning the cursor in the end of the last message (the lowest position the editor allows), expecting it to insert line breaks automatically along with the code. It would be cool if it actually did. I even vaguely remember some native Wikia's horizontal line tool doing this, but was unable to find it. I'm interested how it can be implemented, since the current insertion method works off the displayed text, not a separate pre-formatted code. Even more interesting is, how to make it insert proper "invisible" line breaks and not <br> tags or something. Mitranim
It works! Thanks again! Also, I've found which of Wikia's tools works this way: it's the "horizontal line" button among the formatting buttons in the source editor, the ones that have images to them. Mitranim
Hmm, now this is interesting. I've noticed that while it works totally fine in the source editor, it's somewhat messed up in the visual editor. Instead of adding one new line, it adds two (which are actually four in the source). I suppose it has something to do with the way visual editor treats line breaks: by default, it inserts two lines with one Enter stroke instead of one. No idea why its behaviour with the code is so inconsistent though. It made no difference to the visual when I added an extra line after the code, while in the source mode, it took effect properly. Mitranim
I've done some more testing. Here are the observations.
  • I've noticed (you probably already knew that) that if you have visual editing enabled, the source editor you can access by clicking a tab to the right uses the same insertion code as the visual editor itself (i.e. the first click function). If visual editing is disabled, the second click function is used.
  • The n\ before the text (i.e. "n\" + part) works properly for the source mode by inserting one line break, but in the visual mode, it inserts three line breaks, which results in an extra line.
  • The above is inconsistent with insertion of an extra line after the text in the visual editor. In this case, the editor will insert only one line break, then move the cursor to the start of the next line! In other words, it inserts three times fewer line breaks after the text than before the text, with the same code involved.
  • Example: the code is "\n" + text + "\n". If you put the cursor in the middle of the page, the click will insert:
    • Three line breaks
    • The text
    • One line break
    • Move cursor to the start of the next paragraph (no extra line break)
  • The n\ after the text doesn't work in the visual mode if there is no n\ before the text. It seems unrelated to me, probably some bug. In the source mode, it works properly (i.e. extra break after the text works even if there's no break before the text).
  • In the visual mode, the extra break after the text doesn't work if the end of the editor window is reached. In other words, if the code is "\n" + text + "\n", you place the cursor at the end of the page and click the tool, it will insert three line breaks, the text, and nothing else. It'll stop at the same line where the text is.
In conclusion, this is terribly inconsistent. I'm afraid it also fails to work for the intended purpose, since an extra line break after the text (---- in all the tests) in the visual mode was the main point. =/ Is there any other way to insert line breaks? Please tell me! Mitranim
Hm. It should be possible. I'll tinker a little more with it this evening... -- pecoes 14:11, August 03, 2012 (UTC)

I have another question on the matter of script customization. Practice of the last few days had shown that while many users are able to notice the acid-colored eye-stinging notification and have enough brain tissue to type the symbols or click on the tools, there still is a lot of narrow-sighted people who apparently are unable to see anything on their Adblock-lacking banner-filled screens that is not right in the middle of the display. And even then it's not a guarantee. To save myself some nerve cells, I'm going to enable the modified screen-obscuring notification on wiki pages. However, I want a username-based condition check that will only produce "true" if the user's name matches one of a specific list, ideally a list based on a separate page (I guess I'm just daydreaming at this point, but it's the goal). Basically the minimal info I need for this functionality is the variable / syntax to retrieve the user's name, then I'll check it against an array of names. I googled a bit for MediaWiki variables and messed around with the modified script, but I'm probably mixing up syntax from different coding environments (I can't even tell what is what). I would appreciate some advice. Mitranim

I don't know your wiki, but from your description it seems you're trying to solve the problems you have with certain users by technical means. That's not the most promising approach. If you cannot get these people to play by the wiki rules, you should either try a little harder to convince them or let it go. Both of these solutions will save you a lot more nerve cells in the long run. -- pecoes 18:27, August 07, 2012 (UTC)
It's not some problem we're trying to solve. It's a matter of conveying our distinct formatting practices (indent with * instead of :, sign with ~~~, separate posts with CSS-altered ----). We have messages about these practices all over the wiki, but we've run into a problem of very narrow attention / vision span of some users, they simply don't see the messages on the main page, in the guidelines on their wall greeting, etc, and don't pay attention to how the pages are usually formatted. It irritates me to see so narrowly attentive people, but I acknowledge there's a room for difference. That's why I'm exploring the means to make notifications more noticeable. It will help these people to get a hang more quickly, and other won't have to clean up for them. And regarding your advice to take it directly to the users, I do. These guidelines have long been part of the message wall greeting for the new users, and I often post additional messages on their walls because people hardly read those messages. My additional advice has been ignored sometimes, as well. My guess is that it happens because some people develop a very narrowly focused webpage view and don't notice the message notifications that appear in the corner of the screen. This is precisely why the page obscuring script has been extremely effective, and why the editor notification appears to be less effective: they simply don't look up. That's why I need it back. I just can't talk to users who don't see my messages. Mitranim
Addendum: you should also keep in mind that MEA is an answers wiki, which means a ton of contributions comes from anon users. Many of them are one-timers, which means there's no time to acquaint them with formatting traditions: they'll be gone after their single edit. Which is another reason to make notifications all the more prominent until Wikia implements a non-wiki engine for answers sites. But my current objective is to make the script a tool to convey notification to the registered users who ignore message wall notifications. Mitranim
Oh, and regarding the point I was making about helping users to see the notification: there are users who exhibit willingness to follow our formatting practices but are genuinely oblivious to the existing notifications, including the editnotice. For example, some people try to imitate the ---- dividing line by making up lines of underscores or some skewn apostrophe symbols (``````). These occurences are what lead me to exploring more pervasive notification methods in the first place.
I hope that covers the justification. An actual advice on syntax would still be helpful though. Or even advice where to study it, since I can't really tell which language we're using for this to begin with. :) Mitranim
Okay, I'll write this for you, but I'm going to have to ask you to wait a few days. I have quite a few Wikia obligations right now and - please don't take this personally - this looks like something that will only benefit a single wiki - one I'm not personally involved in I might add. So, I'll do it, but I have to move it a little further down on my todo list. Sorry about that! -- pecoes 08:31, August 10, 2012 (UTC)
Yep, I totally understand, and I'm grateful for help regardless. We all volunteer our time, and have to choose priorities for different wiki activities. I don't demand my questions to be answered, nor expect a quick answer. If a solution is not immediately obvious to a coder's eye, it's understandable if a request goes un-answered. As I said, I have no problem with studying this stuff myself, but I'd be glad to be told where to start (i.e. what's our coding environment). Mitranim
Coding environment? Do you mean the language? That's JavaScript. I'm using quite a few Wikia specific hooks though. Took me a long time to figure this stuff out. Most of it seems to be undocumented... Or do you mean my tools? I currently use Komodo, but will probably migrate to ZendStudio/Eclipse some time soon. -- pecoes 11:10, August 10, 2012 (UTC)
By coding environment, I wasn't referring to local editor / compiler software, but to what we're writing: the mix of programming language (which you tell me is JS) with MediaWiki variables and hooks, and Wikia variables and hooks, and whatnot. Basically, it looks like I have to look into basics of JS programming. Undocumented stuff is sad, but I guess that's what the community is for. Thanks for all the help and advice so far. I'll try to solve this stuff myself if I can, but if solution strikes you at some point, aid is welcome!
Addendum: those clickable tools broke about two days ago. Works neither in Chrome nor in IE I fired up for testing. There weren't any changes to the template, so it's probably on Wikia's side. It would be interesting to know why, and fix it. If you happen to use some of that code on other wikis, does it still work? Could be CSS-related, on some off chance? Mitranim

Just for information, I found out why the clickable tools broke about two weeks ago. It appears that due to some change on Wikia's part, JS put inside the template doesn't work anymore. The functionality was restored when I moved the script to Wikia.js. I also have something to add about the behavior of \n insertion in the visual editor. If you remember my earlier remarks about it behaving inconsistently, it can be buggy, and insert the wrong amount of line breaks in the wrong places. Turns out it's the Chrome problem. When I added back the extra \n for testing, line breaks were buggy in Chrome but worked perfectly in IE. Just so you know. Mitranim

Category spoiler help

I've put this code on my test Wiki, and have created multiple pages using the different triggers described on the page, but none of them seem to be working. The one I'm trying to make work is the trigger that puts up the warning if a page is in Category:Spoiler. All I see is this warning pop up on the category page itself, but not on the other pages in this category. Is this intentional? - Random-storykeeper (YELL AT IT) 04:06, August 3, 2012 (UTC)

It's because the description of additional variables on the script page is botched. Specifically, the function for category check is wrong. The working version should look like this:
window.SpoilerAlert = {
    question: 'This page contains spoilers. Are you sure you want to read it?',
    yes: 'Yes, I am',
    no: 'No, not yet',
    isSpoiler: function () {
        return -1 != $.inArray('Spoiler', wgCategories);
    }
};
Mitranim
Thank you. It works fine now. - Random-storykeeper (YELL AT IT) 06:21, August 4, 2012 (UTC)

Languages

You should add an auto language detection with all current languages that wikia supports.--Jens Ingels (talk) 18:43, August 7, 2012 (UTC)

Unsure

Hello, I'd like to ask about where to add the Category Trigger on my Wiki. I've put it here, but it doesn't seem to work on this page. The page hinted that it was to be put into Css, but I could be wrong. Thanks, ~ Demise101 ♥ Lets Talk! ♥ Blogs! 10:46:23 August 09, 2012 ~

You need to add a trigger to tell SpoilerAlert to look for a category:
SpoilerAlert = {
    isSpoiler: function () {
        return -1 !== wgCategories.indexOf('Spoiler'));
    }
};
importScriptPage('SpoilerAlert/code.js', 'dev');


-- pecoes 00:35, August 10, 2012 (UTC)

Yep, I've added the code to the Common.css, but it still didn't seem to load on my Sandbox. ~ Demise101 ♥ Lets Talk! ♥ Blogs! 01:43:42 August 10, 2012 ~

CSS? Does this look like CSS? :) Add it here, please! -- pecoes 02:09, August 10, 2012 (UTC)

My apologies, the page said something about Css just above the code, so I wasn't sure where to put it.

I've tried to add it, but it doesn't appear on my Sandbox. Any tips? ~ Demise101 ♥ Lets Talk! ♥ Blogs! 05:12:42 August 10, 2012 ~

This exact question was asked recently, in the section right above. You need to use a different function to do category check (see above). Mitranim

The code that Pecoes provided is fine, although it has a small syntax error with an extra parenthesis in the return statement, and Demise mistakenly put 2 import statements for the same script.
What's in your MediaWiki:Common.js right now:
/* Spoiler Alert */
importScriptPage('SpoilerAlert/code.js', 'dev');
SpoilerAlert = {
    isSpoiler: function () {
        return -1 !== wgCategories.indexOf('Spoiler'));
    }
};
importScriptPage('SpoilerAlert/code.js', 'dev');
What needs to be there:
/* Spoiler Alert */
SpoilerAlert = {
    isSpoiler: function () {
        return -1 !== wgCategories.indexOf('Spoiler');
    }
};
importScriptPage('SpoilerAlert/code.js', 'dev');
How they differ: Removed a parenthesis in the return statement that was causing a syntax error. Removed the second copy of the import statement. Do not load the same script twice please! — Mathmagician (message wall) 05:32, August 10, 2012 (UTC)
Oh, I'm sorry about that! Silly mistake. Thanks Mitranim and Math! :) -- pecoes 08:26, August 10, 2012 (UTC)

Hi guys, sorry about the delay on response. I've added the code to Common.js, but it hasn't worked for my Sandbox. I'm still scratching my head as to why it doesn't work :( ~ Demise101 ♥ Lets Talk! ♥ Blogs! 11:21:27 August 12, 2012 ~

It's worked! Thanks everyone, and sorry for the trouble :) ~ Demise101 ♥ Lets Talk! ♥ Blogs! 11:24:30 August 12, 2012 ~

In related news, is the spoiler pop-up supposed to blank the page when it appears? I'm not sure if it's because of my buggy internet/terrible browser, but it doesn't seem to for me. ~ Demise101 ♥ Lets Talk! ♥ Blogs! 11:31:07 August 12, 2012 ~

It's supposed to temporarily blank the page until the user has clicked on "okay" in the dialog. What do you see? Post a link, please! And/or what did you expect? -- pecoes 01:27, August 13, 2012 (UTC)

As I expected, the code does work, I was just using the wrong browser (Internet Explorer) and that's why certain things don't work. Since I'm pretty sure I'm the only one on the wiki who uses IE, I'm sure that it isn't an issue. Thanks :) ~ Demise101 ♥ Lets Talk! ♥ Blogs! 03:21:53 August 13, 2012 ~

Nothing happens when you hit "no"

This is a great script, but it's a bit unsatisfactory that there's no action taken if you hit "no". Is there any way to get a negative response to transport you back to the last page you were viewing? CzechOut 21:21, August 13, 2012 (UTC)

I've added a new configuration setting: SpoilerAlert.back. If you set that value to "true", it will either take you back to the previous page or to the homepage in case the history is empty.
window.SpoilerAlert = {
    back: true
};


-- pecoes 23:26, August 13, 2012 (UTC)
Thanks for the quite quick reply, but my java is ... not the best. What do I do with this code? Below is my first attempt at it, but it doesn't appear to be working since adding in the window.SpoilerAlert def. CzechOut 02:35, August 14, 2012 (UTC)
SpoilerAlert = {
            question: 'This page may contain spoilers about unreleased stories. Are you sure you want to read it?',
            yes: 'Hit me with your best shot',
            no: 'Get me the hell out of here',
    isSpoiler: function () {
        return -1 !== wgCategories.indexOf('Contains spoilers');
    }
};
 
window.SpoilerAlert = {
    back: true
};
 
importScriptPage('SpoilerAlert/code.js', 'dev');
CzechOut: let me add some comments to your code to explain why it doesn't work:
// We're defining the "SpoilerAlert" object here
SpoilerAlert = {
            question: 'This page may contain spoilers about unreleased stories. Are you sure you want to read it?',
            yes: 'Hit me with your best shot',
            no: 'Get me the hell out of here',
    isSpoiler: function () {
        return -1 !== wgCategories.indexOf('Contains spoilers');
    }
};
 
// Okay, now erase/throw away whatever the "SpoilerAlert" object was before
// wipe the slate clean, and give an entirely new value to "SpoilerAlert"
window.SpoilerAlert = {
    back: true
};
 
importScriptPage('SpoilerAlert/code.js', 'dev');
This is most likely not what you intended to do. In JavaScript (in fact, most computer programming languages), if you set a variable equal to one thing, and then set it equal to something else, whatever it was set equal to before is lost. Instead of erasing all of your existing settings, what you are wanting to do is add a new setting to the collection of settings you already have, like so:
SpoilerAlert = {
    question: 'This page may contain spoilers about unreleased stories. Are you sure you want to read it?',
    yes: 'Hit me with your best shot',
    no: 'Get me the hell out of here',
    isSpoiler: function () {
        return -1 !== wgCategories.indexOf('Contains spoilers');
    },
    back: true
};
importScriptPage('SpoilerAlert/code.js', 'dev');
Sidenote: wikipedia:Java (programming language) and wikipedia:JavaScript are two completely different languages with similar names. What we're talking about here is JavaScript. — Mathmagician (message wall) 03:43, August 14, 2012 (UTC)
Cool. It wasn't immediately apparent to me that SpoilerAlert and window.SpoilerAlert were the same variable. And yah, I know that java and js are two different languages; I was just typing quickly. But it's a point that bears repeating for those who might read this discussion later. CzechOut 13:38, August 14, 2012 (UTC)
Ah, yes, window.SpoilerAlert is the same variable as SpoilerAlert in this case. This is because SpoilerAlert is a global variable, and global variables are always properties of the window object, so you can refer to them either way. Also, organizationally speaking, it wouldn't really make sense to have two different config objects. — Mathmagician (message wall) 18:25, August 14, 2012 (UTC)
All good points. Thanks very much for the thoroughness of your reply :) {{SUBST:user:CzechOut/autosig}} 22:58: Wed 15 Aug 2012 

Resetting cookies

It would be cool if somehow I could attach a button to a specific part of the content frame which simply read "Spoiler Defence Mode" — or something equally cheesy. When pressed, the button would reset all SpoilerAlert cookies on the wiki, not just the one that applied to that specific page. Is such a thing possible, or would you have to press the reset button on every individual page? — CzechOut 01:48, September 3, 2012 (UTC)

Hi Czechout! I took my time to reply to your post, because I wasn't sure how to add a user-specific option to a site-wide script. I think I've come up with a solution I like now. This happens to be a solution that's potentially interesting for every script that's on dev (and elsewhere), so I don't want to rush it. The idea is to add a new section named "Addons" to Special:Preferences. The code that adds this new section is entirely written in JavaScript and not specific to SpoilerAlert. It has a few simple methods with which SpoilerAlert - or any other script for that matter - can add a section to the "Addons" tab. The SpoilerAlert-specific functionality is turned off for the time being, because I'd like to get a little feedback from other developers before I proceed with this. If you would like to beta-test the Preferences module, go to Special:Preferences on this wiki or any other, open the console and type in importScriptPage('Preferences.js', 'pecoes');. -- pecoes 04:46, September 04, 2012 (UTC)

More than one function

How can this code be modified and implemented twice on a Wiki? For example, if I wanted to use the spoileralert code to cover spoiler articles, but also wanted to modify it so that it serves as a cover warning to an article that may contain mature content, is it possible to put the code twice on the MediaWiki page? I've tried this several times, but it seems as though the code stops functioning properly if you want the same code to serve two different functions. - Random-storykeeper (YELL AT IT) 01:14, October 31, 2012 (UTC)

Community content is available under CC-BY-SA unless otherwise noted.
Advertisement