Add: Plugin Icon URL API / service

[enej]

Howdy

I would like to be able to do the following. Have a URL that returns the plugin icon or the svg.

So that I can do something like
<img src="​https://api.wordpress.org/plugins/icon/1.0/?slug=jetpack&size=256&default_icon=http://example.com/default-icon.png" width="256" />

Does something like that exits?

Right now the plugin icon urls live on the following url.
​https://ps.w.org/jetpack/assets/icon-256x256.png?rev=969908

And in order to get that information you need to a call to the .org plugin api. Which is fine but it requires 2 trips to the .org servers. One to the api and another for the image.

I would be happy to contribute a patch if you point me in the right direction.

Thanks Meta team!

[Ipstenu]

What are you trying to do with the image?

[Otto42]

No, because we ask that you please do not use our servers by hotlinking to resources like this. The w.org CDN is something we actually have to pay for, along with all the other bandwidth we use, which is a considerable amount. If you need the icon, download it and host it on your own bandwidth.

Only wordpress.org and related properties should be directly linking to our resources. Thanks for the consideration.

[enej]

What are you trying to do with the image?

I am trying to add a predictable url that points to the icon to the WordPress.com plugins api.
So that we don't have to fetch the api for each of the plugins before we can display the plugin icon to the user.

We are planning to use the new api endpoint in the mobile apps as well as improve calypso.

Hi @Otto42
If the issue is hotlinking we could pass the images to Photon but as far as I know Photon doesn't support SVG files yet.

[Otto42]

The rev number is there as a cache-buster. That's the only reason for it. So, you could leave that out of it if doesn't need to be real time. But really, if this is an offical project needing it, then it would be helpful to say that in advance.

[dd32]

As a side-mention, the auto-generated plugin icons are inline/base64 SVG and are not available as a URL anywhere (ie. there isn't a "static"/cached-php-response SVG available)

I guess the default_icon parameter provided in the ticket here is to somewhat address that, however in reality it shouldn't be needed IMHO? Or is that included for when a plugin slug which doesn't exist is passed.

For a reference as to what I'm talking about, see the icons here:
​https://wordpress.org/plugins/author/wordpressdotorg/

In the ​https://api.wordpress.org/plugins/info/1.1/?action=plugin_information&request[slug=admin-color-schemer&request[fields]=icons API we provide it as a large data: uri blob] which should work the same in most places, however might be an issue for usage within mobile apps/etc.

[enej]

I guess the default_icon parameter provided in the ticket here is to somewhat address that, however in reality it shouldn't be needed IMHO? Or is that included for when a plugin slug which doesn't exist is passed.

It exists for plugin slugs when a plugin that doesn't exist is passed.
But if for security reasons we would want to display a default icon (SVG) instead of redirecting to a url I think that would probably work as well.

Where can I find the code that generates the .org plugin api? I couldn't find it in ​https://github.com/WordPress/meta-environment or ​git://meta.git.wordpress.org/ git repos.

[dd32]

Replying to enej:

I guess the default_icon parameter provided in the ticket here is to somewhat address that, however in reality it shouldn't be needed IMHO? Or is that included for when a plugin slug which doesn't exist is passed.

It exists for plugin slugs when a plugin that doesn't exist is passed.

Hm, I guess that's a valid case when you're looking at it from a non-WordPress perspective, however I don't personally think that's something that would need supporting

Where can I find the code that generates the .org plugin api? I couldn't find it in ​https://github.com/WordPress/meta-environment or ​git://meta.git.wordpress.org/ git repos.

Not all of the connector is available, but all the source for it is contained within:
https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory

[dd32]

I'm going to close this one as a wontfix - the only use-case for it appears to have been worked around in a different manner, and I don't expect that this is a hugely common occurrence elsewhere.

The icons are used within core too, but it gets the icons from the plugins update api.