Talk: NoImageLightbox

window.wgEnableLightboxExt

I've only done a handful of tests, but it seems setting

window.wgEnableLightboxExt = false;

is all that's needed to prevent the Lightbox extension from loading in the first place. -- pecoes 17:29, November 09, 2012 (UTC)

The Lightbox is used for videos too, however. My version of NoImageLightbox has the goal of disabling the Lightbox only for images.

Expected behavior for videos:

• If you left-click the video, it should play normally within the Lightbox.
• If you right-click and choose "Open link in new tab" you will get to the File: page.

Mathmagician ƒ(♫) 17:38 UTC, Friday, 9 November 2012

Oh. Right. I only read the first sentence of the addon description and jumped directly to the code. Then I saw those timeouts and couldn't believe my eyes :D -- pecoes 17:47, November 09, 2012 (UTC)

The setTimeouts have nothing to do with videos. Those exist because:

• I need to modify Wikia's global window.LightboxLoader variable
• At the time of writing the script, I was encountering errors with my script not working because it was running too early -- before window.LightboxLoader was defined.
• The setTimeouts are the solution designed for that problem.

I suspect the setTimeouts aren't needed / that problem doesn't exist anymore / it was a fluke on my end or something. I'll try removing setTimeouts and see what happens. Mathmagician ƒ(♫) 17:59 UTC, Friday, 9 November 2012

(Reset indent) May I suggest to remove that click-handler as well?

if ({ oasis: 1, wikia: 1 }[mediaWiki.config.get('skin')]) {
    jQuery(function ($) {
        "use strict";
 
        if (!window.LightboxLoader || window.LightboxLoader.handleClickOverride) return;
 
        window.LightboxLoader.handleClickOverride = window.LightboxLoader.handleClick;
        window.LightboxLoader.handleClick = function (ev) {
            if ($(ev.target).parent().hasClass('video')) {
                window.LightboxLoader.handleClickOverride.apply(this, arguments);
            }
        };
 
        // href to File: page, but not for images that have the link= set, e.g. [[File:Image.png|link=MyPage]]
        $('a[data-image-name]')
        .not('.link-internal')
        .each(function () {
            var $this = $(this),
                e = encodeURIComponent($this.attr('data-image-name').replace(/ /g, '_'));
            $this.attr('href', '/wiki/File:' + e);
        });
    });
}

-- pecoes 18:19, November 09, 2012 (UTC)

I'm not familiar with how to go backwards from "I have an event object, now how do I figure out the element that triggered it" -- it looks like that's what you're trying to do, which is pretty cool. Sadly, I tested your code in both Chrome and Firefox at FloatingToc and it didn't work: left-clicking the video took me to the file page instead of playing the video in the Lightbox. Mathmagician ƒ(♫) 18:37 UTC, Friday, 9 November 2012

Hm. It seems to be $(ev.target).parent(). Not $(ev.target) itself. -- pecoes 19:10, November 09, 2012 (UTC)

Okay, I've tested and incorporated that change. Thanks. I never considered that it was possible figure out which element an event originated from (hence my click handler construction), I thought that elements triggering events was a one-way street and once the event is triggered, there's no discerning where it came from. I suppose I should go actually read the documentation for both native event objects and jQuery's wrapper jQuery.Event. Mathmagician ƒ(♫) 19:44 UTC, Friday, 9 November 2012

Script Has Stopped Working

The script seems to have stopped working over the past few days. The Lightbox is appearing in the most recent versions of both Firefox and Chrome.

--Whistle9 (Talk) 19:31, April 20, 2013 (UTC)

Thanks for reporting this. Looks like Wikia has made some small changes to HTML attributes for Lightbox media pieces. I've pushed a re-write of the script that should address those changes, and the updated version is working for me in all tests so far. There is also a new option I've added to disable the Lightbox for videos as well as images (by default, this script is not meant to affect videos).

Please let me know if the fixes don't seem to be working or if the entire script breaks again. Thanks! Mathmagician ƒ(♫) 23:41 UTC, Saturday, 20 April 2013

Tabs

Usually when I see an image, I Ctrl+Click it to open in new tab (I use Chrome btw). However, Ctrl+Click, normally working on links (and images that are on file namespace pages), does not work with this script. Instead, it opens in the same tab as though you just single-clicked it normally. Would it be possible to look into this and see if there is any way to "fix" it?

Also, Chrome's "Open link in new tab", when applying to Wikia images, lead you to a page with just the image (e.g. I prefer being led to File:ListFiles.png instead of [1]. Is it possible for a script to be written/modified so that it leads to the File page instead? — SW8573 ^(Talk) 13:55, April 26, 2013 (UTC)

These two issues have the same root cause, incidentally. Implementation wise, NoImageLightbox does not treat clicking on an image as clicking a link. Instead, it uses an event to redirect the browser to the File: page. This is why CTRL + click doesn't work properly.

This is undoubtedly poor design, but unfortunately due to the way Wikia's lightbox event handling is set up — as of recent changes within the past week or two — I have not been able to find an implementation that 1) allows the lightbox event to continue to work for videos AND simultaneously 2) kill the lightbox event for images only so that it is ignored and clicking an image is simply the same as clicking a link. Wikia uses the same lightbox for both images and videos, so it's tricky to separate the two. But separating them is exactly the aim of the default functionality of this script.

The right-click -> "Open link in new tab" issue has been fixed, that will now take you to the File: page as intended.

CTRL + click opening a link in a new tab instead of the same window cannot be fixed without coming up with a new implementation that satisfies the 2 conditions I listed above — which, if possible, I lack the event-based knowledge to do. Maybe someone else who reviews this script can suggest a more intelligent event-based approach. Otherwise, this CTRL + click bug probably won't be fixed in the near future.

Note: If you absolutely must have the CTRL + click functionality, use the config option described on the page. That option is a 2nd implementation of NoImageLightbox that doesn't suffer from this issue. You will be able to CTRL + click properly with that option. —However, videos will not play on articles. If you don't care about videos that should be fine. Mathmagician ƒ(♫) 02:56 UTC, Saturday, 27 April 2013

Update — apparently there was a rather simple solution, I just wasn't aware of it. Thanks to Pecoes for pointing me in a better direction. Ignore the above, both of these issues should now be fixed. Mathmagician ƒ(♫) 15:23 UTC, Saturday, 27 April 2013

I undid my earlier edit at w:User:SW8573/global.js as per your advice above; however, these links now lead to [2] instead of [3] (i.e. no longer lead to the File: page). If that is intentional as how you interpreted my previous post, I apologise: I would prefer being lead to [3] than [2], where the preferred page contains details about uploader, file history, etc. Thanks Mathmagician. — SW8573 ^(Talk) 12:54, April 29, 2013 (UTC)

I believe I interpreted your post correctly. To the best of my knowledge, links do correctly point to the File: page. However, in the last update, it looks like I introduced a bug that prevented the section of code that actually corrects the links from running. Should be fixed now. Thanks for catching that. Mathmagician ƒ(♫) 02:42 UTC, Tuesday, 30 April 2013

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Wonderful! Thank you for fixing it. — SW8573 ^(Talk) 07:38, May 2, 2013 (UTC)

Right Rail Images

In the Photos section of the right rail, the script no longer seems to be working; the lightbox loads when an image is selected. I would assume this is a result of the right rail now being lazy loaded with the most recent technical update.

--Whistle9 (Talk) 02:19, October 13, 2013 (UTC)

Gallery Links Issue

It looks like Mathmagician is inactive so I have no idea if this will be fixed but I'll go ahead and add the problem. Any image with a link attached to it in a gallery is currently being ignored and I am taken straight to the file page instead. I and Staff have confirmed that this script is the source of the problem. A fix would be great. DEmersonJMFM 21:36, June 1, 2014 (UTC)

Picture links issue

This script seems to interfere with links, that are placed in pictures like these:

Instead of the image leading to the link, it then links to the file page.

This issue is a fairly recent thing, and has appeared only a few weeks ago.

---ﾌﾞﾙｰﾊﾞｰﾄﾞ🐤 (ʞlɐʇ) 11:57, July 25, 2014 (UTC)

I have pretty much no clue what I'm doing, but adding .not('a.link-external') to the end of the line

$a = $img.parent('a.image, a.lightbox');

line seemed to fix this issue for me. Somebody more experienced should probably check that though, and add it to the script. - OneTwoThreeFall (Talk) 10:44, July 30, 2014 (UTC)

Thanks a lot~ As long as it works, it's good ;D ---ﾌﾞﾙｰﾊﾞｰﾄﾞ🐤 (ʞlɐʇ) 12:39, July 30, 2014 (UTC)

You would need to add .not('a.link-internal') also because it disrupts those as well, not sure if there are more. I'll point the script's author to this discussion. ~Bobogoobo (talk) 04:45, August 20, 2014 (UTC)

I've added .not( 'a.link-external, a.link-internal' ) to the proposed line which has fixed the image external images and internal cqm 08:58, 20 Aug 2014 (UTC)

Ampersands in file names

The script appears to cause an badtitle error for files with an ampersand in their name such as the file on this page which should link here. DEmersonJMFM 16:22, August 27, 2014 (UTC)

The above doesn't appear to be an issue anymore but I believe I found a different case. I receive this error when I click on this image via Special:NewFiles. With the lightbox there is no linking error. DEmersonJMFM 02:34, October 5, 2014 (UTC)

I believe it to be a problem of wikia not encoding & properly. I have added a workaround for it--~UltimateSupreme 07:33, October 5, 2014 (UTC)