MediaWiki talk:Gadget-Favorites.js

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Ideas[edit]

Unlike the gallery picker tool this should at first be active on File: namespace pages. Possibly adding an icon next to the bookmark icon, although that could be confusing.

Changes will be temporarily cached in localStorage. A change is a set consisting of an action, a file name, and an author. The action is either adding to or removing from the favorites list. A change is applied immediately to the localStorage cache. The filename is the name of the image to be added to the Favorites list. The author is the original uploader of the image. It's username will also be added on the /Favorites page. This should trigger a notification to be sent to the uploader.

Changes will be committed to the user's /Favorites page after a condition is met (this can be after some time or after enough changes are accumulated, or immediately, but we might want to keep traffic low).

Commiting a change means editing the /Favorites page. A change will only be marked as resolved (removed from localStorage) one the edit to add it to the /Favorites page is confirmed successful.

The list of currently faved images must also be kept in localStorage. Occasionally the latest page revision of the /Favorites page has to be polled and the localStorage copy of the list has to be updated (in case the /Favorites page is edited manually and to synchronize between different browsers).

Potential expansions:

  • if on a user page, probe if a /Favorites subpage exists and add a sidebar link to it

This should be doable in very responsive way. --Dschwen (talk) 20:43, 4 December 2013 (UTC)[reply]

Implementation[edit]

  • A list of Favorites is cached in localStorage to quickly determine the fave status of the current image (without additional net traffic)
  • Every 15minutes (only checked on page reload!) the /Favorites page is reloaded and the cache rebuilt. This way the localStorage caches between two different browsers don;t get out of sync.
  • Whenever a tab with an image inside get focussed the favorite status is rechecked against the current state of the localStorage cache. That means if you have an image open in multiple tabs and fave it in on tab, as soon as you switch to the other tabs the status (in the top right tab bar) is instantly updated.
  • When you change status a transaction is recorded in localStorage.
    • The script tries to apply the transaction but may fail due to long server response times.
    • The transaction is only removed from localStorage after the change (fave/unfave image) was successfully saved to the /Favorites gallery page.
    • This allows you to fave an image and immediately close the tab. The transaction will be retried when reload any image page.

All this should minimize network traffic, and persistently store any fave action (even if you immediately close the tab after faving).

Thats it so far. --Dschwen (talk) 22:09, 5 December 2013 (UTC)[reply]

Ok, automatic mention notifications do only get triggered in *Talk: namespaces or on project pages. So the won't work on the User:Userbname/Favorites page. On top of that mention notifications are only triggered for signed contributions, and signatures are not parsed in gallery tags. So that's a double fail. I have instead added automatic thanks using the thanks API. The thanks is given for the first revision of the file description page. That m,eans two additional API request, but so what. The thanks giving (oh, hey, Thanksgiving!) is not journaled like the fave action, so thanks could be lost if the tab is immediately closed, but I figured that this part is not the crucial one. --Dschwen (talk) 00:11, 6 December 2013 (UTC)[reply]

Bits of code review[edit]

mw.config.get( 'wgUserName' ) could be mw.user.name()
✓ Done --Dschwen (talk) 06:05, 7 December 2013 (UTC)[reply]
Now you need a dependency to the default module mediawiki.user and note that mw.user.name() is deprecated. Use mw.user.getName(). -- Rillke(q?) 10:54, 10 December 2013 (UTC)[reply]
mw.config.get( 'wgTitle' ) is good but mw.Title.newFromText( mw.config.get( 'wgPageName' ) ) will give you a Title object that may be more useful. It also has the benefit of giving you the namespace number with title.getNamespaceId(), so you can use that for the check at the beginning.
I'll keep that in mind, here I'll keep it as it is for clarity (otherwise I'd have to move the if further down and the alternative is not much more compact. --Dschwen (talk) 06:05, 7 December 2013 (UTC)[reply]
This was actually a very good suggestion. I am now using title objects everywhere in the code to normalize filenames before comparing them! Mark, what is the difference between mw.Title.newFromText() and new mw.Title()? --Dschwen (talk) 17:02, 10 December 2013 (UTC)[reply]
You should maybe use an object for the favCache so lookups are fast, instead of having to call indexOf on an array...
I did think about that, and might switch it over. The motivation initially was to have a slightly smaller JSON structure, but if I just assign a '1' to each key (filename) it won't make much of a difference. I thought indexOf was fast... I'm sure someone must have written a jsPerf case for this :-). --Dschwen (talk) 04:40, 6 December 2013 (UTC)[reply]
And sure enough it exists here. Wow, you are absolutely right. IndexOf is demolished by property lookup (300x faster). --Dschwen (talk) 05:29, 6 December 2013 (UTC)[reply]
✓ Done --Dschwen (talk) 06:05, 7 December 2013 (UTC)[reply]
Try to use $.prop instead of $.attr when you can - the latter will be deprecated soon anyway.
Good point. I have to read up on this, I thought they both had their own applications. --Dschwen (talk) 04:40, 6 December 2013 (UTC)[reply]
✓ Done --Dschwen (talk) 06:05, 7 December 2013 (UTC)[reply]
How can you deprecate using .attr() for setting attributes? /me shares this link to SO. -- Rillke(q?) 10:54, 10 December 2013 (UTC)[reply]
You can likely use the $.post shortcut safely, your HTTP request is sane enough.
✓ Done --Dschwen (talk) 06:05, 7 December 2013 (UTC)[reply]
You should probably be using strict equals where possible. You could interpret that as a style difference if you want, but it's good practice
)
Yep, I'll go over the code again. I do try to use strict equals where possible. --Dschwen (talk) 04:40, 6 December 2013 (UTC)[reply]
✓ Done --Dschwen (talk) 06:05, 7 December 2013 (UTC)[reply]
xhr.status==404. -- Rillke(q?) 10:54, 10 December 2013 (UTC)[reply]
You can definitely use mw.Api to make the API call in saveFavorites and thankUploader
) (I feel like the thanks extension should have a JS library to do the latter for you, though...)
Yeah, I'm still new to the API stuff. I'll read up on mw.Api. --Dschwen (talk) 04:40, 6 December 2013 (UTC)[reply]
In all HTTP request contexts you should probably use the promises API to handle async callbacks instead of using straight callbacks.
Do you mean the jQuery promises API? That will be a good opportunity to finally learn about promises. --Dschwen (talk) 04:40, 6 December 2013 (UTC)[reply]
✓ Done, I guess --Dschwen (talk) 06:05, 7 December 2013 (UTC)[reply]
Date.now() will give you the equivalent of new Date().time()
Yeah, but it is not supported as wide as the (new Date()).getTime() variant! On the other hand it needs only to be supported on browsers that have window.localStorage. --Dschwen (talk) 05:33, 6 December 2013 (UTC)[reply]
and JSON. -- Rillke(q?) 10:54, 10 December 2013 (UTC)[reply]
The locking infrastructure makes me think you should register callbacks for when the lock is unset rather than using timeouts...but I don't think it's too important.
The lock is potentially not unset if the tab is closed or the browser crashes. Is onunload guaranteed to fire? --Dschwen (talk) 04:40, 6 December 2013 (UTC)[reply]
Another thing to keep in mind is that the action from a different tab may set the lock in localStorage. Unless I start getting into cross tab messaging (which I don't even know whether it is possible if the tabs wer not opened by a common script) I think I need to poll localStorage to get some kind of cross tab messaging. --Dschwen (talk) 05:21, 6 December 2013 (UTC)[reply]
This exactly what we have jQuery.jStorage for. You can send messages cross-tab with it and it supports older IEs (userData). To check support do if ( jQuery.jStorage.currentBackend() ), to send messages cross-tab do jQuery.jStorage.publish(channel, payload), to store data do jQuery.jStorage.set('key', 'value'). To load jStorage, do mw.loader.load('jquery.jStorage') -- Rillke(q?) 10:54, 10 December 2013 (UTC)[reply]
You could probably save things to localStorage on page unload and be mostly fine...unless the browser crashes, that is.

Hope some of this is helpful! --MarkTraceur (talk) 01:04, 6 December 2013 (UTC)[reply]

Oh, and you might consider doing something awesome like having a Gadget-Favorites-loader.js file that *only* checks that you're in the file namespace and then loads the rest of the JavaScript. --MarkTraceur (talk) 01:16, 6 December 2013 (UTC)[reply]

How about making gadgets namespace specific? Is it worth it? You are adding an additional request here rather than take advantage of bundling by the ressource loader. --Dschwen (talk) 04:40, 6 December 2013 (UTC)[reply]
One would have to know whether js-interpretation time in the client matters. Given the current size, I doubt it is required. We should be able to define namespaces in the gadgets-definitions. Do we have a bug report for that? -- Rillke(q?) 10:54, 10 December 2013 (UTC)[reply]

Thanks Marc! It is late now, I will implement what I can tomorrow. I have added a few questions inline. --Dschwen (talk) 04:40, 6 December 2013 (UTC)[reply]

P.S.: Driving into the city (ABQ) tomorrow. So it may take a bit more time. --Dschwen (talk) 05:29, 6 December 2013 (UTC)[reply]


mw.util.jsMessage is deprecated; use mw.notify()
-- Rillke(q?) 10:54, 10 December 2013 (UTC)[reply]
✓ Done. Thanks! --Dschwen (talk) 15:41, 10 December 2013 (UTC)[reply]

Can't find the tab[edit]

Had selected the gadget in December already and came across my first picture I'd like to fav today. Searching for the tab - don't have one. Neither to the right of the star (my pulldown menu on Picture pages is: Global Usage, Find Categories, Log, Purge, en-wiki, Verschieben), nor on the left side bar. Any idea? Please feel free to fumble in my vector.js, if neccessary. --Schwäbin (talk) 10:52, 10 January 2014 (UTC)[reply]

Hmm, your vector.js should not need to be touched. But maybe there is a conflict with a tool you installed in there, or another gadget. What other gadgets do you have activated, and which browser/version are you using? --Dschwen (talk) 14:28, 10 January 2014 (UTC)[reply]
You can simply go to that tool and e-Mail the result to Daniel. -- Rillke(q?) 14:46, 10 January 2014 (UTC)[reply]
Ha! Thanks/Danke! Das werde ich mir mal merken. --Dschwen (talk) 15:14, 10 January 2014 (UTC)[reply]
Sent the mail to you two days ago - got lost in the spam folder or just had't enough time for it yet? --Schwäbin (talk) 15:20, 12 January 2014 (UTC)[reply]
Hallo, sorry, ich hatte es mir angeguckt, aber nichts auffaelliges entdeckt was einen Konflikt ausloesen koennte (ich habe ein paar deiner gadgets bei mir aktiviert und alles ging noch). Ich bin bis Montag unterwegs, werde dann aber mal ein paar extra fehlermeldungen in das gadget einbauen. Ich hoffe wir koennen den Fehler so finden. --Dschwen (talk) 15:51, 12 January 2014 (UTC)[reply]
Keine Hektik und kein Grund für sorry, es ist Freiwilligenarbeit und ich wollte eigentlich nur sichergehen, dass die Mail ankam. --Schwäbin (talk) 16:41, 12 January 2014 (UTC)[reply]
Using Firefox, Windows XP (haven't found the time to set up the new notebook with W7 yet, sorry). Adblock Plus is not the problem, I had deactivated it and the only difference was that I then saw the site notice about scholarships ;-)
NoScript kann's nicht sein, alle anderen Addons sind mir als ahnungslosem Anwender unverdächtig.
Kurzer Test: Mit dem MSIE <grusel> erscheint das "fave" ... --Schwäbin (talk) 11:06, 22 January 2014 (UTC)[reply]
Hmmm, hast Du NoScript denn mal abgeschaltet zum testen? --Dschwen (talk) 16:38, 22 January 2014 (UTC)[reply]
Nein, ich lasse via NoScript Scripte von wikimedia.org generell zu. Das Programm würde mir anzeigen, wenn weitere Skripte zugreifen wöllten, aber blockiert wären. Ist nicht der Fall. --Schwäbin (talk) 20:54, 22 January 2014 (UTC)[reply]
Ok. Kannst Du in Firefox mal Strg+Shift+J druecken und dann eine Bildseite neu laden. Es muesste sich ein "Konsole" Fenster oeffnen, in dem evtl. einige Fehlermeldungen auftauchen. --Dschwen (talk) 21:04, 22 January 2014 (UTC)[reply]
Meine Vermutung ist, das DOM Storage bei Dir ausgeschaltet ist. Das ist sowas aehnliches wie ein Cookie (nur dass die Daten nicht automatisch uebers Netz geschickt werden), naemlich eine Moeglichkeit fuer ein Script Daten auf Deinem Computer zu speichern ueber mehrere Seitenaufrufe hinweg. Das script braucht das um eine Liste der von Dir favorisierten Bilder zwischenzuspeichern (sonst muesste das script jedesmal wieder eine Anfrage an die Wikimedia Server schicken). Gib in der Firefox Adresszeile mal about:config ein und suche nach dom.storage.enabled. Da sollte true hinterstehen damit das gadget funktioniert. --Dschwen (talk) 22:02, 22 January 2014 (UTC)[reply]
Ja, da steht derzeit "false". Ich habe einige Einstellungen bezüglich Cookies vorgenommen, unter anderem, dass sie nach Schließen des Browsers gelöscht werden (unterstützt von dem sehr weit verbreiteten Addon BetterPrivacy) und "Cookies von Drittanbietern akzeptieren: nie".
Ich habe keine Ahnung, wie ich das dom.storage.enabled einschalten kann. --Schwäbin (talk) 10:24, 23 January 2014 (UTC)[reply]
Uhm, mit Rechtsklick oder so kann man das aendern. --Dschwen (talk) 20:38, 23 January 2014 (UTC)[reply]
Bei Boolean-Werten macht es auch ein Doppelklick. -- Rillke(q?) 19:27, 24 January 2014 (UTC)[reply]

Wrong author(s)[edit]

The author of a photo is its photographer, not the uploader of the latest version on Commons.

Example for wrong approach: User:Juggler2005/Favorites.

There are many wrong attributions generated by this script and it's very problematic for the CC-BY licensing.

File:Agrigent BW 2012-10-07 12-24-45.JPG is a photo by Berthold Werner and not by Jebulon. File:Ледяной лес.jpg is a photo by Aleks_G and not by me. File:Black-necked Stilt (Himantopus mexicanus), Corte Madera.jpg is a photo by Frank Schulenburg and not by Christian Ferrer. And so on, and so forth.

Imo, the script should be disabled as long as the problem has not been fixed. --A.Savin 10:22, 28 February 2014 (UTC)[reply]

Hi Dschwen, there is a new API for getting the real author, developed by Bawolff: Consider this query: query.pages['23439497'].imageinfo[0].extmetadata.Artist.value. To strip HTML you can simply do stuff like $('<div>').html(value).text();. Since created by the MW-parser, nothing evil can be injected. However, do not forget testing whether Artist and before imageinfo exist on their "host objects". -- Rillke(q?) 11:31, 28 February 2014 (UTC)[reply]
Thanks for the pointer. I will try an d integrate this (I'm a bit busy in real life right now, though). --Dschwen (talk) 20:41, 28 February 2014 (UTC)[reply]
Yeah, don't hurry, if I see how much efforts you put here as a volunteer: I just stumbled across m:Grants:IEG/MediaWiki data browser and m:Grants:IEG/MediaWiki data browser/Final, a project that was funded with $15.000 and produced something of, IMHO, very questionable usefulness. Even programmatically, it isn't done nicely, I would have expected some abstraction about the client side data storage, for example … -- Rillke(q?) 21:48, 28 February 2014 (UTC)[reply]

wrong User[edit]

I added a new image, but the user is wrong. --Atamari (talk) 17:29, 25 July 2014 (UTC)[reply]

is this bug fixed? --Atamari (talk) 19:46, 24 August 2014 (UTC)[reply]
@Atamari: Probably fixed now. Does it work for you? I added a code to avoid extracting suffixes inserted by MediaWiki:Gadget-markAdmins.js. [1] whym (talk) 00:24, 25 August 2014 (UTC)[reply]
@Whym: , I don't know whether it is a good idea to change the user interface for obtaining something from it (ie. the (A) should be probably not removed). $('.filehistory a.mw-userlink').first().clone().find('.adminMark').remove().end().eq(0).text(); for avoiding it. -- Rillke(q?) 00:55, 25 August 2014 (UTC)[reply]
@Rillke: Fixed, thanks for pointing it out. Believe it or not, I meant to have added .clone(), but apparently I forgot. whym (talk) 03:39, 25 August 2014 (UTC)[reply]
Test ok, bug is fixed. thanks. --Atamari (talk) 14:51, 25 August 2014 (UTC)[reply]
Thanks for fixing this, I totally missed that bug report. --Dschwen (talk) 17:33, 25 August 2014 (UTC)[reply]

New technologies[edit]

.sendBeacon() and ServiceWorkers could be interesting for this script. -- Rillke(q?) 01:37, 24 August 2014 (UTC)[reply]

Will gallery options confuse the plugin?[edit]

Hi, I don't speak javascript and I'm also not too familiar with regular expressions, but I think this should be easy to answer for anyone who is: Will it confuse the gadget if I add options to the gallery html page of my favorites? Something like <gallery heights="140px" mode="packed-hover">. That would be great to know. Thanks. :) — Julian H.✈ (talk/files) 21:18, 10 September 2014 (UTC)[reply]

@Julian Herzog: I think the gadget should be robust enough to allow for some customization of the gallery tags. --Dschwen (talk) 17:28, 16 September 2014 (UTC)[reply]
@Dschwen: Thank you, that's nice. I'll give it a try then. :) — Julian H.✈ (talk/files) 17:52, 16 September 2014 (UTC)[reply]

some questions[edit]

I like the idea of the Favorite-Gadget for several reasons, but I'm not sure if all of them are already well implemented. In my opinion, the two main advantages of an automatic favorites gallery are that you could make it accessible for other users (User page, discussion, favorites or something like that - as it seems Dschwen planned for in the beginning; on the other side, I'd also love to have an easier access to the files uploaded by a user than there is now), and the possibility to automatically notify the uploader of the image (is there a possibility for me to check if that happened?).
But I have a few questions/suggestions:

  • is it okay to change the gallery page (as was asked in the last entry)?
  • perhaps change the by to the author and add (uploader: xxx)?

and not as important:

  • would it be possible to change the title style a bit? (ideally to change all underlines into blanks and to remove the .jpg/.png at the end of a file)?
  • automatically add Featured picturesQuality images and   where it applies?

Thanks for the work done so far!
Best wishes, --Anna reg (talk) 10:06, 16 September 2014 (UTC)[reply]

Anna, I'll look into fetching the author credit line through the API. But that is not guaranteed to be a commons user. So the thanks action would still have to be directed at the uploader (thanks for uploading this). I cannot promise much at the moment as I don't have much time to work on this. --Dschwen (talk) 18:07, 16 September 2014 (UTC)[reply]
Thanks for looking into it - and I didn't really plan to notify you three times - that more or less just happened and was not meant to pressure you! I think thanking the uploader is fitting (in case the photographer is a commons user, he normally is the uploader), but it's strange to see a by not mentioning the author/photographer...
Best wishes, Anna reg (talk) 21:38, 17 September 2014 (UTC)[reply]

Multilingual[edit]

What about creating some "MediaWiki:Gadget-Favorites.js/xx" language codes, where "xx" is langcode (for example "MediaWiki:Gadget-Favorites.js/ru". It contains only interface translation of buttons and popups of this js. But I don't understand js-language and don't know how to translate it in my (ru) language. ← Aléxi̱s Spoudaíos talkrus? 06:50, 9 October 2015 (UTC)[reply]

Please add a common warning or confirm box before[edit]

It is a bit annoying if I click by mistake on it (if a page load, to button moves sometimes or you have a touchpad...) I don't know any function/gadget which made an edit+save immediately. User: Perhelion (Commons: = crap?)  13:02, 10 November 2015 (UTC)[reply]

+1. I sometimes make a mistake because of clicking it. Poké95 02:27, 7 April 2016 (UTC)[reply]
PS: for simple comparison: Even with "pages for watching", you need on a separate window, specially still confirm, to watch or not. And as said, this is standard, also for functions which make not any real edit. User: Perhelion 06:27, 7 April 2016 (UTC)[reply]
✓ Done -- User: Perhelion 01:17, 14 June 2017 (UTC)[reply]
Ok, but pressing the watchlist star does not trigger a prompt either... The fact that the gadget edits a page seems somewhat secondary, as the page could be understood simply as a storage backend for the gadget. --Dschwen (talk) 03:45, 15 June 2017 (UTC)[reply]
Everyone which try the link the first time becomes (high possible) an unwanted edit. I be myself clicked the link several times unwanted and wondering later what I have for Fav images. :-P
I tested it today, if you pressing the watchlist star very early, it directs to a confirm page. Best regards -- User: Perhelion 12:05, 15 June 2017 (UTC)[reply]
Oh, if that is your concern, we can change it so that the popup doesn't appear after the document loaded event fired and the page is completely bulit. --Dschwen (talk) 02:59, 16 June 2017 (UTC)[reply]
@Perhelion: could you try to avoid a complete reformat of the script for just a small functional change? It renders the diff view quite useless. If you feel very strongly about the formatting, just put that in a separate edit. --Dschwen (talk) 15:21, 18 June 2017 (UTC)[reply]
@Dschwen: For me this is really not that tragic, this is a common formating which get also automatic formated per a (Edit request) script from Commons. On the other hand the standard Wiki-Diff is pretty bad so I use an Advanced Diff (from user Schnark, which is also a major feature request to WM). Best regards -- User: Perhelion 12:17, 19 June 2017 (UTC)[reply]