Export/Delete personal data lists are empty

Could a moderator please update the title so that we may read it’s GDPR (EN) / GPRD (FR) related ? We’re still stuck at this time and any hint/track would be greatly appreciated. Thanks !

• This reply was modified 6 years, 6 months ago by superflyfr.

We have the same problem.

While debugging seems like WP_Query is not receiving the right post type initiated on method prepare_items() (WP_Privacy_Requests_Table class on wp-admin/includes/user.php).

We are using multisite.

See debug info:
WP_Query Object
(
[query] => Array
(
[post_type] => user_request
[post_name__in] => Array
(
[0] => export_personal_data
)

[posts_per_page] => 20
[offset] => 0
[post_status] => request-confirmed
[s] =>
)

[query_vars] => Array
(
[post_type] => Array
(
[0] => post
[1] => page
[2] => company
)

• This reply was modified 6 years, 6 months ago by luters.martins.

thanks @luthersmartins
indeed, $request_type and $post_type really look weird, defined as ‘INVALID’ …
but might be defaulted as is for unknown reason (WP Core noob here).

/**
 * WP_Privacy_Requests_Table class.
 *
 * @since 4.9.6
 */
abstract class WP_Privacy_Requests_Table extends WP_List_Table {

	/**
	 * Action name for the requests this table will work with. Classes
	 * which inherit from WP_Privacy_Requests_Table should define this.
	 *
	 * Example: 'export_personal_data'.
	 *
	 * @since 4.9.6
	 *
	 * @var string $request_type Name of action.
	 */
	protected $request_type = 'INVALID';

	/**
	 * Post type to be used.
	 *
	 * @since 4.9.6
	 *
	 * @var string $post_type The post type.
	 */
	protected $post_type = 'INVALID';

	/**

• This reply was modified 6 years, 6 months ago by superflyfr.

This is how the generated sql query looks like for confirmed requests:

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_name IN ('export_personal_data') AND wp_posts.post_type IN ('post', 'page', 'company') AND ((wp_posts.post_status = 'request-confirmed')) ORDER BY wp_posts.post_date DESC LIMIT 0, 20

IMHO the post type should be ‘user_request’ instead of ‘post’, ‘page’, ‘company’.

• This reply was modified 6 years, 6 months ago by luters.martins.

We have resolved the problem.

Look for any functions in you theme or plugins that overwrites post types.

We had such hook that allows us to search also post type ‘company’ items:

add_filter( 'pre_get_posts', 'aw_filter_search' );
function aw_filter_search( $query ) {
	if ( ! $query->is_search ) {
		return $query;
	}
	$query->set( 'post_type', array( 'post', 'page', 'company' ) );
	return $query;
}

this clearly overwrites the all the admin side search queries as well.

We amended the hook like this:

add_filter( 'pre_get_posts', 'aw_filter_search' );
function aw_filter_search( $query ) {
	if ( is_admin() || ! $query->is_search ) {
		return $query;
	}
	$query->set( 'post_type', array( 'post', 'page', 'company' ) );
	return $query;
}

Now we have all the users in the lists.

I hope this helps you.

• This reply was modified 6 years, 6 months ago by luters.martins.

Brilliant ! thanks @lutersmartins ??
We did have a search function where we didn’t check if it was a front-office or admin request. Lesson learned & Problem solved: get your next beer in Paris France on me !