Timeline for WP_User_Query unable to retreive all user at once
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 28, 2017 at 12:33 | comment | added | Tom J Nowell♦ |
Also keep in mind if you had 30,000 users and you used -1, you will run into other issues, aside from memory, your database server may not handle the load, especially on shared hosting servers
|
|
| Sep 28, 2017 at 12:32 | history | edited | Tom J Nowell♦ | CC BY-SA 3.0 |
added 854 characters in body
|
| Sep 28, 2017 at 12:26 | comment | added | Tom J Nowell♦ | That won't scale, you should implement it as a WP CLI command ran by a real cron job, or look at mailing lists. Else you'll run into the problem that even if you manage to grab all the users without time or memory problems, you've then got to send 3000 emails, which also takes time. There's also the spam problem that sending so many at once can flag anti-spam measures elsewhere or get you blacklisted. Can you verify that pagination is broken or not broken by instead asking for 2 users? Does it return 2 or does it still return 20? Is it still 20 if you remove the role part of the query? | |
| Sep 28, 2017 at 4:46 | comment | added | Vishal Tanna | Actually my concept is, i have to set cron which will execute weekly every monday morning and will send email to users whose role is 'subscriber'. Now in-order to do so, i have to fetch users with 'subscriber' role. Now as you told that, i have to use parameter like 'number' and 'offset', then also it doesn't work for me. Moreover i had also used "-1" as paged parameter, but then also it is not working for me | |
| Sep 27, 2017 at 13:02 | history | edited | Tom J Nowell♦ | CC BY-SA 3.0 |
added 248 characters in body
|
| Sep 27, 2017 at 12:59 | comment | added | Drupalizeme | Under certain criteria can be different outcomes and this is my point. Telling something is not efficient can be misleading and for that was my comment not to start what and when. Also, my comment was targeted the DB and Network were because at the display part you can choose something like lazy rendering and not actual waiting to the Browser to render everything. | |
| Sep 27, 2017 at 12:47 | comment | added | Tom J Nowell♦ | As for the network, yeah sending all 3k at once is more efficient, but the difference is negligible, micro-optimising, it's the heavy lifting fetching those 3k that's costlier and the latency involved. Sure you might do a little more work fetching them bit by bit, but the users waiting at the other end. It's faster and more scalable to have smaller faster queries than a single larger query | |
| Sep 27, 2017 at 12:46 | comment | added | Tom J Nowell♦ | The displaying part is more to do with WP making subsequent requests for things like user meta as the page gets rendered to HTML. Displaying 3k of anything at a time should be possible if you're the only visitor to the site and the sole occupant of the server, but if you want things to be fast, limit how much you're showing, and be smarter about it. | |
| Sep 27, 2017 at 12:30 | comment | added | Drupalizeme | The Efficient part is not on point. It hides a lot of information to be considered as a valid point. For example, you can choose to retrieve 3000 entries and after that, you can choose to display it as a chank or directly. From Db and Network point of view, it is far better to retrieve this small number than making multiple requests. | |
| Sep 27, 2017 at 12:13 | history | answered | Tom J Nowell♦ | CC BY-SA 3.0 |