D7 to Backdrop upgrade, Backdrop expecting all core modules to be at incorrect path

[kelizoliva]

Description of the bug Working on an upgrade from Drupal 7.67 to Backdrop 1.14.0. Followed all upgrade steps outlined, and upgrade.php runs without any errors. The resulting upgraded Backdrop site is throwing warnings like the following:

Warning: require_once(/var/www/test/ptcrm/modules/user/user.pages.inc): failed to open stream: No such file or directory in require_once() (line 2461 of /var/www/test/ptcrm/core/modules/system/system.module).

This is the case for all core modules that I attempt to access. i untangled this problem by creating symbolic links in /var/www/test/ptcrm/modules to the corresponding (and correct) core modules directories in backdrop.

The settings.php file is unremarkable; I have $settings['backdrop_drupal_compatibility'] set to false and have made no custom changes to that file.

There are no other errors/warnings coming up that I feel relate to this issue, though additionally I am getting:

Warning: call_user_func_array() expects parameter 1 to be a valid callback, function 'drupal_get_form' not found or invalid function name in system_block_view() (line 2464 of /var/www/test/ptcrm/core/modules/system/system.module).

Which I find somewhat suspicious (the path is correct here probably due to the sym link I have set for the system module).

I have retried the upgrade several times, and checked each of the modules (there aren't many) and what they are doing.

This is the first I have run into this issue with a D7 to Backdrop upgrade, and am at a loss as to what the underlying issue is.

Additional information This is on a LAMP with debian 9.11 and Apache/2.4.25. There are other backdrop and drupal instances running on this machine with no issues.

Contrib modules installed in drupal database: backup_migrate (disabled for upgrade), nagios (disabled for upgrade), civicrm (disabled for upgrade), webform, webform_civicrm (disabled for upgrade), redirect (no redirects configured)

[klonos]

Hey @kelizoliva 👋 ...thanks for filing this issue. I am curious about this too, and I will try to reproduce it if can manage to make some time (I always seem to get drawn to other, more "fun" issues 😅). The only things that comes to mind as a possible cause are:

• D7 core modules/themes left over in the root /modules and /themes directories
• misconfigured base path in your settings.php
• misconfigured apache webroot (I see that the site is installed 2 levels deep from the default Debian /var/www directory)

PS: is there any way that we can have a sanitized version of the db to try to reproduce this?

[kelizoliva]

D7 core modules/themes left over in the root /modules and /themes directories

Per the standard Drupal to Backdrop upgrade instructions, the upgrade is run by abandoning the Drupal file structure completely, and running the upgrade against a new copy of the Drupal database. So there wouldn't be any D7 core modules or themes in the root /modules and /themes directories.

misconfigured base path in your settings.php

Do you mean base url? In what ways could this be misconfigured? I am using the identical path to what was being used with Drupal, which is an https domain with no trailing slash.

misconfigured apache webroot (I see that the site is installed 2 levels deep from the default Debian /var/www directory)

The Apache webroot path was not changed from what was being used for the Drupal site (this is being run against a dev site, so the directories were simply swapped out). And if the webroot was misconfigured, then the site would not load at all; the site does load, but is trying to load core modules from the wrong path from webroot. It does not have any issues loading themes from the expected location.

is there any way that we can have a sanitized version of the db to try to reproduce this?

This is a really vanilla instance of D7, which was previously (as in years ago) a D6 instance. Its only purpose has been to host our internal CiviCRM, and for creating webforms. I can clear out the user table for you if you want to reproduce, there is nothing else sensitive in the Drupal database. What is the preferred method of delivery?

To be honest, I'm probably just going to skip this for this project and instead spin up a vanilla Backdrop and migrate in the user table and then recreate the webforms, since there is no other content inside.