Make WordPress Core

Opened 12 years ago

Closed 12 years ago

#21805 closed enhancement (maybelater)

Retina, localized about screen screenshots

Reported by: nacin's profile nacin Owned by: otto42's profile Otto42
Milestone: Priority: low
Severity: normal Version:
Component: Help/About Keywords:
Focuses: Cc:


We need HiDPI screenshots on the About screen for 3.5. In the process, we should serve *all* screenshots from and keep them out of the download package. Additionally, we should allow for these screenshots to be localized by localization teams.

We should implement a endpoint to serve screenshots from Either we hit an API endpoint and get back a list of URLs, or just hit an endpoint directly from an img src, always serving 2x images.

Change History (9)

#1 @nacin
12 years ago

  • Owner set to Otto42
  • Status changed from new to assigned

#2 @Otto42
12 years ago

List of current images in the download (from wp-admin/images/screenshots):


Two options:

  1. Make an API endpoint (api/core/screenshots or api/core/about) to serve up array of screenshot URLs based on passed along localization params. API data could be maintained easily by simply having a static set of file listings on the API server, or have it dynamically built. Either works fine.
  2. Use rewriting to serve them statically based on filename (hit to or, rewrites go to s.wp for the serving of the files) and so on. Rewrite rules would have to be maintained.

Method 1 is more flexible but requires an extra API request to get the URLs. But it means we can build in backward compatibility easily by versioning the API request.

Method 2 is faster and lower on resources, but requires maintenance of the rewrite rules (something that is currently inaccessible to me), and harder to maintain over time. Versioning would need to be in the URL as well, fallback to non-supported localizations, etc.

I'm leaning toward method 1. Objections?

#3 @azaozz
12 years ago

Option 3: include only 2x images in WP. This screen is visited very rarely, using larger images won't make significant difference on network traffic and would remove any need for APIs or maintenance.

#4 @Otto42
12 years ago

Option 3 doesn't account for localization, and it doesn't help to reduce the size of the overall WordPress download.

#5 @azaozz
12 years ago

Right, but is the simplest (no maintenance or API needed). That's how it works at the moment too which has the advantage of working on local networks (no Internet) too.

If we are going to load images from, why not load all of the html / the whole screen? Or update (or make and include that?

Last edited 12 years ago by azaozz (previous) (diff)

#6 @nacin
12 years ago

Unless we are really worried about backward compatibility (and, looking at the public_html on, we keep *everything*), I would do method 2, and would be happy to help.

Two options for implementing method 2:

  1., and serve it. If es_ES doesn't exist, look one level up and serve 3.4/some-image.png (which would be the English ones).
  1., and 302 to the proper image.

I feel like rather hit for four or five screenshots individually, directly from an <img> tag, than with a PHP-side API request. It might just be easier to do an API request (especially since we can then provide links).

#7 @JerrySarcastic
12 years ago

  • Cc fittingsites@… added

#8 @nacin
12 years ago

  • Priority changed from normal to low

#9 @nacin
12 years ago

  • Milestone 3.5 deleted
  • Resolution set to maybelater
  • Status changed from assigned to closed
  • Type changed from task (blessed) to enhancement

The four screenshots for 3.5 are HiDPI by simply serving 2x versions and shrinking them. It adds a bit of space to the download package but I don't think we should be super concerned about that. I think we should leave this to 3.6, and simply bundle it into the same HTTP request as credits.php.

If a specific locale wants to re-do a screenshot in their own language, they can (since we do not have core language packs at this time) just include the file into dist/wp-admin/images/screenshots and we'd include it in their zip. That seems sufficient for now (and was what they've been doing).

So, closing.

Note: See TracTickets for help on using tickets.