22 May 2016, 01:48
That's an interesting, and correct observation. Let me explain:
Unlike all other sorting methods, the shuffle sort is handled by the javascript in the frontend. Why? Because if we shuffle from the backend (which can easily be done), images would get shuffled, but then that initial output will get stored in your X3 page cache. Thus, consecutive visits to the same page will result in "hey, it's not shuffling the images", and therefore this is handled by javascript.
So ... What is happening here, is that X3 backend is outputting first images within the limit range, caching the page output, and the javascript frontend is shuffling those images. Even if we ALSO shuffled from X3 backend, the specific images picked in the shuffle would persist in the page cache.
To achieve what you ask, we would therefore need to shuffle the images on the server script (instead of javascript), before it limits the output. The reason why we can't really offer 'shuffle' from the server, is because this is not compatible with page-caching. The initial output will get cached, so that consecutive visits that load the cached fragment, aren't truly shuffled.
The solution would be to disable page-cache for this specific page. Although it might just take 1 second more to generate the page, that is much slower than cache, which is likely below 0.1 seconds. Simply a poor compromise. It would have to re-process the entire page for all visitors, on each visit.
There is another option, but it would be considered a dirty hack: We could ask the server/php to output ALL images (unbound by limit), and then javascript would do the shuffle AND remove image elements outside the limit setting (after the shuffle is done).
To be honest, none of these options are favorable, so this topic would likely be tagged "technical logical limitation".