wp_get_current_user returns an ID of 0 even if user logged in

@nasgaard,
In Version 3.2.4, that is, the version that you download from WordPress, an unauthorised user can read any published document. (An unauthorised user has user->ID set as 0).

Equally, there is NO logic within this plugin to manipulate the current user information.

It is unclear the nature of the failure that you are having., i.e. cannot see a document that you expect to; or see a document that should be blocked. I have no idea how RCP works. So I cannot really give you any ideas for debugging.

The WPDR plugin is not itself warning of the underlying version. It is a general WordPress warning. As far as I know, there is no issue that changes data access, although the taxonomy counts will be different with V5.7.

Regards,
Neil James

@nwjames Thank you for your response. I have seen two issues which I think have the same fundamental cause. If I mark a document private, I cannot see the document, even if logged in as admin. Using a different plugin that provides access controls, if I restrict access to the document, even if public, it cannot be seen. It thinks I am not logged on.
I have traced it to what I think is a setup issue when the post is being processed. In the second case the plugin adds the filter add_action( ‘template_redirect’, ‘rcp_redirect_from_premium_post’, 999 );. I have instrumented the first few lines of this function

function rcp_redirect_from_premium_post() {
global $rcp_options, $user_ID, $post, $wp_query;
error_log(“In rcp_redirect_from_premium_post. user id is $user_ID, post is :” . print_r($post, TRUE));

When I am attempting to display the document, $user_ID is always 0, therefore the code thinks no-one is logged on. If I observe this with any other post, including other custom post types, it gives me the ID of the logged on user.
As I mentioned, this only occurs in my commercial hosting environment. On a local (RPi) server it works perfectly. I suspect it has something to do with the fact a document is a custom post, but I have no idea why. I was hoping this might jog a memory.

@nasgaard,
Thanks for the update. The key global is $current_user->ID rather than $user_ID. Of course, they both may be set to Zero. However this is the source for the plugin – except fot one occurrence – which ought not to be used!
More than that it is logically the source of the “current_user_can” which is used to determine whether you should have access to the document – as it looks in $current_user to determine the capabilities.
Assuming that that returns zero when you think that you are logged on, then you can use this code (after amendment) to find out where the user is being changed.

<?php
/**
Plugin Name: WP Document Revisions Test
Description: Outputs changes to user.
Version: 1.0.0
Author: Neil James
License: GPL3
 *
@package wp-document-revisions-test
 */

	function dump_set_user() {
		global $current_user;
		print_r('User_id set to :' . $current_user->ID );
		if ( 0 === $current_user->ID ) {
			print_r(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS));
		}
	}

	add_action('set_current_user', 'dump_set_user',);

You can put this into a file called wpdr_test.php, and into mu_plugins or into a directory called wpdt_test and zip it. It can be treated as a plugin and activated/deactivated as wanted.

Note I use my own debug process rather than error_log/print_r so this needs addressing. There aill be quite a lot of output, so good luck.

The action set_current_user is called within wp_set_current_user after current_user is set.

Hope this is of use.
Neil James