Conflicts with Drush

It's weird that editing a user triggers an error in views!

Is this the first time user-revision has been installed on this site? I had a lot of problems when I first tried 7.x-1.x, and did extensive work on it, the results of which became 7.x-2.x.

Could you try the later version and report results?

Sorry, tagged wrong version, I meant 7.x-2.x, both stable and dev.

It's very hard to see what's going on here.

Leaving aside why anything would be invoking views in the first place, the function in views_handler_field_entity could only be invoked via a sub-class, but nothing in user_revision extends this class either directly or indirectly. It's only extended by node and comment.

You say you have a custom text field in your account settings (I also have several which don't cause a problem), but do you by any chance also have an entity-reference custom field? That's the only route I can think that the code reporting the error could be called. Even so it's somewhat bizarre.

Yes there is entity reference field referring to a node. But it's the 'Simple' entity selection and not a 'View' one.

Could you try removing that entity reference field and see what happens? I'm scrabbling in the dark a bit, so anything's worth trying.

Problem still persists without entity reference field. No user page can be opened or edited, same error on dblog.

urgh. Is there anything relevant in dblog (after disabling user-revision), or in the system error.log?

Could you also check the database? in the users table there should be additional columns vid & ip, with vid initialised to the same value as the uid. There should also be a user_revision table, with values initialised as copies of the users table entries.

Thanks

With User Revision enabled:

Databas tables:

When trying to open or edit any user page:

Nothing else in dblog, besides 404 reports for user pages and nothing on nginx error.log

Also I just noticed that Views error I posted earlier it refers to a node that has entity reference of a user. So I don't know if it's related.

But if you try to update that entity reference (by e.g. selecting any user) with User Revision enabled:

The only way I can see that user-revision affects opening a user record for editing is that it adds hooks into the entity controller for the user account (the hook is pretty trivial though). If the entity controller fails to load the user object then 404 would be the result. But why it's doing this in your installation and nowhere else is a mystery.

It may be a conflict with another module, or some specific configuration. Would it be possible to do another clean Drupal install, and then install user-revision as the first additional module?

User Revisions installs and works on new clean Drupal 7 install. BUT, it still breaks drush:

dev@dev /var/www/example.com/htdocs # drush status
Could not login with user ID 0. This is typically caused by importing a MySQL database dump from a faulty tool which re-numbered the anonymous user ID in the users   [error]

Ah, that's some progress. I can't test the drush issue directly as I don't use it.

However I've noticed that user-revision doesn't create a row in its table for user 0. There's not really a need as it's a pseudo-user and can't be updated anyway. I think this means that user_load(0) will fail, but Drupal itself never does that (perhaps drush does). You can make it happen using the URL user/0. This gives me Drupal's page-not-found (though not a system 404 error).

I then manually added a row to the user_revision table with uid & vid equal to 0, other columns empty (or null defaults). URL user/0 now gives access-denied.

Perhaps this is the problem, is a module you're using calling user_load(0) and not recovering from the error?

Could you try manually adding a uid = vid = 0 row to the user_revision table? Try it on both your installations.

I don't really work with databases so I'm not sure were we're even going with this.

Is this still about drush on clean install or previous old install with many modules? Drush is not a module, it's CLI shell-based scripting tool.

How could I tell what module is calling user_load(0)?

I know about Drush, but I've never found a need for it, and it now appears to need Composer to install even on D7, which I don't use either!

If my hunch is right it would affect Drush, as well as some module you're using on your older install. Finding which module is best done by installing them one at a time until you find the one that breaks the site.

Re databases do you have access to PhpMyAdmin or similar? That allows you to dive into the database tables.

If not I can do a patch to user_revision.install, which will allow update.php to add the row to the table. It might take a day or two for me to sort that out.

My new priority would be to make it work with Drush first, because that's huge deal breaker. We run Drush on every website.

This is first time in 11+ years of Drupal and Drush I run into module that somehow breaks Drush.

https://www.drupal.org/project/issues/user_revision?text=drush&status=All →

hmm interesting one from 12 years ago
https://www.drupal.org/project/user_revision/issues/1053398 →

Indeed interesting, and waay before I started working on this module. I'll have a look at the source history, somehow that patch must have got lost. At least it confirms my analysis.

I should be able to complete a patch tomorrow. Are you OK applying patch files?

I'm familiar with the basics.

Please attach the patch and I will try to apply it.

And thanks.

The attached patch will add an update to the .install file. After applying it, as admin run the update.php URL. This should run an update for the module which will add the missing record.

Hopefully Drush will then work!

Looking back through the source history, I think the damage was done over 3 years ago in #2424671: User revision does not install on PostgreSQL → , a patch that was RTBC and I then committed when I first started using user-revision, before deciding to create the v2 branch. The whole install logic with the database was a bit of a mess at that time.

Hi, patch applies cleanly.

curl https://www.drupal.org/files/issues/2023-06-21/user_revision-breaks_drush-3367385-20.patch | git apply -v
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   891  100   891    0     0   4367      0 --:--:-- --:--:-- --:--:--  4367
Checking patch user_revision.install...
Applied patch user_revision.install cleanly.

1. Enable the module `drush en user_revision -y`
2. Run `drush updatedb` or/and update.php both yeld `No pending updates.`.

3. Run simple drush command e.g. `drush status`:

Could not login with user ID 0. This is typically caused by importing a MySQL database dump from a faulty tool which re-numbered the anonymous user ID in the   [error]
users table. See http://drupal.org/node/1029506 for help recovering from this situation.

4. Disable module User Revision, Drush problem solves and it works again.

I don't understand why it says "no pending updates", but because of that it hasn't performed the update to add the missing record.

According to a quick web search you should be able to check the current schema version of the module as below - it shouldn't need to be enabled to do it.

drush ev "var_dump(drupal_get_installed_schema_version('user_version'))"

It was 7002, after applying the update it should be 7003. If it's still 7002 then update.php should see that the update needs to be run. Clearing cache might help.

With User Revision module installed running drush ev "var_dump(drupal_get_installed_schema_version('user_version'))" gives same error as previous:

Could not login with user ID 0. This is typically caused by importing a MySQL database dump from a faulty tool which re-numbered the anonymous user ID in the   [error]
users table. See http://drupal.org/node/1029506 for help recovering from this situation.

With User Revision disabled it gives:

WD php: Error: Call to undefined function drupal_get_installed_schema_version() in eval() (line 1 of                                                            [error]
/var/www/example.com/composer/vendor/drush/drush/commands/core/core.drush.inc(1178) : eval()'d code).
Error: Call to undefined function drupal_get_installed_schema_version() in eval() (line 1 of /var/www/example.com/composer/vendor/drush/drush/commands/core/core.drush.inc(1178) : eval()'d code).
Drush command terminated abnormally due to an unrecoverable error.

This is on clean fresh install.

Drush version 8.4.12, PHP 7.4.

I think that snippet was for a later Drush for D8, seems there's a different Drush version for every version of Drupal.

After poking around, here's some other commands that should do the same thing:

drush eval "drupal_get_installed_schema_version('user_version');"
or maybe:
drush eval "print drupal_get_installed_schema_version('user_version');"
(I'm not sure if Drush by default outputs the result of an evaluated function.)

Some examples use php-eval instead of eval, I don't know the significance of the difference.

Or if that fails, Drush can do a direct SQL query:
drush sql-query "SELECT schema_version FROM system WHERE name = 'user_revision'"

I just need to know what schema version the system thinks it has for user_revision.

# drush cc all
'all' cache was cleared.                                                                                                                                        [success]
# drush updatedb
No database updates required                                                                                                                                    [success]
# drush sql-query "SELECT schema_version FROM system WHERE name = 'user_revision'"
7003

OK, so it thinks it's done the update. Maybe that's a result of enabling the module after updating the .install file, I'm not sure what Drupal does in that situation.

I'd like to check if the missing record has actually been created. Please run:
drush sql-query "SELECT * FROM user_revision WHERE uid = 0"
You should get a record, with all empty or 0 values. In particular, uid & vid (the first two values) should both be 0.

If you get no result then the update hasn't worked for some reason, so please run the following to create the record:
drush sql-query "INSERT INTO user_revision (uid, log) VALUES (0, '')"
drush sql-query "UPDATE user_revision SET vid = 0 WHERE uid = 0"

Following this you can re-run the select query, which should return the record.

I'm about to go out, so I may not be able to follow up now until tomorrow. Hope you get some success!

All commands gave me empty lines with no results, but it did fix drush? Drush now running fine with User Revision enabled.

But I still get Page not found when trying to open or edit any user profile.

Also drush ev "var_dump(drupal_get_installed_schema_version('user_version'))" now worked only once and gave int(-1), but doesn't work anymore and gives previous errors.

RE #26:

OK, so it thinks it's done the update. Maybe that's a result of enabling the module after updating the .install file, I'm not sure what Drupal does in that situation.

When you install a module from scratch, Drupal trusts hook_install does everything that's necessary, and sets the latest schema version to the latest update hook. It doesn't run any existing update hooks. You'll probably need to create that row in hook_install as well.

We decided to move on, we get this error/issue on multiple sites prod and fresh. Thanks for all the help.

@Jelle_S:

Yes, I'm aware that happens at install time, and there is another bit of code that needs fixing. However, AIUI the module was just disabled, which doesn't change the database, and then re-enabled, which doesn't call hook_install. (Enable/disable was remove in D8, which I think was unfortunate).

If enabling a module updates the recorded schema version without invoking the update hook, then I'd call that a bug.

@vibrasphere:

The SQL commands clearly added the missing record, which has enabled Drush to run (the insert and update commands wouldn't produce any output unless there was an error). I'm happy that addresses the issue, and fixes the regression of #1053398: Possible problem with drush → .

The fact that you're still getting page-not-found on user profiles would seem to be another problem, and a conflict with another module. Only by installing modules one by one into a test site, after installing user-revsion, would it be possible to find out which one.

This patch incorporates a fix to the install code, and a schema update for when updating the module.

The patch in #32 fails on install because of behaviour of serial key columns. This patch works!

Hi, this patch solves the drush problem, but not visiting the user/1 Page not found issue.

I cannot understand how nobody is running into this problem, I'm doing this on fresh vanilla installation out of the box with no other modules, user_revision is first module installed.

How nobody else runs into this issue?

Hi, I have to say I'm equally puzzled. Clearly nobody else does have the user/1 problem or we would have heard about it.

Some thoughts:

I assume you are logged in as user 1?
Do you get 404 on edit, or on view as well?
Is it the same with other user IDs?
What user_revision permissions are set?
I've created a new release 7.x.2.1 that includes this fix and a couple of other previous commits. Have you installed that release directly rather than 2.0 + patch?
What version of PHP are you running?
What OS and database?

I can't think of anything else relevant.

1. Page not found only on superuser uid1, logged in as yourself with it, both View and Edit.
2. Creating any new random user works both View and Edit, creates revisions, etc.
3. Permissions default untouched all set to Administrator.
4. Installed stable latest version 2.1
5. PHP 7.4.22, 5.5.5-10.3.38-MariaDB-0ubuntu0.20.04.1, Linux dev 5.4.0-84-generic #94-Ubuntu

It looks strangely like the installation may not have created the initial revision record for user 1. If that's the case I don't know why, but you can check with a SQL command like before:
drush sql-query "SELECT * FROM user_revision WHERE uid = 1"
You should get a record back with info corresponding to the user-1 account. If there's nothing then there's no record.

Did the additional users that work OK already exist before installing user-revision, or did you create them after?

Did another multiple resets in a row with https://www.drupal.org/project/drupal_reset → and now it's working? ¯\_(ツ)_/¯

Weird!

I've never used that reset module (didn't know it existed), but seems straight-forward, simulating a total re-install.

Maybe there's been some kind of sequencing problem in the installation of your site, but very hard to work out what might have been going on. Anyway, if it's working now then effectively problem solved.

I mean on original post about live production site the issue still persists, but the client doesn't need it anymore. I just got solved this on my own personal sandbox.

Automatically closed - issue fixed for 2 weeks with no activity.