Open laryn opened 2 years ago
The module I'm working on has nothing to do with users, by the way (Conditional Fields).
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.
In this case the D7 site did not have Entity API enabled.
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...
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
Yes, I agree we should make sure the red carpet is rolled out for D7 upgrades...
@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?
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)
@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)
@laryn, I've done additional testing, and am still unable to reproduce this error.
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?
@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:
lando drush sql-cli < ./backdrop-ready.sql
to import the D7 databaseupdate_free_access
is set to TRUE
in settings.php
core/update.php
It goes through a bunch of updates but then crashes here:
@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?
@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.
@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.
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.
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
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
: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)