WordPress.org

Making WordPress.org

Opened 5 years ago

Last modified 22 months ago

#613 new enhancement

JSON output/endpoint(s) for profiles.wordpress.org

Reported by: stephdau Owned by:
Milestone: Priority: normal
Component: Profiles Keywords:
Cc:

Description

Some co-workers and I are currently working on a project that would like to pull some profile data about WP developers from profiles.wordpress.org, which we currently have no means to do as a 3rd-party service (besides screen scraping).

I had a brief chat with Nacin about my volunteering to [help] make a JSON endpoint to get an individual developer's data by passing it a dev's WP.org username, and he was in favor of it, so here is my humble proposal and related questions. :)

Endpoint location (will define how it is written, bbpress vs BuddyPress):

  • should this live under api.wordpress.org, as the theme, plugins, etc APIs, which I understand is bbpress and custom?
  • or should it live under profiles.wordpress.org (be it a route or query string param), which would likely involve a small BuddyPress plugin instead?

My preference would be under api.wordpress.org:

  • for general API consistency (they all live there)
  • to start with single dev output, but then be able to have a query interface as well (as is done for plugins, themes, etc).
  • despite the fact I'd rather write a WP/BuddyPress plugin ;)
  • I thought oembed would be neat, but it binds us to a standard schema that's not that useful for us versus the one I'll list below. Still something we could do (embed profile), but unlikely to be right for this project.

Original/default schema for the initial version:

  • User editable data: display name, member since, etc.
  • "Find me on" info (Gravatar verified services)
  • Badges (plugin developer, etc).
  • Time-based Sums from the other tabs (number of plugins, themes, comments, plugin commits, etc) in the last 1, 3 and 12 months (I currently have no clear concept of how heavy/bad those queries would have to be as I've not yet seen the backend for it).
  • MD5 hash of email, aka Gravatar slug: this would let us easily verify if a person who on our end says they're such and such developer are indeed who they say they are (we'll have their email, and expect it to match the ones they used in their WP profile, as the latter does in regards to it being a Gravatar email).

I'm tagging this as "needs patch", but I'll of course provide the latter, once I have answers to the above questions. :)

Change History (15)

#1 @nacin
5 years ago

I would just make it respond to http://profiles.wordpress.org/nacin.json.

There are exactly 2 user_logins that end in .json, and those will redirect to their user_nicename equivalents (old code to support when BuddyPress used to use user_logins in URLs for unknown reasons). So as long as the hook to serve application/json happens after that potential redirect, then you should be fine.

#2 @Otto42
5 years ago

Stuff on api.w is mostly used for talking to and supporting the WordPress core. Not that that is a requirement, but I'd probably put it on profiles.w.org instead. It's already running BuddyPress and has all the data you'd need there to serve it in whatever form you wanted. As a plugin it would probably be simpler to manage and maintain.

URL format = dealer's choice. Nacin's method is sound, but I'd probably want something more explicit if I were doing it. ?format=json or some such thing. Of course, both with a rewrite is an option as well.

#3 follow-up: @stephdau
5 years ago

Works for me. Thanks for the feedback!

Also: MD5 hash of email: I just had a duh moment... Let's just make that field their Gravatar URL (currently displayed on front end), which will contains said hash (and be a grav :) ).

#4 in reply to: ↑ 3 @nacin
5 years ago

Replying to stephdau:

Works for me. Thanks for the feedback!

Also: MD5 hash of email: I just had a duh moment... Let's just make that field their Gravatar URL (currently displayed on front end), which will contains said hash (and be a grav :) ).

There's a wrinkle here, technically — http://www.gravatar.com versus https://secure.gravatar.com. You could pick one based on whether the request (which presumably would support JSONP and also have Access-Control-Allow-Origin: *, for the purposes of JS use) is over SSL or not. Also note that "subdomain" could be www, 0, 1, etc. Core actually does toggle between 0 and 1, but that's likely not necessary here. Barry's preference is 0 over www. (Also note, sharding should not be used for SSL requests as the handshake is slower.)

I just dealt with this for the plugins info endpoint but it should be a little easier as here you're not also trying to determine whether the admin is over SSL (not just the request).

#5 @stephdau
5 years ago

Nacin: Totally.

FYI: timeline: went through all of the thought process with my team this week, got a lot of feedback in person (Paul Gibbs, etc), and will produce the patch next week (traveling intensively this week).

This ticket was mentioned in Slack in #community by georgestephanis. View the logs.


5 years ago

#7 @markoheijnen
5 years ago

I did build something myself a few months ago what does screen scrapping and a bit more. See http://wpcentral.io/api/contributors/markoheijnen for an example.

#8 @swissspidy
4 years ago

  • Cc hello@… added

I used screen scraping for WP Talents too and it's a pain. Especially since there's no way to fetch all activity entries of a user. WP Talents has an API on its own and even supports oEmbed. The code I use lives here: https://github.com/swissspidy/wptalents

Let me know I can help building a JSON API for this. What about building upon WP-API? Or is it unlikely to be activated on w.org anytime soon?

I've been dreaming of a "Log in using WordPress.org" button lately, but I doubt w.org will support oAuth in the future...

#9 @SergeyBiryukov
4 years ago

  • Keywords needs-patch removed

Removing 'needs-patch' from components that are not open sourced yet, to help focus on tickets that actually need a patch.

This ticket was mentioned in Slack in #meta by iandunn. View the logs.


3 years ago

This ticket was mentioned in Slack in #meta by sam. View the logs.


3 years ago

#12 @ocean90
3 years ago

#1736 was marked as a duplicate.

#13 @ocean90
3 years ago

#1737 was marked as a duplicate.

#14 @Compute
3 years ago

+1 for this.

Any update on this? Or how to help this ticket going forward?

Last edited 3 years ago by Compute (previous) (diff)

This ticket was mentioned in Slack in #meta by sergey. View the logs.


22 months ago

Note: See TracTickets for help on using tickets.