Making WordPress.org

Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#6313 closed defect (bug) (fixed)

Users API endpoint is not returng all the users available

Reported by: krysal's profile krysal Owned by: dd32's profile dd32
Milestone: Priority: high
Component: Photo Directory Keywords:
Cc:

Description

At the moment of writing this ticket, the API is only returning seven users, leaving out a lot of others; for example, Roy Tanck is not included.

This endpoint is used in Openverse: https://wordpress.org/photos/wp-json/wp/v2/users

Change History (5)

#1 @dd32
3 years ago

  • Owner set to dd32
  • Status changed from new to accepted

This is the expected behaviour for how the wp/users endpoint works, and will not list users on the majority of WordPress.org sites that have user assets.

This endpoint is available though: https://wordpress.org/photos/wp-json/wporg/v1/users/roytanck

I'm assuming that the reason this is an issue for you, is that you're using https://wordpress.org/photos/wp-json/wp/v2/photos and following the author embed? (especially given it doesn't output the user slug)

It seems like we should be automatically changing those non-accessible endpoints, see incoming PR.

#2 follow-up: @krysal
3 years ago

Thanks for the information about the endpoint and for addressing this so quickly, @dd32!

What is the difference between the shown and hidden users in https://wordpress.org/photos/wp-json/wp/v2/users? It's still unclear to me.

I'm assuming that the reason this is an issue for you, is that you're using https://wordpress.org/photos/wp-json/wp/v2/photos and following the author embed?

That's indeed the case, we are trying to get the user for the images but as most links are invalid, they aren't shown on the image details page (example, normally it would be just below the image's title) and they will not be properly credited.

The script for the photo directory will need some small changes if only the https://wordpress.org/photos/wp-json/wp/v2/photos endpoint is changing but we can work with it, and would be a huge improvement.

#3 in reply to: ↑ 2 @dd32
3 years ago

Replying to krysal:

What is the difference between the shown and hidden users in https://wordpress.org/photos/wp-json/wp/v2/users? It's still unclear to me.

In short:

  • The WordPress user endpoint is only published authors, able to list all published authors, and has edit functionality, and is only accessible via user ID
  • The WPORG user endpoint is all users, non-listable, by user-slug only, and not possible to be used to edit users.

The Content of the endpoints should be close enough to the same for you not to notice the difference.

The script for the photo directory will need some small changes if only the https://wordpress.org/photos/wp-json/wp/v2/photos endpoint is changing but we can work with it, and would be a huge improvement.

The endpoint itself shouldn't change too much, instead of

"author": [
        {
          "embeddable": true,
          "href": "https://wordpress.org/photos/wp-json/wp/v2/users/148148"
        }
      ]

you'll see

"author": [
        {
          "embeddable": true,
          "href": "https://wordpress.org/photos/wp-json/wporg/v1/users/dd32"
        }
      ]

And when you request the photos URL with ?_embed=true you'll see that author response embedded into the same request, rather than having to make the second request.

we are trying to get the user for the images but as most links are invalid, they aren't shown on the image details page

Is that just related to the author? Or are you seeing other invalid links?

A quick glance at Openverse does show that the source-URLs you're using are lacking the trailing slash, but they should be present / looks like they're present in the API.

#4 @dd32
3 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

I've deployed this change now.

eg:

curl -s 'https://wordpress.org/photos/wp-json/wp/v2/photos?_embed=true' | jq '.[] | { url: .link, author: ._embedded.author[0].name, caption: ._embedded."wp:featuredmedia"[0].caption.rendered }'

{
  "url": "https://wordpress.org/photos/photo/843627f92d/",
  "author": "webmariage",
  "caption": "<p>Unnamed</p>\n"
}
{
  "url": "https://wordpress.org/photos/photo/391627f35a/",
  "author": "Hideaki Sekine",
  "caption": "<p>KASHIMOCHI</p>\n"
}
{
  "url": "https://wordpress.org/photos/photo/203627f31f/",
  "author": "Shusei Toda",
  "caption": "<p>Coffee Bean with bags</p>\n"
}
{
  "url": "https://wordpress.org/photos/photo/116627eb3f/",
  "author": "Pravin Parmar",
  "caption": "<p>Green Leaf</p>\n"
}
{
  "url": "https://wordpress.org/photos/photo/296627e728/",
  "author": "systxema",
  "caption": "<p>Piedras en el mar. Ocean rocks. Agua. Playa. Water. Beach.</p>\n"
}
{
  "url": "https://wordpress.org/photos/photo/739627e52d/",
  "author": "Courtney Robertson",
  "caption": "<p>white mushrooms on tree</p>\n"
}
{
  "url": "https://wordpress.org/photos/photo/337627e529/",
  "author": "Courtney Robertson",
  "caption": "<p>apple blossoms</p>\n"
}
{
  "url": "https://wordpress.org/photos/photo/348627e523/",
  "author": "Courtney Robertson",
  "caption": "<p>autumn leaves</p>\n"
}
{
  "url": "https://wordpress.org/photos/photo/36627d204a/",
  "author": "Suresh Shinde",
  "caption": "<p>Pink Chafa</p>\n"
}
{
  "url": "https://wordpress.org/photos/photo/111627d1ee/",
  "author": "Suresh Shinde",
  "caption": "<p>Savitribai Phule, Pune University</p>\n"
}

#5 @krysal
3 years ago

when you request the photos URL with ?_embed=true you'll see that author response embedded into the same request, rather than having to make the second request.

That is suuuuuch an important detail, I didn't know about it, thank you for sharing! It will save tons of requests and speed up the script.

Is that just related to the author? Or are you seeing other invalid links?

Yes, it was just with the author.

A quick glance at Openverse does show that the source-URLs you're using are lacking the trailing slash, but they should be present / looks like they're present in the API.

It does have the trailing slash when receiving the response, we are erroneously removing it when saving. I'll investigate that further, thank you for pointing it out.

Note: See TracTickets for help on using tickets.