OK, I figured this one out. The entities were deleted, but a couple of View Modes are still hanging around:
core.entity_view_mode.pm_thread_access_time.token
core.entity_view_mode.pm_thread_delete_time.token
You have to delete these orphaned config entities with Drush:
drush cdel core.entity_view_mode.pm_thread_access_time.token, core.entity_view_mode.pm_thread_delete_time.token
For reference, here's the Drush manual page.
Changing status back to "Fixed."
Why is this issue marked as fixed? I'm having the same problem.
My prior version is: 8.x-2.0-beta18
Prior system schema version: 8006.
Same exact error message.
Thanks!
firstlut → created an issue.
I am updating Opigno LMS, as well, and I tried the "edit fields" trick, and that merely changed the nature of the error. Then I got an error that the preUpdateEntityTypeSchema function in SqlContentEntityStorageSchema.php was getting mismatched arrays. There was one field that wasn't getting a corresponding revision field created.
I deleted the offending field for now just so I could move on, but I'll have to address it eventually.
You have to install using Opigno's own Composer command. The way it works is Opigno is the dominant package, and Drupal is installed as one of its dependencies. And at the moment, it's still using Drupal 9.
That LMS is not a fork, but a whole new project.
Do you mean they need permissions? Looks like this is the relevant one: Manage group members in any group. It's associated with Opigno Learning Path module. The default is for that permission to be given to "User manager" role and not "Content Manager."
firstlut → created an issue.
Yeah, it's a bit like getting the sprinkles off without bringing any ice cream with them. It can probably be done, but it's a long, tedious process. I know I've turned off some Opigno modules that I don't use.
You'll probably need to look at them all in Composer to see which dependencies are which. composer show drupal/<module_name> will give you a rundown on any given package. Here's a link to the Composer documentation.
It's not a module, but a Drupal profile. The upshot is that Drupal is the dependency, not Opigno. You'll need to remove it with Composer.
It's not abandoned. The developers are prioritizing their paying customers, and they won't let any volunteers pitch in.
Looks like it's set up to install Opigno 3.2.0, which isn't out yet. We're only up to 3.1.0.
You might check the Guided Navigation field in the upper-right corner of the Learning Path editor. Our trainings are very rigid, and with the latest update, everything was set to be free navigation, which threw everything off and put people back to take modules they'd already completed.
For some reason, this field was never added in our 4-year-old installation, and I had to add the field, then write an update hook that went through all our existing Learning Paths and set the Boolean to true.
Still here!
That route did get dropped. We ran into trouble with a Boolean field for Guided Navigation that wasn't ever installed in our instance, and now we have to add it. Opigno did some work on navigation in Trainings and made free navigation the default.
Drupal 9.4 is still an active version, even if it isn't the latest and greatest. I've been working with Opigno for 4 years, and they always wait until the last possible minute to release a new version with a Drupal upgrade.
If you're feeling really antsy, you can use Composer aliases to upgrade past the Opigno requirements.
I'm assuming you're asking about making patches. Here's how I learned to do it:
go to module directory root
run git init
run git add *; git commit -m "init"
make changes to the file
run git diff > name_path_however.patch
move patch to ./patches directory
add patch entry to ./patches/composer.patches.json
run composer install
Some people list their patches in their main composer.json file, but we have a separate composer file and directory just for patches (we use A LOT of them).