D7 Upgrade: undefined function entity_load() in user_load_multiple()

[laryn]

Description of the bug

I spun up a fresh Drupal 7 site, installed one module that I'm working on and then tried the upgrade process. I ran into this error unexpectedly while trying to run update.php:

Error: Call to undefined function entity_load() in user_load_multiple() (line 266 of /app/web/core/modules/user/user.module)

It looks like entity is enabled (status = 1) in the system table at this point, with a schema of 0.

NEXT STEPS

It seems that no one has been able to reproduce this problem other than @laryn. The next steps are probably to try once more to reproduce this problem? (Edited by @stpaultim)

[laryn]

The module I'm working on has nothing to do with users, by the way (Conditional Fields).

[argiepiano]

Hi @laryn. Yes, this is an issue I discovered when working on #5499. It happens if your D7 site had Entity API enabled. The PR I included for that issue solves this issue, but it has not been merged yet.

[laryn]

In this case the D7 site did not have Entity API enabled.

[laryn]

Just to keep my current project moving forward, I've hacked the line above to use require_once to load user.module and that works for me for now. The upgrade completes at this point, although another strange warning:

Warning: Use of undefined constant VIEWS_STORAGE_DEFAULT - assumed 'VIEWS_STORAGE_DEFAULT' (this will throw an Error in a future version of PHP) in filter_update_1004() (line 491 of /app/web/core/modules/filter/filter.install).

EDIT: Now I've run it again from the same backdrop-ready.sql database and don't see the Views warning above...

[argiepiano]

In this case the D7 site did not have Entity API enabled.

OK. Then this is something I haven't seen before. TBH the D7 upgrade process is getting so little attention and seems to be so fraught with problems, yet it's such an important aspect; the future of Backdrop may very well rely on a smooth experience upgrading from D7

[laryn]

Yes, I agree we should make sure the red carpet is rolled out for D7 upgrades...

[argiepiano]

@laryn, I'm interested in looking further into this. So far I've been unable to reproduce this error. I'm wondering if the Backdrop codebase is a clean install? And are you starting up from a Standard D7 profile of the latest version? What D7 modules did you have enabled?

Also, what's the name of the D7 module you are referring to?

[argiepiano]

Also, can you clarify when you see this message? In my testing user_load_multiple() is never called during the upgrade process of a clean Standard D7 site - it's only called when you try to log in after the update.

(BTW, entity doesn't have any update_N hooks, so it's normally schema "0" - it doesn't even have an .install file)

[laryn]

@argiepiano I believe it was just a vanilla D7 with conditional fields installed (and one conditional field defined in a content type). The error occurred during the database updates step. (I installed a blank backdrop site then pointed the database to the D7 database and ran the updates)

[argiepiano]

@laryn, I've done additional testing, and am still unable to reproduce this error.

1. In my D7 clean install, I enabled Conditional Fields, created a new content type, added two fields (one of them boolean) and created a dependency so that field B was shown if the boolean was set to true. All works well.
2. I created content.
3. I followed the usual upgrade steps with a Backdrop codebase that included Conditional Fields in the modules folder
4. The upgraded proceeded smoothly, no errors. I logged in the upgraded site. The content type and content were both migrated, and the Conditional Field works well

Any special settings you used in the D7 Conditional Field relationship? For example, did you use any of the "per user" or "per role" settings?

[laryn]

@argiepiano

I had nothing fancy configured on the D7 site, just as little as I could configure to test the CF update process. I can replicate it locally.

I took the backdrop-ready.sql database (compressed version attached below) and did the following:

1. Install a vanilla version of Backdrop in a lando container
2. Download Conditional Fields into the modules directory
3. Use lando drush sql-cli < ./backdrop-ready.sql to import the D7 database
4. Make sure update_free_access is set to TRUE in settings.php
5. Run core/update.php

It goes through a bunch of updates but then crashes here:

backdrop-ready.sql.zip

[olafgrabienski]

@laryn you seem to install Backdrop before the upgrade, and @argiepiano you do not, correct? (The docs recommend the latter, see https://docs.backdropcms.org/documentation/step-3-upgrade-the-drupal-site.) Could that make a difference here?

[argiepiano]

@laryn, I tested an upgrade with the database dump you attached. I did not find any issue. I'm starting to suspect that the problem is with your setup. I'm using a manual, clean, local install of Backdrop (I use MAMP for database and web server). I don't have/use lando, so I can't test that. I have the dev version of Backdrop's Conditional Fields. Since I don't have the admin credentials for the dump you attached, I could not log in, but the upgrade did not through any errors, and I could see the site fine. Here are screenshots of the BAckdrop site after upgrade.

[argiepiano]

@olafgrabienski comment may be on to something. I'm not familiar with the drush command sql-cli <, but I would make sure that you "wipe out" the old Backdrop database before importing the new (D7) one.

Also make sure a config folder doesn't exist in files.

[laryn]

I did try using drush sql-drop before the import command, with the same results. I'll try to test in a different (maybe non-Lando) setup another time. Not likely today though.

[laryn]

I suppose it's possible that having config files from a vanilla install still in the config folder could be part of the issue.

PS. in that test database, the login is simply admin/admin