This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current talk page.
That looks overkill for something that few editors use, probably many aren't even aware of. Making it as prominent as, and so as important as, the article name is excessive. It doesn't display any useful information as the data IDs are on their own meaningless, and for editors unfamiliar with wikidata will be confusing. Better to put it in a menu, e.g. the 'actions' menu, and with a more descriptive title such as 'visit wikidata' or 'wikidata (Q144)'--
JohnBlackburnewordsdeeds10:18, 20 February 2015 (UTC)
The claim "doesn't display any useful information" is subjective; and easily refuted by the fact that I've asked for it because I regularly use such values. Specifically, I need to be able to right click and "copy link text", to capture the ID, so displaying the value as the (whole) link text, rather than text such as "visit wikidata", is imperative Andy Mabbett (Pigsonthewing);
Talk to Andy;
Andy's edits16:35, 21 February 2015 (UTC)
This tool is not under active development and basically in a 'keep alive' and 'bug fix only' mode. If you want a feature, you will have to find someone willing to program it. Amalthea has made a few functional changes over the last years, but also seems preoccupied with other things lately, same for me. So you will need to find a new developer for this piece of abandonware. —
TheDJ (
talk •
contribs)
23:44, 3 March 2015 (UTC)
Request: Quality/class assessment indicator
I love this script. One of my favorites, and I only found it after disabling the beta hovercards. Idea: The top feature I'd want is something like
User:Pyrospirit/metadata, or at the very least, the GA circle or FA star in the corner of the popup. It would really help me know how the page has been vetted. czar⨹22:46, 1 April 2015 (UTC)
Bug: Overflowing box
When hovering over an article history within a
watchlist, if there is one of the new long-form IP addresses in the history, the edit summary column overflows the right-hand boundary of the box and is superimposed on the underlying watchlist, making the summaries hard or impossible to read. (Monobook skin, Firefox latest version, in case this is relevant) Could this be fixed?
: Noyster (talk),18:24, 7 April 2015 (UTC)
Same problem. Vector skin, also Firefox but alpha (development) build. I think something in
User:George8211/vector.js might have broken it. No, commenting out all the JS options doesn't fix it. —
George8211 /
T18:31, 7 April 2015 (UTC) Edit 18:33, 7 April 2015 (UTC)
Confirmed. I, too, have observed this behaviour. I think it's always been thus and, given the inactive state of this tool's development, I put up with it. OTOH, I noticed that this behaviour sometimes changes when one hovers over a history without long usernames and then returns to the one which previously overflowed. --
Michael Bednarek (
talk)
05:05, 8 April 2015 (UTC)
Requests: Make popups work with images from Commons and make red links red (Round 2)
@
Rezonansowy: Popups is maintained by volunteers, and none of them has decided to implement your requests. And why should they? You didn't even say the word "please" in your request; and you used not-so-polite language ("They're still not fixed"). If you don't want to learn enough JavaScript to implement your requests yourself, another option would to attach a monetary bounty to each request. If the requests are implemented, you can pay the bounties using PayPal or using a major credit card. Are you willing to attach such bounties? If so, how much are you willing to pay? Cheers, —
Unforgettableid (
talk)
03:32, 22 April 2015 (UTC)
Popups wouldn't actually have to show the entire text of an article's attached maintenance template.
It could show just the name of the template (e.g. {{news release}}).
Alternatively: It could show just the template's issue text ("This article reads like a news release, or is otherwise written in an overly promotional tone"). It could leave out the fix text ("Please help by either rewriting this article from a neutral point of view or by moving this article to Wikinews"). Cheers, —
Unforgettableid (
talk)
03:32, 22 April 2015 (UTC)
AFAIK not directly. The obvious method is to click on the REDIRECT (
ΡΨ) which takes you to
Rho Psi and there click on (Redirected from ΡΨ) which will take you back to the REDIRECT. Alternatively, in the popups "actions" menu for
ΡΨ, click on "most recent edit". --
Michael Bednarek (
talk)
07:23, 20 May 2015 (UTC)
Unwatch oddity
Since the restoration of popups, I have noticed a new and odd behaviour when using actions - un|watch. Before the downage, clicking on the un produced a white box in the top right-hand corner of the screen to appear, with a message that the page, and its talk page, had been removed from my watchlist.
Now, as well as this box appearing, I am taken to a page which asks me if I want to unwatch, and asks me to click "OK". It also leaves me on the page I was unwatching, but with none of the content shewing, just a message telling me it has been removed from my watchlist. Previously I would not leave the page I was on, whether it be watchlist or anything else.
Yeah, it's going to the fallback url, instead of executing the bound function. I notice that the script still depends on a lot of global variables, which won't work anymore. —
TheDJ (
talk •
contribs)
16:18, 7 August 2015 (UTC)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please deploy the following version of the code:
source,
diff. This exposes several of the variables to the global context, which was no longer exposed due to switching over to RL. —
TheDJ (
talk •
contribs)
10:01, 8 August 2015 (UTC)
At the moment, popups doesn't seem to be opening most of the time on my browser (FFox). The popup box will sporadically work on articles, but definitely tends to fail on watchlists and contribs pages. Perhaps a general script server wonkiness of the day? Maybe another scripted tool is breaking things (although some tests with disabling various other scripts in vector/monobook.js didn't fix anything yet). Maybe a leftover ancient config which needs updating? Anyone else getting recent popup grief?
Dl2000 (
talk)
00:48, 7 August 2015 (UTC)
Pop-ups still fine for me on enwp, Chrome, OS X, but the gadget that put my category box at the top just broke so perhaps something is up. –
czar02:29, 7 August 2015 (UTC)
(
edit conflict) Would like to report on some findings: popups is broken (well, it loads erratically) on enwiki, and it doesn't work at all on simplewiki either. It works on Commons, Meta, and enwikt. It also seems to work just fine on Wikia. Using Chrome 44 on a Windows 7 computer. This issue also appeared for me on FF 39 (updating it as we speak) as well. --I am
k6kaTalk to me!See what I have done02:35, 7 August 2015 (UTC)
I don't know if this is a temporary godsend or not, but it's working for me on enwiki right now. It's still not working on Wikia, and it doesn't seem to be functioning on simplewiki either. Not sure if this is a cache/update issue I'm not aware of. --I am
k6kaTalk to me!See what I have done03:07, 7 August 2015 (UTC)
Did some hard reloads, popups is now working much better from here, especially on the watches and contribs. Thanks everyone for the input and resulting repairs.
Dl2000 (
talk)
03:31, 7 August 2015 (UTC)
The gadget is not working for me anymore on enwiki (but strangely works fine on Commons). Popups worked fine just before the recent change, but now I can't see popups on my computer (OSX Yosemite 10.10.3 with Google Chrome).
Epic Genius (
talk)
03:20, 7 August 2015 (UTC)
Since the ResourceLoader issue was just repaired, you could try doing a hard refresh (or cache-clearing reload) e.g. Ctrl-Shift-R in FFox; see comparable commands for other browsers. These fixes may not be properly propagated with a regular refresh (or if you have not yet reloaded a page in question).
Dl2000 (
talk)
03:38, 7 August 2015 (UTC)
I don't know if it's just me, but my pop-ups are down now. Tried different browsers, resetting cache, updating browser, uninstalling and reinstalling the gadget from preferences... –
czar09:17, 7 August 2015 (UTC)
Popups still broken for me - Chrome 44.0.2403.125 m or Firefox 39.0, Windows 7 Pro. In Chrome, I tried Ctrl-Shift-R, also F12 + right-click on reload button > Empty Cache and Hard Reload, still doesn't work. Any suggestions, please? --
RobertG ♬
talk09:22, 7 August 2015 (UTC)
Still broken for me. It's nearly working - in developer tools I can see, when I hover over a wikilink, that a <div class="navpopup" ... /> is created, with display:none included in the style attribute. --
RobertG ♬
talk12:56, 7 August 2015 (UTC)
popups go down for me about every six months. This time, though adding ('
http://en.wikipedia.org/?action=raw&ctype=text/css&title=User:Lupin/navpopdev.css'); to css file did not work, nor clearing the cache, nor rebooting. I am using Firefox 39.0.3 with (gulp) XP Windows. Was working 2 days ago. Forced to hard boot (not related to this problem).
I don't understand references to .js. Mine have something else entirely there than doesn't relate: filling in citations.
Student7 (
talk)
18:00, 8 August 2015 (UTC)
I just lost the Navigation popups entirely, for the first time ever. I thought my own java machine might have caused it so I went to facebook to see if popups work. No problem.
Poeticbenttalk16:58, 7 August 2015 (UTC)
Thank you. All is fine. I removed the Lupin popups from my monobook. The actual popups came back. But what "Gadget" did you have in mind
User:Nakon? In my Preferences' section Gadgets I deselected Navigation popups as a gadget.
Poeticbenttalk17:37, 7 August 2015 (UTC)
The Gadget "Navigation popups" is just the renamed version of Lupin's popups. That one should work properly going forward. Thanks,
Nakon17:40, 7 August 2015 (UTC)
I have the same problem on my laptop. When I removed it doesn't seem to work. I removed it from Javascript and somewhat it is not working. Could someone help me get them back. Have a look at my javascript and see what I should do --
EurovisionNim(talk to me)(see my edits)02:19, 8 August 2015 (UTC)
Same here, although I'm using my own (slightly modified) version of the tool (
zh:User:Moonian/popups.js); dunno which part(s) of the code the RL is not happy about (feel free to modify it if you have the privileges to edit the page). — Preceding
undated comment added 11:28, 8 August 2015 (UTC)
Just found the reason - it seems that the RL isn't happy about the getImageUrlStart(pg.wiki.hostname) call. Have to find a replacement of it, or the images from non-en wikip may not load... --
Moonian (
talk)
16:45, 10 August 2015 (UTC)
Problem is, that ths gadget is only on some wkis, but when I am using it on my global.js, I have no other option in many wikis...
JAn Dudík (
talk)
19:55, 9 August 2015 (UTC)
Pursuant to the above, I've lost the pop-ups too. I disabled and enabled the Gadget, but I'm still not seeing anything. I don't have a monobook.is, whatever that is. If someone could help me out, that'd be great.
Braniff747SP (
talk)
21:08, 9 August 2015 (UTC)
I have a similar problem. I don't have popups in my monobook.js. I do have my own version of
WP:AVT. Now popups doesn't work from within that tool anymore. It used to, and something has changed. It would be kind of helpful if someone explained what has changed and why. I'm aware that the underlying Wiki software is in constant development, and that features get deprecated and deleted, but the development updates I've seen are, um, couched in opaque language that is only meaningful to the developers.
Philip Trueman (
talk)
03:25, 10 August 2015 (UTC)
@
TheDJ: Indeed, but as I said, I have my own version of AVT (see
PILT), which I am prepared to make some effort to maintain. What's frustrating is not that I need to [do] so but that it's far from clear what I have to do to get things working again.
Philip Trueman (
talk)
08:36, 10 August 2015 (UTC)
Not having access to this tool significantly impairs my ability to check diffs and navigate. If anyone knows what my problem is, please help?
Dustin(talk)17:35, 12 August 2015 (UTC)
Could you provide the output of your browser's error console (only category Javascript errors)? In short: MediaWiki dropped support for some outdated libraries. If any script you're using is using on of them this results in an error, which makes the browser stop all js execution on that page. Find them and disable or update them. --nennt
michruhig
ip (
Diskussion)
09:24, 14 August 2015 (UTC)
15 August 2015
I have removed the Lupin popups from my monobook.js and vector.js. Navigation popups was already enabled in my Preferences; but popups no longer works for me. I have purged the cache. What should I do now? RolandR (
talk)07:58, 15 August 2015 (UTC)
@
Smalljim: I don't refer to Lupin.js in any of my subpages, but the gadget refuses to work. Why could I be having this problem? I don't meant to make you the go-to person, but since you might know...
Dustin(talk)22:58, 19 August 2015 (UTC)
@
Dustin V. S.: I'm not an expert by any means! The only thing I can suggest is to try removing all content from your common.js in case it's another script that's causing the problem. If popups then works, adding the other scripts back one at a time would show which is the culprit. (don't forget to clear the cache for each change) —
SMALLJIM23:07, 19 August 2015 (UTC)
@
TheDJ,
Amalthea, and
Mr. Stradivarius:
I have been working on a Beta Feature called
Hovercards. It has a setting to switch to Navigation Popups if its enabled (a few bugs there). So, I thought it might be nice if Navigation Popups and Hovercards had a similar style. I have made a few typographic and color changes — made the background white, moved to a gray color palette and reduced the font size of the meta data . Some of the changes like the drop shadow aren't in Hovercards yet but there are patches for it that are awaiting review.
Agree I've been increasing the excerpt's font-size for many months, and I like almost all the other changes proposed here. I hope we can do this, or something close.
I would suggest changing 2 things: Change the "popups" menu item into a cog-icon instead (to take up less space); and change the menu-links back to blue text (per standard link color). HTH.
Quiddity (
talk)
01:10, 31 October 2014 (UTC)
I've reverted, seeing as the initial reactions here weren't positive. If we find a consensus about whether/how to tweak the new styling, then it can be applied again. — Mr. Stradivarius♪ talk ♪05:42, 27 January 2015 (UTC)
For me it seemed suddenly way too large, both the font size and the borders (though it's possible that's just the font's natural borders), and the grey for menus was hard to distinguish from black. I could probably get used to the grey, as it's just the same three items usually, and the background colour though I prefer the slight colouration. But the much larger box made it immediately less usable.--
JohnBlackburnewordsdeeds05:56, 27 January 2015 (UTC)
I also saw the problem with the font size being too big. Interestingly, it didn't happen when I copied
User:Prtksxna/common.css to my vector.css page to test the styling. I'm guessing that something must be being overridden in user CSS pages but not on the gadget CSS page (or vice versa). (This is in Firefox on Windows 7.) — Mr. Stradivarius♪ talk ♪06:05, 27 January 2015 (UTC)
I hope the new styles can be restored once the font size issues can be resolved. While I'm sure the bright orange coloring appealed to Lupin's tastes, it was always a strange choice, and I also disliked the cramped format of the popups themselves (which seem to be a holdover from the bad old days of Monobook with its tiny UI elements, from when people still ran desktop computers on 15 inch CRT monitors). A design refresh of popups is long overdue. — This, that and the other (talk)08:36, 27 January 2015 (UTC)
I like the idea, but there are some flaws. There is nothing wrong with a bit of color indicating this is still NavPopups, maybe just the top part. The header could use a little rearranging anyway, moving the menus to the next line. Finally, move the window down so that, just like Hovercards, it does not obscure the link being hovered over. -- [[
User:Edokter]] {{
talk}}09:54, 27 January 2015 (UTC)
I have removed the font size changes for now, I need to test it with more screen types (lower DPI) before we can make that change. I also agree that the gray menu links don't seem like call to actions. People using the gadget already might know what to do, but new users would never hover over it if its that color. I've updated
User:Prtksxna/common.css with these changes.
Prtksxna (
talk)
17:36, 27 January 2015 (UTC)
Cool. Thanks for the quick responses, all. :-) Maybe we can try re-applying the styling changes (minus the font size changes) in the next few days? It'd be great if some of the users who had issues could beta test first before updating the gadget for everyone. --
MZMcBride (
talk)
17:50, 27 January 2015 (UTC)
Had it in my own style sheet for a couple of hours and it looks much better: the size seems the same as before, small, which was my main complaint. The grey menus still seems a bit odd; I noticed odd words in them which were blue and on experimenting it seems to be visited links are blue, non-visited links are grey which is very counterintuitive. Also looking for the lines which e.g. are above and below the 'un watch' line they are very faint, visible only if I look for them and move my head down, so invisible when looking at them normally, on what I think is a well-adjusted LCD display.--
JohnBlackburnewordsdeeds02:40, 28 January 2015 (UTC)
Thanks for testing this! I've made the color for the normal and visited links the same now and made the lines in the menu darker. Could you please test again?--
Prtksxna (
talk)
02:43, 9 February 2015 (UTC)
OK. It will take some time. I had the last version in place for a couple of weeks so also want to give this some time, and look at the original/current version again to remind me of it.--
JohnBlackburnewordsdeeds02:53, 9 February 2015 (UTC)
How about doing this in a safer method way ? Update and deployed the gadget and gadget definition on test.wikipedia.org. Build table of skins and browsers and let people sign off on wether or not it matches the screenshot as included above. —
TheDJ (
talk •
contribs)
18:31, 20 August 2015 (UTC)
I personally don't use navigation popups, but another attempt at updating the styling seems like a good idea to me. --
MZMcBride (
talk)
17:58, 20 August 2015 (UTC)
From a brief look they appear to respect my choice of fonts, so I’m happy. (Vector here.) I’ve become used to the pink background, but I don‘t think I‘d particularly miss it.—
Odysseus147921:44, 22 August 2015 (UTC)
Has anyone tested IE versions ? Did all people who complained about the original change had a change to check out the test.wp version ? —
TheDJ (
talk •
contribs)
07:53, 26 August 2015 (UTC)
The background of the popup is now the same color as the background of the page, making it harder to focus visually on the widget.
DMacks (
talk)
21:16, 8 September 2015 (UTC)
I think that's why the drop-shadow was added. Maybe
Prtksxna has more thoughts on this. Personally, I don't have any trouble focusing on it, and I like it better than the yellow color, but that's just me :)
Kaldari (
talk)
21:34, 8 September 2015 (UTC)
The popup with the on-hover text for images is still yellow (see [[File:Question.png|right|This text.]] at right). That's probably a sitewide stylesheet, but I assume (ha!?) they have some design plan or basis for it. Might be good to have "the popup boxes on en.wp" all be consistent.
DMacks (
talk)
21:57, 8 September 2015 (UTC)
I don't understand why we're introducing a new style to an existing gadget to match a new feature. Hovercards and Navigation Popups are two different gadgets. One predominantly targets readers, the other tends to be more useful to editors. An opt in is available if users want to use the beta feature. Changing the background to white on such a small focal point just makes it more difficult to read. Please change it back.
Fuebaey (
talk)
22:57, 8 September 2015 (UTC)
I believe the reason was so that editors can switch from Hovercards to Navigation pop-ups without the interface changing dramatically.
Kaldari (
talk)
23:51, 8 September 2015 (UTC)
As an editor who doesn't use Hovercards, I don't think it's fair to expect existing Nav popup users to adapt to a new interface just to suit another gadget. Why not make this an optional skin if a user chooses to use Hovercards?
Fuebaey (
talk)
02:18, 9 September 2015 (UTC)
You area allowed to destroy wikimedia's best editor script in lupin's popups as WMF has a habit of enforcing stupid changes without the consent of editors but can you damn chance the colour back to yellow?..I have 40/40 vision and that colour change is hurting my eyes...atleast restore it to a lighter shade of yellow (not beige)--Stemoc23:29, 8 September 2015 (UTC)
I'm fine with setting it to whatever color people want. The reason it was changed to white was to match Hovercards (so that people can change to Navigation pop-ups without the UI changing dramatically). There were many editors involved in the discussion and it lasted 11 months, so I don't think it's fair to say it was done without the consent of editors. If the consensus is to change it back to yellow (or whatever), I'm fine with that. Perhaps someone would like to start a formal discussion about it below.
Kaldari (
talk)
23:51, 8 September 2015 (UTC)
Personally, I much prefer the new style. For those that like the old style better, perhaps we could have an easy way to revert back on a per-user basis? I had a go at importing the old stylesheet via JavaScript, but that didn't work. I assume that copying and pasting
Special:PermaLink/651663158 into
Special:MyPage/common.css would do the trick, but is there an easier way? — Mr. Stradivarius♪ talk ♪00:10, 9 September 2015 (UTC)
Some of us, who are wikiMedians are using this globally, its one of the few scripts which can be used across Wikimedia without effing up the individual settings of each wikis..how would you suggest changing that? again, its basically restoring the colour..No one likes Hovercards but its been forced upon us and we can't do anything about it so FGS stop messing up with things you should have no control over!....Can a sane admin just change the colour back please? the world does NOT revolve around the English wikipedia only..--Stemoc05:19, 9 September 2015 (UTC)
To change it globally, add .navpopup {background-color: #FFFAEF !important; border: 1px solid #ffbe20 !important;} (or the colour of your choice) to your
m:special:MyPage/global.css. I use font-size: 0.875em !important; (to bump the font-size up to the same as the rest of the site). HTH.
Quiddity (
talk)
17:24, 9 September 2015 (UTC)
There was proper en.wp consent here. It was not an arbitrary choice. Some folks might not like it, but that's what you get with 100000 users, there is always SOMEONE not happy. That's why people can use their own common.js and common.css to make changes to their hearts content. —
TheDJ (
talk •
contribs)
08:52, 9 September 2015 (UTC)
Me, too. In particular, I am happy to see the weird yellow color go away. Whether it should be white or extremely light gray is a decision for someone else, but please: no more yellow ever again.
WhatamIdoing (
talk)
18:38, 9 September 2015 (UTC)
In the last couple of days, popups do not seem to work on history pages for me. No diff view, no user contributions, nothing. I am using Monobook on Safari, and none of the
options I use seem to have anything to do with histories. Is there anything I can do? —Kusma (
t·
c)
09:04, 14 September 2015 (UTC)
@
Kusma: Popups on history pages are working fine for me in both Firefox and Chrome, and on both Vector and Monobook. Do you still see the problem when you are on a different browser or a different computer? Also, have you enabled any gadgets recently? And finally, if you're feeling technical, the most useful thing that you can do is to
open your browser console on a history page, refresh the page, and let us know if you see any error messages, either when you load the page or when you hover the mouse above a link. — Mr. Stradivarius♪ talk ♪09:41, 14 September 2015 (UTC)
Thank you @
Mr. Stradivarius: for the pointers. With Chrome on a Mac, I had no issues so far. I have now discovered that it sometimes (rarely) works in Safari, but most of the time the console tells me (on page load; popups no longer work after that)
TypeError: undefined is not a function (evaluating 'performance.mark('mwLoadEnd')')
If it's only in history pages it's likely due to resvision counter, revision jumper or similar gadgets. Those may be hard to tell from error console, so check if you're using one of them and try disabling them if there's nothing interesting on the error console mentioned by Stradivarius. --nennt
michruhig
ip (
Diskussion)
09:56, 14 September 2015 (UTC)
It doesn't seem to be only history pages, but it does not seem to be completely reproducible. I turned off all gadgets expect popups and still get errors that disable popups, sometimes also on Contributions pages. —Kusma (
t·
c)
10:05, 14 September 2015 (UTC)
I have Safari and tried reproducing it, but popups worked everytime. I saw the above error twice, but popups kept working. Oddly the two times I saw the error were immediately after switching to Monobook and immediately after switching back to Vector.--
JohnBlackburnewordsdeeds10:33, 14 September 2015 (UTC)
The problem seems to be more general, and probably not connected to popups -- other javascript also sometimes (in a fairly erratic way) fails to load, so I will need to do some more research. Thank you, everybody, for your suggestions so far! —Kusma (
t·
c)
11:51, 14 September 2015 (UTC)
"This tool is no longer being developed. Guarantee to the door. If you find a problem, you should fix it...." Given that popups is one of the most useful and widely used tools on Wikipedia, perhaps an effort should be made to find volunteers who will officially (in the Wikipedia community sense) support/enhance the tool? --
NeilNtalk to me18:18, 15 September 2015 (UTC)
Sudden shutdown?
Seems the popups have suddenly stopped working in the past several minutes. Anyone else finding their popups suddenly go nonfunctional?
Dl2000 (
talk)
23:34, 4 September 2015 (UTC)
Scratch that - popups seem to be working again after resetting a few things. Probably was a client-side JavaScript hiccup.
Dl2000 (
talk)
00:19, 5 September 2015 (UTC)
No matter what I do, popups will not work. Editing now takes me longer than it used to. I haven't been able to use the tool for a month now.
Dustin(talk)21:54, 10 September 2015 (UTC)
@
Nenntmichruhigip: Information: You are importing User:Lupin/popups.js into your common.js or <skin>.js! This script is unmaintained. Please remove this inclusion and enable the Navigation popups Gadget in the preferences of your account instead.
Dustin(talk)21:48, 11 September 2015 (UTC)
This message which
TheDJ put there is causing a lot of confusion. You need to delete Lupin's version of the scirpt from
your global.js file on Meta and read the instructions on how to install the new version. --
V111P (
talk)
06:02, 12 September 2015 (UTC)
I am being told to remove this 'plug in' but when I look at my common.js page I don't see anything there. Any clues, the tec=chnical side of Wiki' isn't my forte at all. Thanks.
Stephenjh (
talk)
08:50, 21 October 2015 (UTC)
You're using the monobook skin and are calling the ancestor(?) of this script from
your monobook.js. Another option is checking
here whether "Navigation popups" (currently sixth checkbox) is checked. Also it might be useful to know where you've been asked to do this, in case you'd prefer to keep using it's functionality. --nennt
michruhig
ip (
Diskussion)
11:50, 21 October 2015 (UTC)
Popups gets in the way on an IPad. Touching a diff brings up the popup instead of the diff, and I can't seem to get rid of it. Is there an easy way to disable popups on a per-browser basis? ISTR doing this in the past. TIA
Mr Stephen (
talk)
17:36, 7 February 2016 (UTC)
Images in NAVPOPS
There is a discussion at
Wikipedia talk:Non-free content/Archive 65#Hovercards that is ostensibly about Hovercards (a stripped-down version of NAVPOPS), but which could force the removal of many images from the
WP:NAVPOPS gadget (or all images, if the gadget maintainers can't find a way to suppress solely non-free images). Whatever standard is applied to Hovercards will be applied to NAVPOPS.
WhatamIdoing (
talk)
23:06, 16 March 2016 (UTC)
Hi everyone! The function popupLastModified isn't working well on the Uzbek Wikipedia. We're getting popus that say something like "Last edited a few 4 days ago". Moreover, the first half of the sentence is rendered in Cyrillic, the second - in Latin.
Here is a screenshot. I can't seem to find the corresponding entries on Translatewiki. Specifically, I can't seem to figure out where the Cyrillic phrases бир неча, кун олдин, ой олдин, йил один are coming from. Can anyone help us on this? Is it possible that the first half of the clause is rendered from Translatewiki and the second from, say, Meta?
Nataevtalk06:44, 19 April 2016 (UTC)
NavPopup’s messages are stored in JavaScript files, but your screenshot seems to be
Hovercards, which can be translated generally
here. However, the time gap itself (e.g. “4 days ago”) is provided MediaWiki core—this is the reason for the two scripts. The Latin version is easy to find, it can be translated at the above location; the Cyrillic part might come from
CLDR (is your interface version Cyrillic?). --
Tacsipacsi (
talk)
21:52, 19 April 2016 (UTC)
Thank you for your response! Our interface is in Latin. (We do have a Latin-to-Cyrillic converter for those who prefer to read in Cyrillic.) How can we change the Cyrillic entries on Phabricator to Latin? If I translate them all and have my work checked by other Uzbek wikimedians, can we request somebody to make the changes on Phabricator? One more thing. The annoying phrase бир неча is nowhere to be found. Somebody translated the English word "some" as "a few". It should've been translated as тахминан i.e. "approximately". Currently we're getting messages like "The page was last edited a few 4 days ago". If this mistake is fixed, we'll get something like "The page was last edited approximately 4 days ago" which is pretty decent. Or the phrase бир неча should be completely removed. "The page was last edited 4 days ago" sounds good.
Nataevtalk03:27, 20 April 2016 (UTC)
Popups, anchors and hidden anchors
Hello!
I came across the following set of links (on the documentation page for {{Harvard citation}}) and they work funny (try hovering over the links):
Wikipedia:Citing sources#Shortened footnotes produces a link to a hidden anchor produced by code <span id="Shortened footnotes"> at the beginning of the
Short citations section. In this case, the anchor is ignored by navigation popups, which displays the beginning of the page: "A citation, also called a reference, uniquely identifies a source of information..."
the same (unexpected) behaviour happens for anchors created by the {{shortcut}} template, such as links to
WP:SFN and
WP:CITESHORT
Does anyone know if Navigation popups can (should) manage hidden anchors to produce the same result as actual section titles?
Place Clichy (
talk)
12:56, 3 May 2016 (UTC)
It does sound like that would be the expected behavior; I'll read over some of the code involved to see if making that happen is possible.
APerson (
talk!)
16:30, 3 May 2016 (UTC)
Popups works with Wikitext and tries to find a wikitext section that matches the anchor that you hover. A hidden anchor is not a section, and can thus not be found. Same for the shortcuts links. —
TheDJ (
talk •
contribs)
18:40, 3 May 2016 (UTC)
Show last edit
For users, I think it would be helpful if we showed the time since the user made their last edit, in the style of PleaseStand's userinfo script. This would help with, among other things, finding users that are still active in a list of many editors. Any objections?
APerson (
talk!)
16:12, 22 May 2016 (UTC)
Great idea. I often try to solve it using the contribs list, but it's much slower—if it appears at all, otherwise I have to load the full contribs page. —
Tacsipacsi (
talk)
19:01, 22 May 2016 (UTC)
Oddly, after this was added, normal user contrib, account creation info etc is now failing to show on some random accounts on commons for me..--Stemoc12:49, 24 May 2016 (UTC)
For some reason, whenever I hover over a link to a user's userspace, the popup shows them as both globally locked and hidden, despite the fact that such users - some of which are administrators in good standing - can't possibly be either. —
Jeremyv^_^vBori!22:26, 15 June 2016 (UTC)
My bad. A change I authored, which essentially was fixing style issues in the code, apparently changed the behavior of the code too. The fix was reverted later on. See
this thread for the initial edit request and subsequent discussion.
Enterprisey (
talk!) (formerly
APerson)02:34, 19 June 2016 (UTC)
I think it would be a bit more useful to have bugs and feature requests also hosted on Phabricator under the (proposed) navigation popups project for a number of reasons:
Talk page archives aren't a good way of storing bugs that are probably still valid and need work.
Wikipedia threads don't support things like filtering, moving between boards, and assignment, not without doing it in natural language instead of software fields.
Phabricator has excellent Mediawiki integration, so people won't have to make a whole new account.
{{Tracked}} provides a link from Wikipedia discussions back to Phab, which is very helpful.
For the most part, phabricator is for software and configurations used by all the mediawiki projects. That does not preclude using it for other types of things if it makes sense. My biggest concern about THIS is that the main page for NAVPOP basically tells everyone: this has not been maintained in 7 years, don't expect anything to be fixed or supported. Has "development" been taken over by someone else, or has this been forked? —
xaosfluxTalk02:24, 8 June 2016 (UTC)
xaosflux, well, looking at the last 7 sections on
Mediawiki talk:Gadget-popups.js, five are edit requests; out of those five, four were from me. Each one was to implement a feature request of some description. I guess you could call this "development".
Would it be true to say that you're concerned about Popups not being maintained in the context of this discussion because you're worried that it might give the false impression that Popups was being maintained, or were you thinking about something else?
Enterprisey (
talk!) (formerly
APerson)02:59, 8 June 2016 (UTC)
I supposed I'm ready to remove the big banner "The developer of popups (Lupin) has not been active on Wikipedia since 2009." - assuming this is being "community maintained". That banner suggests that there is only 1 developer, and they are gone. —
xaosfluxTalk03:04, 8 June 2016 (UTC)
Back to the phab question - there is no code to "merge" (e.g. this isn't using gerrit right?) - and as far as multi-project: has this been ported to other wiki's (are they maintaining their own forks?). —
xaosfluxTalk03:06, 8 June 2016 (UTC)
At least a couple don’t show the style update of a few months ago—Meta and Commons IME—but if the recently added pronoun-gender indicator is anything to go by, all the projects where I’ve used it are functionally in synch.—
Odysseus147904:25, 8 June 2016 (UTC)
Re people won't have to make a whole new account: Not completly, but it's still less accessible as one has to provide a reachable mail adress, which isn't neccessary for a normal WMF-Wiki account. So if this will move to Phab, please make sure that it's still fine to post bug reports to talk pages and that they'll still be taken seriously. --nennt
michruhig
ip (
Diskussion)
09:58, 27 June 2016 (UTC)
nenntmichruhigip, oh, of course. I don't intend to discourage anyone from posting to talk pages in any way - I just want Phab to be used to track the implementation of features and the fixing of bugs.
Enterprisey (
talk!) (formerly
APerson)03:32, 10 July 2016 (UTC)
Then it's fine for me :-) It's just that I had issues with a similar transition (not Wikimedia-related) in the past, where the maintainer's oppinion on where users should post bugs suddenly changed a bit later, which excluded quite some users, and some bugs were even not resolved because they've been posted to the wrong place first… Maybe I'm a bit over-careful after this. --nennt
michruhig
ip (
Diskussion)
10:03, 10 July 2016 (UTC)
Ah, no problem at all. Yeah, I've recently been going through the archives of this page and filing new tasks based on old, unresolved discussions, but I still expect people to primarily discuss the gadget right here.
Enterprisey (
talk!) (formerly
APerson)19:05, 10 July 2016 (UTC)
Account not registered
In earlier versions of the tool, when a non-existent account's (e.g.
Ex4mp1e (
talk·contribs)) pages were moused over, Popups would note that the account was not registered. That feature no longer works, but it was very useful to some of us in the community when investigating sockpuppetry and other forms of abuse. If this could be sorted out, I'm sure that I'm not the only one who would be thankful. —
DoRD (
talk)
13:41, 14 July 2016 (UTC)
On a similar theme, I seem to also recall earlier versions handling accounts with no edits or only deleted edits differently. I recall it displaying some account information and maybe the deleted edit count. For example, I do a lot of spambot account blocking. Here is one account with only deleted edits
Hewmhraex08n (
talk·contribs) and one with no edits
Tusar2184 (
talk·contribs). Both of these accounts are now blocked and it would be helpful to see that they are blocked. --
Gogo Dodo (
talk)
06:03, 15 July 2016 (UTC)
Hi. Is anyone aware of a way to completely disable navpopups over images? I tried the js options, but none of them have the desired effect for me.
Aasasd (
talk)
04:35, 11 September 2016 (UTC)
Thanks function
I know there's no maintainer, but if someone's interested, I think it'd be nice to have easy access to the "thanks" function in the popup over a diff. czar19:24, 11 December 2015 (UTC)
I can't get it to work, though I have installed window.popupFixRedirs = true; in
User:Wbm1058/vector.js – window.popupFixDabs = true; works great for me.
There is code in
MediaWiki:Gadget-popups.js relating to this that seems to do something. What does it do?
varwarnRedir=redirLink(target,navpop.article);setPopupHTML(warnRedir,'popupWarnRedir',navpop.idNumber);functionredirLink(redirMatch,article){// NB redirMatch is in wikiTextvarret='';if(getValueOf('popupAppendRedirNavLinks')&&getValueOf('popupNavLinks')){ret+='<hr />';if(getValueOf('popupFixRedirs')&&typeofautoEdit!='undefined'&&autoEdit){log('redirLink: newTarget='+redirMatch);ret+=addPopupShortcut(changeLinkTargetLink({newTarget:redirMatch,text:popupString('Redirects'),hint:popupString('Fix this redirect'),summary:simplePrintf(getValueOf('popupFixRedirsSummary'),[article.toString(),redirMatch]),oldTarget:article.toString(),clickButton:getValueOf('popupRedirAutoClick'),minor:true,watch:getValueOf('popupWatchRedirredPages')}),'R');ret+=popupString(' to ');}elseret+=popupString('Redirects')+popupString(' to ');returnret;}elsereturn'<br> '+popupString('Redirects')+popupString(' to ')+titledWikiLink({article:newTitle().fromWikiText(redirMatch),action:'view',/* FIXME: newWin */text:safeDecodeURI(redirMatch),title:popupString('Bypass redirect')});}
Wbm1058, what do you expect it to do? It works fine for me - the "Redirects" in "Redirects to" that appears whenever I hover over a redirect turns into a green link that opens an edit window and invokes autoedit.
Enterprisey (
talk!)
02:35, 29 November 2016 (UTC)
Enterprisey, dang! thanks, now I see how it works and what it does. I just uploaded a screenshot. I installed
User:Anomie/linkclassifier and set that up to use the linked-misspellings class to highlight the linked misspellings in pink. Hover over one of those to start. Right, don't get distracted by or hover over the big bold links to the redirect and the redirect target, or the blue "actions" and "popups" pulldown menus. Hover over the little (green) Redirects to and the hint box Fix this redirect appears. When I click on that, one of two things happens, it's seemingly random which:
I get the preloaded edit summary Redirect bypass from [[Dilma Rousseff]] to [[Dilma Rousseff]] using [[:en:Wikipedia:Tools/Navigation_popups|popups]]
and (No difference)... it doesn't change anything
I get lucky and the preload summary is Redirect bypass from [[Dilma Roussef]] to [[Dilma Rousseff]] using [[:en:Wikipedia:Tools/Navigation_popups|popups]]
and each of the two pink-highlighted linked-misspellings is changed from [[Dilma Roussef]] to the piped [[Dilma Rousseff|Dilma Roussef]].
This is kind of stupid as the objective is to fix both the linked and reader-visible misspellings. It should just change it to [[Dilma Rousseff]].
To editor
Wbm1058: Might want to come up with a similar new script for that, since this one is luscious for bypassing redirects in Navbars so the links will turn to boldface type in their articles. Paine Ellsworthu/
c23:13, 16 December 2016 (UTC)
Note that on the Preferences →
Gadgets page we can make links that may need to be disambiguated appear in the color "orange". In the popup box for FixRedirs the "Redirect" link appears in the color "green". This is a great tool to fix redirects in navbars and sidebars; however, it can be tedious to have to hover over every single link in some large navbars. So I wonder if we can adapt the FixRedirs tool to change the color of redirect links on pages in the same manner that we can see links that need disambiguation in orange? Green would be a good color to use for this. Is this doable? Paine Ellsworthu/
c08:29, 18 December 2016 (UTC)
Is there a reason as to why the navigation popups for history (like when hovering above "hist" on a Watchlist entry) doesn't include "(cur)" links? Would it make Watchlist page loading noticeably more sluggish, or is there a different reason?
Stevie is the man!Talk •
Work18:01, 24 October 2016 (UTC)
Several months ago, the "preview diff" feature of Navigation Popups stopped working for me. If I hover over a diff link, I see a popup with the page title, but no diff text.
I normally use Firefox with the Ublock Origin add-on. I tried disabling Ublock Origin for en.wikipedia.org, but this made no difference — I get popups, but only with the page title and no diff text.
If I look at Wikipedia pages in Google Chrome, everything works fine — if I hover over a diff link, the popup shows the diff text as expected.
If I hover over a regular article link, the popup includes everything I would expect — article title, initial text snippet, first image, etc.
The "preview diff" feature used to work, and I believe it stopped working for me sometime during the past year (2016), but I can't recall exactly when.
Specifically, this problem happens with Firefox 51.0b10 (64-bit) running on Ubuntu 16.04.1. If I use this same version of Firefox on Windows 7, the preview diff popups work OK. —
Richwales(no relation to Jimbo)22:07, 27 December 2016 (UTC)
I just started experiencing this issue today. The previews appear to be a diff off; hovering over a previous edit shows the diff of the one it follows, and the most recent one shows up blank. Interestingly, this only happens from my watchlist. This problem doesn't occur from the 'View History' tab on an article. Nothing on my side has changed, except the year. Clicking on the link also leads me to a blank diff:
[1]. Again, from the 'View History' tab, this doesn't occur:
[2] —
ξxplicit05:02, 2 January 2017 (UTC)
Width problem with history view
I am seeing an odd problem with histories, both when I hover over a 'hist' link in my watchlist, and when I navigate to a history from any popup instance. The leftmost column seems far too narrow, so the '(cur | last}' is split over three lines, making it hard to use and making every line wider by the same amount. I only just noticed this, so it probably started happening today. I am using the latest version of Safari on macOS, which has not been updated that recently. Clearing my cache did not help. Looking at the history
this diff by
Mr. Stradivarius and
Enterprisey may be the reason, though my JS is too rusty to diagnose it myself.--
JohnBlackburnewordsdeeds19:00, 1 January 2017 (UTC)
I'm of the opinion that it's more intuitive to copy the order used by the MediaWiki software (cur | prev). Speaking of which it should probably use 'prev' instead of 'last'. --
zzuuzz(talk)20:22, 1 January 2017 (UTC)
I guess I'll have to get used to hovering over over last instead of diff; at the current time, I keep hovering over cur which obviously isn't what I want to see most of the time. Thanks to zzuuzz for fixing the spacing issue regardless.
Dustin(talk)20:43, 1 January 2017 (UTC)
@
Enterprisey: Good point - we don't want to break that message for anyone who's already localised it. I've changed the message key back to "last", and changed the default "last" message in pg.string instead. — Mr. Stradivarius♪ talk ♪14:35, 2 January 2017 (UTC)
New cur links faulty on user contribs lists
When using popups to look at user contributions, the new 'cur' link isn't working correctly. On the top line (most recent edit) it shows no change, as expected (as long as no-one else has edited the page since). But all the subsequent 'cur' links in the list show the diff to the top line's edit, even if the edit was to a different article. Result: crazy diffs like
this. Inspection of the full url confirms the problem: &diff=nnnnnnnnn stays the same, while the &oldid=mmmmmmmmm changes. This is correct behaviour for page histories, but not for user contributions: it appears to be caching the top line's revision id when it shouldn't be. I've checked this on several different browsers and logged in as both this account and my
other one - with the same effect. —
SMALLJIM23:27, 5 January 2017 (UTC)
@
Smalljim: I am unable to repeat this issue. I browsed through both my contributions and yours, looking at curs, and they all seemed correct. I assume you are talking about the cur links that appear when you hover over hist?
Stevie is the man!Talk •
Work17:29, 6 January 2017 (UTC)
I see this too. Hover over any 'contribs' link, in a page history such as
this one, and the 'cur' links are all broken. The first shows nothing as it does a diff between two identical revisions. Below that the diffs are with that revision and the top revision and so meaningless. 'cur' in page history compares that revision with the current one and so summarises all intervening edits. That makes no sense for a user’s contribution record as the edits are generally to different pages. It would be better to replace it with a 'hist', i.e. history of that page – as seen in any user’s contributions if you click through to them, such as
Special:Contributions/JohnBlackburne.--
JohnBlackburnewordsdeeds18:01, 6 January 2017 (UTC)
Using &diff=0 should fix the link for sure (i.e. when you click on it, you get the right page), but I hope it fixes the popup diffs too. --
Tacsipacsi (
talk)
18:44, 6 January 2017 (UTC)
I see it now, thanks to your explanation of the scenario. I think the problem is a little deeper, as in user contribution lists, the choices are supposed to be "(diff | hist) ", not "(cur | prev)".
Stevie is the man!Talk •
Work19:10, 6 January 2017 (UTC)
Facepalmit appears to be caching the top line's revision id when it shouldn't be is exactly how I coded it. I don't think the cur links would be that useful on user contrib pages - should they just be removed?
Enterprisey (
talk!)
20:46, 6 January 2017 (UTC)
Yes, that's nailed it: the real problem is that the user contributions lists in popups (as seen, for instance, when hovering over
Special:Contributions/JohnBlackburne) should not show "cur | prev", but "diff | hist" – the same as the full page does. —
SMALLJIM21:08, 6 January 2017 (UTC)
I'm currently neck-deep in the Popups source code, and there's this one piece of code that's used, as you might expect, by both the display-user-contributions code and the display-page-history code. It's possible to change the behavior of this one piece based on whether it's showing user contributions or a page history, so I'm writing some code for that now.
Enterprisey (
talk!)
21:14, 6 January 2017 (UTC)
Clarification: I forgot to mention what that one piece does. It takes the data about edits from the API and makes the actual links and text and whatever that gets shown to the user, and it's what I changed to make the "cur" links visible.
Enterprisey (
talk!)
21:15, 6 January 2017 (UTC)
Smalljim, alright, the finished product is in
the sandbox, so if you (or anyone else reading this) wants to try it out during testing, you can install it just like a user script.
Wow, my request was already logged – that's impressive! I must remember to look at phab more often. Regarding testing the sandbox version, yes happy to try it. I've disabled the gadget and I assume that adding
mw.loader.load( 'SOMETHING&action=raw&ctype=text/javascript' ); to
my vector.js will do it: if you could just tell me the SOMETHING that I need to add. —
SMALLJIM22:31, 6 January 2017 (UTC)
I was trying to figure out how to set it up too, like other scripts in my common.js, but the results are very messy. I had to revert. Any instructions for testing are welcome.
Stevie is the man!Talk •
Work22:39, 6 January 2017 (UTC)
Thanks for testing! Wow, I didn't even know about importStylesheet(). I guess that's one good thing to come out of this, besides the
writeup I did as I was writing the patch to keep myself from going crazy.
Enterprisey (
talk!)
23:04, 6 January 2017 (UTC)
Working here too, thanks! JohnBlackburne, I thought that way of loading scripts was deprecated (I wrote myself a tetchy edit summary about it back in April.
[3]) But it does still work. —
SMALLJIM23:25, 6 January 2017 (UTC)
Enhancement: Show latest delete log entry for red internal links
This is just an enhancement request. It would be useful for when I hover over red links to see the latest delete log entry (if it exists) under it instead of having to go to the page to see it. Thanks for your consideration -- not a huge priority.
Stevie is the man!Talk •
Work16:02, 5 January 2017 (UTC)
A use case for this would be when reviewing an article, I may want to hover over a particular red link, and if was deleted (rather than simply not created yet), that would tend to make me consider removing the link altogether, thus improving the article in that minor way.
Stevie is the man!Talk •
Work16:34, 13 January 2017 (UTC)
Related to this, it would also be nice to see how many other articles link to that red link when I hover over it. This would also help me decide if the red link has merit. Of course, there are other aspects to that decision, but this bit of info helps.
Stevie is the man!Talk •
Work16:38, 13 January 2017 (UTC)
Footnotes and citations
By default, at least for me, Wikipedia already displays the contents of footnotes and citations when I mouse over them. However, the pop-ups extension interprets these as windows it must open as well, so the result is two of the same thing on the screen. Is there any way to make this stop? Zeke, the Mad Horrorist(Speak quickly)(Follow my trail)07:14, 16 January 2017 (UTC)
The easier way is to disable
Reference Tooltips in your
preferences. The harder is to detect somehow in NavPopups if Reference Tooltips is active, and disable reference tooltips in that case. I’m not familiar with the code enough to know how difficult it is or if it’s possible at all. --
Tacsipacsi (
talk)
15:42, 16 January 2017 (UTC)
Can there be a feature where popups can recognize articles that are GA, FA, and FL based on the level templates that are placed on the articles? --
1989 (
talk)
16:21, 19 January 2017 (UTC)
Unfortunately, this isn't one of those bugs that's gonna take only an hour to fix, since I have to change some stuff that's connected to everything. If I don't get some fix for this out in a few days, feel free to ping me here.
Enterprisey (
talk!)
21:21, 1 February 2017 (UTC)
In the preview for the link to the section "Sprache"
on this talk page, I’m getting Sprache= – wann du in welcher Vorlageneinbindung steckst, ist nach der Vereinheitlichung kaum noch auseinanderzuhalten. Nur werk= und url= unterscheiden dann noch von Sammelwerk= und Online as the section heading’s preview and no content preview. This appears to be an excerpt from
another section, which is earlier than the section "Sprache" and contains = Sprache= in it’s text. Afaik = has to be the first character of a line to start a heading, which seems to not be checked in NavPopup’s parsing. (I’m using
dewiki’s gadget, which imports the one from enwiki) --nennt
michruhig
ip (
Diskussion)
09:09, 13 February 2017 (UTC)
Reverts/edits no longer autosaving
When I use popups to revert articles, the edits are no longer autosaving. The old version of the article is opened and the edit summary is populated but the edit isn't automatically saved; I have to manually click on the "Save changes" button. This has been happening for a few days now across multiple computers and different browsers. I have unchecked the popups tool option in my preferences, saved my preferences, and rechecked the option in an attempt to "reset" any potential changes I might have made or force an update if one is available.
Forgive me if you've already tried this, but did you
bypass your browser's cache after TheDJ's edit to your monobook.js? —
DoRD (
talk)
23:42, 16 March 2017 (UTC)
Here's something odd: This works just fine if I click on the "revert" link for it to act in the same browser tab. But it fails when I right-click on the link and open it in a new tab. I typically use Firefox or Firefox-derivative browsers with the Tab Mix Plus addon so I'll begin testing in different browsers and with that addon disabled.
ElKevbo (
talk)
17:06, 19 March 2017 (UTC)
For what it's worth, this change happened for me also, several months probably up to about a year ago. Chrome and Firefox with no extensions. Perhaps your cache has only just been refreshed. --
zzuuzz(talk)17:20, 19 March 2017 (UTC)
Sometimes when a red link is shown, a page already exists with a differently spelled title. To discover this, an editor could search the wiki (in the same namespace) for the link text. Could someone add a search link to the menu for red links? --
Bdijkstra (
talk)
09:27, 17 May 2017 (UTC)
Popups only working on some pages
For some reason popups are not working for me on most pages but are on some. Right now they work on Special:Mycontributions and Special:Watchlist, but nowhere else including articles and WP pages. Anyone else have this problem or know how to fix it?
Reywas92Talk18:12, 17 May 2017 (UTC)
Most probably it’s caused by one of your user scripts (
vector.js or
monobook.js, depending on your skin). The easiest fix is to wrap the whole script in a call beginning with mw.loader.using('mediawiki.legacy.wikibits',function(){ and ending with });, but it’s only a temporary fix, since wikibits.js will go away entirely after some time. If you would like to have a permanent fix, you might do it yourself (
here are the replacements) or ask for assistance on the
village pump. (These JavaScript subpages can be edited only by you and by admins.) --
Tacsipacsi (
talk)
18:44, 17 May 2017 (UTC)
If it doesn’t work, then there are other errors too (these files do have errors for sure) which produce
error messages shown on the browser console. Those show exactly where the error occurred and help correcting them. (N.B. I can help you finding the errors, but I don’t have any rights to actually correct them; you need admins for that.) --
Tacsipacsi (
talk)
12:45, 18 May 2017 (UTC)
Seeing whether a page is on your watchlist from the navpop
It would be helpful to be able to see whether an article was on your watchlist without having to click it. Would it be possible to add a similar star to the navpop of articles so that you can see if the article is on your watchlist (and maybe even add it to your watchlist)?
Absolutelypuremilk (
talk)
07:28, 14 June 2017 (UTC)
Hello, good afternoon. It would be great if through the popup i'd be able to view a review of the article in other languages the same way i view in the original language, or at least be able to jump to another language through the popup. can someone add a link to other languages inside the popup that would enable it?
melo kol haaretz kevodi (
talk)
20:09, 28 June 2017 (UTC)
Missing user info if no contributions
When hovering on a User: link for an account that has made any edits, the popup includes a footer line with a list of permissions bits, the edit-count, the date the account was created, and the date of the most recent edit. If the account has not made any edits, that footer is missing altogether. When tracking vandals (especially possible sleepers at SPI) it would be useful to see the account-creation date. And it would also be useful to see an explicit "0" for edit-count, to help distinguish this actual piece of data from the popup stalling before completely rendering itself. And it also is important to see tags like "blocked" and "locked" so I don't waste my time trying to clean up a mess that has already been cleaned up.
DMacks (
talk)
21:11, 8 April 2017 (UTC)
The account that prompted this is both suppressed and globally hidden, so I don't think that the Popups script can even see the account. Thankfully, this is a rare case, and I don't know if there's any graceful way for Popups to handle it. However, I agree that it would be useful if Popups could display complete information for other accounts without any edits, as that's an issue I frequently encounter as well. —
DoRD (
talk)
21:24, 8 April 2017 (UTC)
Not finding anything in the FAQ or talk archives on this, so might as well ask: does this only work if you are using a mouse/trackball/trackpad, or will it work for touchscreen users?
Beeblebrox (
talk)
18:21, 29 April 2017 (UTC)
Hello. Intermittently (about 1 time in 6) popups fail to load for me on a Wikipedia page. It doesn't seem to be restricted to any namespace or any particular type of page, nor is it consistent on any individual page. The popups load if I do a Ctrl+F5. Happens on latest Chrome and on latest Firefox.
When popups have failed to load, the JavaScript console reports the following error.
ReferenceError: addPortletLink is not defined
at eval (eval at <anonymous> (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:4), <anonymous>:1:228)
at HTMLDocument.<anonymous> (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:179)
at fire (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:45)
at Object.add [as done] (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:45)
at jQuery.fn.init.jQuery.fn.ready (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:49)
at new jQuery.fn.init (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:41)
at jQuery (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:1)
at load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:179
at eval (eval at <anonymous> (load.php?debug=false&lang=en-gb&modules=jquery%2Cmediawiki|mediawiki.legacy.wikibits&only=scripts&skin=vector&version=0cg1aij:4), <anonymous>:1:203)
at eval (<anonymous>)}}
Have I configured something incorrectly? Or have I found a problem? Grateful for any help anyone can offer. --
RobertG ♬
talk09:08, 3 October 2017 (UTC)
@
RobertG: Yes, this kind of behavior (random javascript initiated elements going missing) is usually due to errors in a script, which most of the time is your own script. I've
corrected a script of yours which was of an outdated form. I think it will be better for you now. —
TheDJ (
talk •
contribs)
20:36, 3 October 2017 (UTC)
Javascript was not loading properly for me, and when I tried to find out what it was, I saw this: Uncaught TypeError: Cannot read property 'getParamValue' of undefined and the link next to it was the Popups script.
at autoEdit (/?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript:1097)
at HTMLDocument.<anonymous> (/?title=MediaWiki:Gadget-popups.js&action=raw&ctype=text/javascript:7837)
at fire (load.php:45)
at Object.fireWith [as resolveWith] (load.php:46)
at Function.ready (load.php:49)
at completed (load.php:49)
Note for later. "if (!setupPopups.completed) { setupPopups(); }" setupPopups is async, seems that autoEdit doesn't wait for it to be completed. —
TheDJ (
talk •
contribs)
13:40, 28 September 2017 (UTC)
Beginning today, on multiple computers and multiple browsers, popups no longer autopopulates the edit summary when I use it to revert edits. Any ideas what may be going wrong and how I can fix it?
ElKevbo (
talk)
02:33, 6 October 2017 (UTC)
This seems like a very significant issue. I've had another issue - discussed above in " Reverts/edits no longer autosaving" - for about six months now. If this tool is no longer being maintained then we shouldn't include it as an option for all (logged in) editors to use.
ElKevbo (
talk)
15:41, 6 October 2017 (UTC)
If they're still working as intended then it may not be an immediate problem. This tool is not working as intended so it is an immediate problem.
ElKevbo (
talk)
20:04, 6 October 2017 (UTC)
The problem is that if we remove it as an option, it's gone for all 47000 people who currently have it installed (plus probably as many users on wiki's that reuse directly include this specific version) and there is no undo button for that action. So while adding things is easy, removing them is much more difficult. I for one do not intend on pissing off potentially 47000+ users. —
TheDJ (
talk •
contribs)
20:16, 6 October 2017 (UTC)