You should update "pantheon-systems/drupal-integrations" from ^10.0 to ^11.0. And it will fix the issue
No dice. Same error. Same behavior as before.
In https://www.drupal.org/project/opigno_learning_path/issues/3524000 🐛 LpSteps::getCourseStep should include attempts allowed Active we also found out that we need to compare the number of attempts compared to the maximum allowed attempts for each mandatory step to be sure the LP should be marked as "failed" rather than just "incomplete".
This patch updates the logic to include the fix, but also requires the patch from the above issue in order to work.
socketwench → created an issue.
In https://www.drupal.org/project/opigno_learning_path/issues/3523674 🐛 LpSteps::getCourseStep should include max score Active it was discovered that the completion logic still doesn't work as expected. This patch corrects the issue (hopefully for the last time) along with the referenced opigno_learning_path patch.
In addition, opigno_learning_path_get_step_status() and opigno_learning_path_is_passed() don't calculate the step's completeness correctly for this reason. By including the max score, we can calculate the correct result in these methods too.
socketwench → created an issue.
This updated patch corrects a fault where the step achievements also do not score correctly, resulting in an issue where the opigno_statistics.training route does not display the expected completion amount.
This patch adds a check to complete the Learning Path in the form. This works, but as I borrowed this from OpignoModuleController::userStatus(), I feel the problem is architectural. Either way, this works to correct the fault for manual scoring.
socketwench → created an issue.
Further examination of the module and other Opigno modules suggests that the correct output for this method is an integer percent. This patch then corrects the clamping on the outputted value so as to always be between 0 and 100.
The following patch changes the execution to use the UserModuleStatus' user, rather than the current user.
socketwench → created an issue.
socketwench → created an issue.
Patch for 10.4.x.
I also had the same problem as #56. I could not access the detection page to save it, so I could not use that work around.
I was hoping to uninstall the module, but it's required for search_api_solr, so I cannot uninstall it.
When I did add a nullity check for $configuration, that actually ran into the problem from https://www.drupal.org/project/drupal/issues/3002532 🐛 Call to a member function set Weight() on null in Drupal\language\Configurable LanguageManager->updateLockedLanguageWeights() Needs work
Adding the patch there and the nullity check allowed me to save the language detection form.
socketwench → created an issue.
This doesn't appear to be the correct fix. At least, not in our case.
On a fresh opigno site, non-admins cannot access any of the files in the document library. Admins can, but everyone else hits the accessCheck(TRUE) in _tft_get_group_gid() and are locked out. This despite the fact that the student is a member of the group (learning path). When the call is accessCheck(FALSE), the document library works as normal.
It's possible that our install is missing a permission or a group type configuration, but there doesn't seem to be any other way to resolve the bug.
I was able to replicate this using paragraphs and core alone.
In our case, we had an image field on a paragraph. The image field was configured to link to content. In `core/modules/image/src/Plugin/Field/FieldFormatter/ImageFormatter.php`, that resolves to:
if ($image_link_setting == 'content') {
$entity = $items->getEntity();
if (!$entity->isNew()) {
$url = $entity->toUrl();Since the paragraph is the parent entity in this case, core gets the paragraph, then attempts to generate the default link template, causing the error.
Removing the link to content resolves the error, but this is a workaround. The proper solution is that either core has to cross check that the default link template is available, or Paragraphs needs to provide it in all cases, even if it links to nothing.
socketwench → created an issue.
Rerolled the patch for 3.0.x
I've long since left both out of a need for personal safety.
There's other alternatives which maintain control, and respect privacy. In addition to mailing lists, and RSS, there are options on the Fediverse such as drupal.community and phpc.social.
I realize I'm jumping in on an old thread, but the thought occurred to me that "role weight" feels non-obvious to the site builder. Instead, if we were to replicate the Shortcut Per Role UI in core, it would make the most sense to set the assignment weights there by dragging the roles up and down in the preferred selection order. Then, the "default" set would be selected by the first role/user match with the lightest weight.
Given the differing features from the 1.x to 3.x branch, the 3.0.0 version is effectively a downgrade. We're finding that moving to 3.0.0 can break some sites during updates.
I would be open to adding this to migrate_process_skip. Seems like a good match.
This is likely not the correct fix. It seems more likely that a InstapageCmsPluginDrupal10Connector may need to be created here and other method refactored.
socketwench → created an issue.
socketwench → created an issue.
socketwench → made their first commit to this issue’s fork.
For those falling on this issue from a web search, the #6 patch neglects the ::getPrevious() method which is subject to the same error. The attached patch fixes it for 6.0.0-alpha7.
Neither patch is necessary when using the dev version.
socketwench → created an issue.
socketwench → created an issue.
This appears to have been fixed in #3273481.
While not a solution to this issue, this patch can help site maintainers who fall upon this fatal error with the 2.0.0-alpha1 version while on D9 as a stopgap.
https://www.drupal.org/files/issues/2023-07-13/cloudflare_2.0.0_D9_compa... →
socketwench → created an issue.