Opened 3 years ago

Last modified 2 years ago

#14757 reopened enhancement

users with no posts are not exported

Reported by: sillybean Owned by:
Priority: normal Milestone: Awaiting Review
Component: Export Version: 3.0.1
Severity: normal Keywords: 2nd-opinion needs-patch
Cc: steph@…

Description

I just exported a large standalone site and imported into a multisite setup, and I discovered that a number of users who hadn't yet posted anything didn't get moved to the new site.

Attachments (3)

14757.diff (2.0 KB) - added by logiclord 2 years ago.
Users with the ability to edit posts and above can be exported
14757.2.diff (1.8 KB) - added by logiclord 2 years ago.
Blog id added and !=0 used
14757.3.diff (1.9 KB) - added by logiclord 2 years ago.
specific capability test. Still needs testing.

Download all attachments as: .zip

Change History (12)

comment:1 follow-up: ↓ 2   duck_3 years ago

  • Keywords 2nd-opinion added

The arguments against would be that you could potentially be creating a massive export file with all the users and that WXR export files are "not intended to serve as a complete backup of your site".

Though I suppose only users with edit_posts capability and above could be exported or something.

comment:2 in reply to: ↑ 1   nacin2 years ago

Replying to duck_:

Though I suppose only users with edit_posts capability and above could be exported or something.

That seems like a good idea.

  • Type changed from defect (bug) to enhancement

Users with the ability to edit posts and above can be exported

all changes to be made in wp-admin/includes/export.php .
We can also specify selective users as mentioned in diff file.

  • Resolution set to fixed
  • Status changed from new to closed
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Keywords has-patch added
  • Keywords needs-patch added; has-patch removed

This patch isn't scalable and doesn't use the API properly.

Querying all user IDs in a multisite instance might result in thousands (or millions) of users to loop through. That's a lot of queries. What we could do instead is join the usermeta table and fetch users that are specifically assigned to this blog. (And at that point, we'd probably just use get_users() with a blog ID.)

The logic is also flawed -- we can't make assumptions based on roles. We'd instead need to run user_can() for each user -- which is pretty expensive for so many users. Will take too much memory. The goal here would be one of two things: export any user with a user level <> 0, or export any user tied to the blog in general (including subscribers). If our goal is to include users in export files for now on, then this seems reasonable (except where limited by just too many users).

It should be noted that user level <> 0 is a hack -- normally, we can only check capabilities. Not role names, not user levels. Just when using the API for future patches.

Re user level <> 0: #16714

Blog id added and !=0 used

specific capability test. Still needs testing.

Note: See TracTickets for help on using tickets.