Theme details should be able to include multiple screenshots

Description

Per 3.4 scoping, themes should be able show multiple screenshots. This would require an API change on .org.

Ideas include showing a gallery inline with the current placement of the screenshot. Other visual ideas welcome. The thickbox will likely disappear and would not serve as a good place, as it is used for installing and not shown for installed themes.

A note about screenshot sizes: the plan is to stick to the same size that appears in the install thickbox for the multiple screenshots - 300px by 225px. Also going to up the size of the single screenshot that shows in the list table view to match. Have run this by the Theme Review Team and don't foresee any issues.

19816.diff​ is a rough initial pass with heavily commented JS. JS used to determine where to pop in the extended details div. Currently looks like this: ​http://cl.ly/3h3Q1Y290N3G083J1L42 - just scraped the other screenshots in for demonstration, and the stack would only show for themes with multiple screenshots. The stack does intentionally disappear when the layer is open. Thinking perhaps the screenshot grid within the extended details div should match that of the list table.

Things to work on:

Adding .has-screenshots to .available-theme divs when applicable

Retrieving the multiple screenshots in get_themes() and adding to the .org API response

19816.2.diff​ adds in .has-screenshots (needs stack.png​ in wp-admin/images, not added in the patch) and handles screenshots as an array, as well as appending them in to the extended details div.

Thinking further, we could probably just have both get_themes() and the .org API response continue to return the first screenshot, as it does now, and then just the number of screenshots. The full URL for all of the screenshots isn't needed, since naming and file extension (.png) should be consistent for additional images. The JS in this patch only receives the total number of images and builds the image src URL from there.

Caching: Introduces a wp_cache_themes_persistently filter (also in [20020]) to enable persistent caching of all filesystem and sanitization operations normally handled by WP_Theme (and formerly get_file_data() and get_themes()). Themes are cached individually and across five different cache keys for different data pieces.

Compatibility: A WP_Theme object is backwards compatible with a theme's array formerly returned by get_themes() and get_theme(), and an stdClass object formerly returned by current_theme_info().

i18n/L10n: Theme headers are now localizable with proper Text Domain and Domain Path headers, like plugins. (Language packs may remove the requirement for headers.) For page templates, see #6007 (not fixed yet, but will be easy now). For headers, fixes #15858.

PHP and CSS files: New methods that fetch a list of theme files (for the theme editor) only on demand, rather than only loading them into memory. fixes #11214.

19816.4.diff​ is a refresh to use the beautiful WP_Theme for the screenshot count. Theme install side will likely need to be tweaked later to accommodate whatever gets returned from the .org API, and then should probably have variable names actually match. Would like some eyes on the JS and then to get this in for a look at UX. It all works nicely - add some appropriately named screenshots to an installed theme folder for a look. And stack.png​.

One note about the UX that started with 19816.3.diff​ - the details div snaps shut when the window is resized. We can look at other behaviors, but this seemed the most sane for a first go. Nothing particularly breaks on window resize, but there is some funkiness without the function on $(window).resize().

Will the extra theme screenshots (other than screenshot.png) be housed in the top level of the theme directory like we do with plugins? Or, will there be a /screenshots folder, or at least an option to filter it to do so?

Theme folders already get pretty cluttered with so many template files. Having the option of adding the screenshots to a sub-folder would be nice.

Will the extra theme screenshots (other than screenshot.png) be housed in the top level of the theme directory like we do with plugins? Or, will there be a /screenshots folder, or at least an option to filter it to do so?

Theme folders already get pretty cluttered with so many template files. Having the option of adding the screenshots to a sub-folder would be nice.

I would tend to agree, but that would mean that the initial screenshot would still need to remain the root, so then only extra screenshots end up in /screenshots.

Will the extra theme screenshots (other than screenshot.png) be housed in the top level of the theme directory like we do with plugins? Or, will there be a /screenshots folder, or at least an option to filter it to do so?

Filter wouldn't work. If these shots are on the theme selection screen, then core needs to know their location without any code from the theme running.

For the moment, everything is geared towards having core-known-files be in the theme root. If we want to add subfolder functionality, then I think a better approach would be higher level than just the screenshots. Make the theme-file-searcher-thingamabob such that it's capable of looking in named subfolders as well as for named files and such.

For now, I'd stick with a root level naming scheme. screenshot-1.png, screenshot-2.png and so forth. This is simple to understand, works fine, and using the dash (-) makes it flexible to possibly allow for smarter theme-file-searching later (in the same way get_template_part uses the dash to separate things).

/screenshot\.(jpg|png)$/ should also include gif and jpeg, as those are supported extensions in core.

For theme installs, the API is set up to serve a screenshot_count field (int) and also a screenshots field (array of URLs).

I searched for "screenshot-2.png" site:themes.svn.wordpress.org, but couldn't find a single theme approved in the last two years that has more than one screenshot fitting the requirements. I am going to ping the theme reviewers list to see if we can get some themes operational with the new specs.

/screenshot\.(jpg|png)$/ should also include gif and jpeg, as those are supported extensions in core.

For theme installs, the API is set up to serve a screenshot_count field (int) and also a screenshots field (array of URLs).

I searched for "screenshot-2.png" site:themes.svn.wordpress.org, but couldn't find a single theme approved in the last two years that has more than one screenshot fitting the requirements. I am going to ping the theme reviewers list to see if we can get some themes operational with the new specs.

I do not believe it has ever been considered prior to this ticket in the sense that why include files that for all intent and purpose would never be used.

We could put a call out to have themes submitted / updated with extra screenshots.

NB: I am preparing a "quick" fix (as noted in #19910) for Desk Mess Mirrored; I can include an extra screenshot of two for testing purposes if wanted.

I do not believe it has ever been considered prior to this ticket in the sense that why include files that for all intent and purpose would never be used.

A few themes did include extra screenshots anyway, but the only ones I found A) were older than two years, B) used jpg instead of png, or B) used Screenshot-2.png instead of screenshot.png.

We could put a call out to have themes submitted / updated with extra screenshots.

Sure. We will need to make a major push on that front. (We should probably allow updated screenshots to be quickly approved for previously updated themes.) But not until we have code in place to actually count the screenshots; that is not set up yet.

NB: I am preparing a "quick" fix (as noted in #19910) for Desk Mess Mirrored; I can include an extra screenshot of two for testing purposes if wanted.

That would be fantastic. 300x225 like screenshot.png. must be screenshot-2.png, -3.png, etc. Let me know once it is live so I can set up the data point.

We could put a call out to have themes submitted / updated with extra screenshots.

Sure. We will need to make a major push on that front. (We should probably allow updated screenshots to be quickly approved for previously updated themes.) But not until we have code in place to actually count the screenshots; that is not set up yet.

We can make that part of the Review-In focus on March 3, 2012 if there are any available for review.

NB: I am preparing a "quick" fix (as noted in #19910) for Desk Mess Mirrored; I can include an extra screenshot of two for testing purposes if wanted.

That would be fantastic. 300x225 like screenshot.png. must be screenshot-2.png, -3.png, etc. Let me know once it is live so I can set up the data point.

I should be able to have something later today ... just have to grab a few screens and crop them into the right size.

NB: I'll also note the screenshots in the theme's 'readme.txt' file in a similar fashion as a plugin's 'readme.txt' file re: screenshot description etc.

There is investigation of some ways of making this part of the theme admin enhancements better going on, and we may very well end up with something a bit different from the current track. The UI now isn't beautiful, and the UX kind of sucks. The Jetpack admin screen, with its controlled content, is a sort of best case scenario of this kind of UI and it isn't necessarily perfect, either. Theme/author names and descriptions are not really restricted in terms of length.

Thinking we should reconsider including an inline image slider as a part of the UI - the hover-carousel thing on the larger screenshots in the Chrome Web Store seems like a good inspiration (minus the description slide-in - same issue as above with content length).