Posted by Egmund on Sun, Oct 03, 2021 - 1:52am

Trying again migrating/upgrading a drupal 7 site to backdrop.

Followed the instructions, but running update.php I get following errors:

Error

Warning message

The staging configuration directory (./files/config_18424bb2b506807e530d9584de0e8c9e/staging) could not be found. Please make sure it exists and is properly referenced in settings.php.

Error message

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'buddhistisk_xd7.system' doesn't exist: SELECT name, schema_version FROM {system} WHERE type = :type; Array ( [:type] => module ) in backdrop_get_installed_schema_version() (line 170 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/includes/install.inc).

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'buddhistisk_xd7.system' doesn't exist: SELECT name, schema_version FROM {system} WHERE type = :type; Array ( [:type] => module )

The first one I don't understand. The second is simply wrong. The db exist and is set up properly in 'settings.php' - and I did not write '.system' in the name.

Any help in here?

Most helpful answers

Hi @greenstick

Hi @greenstick

Seems to depend how you enter the password.   If you use the UI installer then it processes it so it will work.  If you just enter into settings.php then it won't.

We recently changed the command line tool (bee) to accommodate complex db passwords, db usernames and db names in command line options and when entered interactively. 

Even though you are talking

Even though you are talking about "migration" it seems to me that you are using an existing Drupal 7 database and try to run an upgrade? (I'm unclear on why you were trying to import users if you already had a Drupal 7 site which presumably already had the users in the database). There's a crucial difference - an upgrade can appear to be messier at first. And that can be off-putting.

If that is true, then I think you're not far off from having a functioning upgrade. When I'm at the stage where I've got Backdrop code but a Drupal 7 database, I will usually see a bunch of errors. But when I go to https://MYSITE.site/upgrade.php it'll show that there are a lot of upgrades to be done to the tables. So far so good. I attempt to run them all. And it might go well. After that I can log in and go to Configuration > File System so it can find the new file directory. And it'll seem more or less working.

Some times it takes a few tries and tweaks.

I always make sure all my modules were updated to the latest versions on the Drupal 7 site before starting. I make sure that I've removed any modules I don't need on the Drupal 7 site. And make sure all the modules have an upgrade path and are present when I'm trying to do the final upgrade.

Comments

Sun, Oct 03, 2021 - 3:55am by Egmund

Update:

The first error disappeared on second try. But - - :

Error

Error message

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'buddhistisk_xd7.system' doesn't exist: SELECT name, schema_version FROM {system} WHERE type = :type; Array ( [:type] => module ) in backdrop_get_installed_schema_version() (line 170 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/includes/install.inc).

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'buddhistisk_xd7.system' doesn't exist: SELECT name, schema_version FROM {system} WHERE type = :type; Array ( [:type] => module )

As said above, I have not put in '.system'. Where does that come from & how do I eliminate?

Here is the line from setup.php:

$database = 'mysql://buddhistisk_xd7:password@localhost/buddhistisk_xd7';

password of course changed. User & db have same name.

Sun, Oct 03, 2021 - 6:02am by laryn

Are you pointing the settings file at the “Backdrop ready” database, or an empty database?

Sun, Oct 03, 2021 - 6:18am by Egmund

Should be backdrop ready. Set up on same account as backdrop. Empty db with imported data from D7 db

Sun, Oct 03, 2021 - 12:46pm by laryn

If you look in that database, does the `system` table exist?

Olafski's picture

Mon, Oct 04, 2021 - 2:04am by Olafski

Just spitballing: Egmund, can you check if your database password contains special characters like a forward slash, a semicolon, or a hash sign? They can cause issues in certain cases.

Mon, Oct 04, 2021 - 2:31am by Egmund

Hi Olaf,

No just several % and an @ plus three .

Olafski's picture

Mon, Oct 04, 2021 - 2:44am by Olafski

Okay! I'm not sure if my list of special characters is complete, but I think, the ones mentioned by you shouldn't be an issue. (To be sure, you could still try with a a password of only numbers and letters.)

No more ideas, at the moment.

Mon, Oct 04, 2021 - 4:42am by Egmund

Not going to. It would be really bad code if normally accepted passwords would not function here.

Mon, Oct 04, 2021 - 4:52am by Egmund

Well, tried anyway. Now I get:

Error

Error message

PDOException: SQLSTATE[HY000] [1045] Access denied for user 'buddhistisk_xd7'@'localhost' (using password: YES) in backdrop_get_installed_schema_version() (line 170 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/includes/install.inc).

SQLSTATE[HY000] [1045] Access denied for user 'buddhistisk_xd7'@'localhost' (using password: YES)

Why would that be denied? User exist and have all rights to the db.

Mon, Oct 04, 2021 - 5:26am by Egmund

Well. Seems connect line in settings.php should not contain @localhost.

The above error disappeared. Now I 'simply get a blank page running update.php

Error in server log:

[04-Oct-2021 14:11:59 Europe/Copenhagen] PHP Fatal error:  The database setting could not be parsed. Please check the $database setting in settings.php. in /home/buddhistisk/d7.buddhistisksamfund.dk/core/includes/bootstrap.inc on line 841

Apparently several wrong info in 'how to install'

Here the string (slightly altered pw):

$database = 'mysql://buddhistisk_xd7:olga25FTE21/buddhistisk_xd7';

Mon, Oct 04, 2021 - 8:16am by laryn

Again spitballing (I haven't run into the issues you are facing) but could you try using `@127.0.0.1` instead of `@localhost`?

Mon, Oct 04, 2021 - 9:54am by Egmund

That gives me:

Error

Error message

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'buddhistisk_xd7.system' doesn't exist: SELECT name, schema_version FROM {system} WHERE type = :type; Array ( [:type] => module ) in backdrop_get_installed_schema_version() (line 170 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/includes/install.inc).

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'buddhistisk_xd7.system' doesn't exist: SELECT name, schema_version FROM {system} WHERE type = :type; Array ( [:type] => module )

Which I 'escaped' by eliminating @localhost (this site is on a shared server). See above post.

I got this hint from another experimental site - a fresh install, where I tried to 'import users' (as you know).

In the meantime I tried 'user-import' into a MODX site - worked without any errors (except my own typing errors). Besides I asked in MODX forum about another problem with a MODX module - got answer within minutes, that were actually useful. No, I am not putting your efforts to help down - there is just a huge difference in quality of code as I see it between these two CMS systems. I wanted to try backdrop one final time - gave up a couple of years ago - because of my knowledge and use of Drupal 7.

Edit:

Sorry, you are right. The @127.0.0.1 was in the other site's connect-line. Any way  -- didn't work (as you see in the error msg).

& where does this '.system' come from?

Mon, Oct 04, 2021 - 10:24am by Egmund

By the way: The 'system' table exist but as 'drup_system'

Mon, Oct 04, 2021 - 10:33am by laryn

Ah. That's important information. In your settings.php do you have any value set for the database prefix?

$database_prefix = '';

I think that should be in your case:

$database_prefix = 'drup';

I don't generally use prefixes so I'm not 100% sure -- it's also possible it should be:

$database_prefix = 'drup_';

Mon, Oct 04, 2021 - 10:45am by Egmund

Drupal usually set prefix as 'drup_' .

I tried to remove it from 'system' table, but didn't change the error.

Mon, Oct 04, 2021 - 10:48am by laryn

I am not suggesting to start changing table names one at a time, but adding the database prefix that you have used in this database into the Backdrop settings.php file so that it knows the tables are prefixed.

Mon, Oct 04, 2021 - 10:52am by Egmund

I put in the 'drup_' ans something happened: I am getting an awful lot of errors (after ignoring a couple):

fejl

Fejlmeddelelse

  • Warning: Invalid argument supplied for foreach() in system_get_date_formats() (line 3891 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/system/system.module).
  • Warning: Invalid argument supplied for foreach() in system_get_date_formats() (line 3891 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/system/system.module).
  • Notice: Trying to access array offset on value of type bool in dblog_update_1001() (line 108 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/dblog/dblog.install).
  • Notice: Trying to get property 'permissions' of non-object in user_role_grant_permissions() (line 2661 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/user/user.module).
  • Warning: array_merge(): Expected parameter 1 to be an array, null given in user_role_grant_permissions() (line 2661 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/user/user.module).
  • Warning: array_unique() expects parameter 1 to be array, null given in user_role_grant_permissions() (line 2661 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/user/user.module).
  • Warning: array_values() expects parameter 1 to be array, null given in user_role_grant_permissions() (line 2661 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/user/user.module).
  • Warning: Creating default object from empty value in user_role_grant_permissions() (line 2661 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/user/user.module).
  • Notice: Undefined property: stdClass::$name in user_role_save() (line 2505 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/user/user.module).
  • Notice: Undefined property: stdClass::$label in user_role_save() (line 2506 of /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/user/user.module).
  • Warning: Invalid argument supplied for foreach() i system_get_date_formats() (linje 3891 af /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/system/system.module).
  • Notice: Trying to access array offset on value of type bool i date_default_format() (linje 19 af /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/date/date.module).
  • Error: Call to undefined function layout_load_multiple_by_path() i dashboard_menu() (linje 14 af /home/buddhistisk/d7.buddhistisksamfund.dk/core/modules/dashboard/dashboard.module

Seems I need to disable or uninstall a lot of modules.

Mon, Oct 04, 2021 - 10:53am by Egmund

& now I'm retiring for the day.

Tue, Oct 05, 2021 - 12:17am by Egmund

Thank you Laryn for taking the time to help me - & I apologize for overlooking the (problem with) the prefix (should maybe be clearer in the migrate instructions).

The errors I get now are too overwhelming for me to deal with. I give up on backdrop. I have a functioning backdrop site, but could not even import users, the most important thing, into it. The so-called 'built-in' path for D7 is definitely worse than Drupal's own D7 to D8/9 migration 'feature'.

Tue, Oct 05, 2021 - 7:24am by laryn

Thanks for letting me know. It's too bad the oversight about the prefix used up so much of your troubleshooting energy -- but come back any time if you would like to try again.

I'll keep the issue you filed in User Import open and try to do some testing when I get a chance. Thanks for reporting.

EDIT: Just noting that:

  • another avenue for importing users might be the Feeds module which also has a CSV import option and can be directed to import Users instead of Nodes
  • I've made a new release of User Import

Tue, Oct 05, 2021 - 7:45am by herb

Even though you are talking about "migration" it seems to me that you are using an existing Drupal 7 database and try to run an upgrade? (I'm unclear on why you were trying to import users if you already had a Drupal 7 site which presumably already had the users in the database). There's a crucial difference - an upgrade can appear to be messier at first. And that can be off-putting.

If that is true, then I think you're not far off from having a functioning upgrade. When I'm at the stage where I've got Backdrop code but a Drupal 7 database, I will usually see a bunch of errors. But when I go to https://MYSITE.site/upgrade.php it'll show that there are a lot of upgrades to be done to the tables. So far so good. I attempt to run them all. And it might go well. After that I can log in and go to Configuration > File System so it can find the new file directory. And it'll seem more or less working.

Some times it takes a few tries and tweaks.

I always make sure all my modules were updated to the latest versions on the Drupal 7 site before starting. I make sure that I've removed any modules I don't need on the Drupal 7 site. And make sure all the modules have an upgrade path and are present when I'm trying to do the final upgrade.

Wed, Oct 06, 2021 - 12:44am by Egmund

Thank you Herb for trying to help.

I had two sub-domains for experimenting. One w. D7 database and backdrop code. The other a fresh install of backdrop where I tried to import users.

These sites are now eliminated since neither update nor user-import worked.

I tried the update path a couple of years ago on another domain - catastrophic result. I therefore upgraded D7 to D8 (easy) and later converted to MODX (also easy).

I see some people have much better luck w. backdrop, but to become more popular there has to be a simpler/easier way to 'convert' from D7 to backdrop.

Maybe I am getting too old/senile.

Thu, Sep 15, 2022 - 11:04am by greenstick

Since this thread came up when I was looking for the cause of my issue - just wanted to verify that a '...could not be parsed' issue for me today was caused by a hash tag # in my database password.  (For the next one looking.)

Thu, Sep 15, 2022 - 12:29pm by yorkshirepudding

Hi @greenstick

Seems to depend how you enter the password.   If you use the UI installer then it processes it so it will work.  If you just enter into settings.php then it won't.

We recently changed the command line tool (bee) to accommodate complex db passwords, db usernames and db names in command line options and when entered interactively. 

Thu, Sep 15, 2022 - 12:38pm by greenstick

Cheers - normally I'm porting over from a local install to a live server so it's as easy as uploading the files, importing the DB dump then changing the database setting manually after the fact, first time it's happened (I guess coincidentally 5 installs later this is the first time my host has auto generated a PW with a #.)

Is the command line tool simply adding a prefix or something to the hash so it's not read in as a comment or something?  Can't say I get how it works, but maybe a comment line could be added to the settings file to indicate how to do so manually if so?