Template talk:VideoGallery

Random Videos
Issues remain with this template only generating random videos per page edit, rather than per page load, seemingly related to caching. We may want to look into what sorts of cache-control may be possible. Otherwise this likely requires implementing some alternate script based handling for the video selection / rotation. Kolano (talk) 03:37, 27 September 2017 (CEST)


 * I understand page caching a lot better now than I did. MediaWiki has really good documentation about everything, it turns out, it just might be a bit buried where it's at. Pages are processed in a job queue wherein any pages using templates/images/etc that were edited, or any categories that need to be updated, are added to a big stack and processed one at a time. The default setting is per 1 page load from a visitor to the site, 1 task on the top of the job queue is processed, but this can be changed in server configuration. Pages are given an automatic "expiry" time when they're cached, so a page that's not edited and has no templates for example should still be added to the job queue occasionally, just on a more periodic basis. You can see this refresh date and a lot of other miscellaneous cache info like performance statistics by viewing the page source for different wiki pages in your browser. Basically as I see it, all game pages are already being added to the job queue at least once a day and reprocessed because of CurrentGitRevision. Even making all the site's templates faster/slower doesn't affect the job queue because the tasks are processed depending on page loads and don't actually continuously run in the background unless explicitly told to do so. Short of rewriting the template completely to not have random elements, there's nothing that can be done to fix this from the user side. That's why I held off on touching this at all. - Xerxes (talk) 10:33, 27 September 2017 (CEST)


 * Thanks for the further explanation around caching. And yeah, I'm not clear there is a lot we can do in the pure wiki. Admins can revise the site JavaScript and had thought some script running on a list of links could likely resolve this more cleanly. Though I think I'd forgotten about an aspect you brought up, in that the regular version updates force page refreshes. I wasn't clear that those sorts of refreshes updated the video order, if they do this is less of a concern; though preventing the user edit's trying to game the system (even if their "fixes" reset the next revision) would probably be for the best. Kolano (talk) 12:40, 27 September 2017 (CEST)


 * Some script could enable some other niceties, like rotating through all available videos over time, or querying video sources via search. Kolano (talk) 12:57, 27 September 2017 (CEST)

I don't know about the automatic rotation. If someone's interested by a thumbnail and goes to click, it shouldn't be able to change mid mouse movement, or if it does there should be a way to go back to the last set of thumbnails. Maybe it can use one of those systems that a lot of installers/websites use now where there's a simple automatic cycle through sets of 2 or 3 videos on a loop, with little bubbles on the bottom that you can mouse over to switch it between sets? If you don't know what I'm talking about, this site uses a really basic example on top of the home page. I think that look is common enough to people that it should be easy to understand how it works, it keeps them cycling so there's no "top" video, and it preserves the video order as it is on page edit. - Xerxes (talk) 10:40, 29 September 2017 (CEST)

Dropping a reminder here that some sort of wiki randomization will remain necessary even with a JavaScript randomizer. Without such video order will still matter to search engines, which we should try to avoid. Kolano (talk) 05:50, 23 February 2018 (CET)

= Old Discussions =

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 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 , 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...

 Xenoblade JP HD Gameplay 1A (Dolphin Emulator @ 720p ]


 * 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 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)