Posted by jeanloup_sasa on Tue, Aug 06, 2024 - 4:01am

Hi folks,

I was hoping migrating our Drupal 7 to Backdrop would be an easy task for once but I'm faced with dealing with errors which don't seem to have a readily available solution so I'm hoping someone here can help.

First of all, my setup is a docker based development environment where I have a local copy of our Drupal 7 website. The setup runs on a php-fpm platform with the database located in its own container, all normally working as expected. Since it's docker, the base image runs from a debian-based image (so no SELinux to worry about at least in that setup). PHP version is 8.2, web server is Nginx. If I've omitted other details to help troubleshoot this, please let me know.

So on to my problem. I've followed the migration guide as closely as I could and got to the point of installing all the modules on the freshly installed Backdrop instance. I managed to run https://localhost:xxxx/core/update.php (where localhost:xxxx is my local instance of Backdrop running on a dedicated port number) and at first it complained about some missing modules for dependency which I eventually resolved. Only now that those are resolved, I'm being served a 500 error. Looking at my logs on the docker container, I see that it's throwing the error:

PHP Fatal error:  Uncaught Error: Call to undefined function _system_rebuild_theme_data() in /path/to/backdrop/core/includes/theme.inc:822

I can confirm the _system_rebuild_theme_data() function exists in /path/to/backdrop/core/modules/system/system.module so why it thinks it's an undefined function I'm not sure. I haven't seen anything that suggested changing permissions in any way in the migration guide but it's possible I missed it somehow.

I should point out that our original theme is Zeropoint, which hasn't been ported to Backdrop. However I did revert it back to Bartik as instructed and unless the issue is there is no theme at all that comes with Backdrop, I would have expected that theme to load up.

I also seem to have issues with the config folders defined in settings.php but I'm hoping the two issues are related. Any help would be greatly appreciated as if I'm able to mostly transfer our Drupal 7 site over to Backdrop that would save me a lot of time.

Cheers

Most helpful answers

I'm pleased you've found it.

I'm pleased you've found it. I think it would be helpful if you could raise an issue there.

https://github.com/backdrop-contrib/css_injector/issues

So apparently the culprit was

So apparently the culprit was actually css_injector.

When I removed DisplaySuite, it came back with this permission error for css_injector I mentioned earlier so I figured I'd try to disable that as well to see what would happen and lo and behold, the upgrade process has now moved on to "Overview". Out of curiosity I re-enabled DisplaySuite and it didn't complain.

I'm pretty sure css_injector was there to mitigate to display issues with Zeropoint (I wasn't the one who built the site) so if the theme isn't even compatible I suppose there's no real reason for this module to be there.

Comments

Tue, Aug 06, 2024 - 11:09am by laryn

I searched contrib to see if any modules call that function directly, and it looks like Fences does. Are you using that module by chance?

I also seem to have issues with the config folders defined in settings.php

Can you describe these issues further?

if I'm able to mostly transfer our Drupal 7 site over to Backdrop that would save me a lot of time.

I'm confident we can get you transferred!

Thu, Aug 08, 2024 - 5:20am by jeanloup_sasa

I do not use the Fences plugin no. I assumed it had something to do with possibly some Zeropoint configurations being in the database and somehow causing an error but as I said, I reverted back to Bartik and the database I copied in my Backdrop install should have that in it.

The settings issue I'm having is this error on the home page:

Exception: The configuration directory in settings.php is specified as '/path/to/backdrop/config/active', but this directory is either empty or missing crucial files. Check that the $config_directories variable is correct in settings.php. in _backdrop_bootstrap_configuration() (line 3064 of /path/to/backdrop/core/includes/bootstrap.inc).

I have the configuration set in a config directory at root level that contain both the active and staging directories. Somehow the file locale.settings.json got written in config/active so it's definitely not empty and if it's missing crucial files, it's nothing that's specified in the settings.php file (which also lives at root level)

I also get that error if I try to run a command with bee, so for instance running /path/to/backdrop/modules/contrib/bee-1.x-1.x/bee.php cc to clear the cache will trigger that error

Mon, Aug 12, 2024 - 4:18am by jeanloup_sasa

Anyone has any further updates on this? No matter what I try I keep getting those error messages which do not relate to how my system is setup. Any help would be appreciated.

Mon, Aug 12, 2024 - 4:40am by yorkshirepudding

I don't have any immediate answers but here are a few ideas.

Can you try setting up a new Backdrop site in an identical environment? Does that work fine?

When you say the database is in its own container, I presume that it has access to the database? I use lando, which is based on docker and it creates an app with multiple sub containers where the 'appserver' container can access the 'database' container.

You have bee installed inside the web root which is not normal or recommended but it can work, though you will normally get a warning.  What is the output from bee status on the site? 

There is a weekly "Office Hours" which is on Wednesday at 19:00 GMT (not sure what timezone you are) where you can get live help.

Mon, Aug 12, 2024 - 5:02am by jeanloup_sasa

I just ran the install script from the exact same zip I downloaded for the upgrade, ran it in the exact same environment, same database server but different database (obviously) and it works like a charm.

Yes the database server is a separate container which exists in the same network so talking to it just means specifying the right host name which should work.

Bee being inside the webroot is not an immediate concern for this build as it's a development environment. Once I can make it work it will live somewhere else in the production environment.

Bee status says

  

        Backdrop CMS             1.28.2
   Bee version              1.x-1.1.x-dev
   Bee latest release       1.x-1.0.2
   Bee root directory       /path/to/backdrop/modules/contrib/bee-1.x-1.x
   Site root directory      /path/to/backdrop
   Site type                Single
   Database                 mysql
   Database name            <mydb>
   Database username        root
   Database password        **********
   Database host            <db_host>
   Database port            3306
   Settings.php path        /path/to/backdrop/settings.php
   Drupal compatibility     on
   Config storage active    /path/to/backdrop/config/active
   Config storage staging   /path/to/backdrop/config/staging
   PHP cli version          8.2.14
   PHP ini path
   ℹ  TELEMETRY
   Status                   off
   Data: None

 

I'm in the UK and Wednesday is a non-working day for me, even if it wasn't 7pm is rather late

Mon, Aug 12, 2024 - 6:27am by yorkshirepudding

Hi. I'm in UK too.

Could you try, if you haven't already, delete the locale.settings.json file so the folder is empty before running update again?

This is really clutching at straws as I'm a bit flummoxed by this - there are no issues similar to this and nothing else in the forum.

Another thing to try: I did a search on the internet to see if I can find mentions of this for Drupal 7. These look possible:

Another straw clutching idea: was the site in maintenance mode? Try doing it not in maintenance mode if it was, or in maintenance mode if it wasn't.

Mon, Aug 12, 2024 - 6:46am by jeanloup_sasa

Could you try, if you haven't already, delete the locale.settings.json file so the folder is empty before running update again?

I did that and removed other config files I tried to manually create but the issue still persists. Looking at the equivalent folder in the clean install, these folders end up having quite a few config files in them. I'm not sure to what degree this specific issue affects the upgrade process but I'm betting it's not helping that this error is triggered.

This is really clutching at straws as I'm a bit flummoxed by this - there are no issues similar to this and nothing else in the forum.

I noticed. Given that this happened right as I was finishing to add required modules for dependency of those I had installed, I would have assumed someone else had this issue before but it's just not popping up. Side note about modules. I manually added all those I identified in the audit which haven't been folded into core and which had a backdrop equivalent. The instructions don't say one way or the other but I assumed it wasn't just going to install them automatically.

Another thing to try: I did a search on the internet to see if I can find mentions of this for Drupal 7. These look possible:

I saw those too, and I do have a custom module (a fairly simple one at that) but even if I remove it the error still pops up, that and the fact that they're fairly old threads, I'm not sure how relevant they would be to my setup.

Another straw clutching idea: was the site in maintenance mode? Try doing it not in maintenance mode if it was, or in maintenance mode if it wasn't.

I did wonder about that as the instructions do tell you to put your site in maintenance mode (which was silly of me to comply with given I'm on a dev environment). However now I can't access the site at all, I'm not sure how to disable it again. It would be a simple command with Bee but that triggers the same config folder error as it does when trying to clear the cache. I don't know Drupal well enough to figure out where in the database the flag is triggered to manually turn it back off :/

Mon, Aug 12, 2024 - 6:52am by yorkshirepudding

In Backdrop, maintenance_mode is in the state table whereas is D7, it is in the variables table

Mon, Aug 12, 2024 - 6:58am by jeanloup_sasa

And it seems the data type of the Variable table is "blob" so not exactly straightforward to edit on the spot... I'll try to disable it on my copy of the Drupal 7 site then re-import the database. It feels overkill but at this point I'm not too sure how else to change that flag

Tue, Aug 13, 2024 - 3:52am by jeanloup_sasa

I disabled maintenance mode (in the most obtuse way but whatever) and unfortunately I still get "PHP Fatal error:  Uncaught Error: Call to undefined function _system_rebuild_theme_data()" and still cannot proceed with the upgrade. Just for info

Mon, Aug 12, 2024 - 7:24am by jeanloup_sasa

Thank you, I appreciate that.

I wondered if it would be worth removing all the modules but then I figured they're also part of the upgrade process so I'm not sure that would help necessarily or if it would just create another problem

Mon, Aug 12, 2024 - 8:01am by jeanloup_sasa

If it helps here's the whole stack trace from the error: 

        2024-08-12 15:30:39 12.12.12.42 -  12/Aug/2024:15:30:39 +0100 "GET /core/update.php" 500
    2024-08-12 15:30:39 [12-Aug-2024 15:30:39 Europe/London] PHP Fatal error:  Uncaught Error: Call to undefined function _system_rebuild_theme_data() in /path/to/backdrop/core/includes/theme.inc:822
    2024-08-12 15:30:39 Stack trace:
    2024-08-12 15:30:39 #0 /path/to/backdrop/core/includes/theme.inc(94): list_themes()
    2024-08-12 15:30:39 #1 /path/to/backdrop/core/includes/theme.inc(293): backdrop_theme_initialize()
    2024-08-12 15:30:39 #2 /path/to/backdrop/core/includes/theme.inc(1024): theme_get_registry(false)
    2024-08-12 15:30:39 #3 /path/to/backdrop/core/includes/errors.inc(256): theme('maintenance_pag...', Array)
    2024-08-12 15:30:39 #4 /path/to/backdrop/core/includes/bootstrap.inc(2998): _backdrop_log_error(Array, true)
    2024-08-12 15:30:39 #5 [internal function]: _backdrop_exception_handler(Object(Error))
    2024-08-12 15:30:39 #6 {main}
    2024-08-12 15:30:39   thrown in /path/to/backdrop/core/includes/theme.inc on line 822

And also just to be clear I'm currently stuck at step 8 of the instructions at https://docs.backdropcms.org/documentation/step-3-upgrade-the-drupal-site

Mon, Aug 12, 2024 - 8:37am by yorkshirepudding

Did you try this step:

  • Note: You will need to be both logged in, and have sufficient privileges to run the update. If this is not the case, you can change $settings['update_free_access'] = TRUE; in your settings.php file.

Mon, Aug 12, 2024 - 8:40am by jeanloup_sasa

Yeah that's been in my settings file from the start given that's mentioned twice in the instructions :)

Tue, Aug 13, 2024 - 4:46am by DrAlbany

Have you tried dropping down to php 8.0?

Tue, Aug 13, 2024 - 5:06am by yorkshirepudding

Good idea. You could even try dropping to 7.4

Tue, Aug 13, 2024 - 5:06am by jeanloup_sasa

I'm afraid that's not an option. The server it's marked to go in (assuming I can get the migration to work) runs on PHP8.2 and 8.0 being out of support means it's not something we're able to consider.

Tue, Aug 13, 2024 - 5:07am by yorkshirepudding

I think what we're suggesting is to just do that for the upgrade.  Most modules work with 8.1 at least, but perhaps there is an update hook that is not 100% compatible.

Tue, Aug 13, 2024 - 5:21am by jeanloup_sasa

I have an 8.1 image I can try to run it on and see if it makes a difference

Edit: nope same issue on 8.1

Tue, Aug 13, 2024 - 4:52am by yorkshirepudding

I'll try to help further; I haven't yet managed to get anyone else to help.

Please can you provide a list of all the modules and themes. My suspicion is that some module that does something with the themes is causing this.

Tue, Aug 13, 2024 - 5:14am by jeanloup_sasa

Themes, which I assume is the culprit here, should be easy. 

Our original theme is Zeropoint but that's not supported by Backdrop so as instructed I reverted the site back to Bartik and for now that's it until I can find another theme we can rebuild the site on. But I gotta get the whole thing to work before then. So I haven't migrated any external themes.

Modules, excluding the custom module because I have excluded it before to no avail, I have the following installed in modules/contrib

  • aggregator
  • autologout
  • bee
  • biblio
  • captcha
  • css_injector
  • ds-1.x-2.x
  • email_confirm
  • entity_plus
  • entity_token
  • entity_ui-1.x-1.x
  • eu_cookie_compliance
  • feeds
  • field_group-1.x-1.x
  • googleanalytics-1.x-2.x
  • i18n
  • imce
  • job_scheduler
  • libraries
  • logintoboggan
  • metatag
  • multifield-1.x-1.x
  • profile-1.x-1.x
  • protected_pages
  • restrict_by_ip
  • rules
  • seckit
  • session_limit
  • site_map
  • statistics-1.x-1.x
  • trigger_actions-master
  • webform
  • xmlsitemap

And that's it

Tue, Aug 13, 2024 - 5:30am by yorkshirepudding

Another thing to try. Wherever your folder name is like modulename-branchname try renaming them to just modulename

bee dl does this but the Backdrop UI doesn't (though there is a plan to make it do so)

Tue, Aug 13, 2024 - 6:07am by jeanloup_sasa

Does it make a difference on how modules are loaded? All the modules were manually downloaded from github for the most part so it's just how the folder appears when unzipped... I can manually rename them of course. I did that with Bee

Tue, Aug 13, 2024 - 6:24am by yorkshirepudding

I don't know. I'm trying to suggest things that may rule out all the possible causes.  Feel free to try other things first.

Tue, Aug 13, 2024 - 6:33am by jeanloup_sasa

So if I remove display suite, I get a new set of error:

  • Deprecated function: realpath(): Passing null to parameter #1 ($path) of type string is deprecated in BackdropLocalStreamWrapper->getLocalPath() (line 380 of /path/to/backdrop/core/includes/stream_wrappers.inc).

And then so weird permission error for the public://css_injector folder, which at first I thought was located in /path/tp/backdrop/sites/default/files/css_injector (this director does exist) but changing permissions there makes no difference. Maybe it's on the module itself or maybe the folder needs to be created somewhere else but if so it would be useful for the error message to say so.

Tue, Aug 13, 2024 - 6:56am by jeanloup_sasa

So apparently the culprit was actually css_injector.

When I removed DisplaySuite, it came back with this permission error for css_injector I mentioned earlier so I figured I'd try to disable that as well to see what would happen and lo and behold, the upgrade process has now moved on to "Overview". Out of curiosity I re-enabled DisplaySuite and it didn't complain.

I'm pretty sure css_injector was there to mitigate to display issues with Zeropoint (I wasn't the one who built the site) so if the theme isn't even compatible I suppose there's no real reason for this module to be there.

Tue, Aug 13, 2024 - 7:24am by jeanloup_sasa

I'll pop a note to let the maintainers know as soon as I can

Tue, Aug 13, 2024 - 6:34am by kswan

Here are some ideas that come to mind:

  • Check file permissions. The whole backdrop directory should be owned by the webserver user.
  • Reduce infrastructure/configuration complexity to complete the migration. The production environment/configuration can be applied after the migration is complete. For example:
    • Use a VM with webserver, files, and DB on the same system without docker.
    • Use Apache instead of nginx.
    • Use PHP 7.4.