Template talk:VideoGallery

Lift Thumbnail Limit

Back when we're implementing this template, we decided to limit the number of thumbnails to 3 because of the crappy Flash plugin that caused slowdowns in pages with various videos (like Xenoblade Chronicles). From a quick look, a huge part of our wiki have video links hosted on YouTube and currently it uses an HTML5 player by default in major browsers (Chrome, Safari, Firefox, the new Microsoft Edge). Said that, I think we should remove the thumbnail limit (especially now that it's becoming common random users reordering the list of videos when adding new content). Thoughts? mbc07 (talk)

I'm OK with lifting it or minimally increasing the limit. We should test out some of the more densely populated pages first. Super Smash Bros. Brawl has 12 separate videos and I'd want to be sure there doesn't need to be some limit still. Kolano (talk) 07:02, 12 September 2015 (CEST)

I'll try to find a way to measure the impact this change could take then report back. Do we have more dense pages? Right now I remember only of Xenoblade Chronicles and now that you mentioned, Super Smash Bros. Brawl - mbc07 (talk)

I would like to keep the limit, honestly. There's more than just the limit at stake, but also page composition. Endless rows of videos is just tacky! If the limit should be changed, it should just be increased to 6. - MayImilae (talk) 11:14, 13 September 2015 (CEST)

I think the other goal here was to prevent edits from folks who think the order of videos makes a difference regarding which are displayed. If we maintain the limit, we should probably add a comment along with the template that more clearly explains videos are chosen at random and order does not matter. We probably should also universally add the empty template across pages, so the mechanism for adding videos is more clear (i.e. currently the template only appears where there are videos populated). Kolano (talk) 19:43, 13 September 2015 (CEST)

Square Bracket Handling

YouTube videos seem to be prone to use square brackets in their titles. These seem to cause breakages when used in the captions here. We either need to account for that internally, or document how to escape them. Pipes similarly need a documented escape. Kolano (talk) 20:15, 22 January 2016 (CET)

Sounds critical, could you share an example? I would like to apply at least a "band-aid" here until I can finish the RFC of the video templates... - mbc07 (talk) 02:33, 23 January 2016 (CET)

There's something weird going on with <span title=""> in the middle of a link. The YouTube template does some funky stuff and calls a mouseover template from within a [ ] link, and that template sets a span title. If the span title contains a closing bracket ] then it freaks out and actually parses the bracket into html for some reason as an </a>, then the weird glitchy links happen after that. I have it working and fully functional in the sandbox, the only problem is that the tiny blue link square in the bottom right of the YouTube embed is either missing or cut off. I was mostly shuffling things around so it must do with ordering (which caused the problem to begin with). You could probably also do this fix by using Template:Hover over the whole link, but I don't think that would be any better honestly. - Xerxes (talk) 16:46, 15 July 2017 (CEST)

Thanks for taking a stab at this. Something is still off with the parsing even in your revised template. The final square bracket seems to end up outside of the link...

<span style="text-overflow: ellipsis; display: inline-block; width: 275px; white-space: nowrap; overflow: hidden; vertical-align: top;" title="Xenoblade JP HD Gameplay 1A (Dolphin Emulator @ 720p]"> <a class="external text" rel="nofollow" href="http://www.youtube.com/watch?v=sam9lDWDvXE">Xenoblade JP HD Gameplay 1A (Dolphin Emulator @ 720p</a> ] </span>

User:Lucario's nowiki tagging on live fixes that behavior. I only needed to port over the Template:YouTube tag though, the change to Template:VideoGallery is giving the same page source output as without it. I tried going crazy and throwing a million brackets at the sandbox and live versions, and it seems that in both, double open brackets [[ cause some total madness and completely break the YouTube template and just display the wikitext as page text. But, that doesn't seem to be nearly as common of a situation as single open/closed brackets. - Xerxes (talk) 01:52, 16 July 2017 (CEST)

To be honest, I would just remove the random thumbnail selection code since it's broken for ages and just do a loop calling the respective subtemplates to embed every video from the arguments, that would make the code cleaner and probably fix those strange issues. I hope I'm able to finish {{Video}} someday, but until that I think this will suffice... - mbc07 (talk) 20:16, 16 July 2017 (CEST)

I removed the rand calls and cleaned up the loop logic to be faster/easier to read. I did two versions, one which embeds the first 3 and links the rest like current behavior (just not randomly), and a version which embeds them all like you requested. You can see how it looks embedding a lot of videos here. Loading that page slows my browser down quite a bit even after speeding up the loops, so I don't know if that's such a good idea. - Xerxes (talk) 01:03, 17 July 2017 (CEST)

Whoops, I hadn't considered the impact in the page loading. Anyway, the first version (which embeds the first 3 and links the rest without the rand stuff) LGTM, I would move it out of the sandbox right now, but perhaps, Kolano or MayImilae might have something to add in the discussion - mbc07 (talk) 01:38, 17 July 2017 (CEST)

Um, the rand calls are somewhat important if we are only thumbnailing 3 videos. Otherwise we end up with people fighting over which videos are "first" and get thumbnails; and I believe there are pages with too many videos to show them all (i.e. Xenoblade Chronicles, F-Zero GX, though those video lists could be cleaned up a bit). Kolano (talk) 01:53, 17 July 2017 (CEST)

Please excuse me if you're already aware, but as I understand it there's two separate things going on with the random videos. First of all, templates on the wiki seem to work off a cached version on page refresh, and don't update until the page they're on or a called template/subtemplate is edited. You can see this by first trying to refresh the page on Template:Random number/doc, then going into edit on it and hitting preview over and over. The former will give the same numbers, the latter will have them change normally. The second problem is that the rand calls in VideoGallery are seeded with "1", "2", and "3". This means that the random choices are sequential, i.e. for a single first random video, you'll always get the same next two "random" videos after it. The second behavior could probably be improved with better seeds, but this might make it possible to get two of the same results without adding more ugly checks, I'm not sure about that. The first one though is a sitewide behavioral quirk and "fixing" that might lead to a huge performance hit. For example, I used to have a ton of dpls on my talk page, and dpl's documentation is covered in warnings about server load. It might not be the best thing to have those refresh every time I wanted to look at the results of the same search. - Xerxes (talk) 02:33, 17 July 2017 (CEST)

Well, when I created this template ages ago (early 2013, if I'm not wrong), MediaWiki itself worked a lot differently. Basically, there were no caching, you would always get randomized thumbnails just by loading a page with {{VideoGallery}} on it, on every page refresh the thumbnails would also randomize again, without needing to edit or preview anything. Not only MediaWiki but also the server which hosts our wiki got tons of updates since then and it eventually (don't remember exactly when) became stuck to the behavior we're seeing now (a "cached" version with always the same thumbnails, which changes only if the page or the template get edited). I had no clue on how to fix this (not even sure if it's feasible), so I didn't touch it anymore. Fast-forward to 2017 and you can see the template logic itself it's almost exactly the same (now broken) one from 2013. Regarding the seeds, the only thing I remember was that those values (1, 2 and 3) worked reliably on every test case I threw at it at that time, so I stuck with them (I have no idea on how I ended up with them, though -- maybe it worked at that time by luck or some undefined behavior?). Anyway, if you think you can fix it, feel free to go ahead, I have no objections at all - mbc07 (talk) 08:23, 17 July 2017 (CEST)

Thank you for providing some more specific details. I wasn't clear regarding the deficiencies in the randomization. Things still work somewhat as intended (i.e. a random set of videos get thumbnails, outside the order they appear on the page preventing editors from easily controlling the order on the page). Though I guess since random updates change the order, that may lead to random edits to force resets for those in the know. It still provides some discouragement to playing with video order. I'd need to look more closely, but I'd presume there's probably a better way of handling the randomization seed, though that may have impact on performance since a properly randomized seed likely impacts caching of pages. Perhaps a date based seed using the day could work out, so it would still rotate regularly but still allow a page to be cached for a while.

I think some of this also comes round to something I think we've been trying to avoid, which is more general care taking of the posted videos. There's many links that can be purged (i.e. whole lists of playthrough videos's rather than just the first clip, odd ball recordings with cameras, obnoxious commentary, etc.). We might want to rethink the handling somewhat generally, perhaps pruning things down to a few "curated" videos and providing a search link into Youtube for others. It might be possible to even surface search results on the page via the Youtube API, though particularly for rarer/less unique title names that may have some odd content. Kolano (talk) 06:12, 17 July 2017 (CEST)

My idea to solve this was to make an empty template and call it from VideoGallery, and have User:BuildBot make a meaningless edit to it once a day, but the way it works is different from how I thought. Apparently second level nested templates being changed doesn't update the cache on the top level page. This is kind of bad behavior since say if we just pushed the YouTube template fixes for the brackets but the VideoGallery wasn't being edited around the same time, I guess that means the fix wouldn't be applied to any pages until those individual pages were edited. I then tried to add a current time template to the VideoGallery since that's extremely volatile to see if there was some sort of specific override for date stuff, and that still wasn't updating on refresh. The only thing I can think of here client side would be to have BuildBot just add a newline and then remove it or something on the VideoGallery template every day if you just want a daily refresh. Since nobody noticed the pseudo randomness until now, I don't think that's such a problem, and fixing it would require adding checks of the random values against each other which seems like a mess. And, the behavior of having the same ones show up at the same time would never really be different I don't think unless there were at least 2 separate dynamically changing seeds, which doesn't seem worth the effort really (especially since they won't cause a reload).

And if we called EmbedVideo plugin directly into {{VideoGallery}} instead of calling subtemplates like {{YouTube}} inside it, would that work? Maybe you could also use the current Dolphin revision (which is automatically updated by a bot) as a "base" for the seed calculation, to trigger the refreshes... - mbc07 (talk) 18:20, 17 July 2017 (CEST)

I really don't understand this. First I tried adding a useless space to VideoGallery inside the noincludes ("pinging" it), and that was causing page reloads. Then I pinged YouTube, and that was reloading too, even though yesterday I tried reverting the entire bracket fix in the sandbox and that wasn't reloading my sandbox test cases. So then I pinged Template:Documentation since every single template on the site calls that, and it didn't cause page reloads. Then I tried making a totally blank template with just one variable definition and adding that to the VideoGallery sandbox, and that was causing reloads on ping. So I made the unused variable definition take a dummy of CurrentGitRevision as an argument, and changing the git revision dummy was causing reloads. So my conclusion is I don't have any idea what's going on, and pages probably already do reload when Dolphin updates, but I don't want to touch the real git revision template at all or make 50 sandboxes to find out. I'm just going to go ahead and say that in this current state, trying to work around the page caching at all would be bad design because of its inconsistency, there should be a different approach. - Xerxes (talk) 02:45, 18 July 2017 (CEST)

I think a totally new approach with some kind of expandable box or Kolano's YouTube API pairing idea seem interesting, but I wouldn't know where to start with that. Frankly I'm horrible at web styling CSS kind of stuff, so anything involving that is outside of my current ability. - Xerxes (talk) 10:19, 17 July 2017 (CEST)