-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WP_CLI create-guest-authors creates profiles for ALL users #553
Comments
@smistephen Do you want to take a look? |
The offending line of code seems to be https://github.com/Automattic/Co-Authors-Plus/blob/master/php/class-wp-cli.php#L28, which just plucks out My proposed solution is to simply whitelist the roles that get profiles created for them. We could do this via changing the args to
We could also do the processing on the back-end, like this:
Tomorrow, I'll generate a bunch of users and pit the two against each other. I'll probably just write a bash script to call |
Alright, faceoff time. First step, generate 1000 authors.
Backup the database so we can restore it and run the test again with different code.
First up is changing the
Not bad. Now let's restore the database:
Revert our first change, institute our second, and run it again:
Welp. Hey, there's a saying in science: "Any result's a result." Clearly, either one would be fine. And in those cases, I choose the one-liner that uses the WordPress API over the complicated custom algo every time. Next up: implementing the victorious approach, and testing the heck out of it. |
…ommand. Previously, as noted in Automattic#553, `wp co-authors-plus create-guest-authors` created a guest author for every user in the database. This was a massive performance suck, as well as being largely unnecessary. Adding a subscriber as a guest author is not a common use case. Now, only users having the role of administrator, editor, and author have guest authors generated for them. The query to filter users by role is a touch heavy (it performs LIKEs on meta values), but testing it on a site with 1000 users showed no major issues. It was also compared to simply querying all the users, and doing the filtering in PHP. Head to head, there was no significant difference in performance between the two approaches, and using the WordPress API is always a better bet than writing your own one-off custom filter algorithm.
How are users which are subscribers handled? Some sites can have thousands (or hundreds of thousands) of subscribers. Does it impact the two different methods? |
By default, subscribers are excluded, but can be included if the end user wants. I re-ran the faceoff with 5000 subscribers included, and still saw no significant difference in the run times. It appears that any difference between the two methods of filtering is by far drowned out by the time it takes to process the result. |
How would this work on a multisite? |
Perhaps we could ban them from generating guest authors for subscribers? |
They could still do it manually, in the rare case they wanted to make a subscriber a guest author, but they wouldn't be able to do it en masse. |
I've added some code to that effect: #575 |
While creating the guest authors for subscribers might be a problem, I'm concerned about how the SQL query against the DB would be with a join and a LIKE against an unindexed field on tables with 100K-100M rows |
I share your concern, and I think I've come up with a way to bridge the gap between the two approaches. The problem with the database query is that it has the potential to put tremendous strain on the database server. The problem with back-end processing is that it has the potential to put tremendous strain on that server (fetching an array with ten million elements would blow out most servers). The solution? Combine a simple database query with batched back-end user processing. Rather than 1 enormous query, or 1 monolithic array, we make 10,000 tiny queries for 1000 users each, and filter them as we go. The code I just pushed to #575 should scale much better, though nothing will make processing ten million rows "fast", haha. |
wp co-authors-plus create-guest-authors
will create guest authors profiles for all WP users, including subscribers, which we wouldn't want to ever add as coauthors, and uselessly pollutes the database.The text was updated successfully, but these errors were encountered: