Posted by robbrandt on Wed, Feb 05, 2025 - 5:35pm

I am polishing a step by step script for myself to migrate a Drupal 7 site to Backdrop. I had all this working previously, but progress was chaotic and I don't know what I am doing different this time.  When I try to access the configuration for the Content Access module, I get this error:

Indeed, I do not have cron jobs enabled as this is a temporary site. But it seems I should be able to do this manually.  I have been to the Status Report page and have clicked Rebuild Permissions for the Node Access Permissions, with no improvement.  It seems it's looking for a content_access_node_access_rebuild table in the database, which I can confirm does not exist.

Suggestions?

Comments

Wed, Feb 05, 2025 - 5:45pm by argiepiano

This seems to be a problem with an update hook that did not run when you upgraded your site from D7. The hook in question is content_access_update_1004, which should have run during upgrade. Or perhaps it did run, but failed to create that table.

Try to manually run update.php again, as inhttps://example.com/core/update.php

Inspect the database again to be sure that the table content_access_node_access_rebuild indeed does not exist

Check the  system  table and look for the row that has content_access in the module column - then check the schema_version for that row. It should say 1005. If not, you have a problem. Check that you have the latest version of  content_access (1.x-1.3.1)

 

Thu, Feb 06, 2025 - 9:26pm by argiepiano

Hi. 

So, the update for content_access is not running. Otherwise you wouldn't have schema version 7103, and you would have that missing table.

One aspect of the latest version of the Backdrop version of the content_access module is that (unfortunately) it assumes that your D7 site had the dev version of content_access, instead of the latest version (7.x-1.3). This has been reported, but hasn't been fixed in the Backdrop version.

So, you could go back and install the dev version in your D7 site, then try the upgrade again. 

Or, you could try and modify content_access.install in your Backdrop site, by changing return 7104; to return 7103; inside the function  content_access_update_last_removed(), and then run update.php one more time. This last approach may be a bit risky, but you can give it a try and see what happens.

 

Fri, Feb 07, 2025 - 4:09pm by robbrandt

As the link to the previous support question shows, I already upgraded to the dev version. And this failure is the result of that. A different failure than NOT having the dev version.

But my content_access needs are simple, so what I've now done is uninstall it, then reinstall it for a fresh start.

But now I see other problems: I have no admin access to existing content/basic pages. Nor the user list, for that matter.  I am pretty sure I did on my first go 'round in figuring out the migration. I have ALL permission boxes checked for Administrators in the Permissions page.

What I DO have is links to Add Content, either an Article or a Basic Page.  But no ability to edit them. For that matter, it's the same for users.  /admin/content and /admin/people both show:

 If this isn't a simple question I'll open another thread here.

 

Fri, Feb 07, 2025 - 4:13pm by robbrandt

Does backdrop have a super admin that's different than users assigned the administrator role?  I am using a regular user assigned to the administrator role, not the "admin" account per se. This is because I am using the OpenID module I converted from the old Core OpenID module.  Which is working pretty well FWIW.

Fri, Feb 07, 2025 - 8:28pm by stpaultim

Does backdrop have a super admin that's different than users assigned the administrator role?

Sort of. Backdrop has an administer role that can be granted specific permissions just like any other role with the exception of user/1. User/1 has access to every permission, whether or not other administrators do. 

I believe this is a fail safe to make sure that an administrator does not accidentally lock themselve out of their own site, but removing an important adminstrator permission accidentally. Only user/1 can do everything, all the time. While we don't officially call this an account a Super Admin, effectively it is one.

https://docs.backdropcms.org/documentation/users-roles-and-permissions

Fri, Feb 07, 2025 - 4:45pm by argiepiano

OK, my ability to help here is pretty limited as the details are sparse, and your questions/problems keep shifting.

Content and User lists are both Views that get installed automatically into your active config folder when you run the Drupal upgrade. If something went really wrong with your upgrade, then you'll end up without those Views. Or if you somehow messed up the files/config_XXX/active folder of your installation (for example by deleting files in there) then you will lose the ability to see users and contents.

You can reinstall those Views files by manually copying the file views.view.node_admin_content.json from the original pre-installation location (core/modules/node/config) into your files/config_XXXXX/active folder. Same for the views.view.user_admin.json file.  (Notice that the XXXX are typically a long hashed code unique to your installation).

As for your question about super admin: no, Backdrop (or Drupal) do not have that.

I have no experience with the OpenID module, and do not know what that may do to your installation, your users, or your permissions. 

Maybe someone else can help here. (We are all contributors to Backdrop typically during our spare time, not a support desk). 

Fri, Feb 07, 2025 - 4:55pm by robbrandt

Thanks, that's really helpful.  I never used Views in Drupal, so it was disabled when I started the latest migration cycle. I'll try your suggestion. The question about the super admin was a guess as to why I wasn't seeing content and people, but you've answered that question.

Fri, Feb 07, 2025 - 5:11pm by robbrandt

No, both those .json files are extant in the files/config_XXXXX/active folder.

Views UI wasn't enabled. I did so, and now I can manage content and people.

Thanks!