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?

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.

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.

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

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?

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

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?

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.

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.

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.

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!

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.

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

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?

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.