Notice: Undefined property: stdClass::$uid in user_access()

Hi @vibrasphere

I am trying to generate the issue in Drupal 7 as mentioned module version but not able to replicate the issue. Could you please let us know if we need to enable the other module also together with the User revision.

I'm not sure.

addressfield
addressfield_phone
adminimal_admin_menu
admin_menu
admin_views
autologout
backup_migrate
better_exposed_filters
block_class
captcha
ckeditor
colorbox
commerce
commerce_extra_tokens
commerce_license
commerce_option
commerce_paypal
commerce_pricing_attributes
commerce_product_attributes
commerce_registration
commerce_rules_extra
conditional_fields
content_access
css_injector
ctools
custom
customer_profile_type_ui
date
email_registration
entity
entity_bundle_plugin
entityreference
extlink
feeds
feeds_xls
field_collection
field_group
field_permissions
filefield_paths
filefield_sources
filefield_sources_plupload
flexslider
fontawesome
fontyourface
globalredirect
iframe
imagecache_token
imagefield_tokens
imce
imce_copylink
imce_mkdir
job_scheduler
jquery_update
js_injector
judy
libraries
link
log_filter
mailsystem
menu_attributes
menu_editor
menu_per_role
menu_token
mimemail
nocurrent_pass
nodeaccess
opengraph_meta
panels
paranoia
path2ban
pathauto
pathologic
plupload
README.txt
realname
recaptcha
redirect
registration
registration_commerce
responsive_menus
rules
schema_metatag
security_review
select_or_other
shield
smart_ip_ban
special_menu_items
stringoverrides
superfish
tabtamer
token
token_filter
total_control
transliteration
userone
userprotect
user_revision
uuid
views
views_bulk_operations
views_data_export
views_export_xls
views_fieldsets
views_rules
webform
webform_validation
weight
xmlsitemap
youtube

Tried enabling the module in another site and got fatal error/WSOD.

Disabled the module via drush and it got fixed.

Checked dblog:
Error: Attempt to assign property "logged_in_user" on bool in ctools_context_create_user() (line 46 of/sites/all/modules/ctools/plugins/contexts/user.inc).

The clue here is ctools_context_create_user(), which must be being invoked by one of your modules. It appears from the code that it is failing to load a user object, but very hard to see why and what the conflict with user-revision might be.

Have you any idea which module is using ctools in this way? I'm no expert on all the magic things that ctools can do, but if we can work out what's invoking it, it could provide more clues as to what's happening.

The ctools error I get is same as here https://www.drupal.org/project/user_revision/issues/3416827 🐛 Notice: Undefined property: stdClass::$uid in user_access() Active except mine says line 65, but not sure if this is any related. My error triggers when enabling the User Revision and not when visiting as anonymous, so not sure if related.

Notice: Undefined property: stdClass::$uid in ctools_context_create_user() (line 65 of /sites/all/modules/ctools/plugins/contexts/user.inc).

Also when enabling User Revision there's a message at the top 537 records were added to {user_revision} table. Does that mean there's 537 users? There's one revision table created for each?

So far I'm trying to track down the errors by disabling modules one-by-one.

Okay I think I was able to reproduce it, not sure why or how it's related to User Revision, but there it is:

Reproduce:
1. Install fresh Drupal 7
2. Enable CTools
3. Enable Total Control → (stable 2.4)
4. Enable User Revision
5. Check dblog for errors

All the listed user and ctools errors above happen only when enabling User Revision with Total Control already enabled. When enabling any other module errors do not appear.

No idea how this is related, because Total Control is only a Dashboard module?

Okay I drilled it down further:

1. Go to admin/structure/pages
2. Disable Total Control administrative dashboard
3. Enable User revision: no errors
4. Disable and uninstall User revision
5. Enable back Total Control administrative dashboard
6. Enable User Revision: all the errors appear.

The possible root cause:

If you go and edit the Total Control administrative dashboard under Access tab at admin/structure/pages/nojs/operation/page-dashboard/settings/access and simply delete the Logged in user has "Have total control" and enable the User Revision, there are no errors.

I tested it by readding that Access rule and enabling User Revision and all the errors re-appear.

So I guess this is it. But I still do not understand how or why these two are related.

Current temporary fix is to either delete that Access rule for Total Control or completely disable/uninstall Total Control module, just to install User Revision without any errors.

You've clearly found the module conflict. I don't know anything about how Total Control works, I've never used it.

I'm not quite clear if the conflict is permanent, or just causes a problem with order of installation. If you install User Revision first, then Total Control, do you still get errors?

Is Total Control usable after deleting the access rule? If so, then the workround is simply to remove the access rule.

I suspect this is something to do with the anonymous user. The update to 7.x.2.1 was to add a blank revision record for user 0, because of something only Drush appears to do (I think it was calling user_load(0) instead of drupal_anonymous_user()). Total Control may be doing something else unconventional.

Yes, the current workaround is to remove the Access rule for Total Control to be able to install and use User Revision together with Total Control with no errors.

If you install User Revision first there are no errors, but really can't do that on existing production website, where Total Control already fully set up and running.

Just saying, there's weird conflict between these two modules, because none of the errors are reported when enabling any other module, only with User Revision.

Sure, I get that it's a conflict that shouldn't exist, and that User Revision looks like the culprit. I just want to be absolutely clear exactly where the conflict does and doesn't occur.

In your last message you implied that installing UR first, then TC, that there were no errors. Is that actually the case, that the site is usable without removing the access rule? That would be quite strange if so!

But if it is true, what happens if you install TC, then disable (but not uninstall) it. then install UR, then re-enable TC?

Sorry to be picky, but will really help pin down the problem.

Yes your scenario works too. But only on fresh D7 install. I can't do it on production.