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.