Posted by jeanloup_sasa on Thu, Aug 15, 2024 - 8:00am

So after finally managing to run the upgrade process from Drupal 7 to Backdrop, what I'm left with isn't a 100% functional site unfortunately. What I want to try and get help for today is the fact that the update page thinks there are still "some modules" which have db schema updates to install. 

However when I run the update script again, I'm served with this very helpful message below:

 Needless to say this is leaving me slightly confused as per what exactly has unmet dependencies and whether there's some way I can find out more about what's needed?

Anyone else come across this before or know where I can figure out what modules need installing to meet dependencies? Thanks

Most helpful answers

And the correct schema will

And the correct schema will depend on the module itself. To find out, open the .install file and use the latest number from the implementations of hook_update_N() in that file. If there are not update hooks in that install file, then set it to 0.

EDIT: This answer is wrong. See below in this thread for the correct manual fix.

Comments

Thu, Aug 15, 2024 - 8:15am by argiepiano

Hi jeanloup_sasa. Congratulations on your successful D7->Backdrop upgrade.

The problem you describe is an existing bug. There is some discussion about this in Zulip:

https://backdrop.zulipchat.com/#narrow/stream/218635-Backdrop/topic/Database.20updates.20-.20out.20of.20date.20-.20finding.20the.20cause/near/433760217

Also issues in the queue:

https://github.com/backdrop/backdrop-issues/issues/6438

https://github.com/backdrop/backdrop-issues/issues/6645

Some of them contain a way to manually fix this in the database. The main problem is that at least one of your enabled modules in Backdrop has a schema_version of -1 (wrongly). 

Thu, Aug 15, 2024 - 8:30am by jeanloup_sasa

okay looking at my database I count 165 entries in the System table where the schema_version is set to -1... What would I even manually change that to?

apparently forcing the value of 7203 for the xmlsitemap module does get the update process unstuck but now it complains about 3 other modules. Do I have to manually set the schema_version for every module it complains about? Is there a reason this fails to run as part of the upgrade process?

 

Thu, Aug 15, 2024 - 8:35am by argiepiano

Please read the issues I linked. 

Not all -1 schema_versions are wrong. Only the ones where the status column is 1 AND the schema_version is -1. 

 

Thu, Aug 15, 2024 - 8:40am by jeanloup_sasa

okay in that case it must have just been xmlsitemap then as since I fixed that it only gives me 3 items, all of which are themes (although the prompt to run the update script hasn't gone away despite successfully updating xmlsitemap so maybe those themes - some of which I installed since running the initial update - do have an impact?)

Thu, Aug 15, 2024 - 8:37am by argiepiano

And the correct schema will depend on the module itself. To find out, open the .install file and use the latest number from the implementations of hook_update_N() in that file. If there are not update hooks in that install file, then set it to 0.

EDIT: This answer is wrong. See below in this thread for the correct manual fix.

Thu, Aug 15, 2024 - 8:47am by argiepiano

I think I'm wrong about the steps to fix the schema_version in my above response. The ideal way to do this is to manually set it up to the last schema_version used in the D7 version of the module, just to assure the update hooks will run in Backdrop (this is often needed when upgrading).

As for themes, I'm not familiar with a possible fix for those. I believe that was discussed in the Zulip thread above. To be on the safer side, you can join Zulip and ask the question there.

Thu, Aug 15, 2024 - 8:52am by jeanloup_sasa

Well the only 3 themes that show up as being enabled and having a schema_version of -1 are

  • Bartik, which is a core theme
  • Materialize, which I only downloaded an hour ago
  • Seven, which is a core theme

I'm assuming none of this manually updating scheva_version numbers is necessary with anything that's in core?

As an aside is there an easy way to delete a theme like Wordpress does?

Thu, Aug 15, 2024 - 9:00am by argiepiano

Hmm.. I really don't know how themes handle schema_version. In my own sites, I see Seven and other enabled themes with a status of "1" and  a schema_version of -1, and this is not causing any issues re: updates. 

As for deleting a theme (I assume you mean a contrib theme you downloaded) - disable and uninstall it through the UI, then manually remove its folder from  the themes folder.

Thu, Aug 15, 2024 - 9:05am by jeanloup_sasa

okay so it's a manual deletion from source for themes instead of a delete button I might have missed somewhere...

In any case, the issue persists:

even though the only enabled modules which a schema_version of -1 are the 2 main core themes (I disabled the third one)

Fri, Aug 16, 2024 - 12:22pm by laryn

I'm guessing that you have a module installed which has a version number that is not expected by the Backdrop version of the module. This could be if you were using a dev version on Drupal, or maybe if a new version came out for Drupal since the Backdrop module was ported and the Backdrop module was not yet updated (just guessing that that might do it).

Mon, Aug 19, 2024 - 2:23am by jeanloup_sasa

I made sure everything was up to date with the Drupal 7 instance I took the database snapshot from so there shouldn't be any discrepancies there. I just checked and everything still shows as up to date.

I do have the internationalization module which still has an "in development" status so it's possible there is an issue there but I would have thought it'd be a bit more explicit about that.

As for the PR, I tried installing the paging module but that didn't really do anything helpful... clearly I'm doing something wrong.

Thu, Aug 22, 2024 - 8:53am by jeanloup_sasa

So a quick update on this. I tried removing all my contrib modules one at a time to see if anything would trigger a change in the update status but other than a weird error message when I removed xmlsitemap (which may have been cleared by a cache clearing), it made no difference.

So I decided to output the values of the read and expected schemas to spot the discrepancies and it started giving me this:

  

block has a current schema of 1004 and a latest schema of 1004

book has a current schema of 6000 and a latest schema of 1002

ckeditor5 has a current schema of 1000 and a latest schema of 1000

color has a current schema of 1000 and a latest schema of 1000

comment has a current schema of 1008 and a latest schema of 1008

dashboard has a current schema of 1000 and a latest schema of 1000

date has a current schema of 0 and a latest schema of 1002

block has a current schema of 1004 and a latest schema of 1004

book has a current schema of 6000 and a latest schema of 1002

ckeditor5 has a current schema of 1000 and a latest schema of 1000

color has a current schema of 1000 and a latest schema of 1000

comment has a current schema of 1008 and a latest schema of 1008

dashboard has a current schema of 1000 and a latest schema of 1000

date has a current schema of 0 and a latest schema of 1002

 

Since it stopped at the date module, I just went ahead and modified its schema value from 0 to 1002 in the database and presto the outstanding updates message finally went away (well I still had the Paging module which I had installed as a test like on the Github ticket but after disabling it, the message went away).

It may be something worth looking into for an update to the umm, update process since the date module is in core...

However ...

If I re-enable the Paging module, it bring back the message that updates need to be applied but if I run the update script it's back to the message where some module has unmet dependencies but that there are no updates to apply.

So it's back to square 1 for any new module I would want to install essentially.

I tried to also manually change the Book schema version manually 1002 from 6000 but that made no difference. From now I think the only way to make it work is to keep my debug line and just manually edit the schema version in the database which is less than ideal for a live environment.

Thu, Aug 22, 2024 - 9:20am by jeanloup_sasa

Since adding various debug / print_r statements in strategic places seems to help to pinpoint the issue, I put a few around the update.php file and .. well it gives me this now:

One of these messages isn't where it should be it seems.

Long story short, in update_script_selection_form() in order for the $form array to be returned, the $update array (output above) must have a key called 'pending'. If it only has 'warning' as above, the whole thing get reset and the system outputs that there are no pending updates, which is true in a way but does not return the whole story.