luters.martins

Hello Pardot,

I am experiencing the same problem with Salesforce SSO authentication on subdirectory site of a Multisite env.

Thanks

We are experiencing the same problem. It happens when we are using post_updated action hook to detect wprss_feed post update and within the callback method in a certain case we call wp_update_post to update another custom post type’s post. On that moment we are getting the error, however, behind the scenes wp_update_post does update a post.

WP RSS Aggregator v4.17.10
WP core v5.6

PHP Fatal error:  Uncaught OutOfRangeException: Post "66048" was not found in /wp-content/plugins/wp-rss-aggregator/src/Entities/Collections/WpEntityCollection.php:128
Stack trace:
#0 /wp-content/plugins/wp-rss-aggregator/src/Entities/Collections/WpEntityCollection.php(111): RebelCode\Wpra\Core\Entities\Collections\WpEntityCollection->get(66048)
#1 /wp-content/plugins/wp-rss-aggregator/src/Handlers/FeedSources/FeedSourceSaveMetaHandler.php(88): RebelCode\Wpra\Core\Entities\Collections\WpEntityCollection->offsetGet(66048)
#2 /wp-includes/class-wp-hook.php(289): RebelCode\Wpra\Core\Handlers\FeedSources\FeedSourceSaveMetaHandler->__invoke(66048, Object(WP_Post))
#3 /wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(NULL, Array)
#4 /wp-includes/plugin.php(484): WP_Hook->do_action(Array)
#5 /wp-includes/post.php(4 in /wp-content/plugins/wp-rss-aggregator/src/Entities/Collections/WpEntityCollection.php on line 128

• This reply was modified 3 years, 10 months ago by luters.martins. Reason: providing version numbers
• This reply was modified 3 years, 10 months ago by luters.martins.

+1
Should be a fairly quick fix.

Use “ssh -o ServerAliveInterval=30 [email protected]” to connect on WP Engine to keep alive the connection.

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.

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 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.