davej β created an issue.
For reference, a slightly different version of the fix was committed at https://www.drupal.org/project/paragraphs/issues/3010938#comment-13166219 β .
Same issue replicated here on 8.x-2.1, 8.x-2.3 and current 8.x-2.x-dev . Specific menu structure:
- menu_link_content id 71: no parent, menu_item_override_children = 0, roles A & B
- - menu_link_content id 72: parent 71, menu_item_override_children = 0, role A
With "Allow parents to override children" ticked, getOverridingParent() incorrectly returns the parent (id 71) here, resulting in the item incorrectly being shown to role B.
Patch #3 fixes the error here for this case.
Same issue here with 8.x-3.9 . Merge request 11 fixed it here too, thank you!
Patch #156 has been successful here on a site where the rules stopped firing. Without the patch, disabling & re-enabling the rules would get them working for a short time, then they would silently stop firing again. With the patch, they have been firing OK for over a month.
The change to src/vapnHandler.php in https://git.drupalcode.org/project/vapn/-/merge_requests/6/diffs looks odd to me, itβs inserting a function header phpdoc comment into the middle of a function. This comment refers to a variable $node that doesnβt occur in the function and says "Some function description". Looks like this comes from patch #6 .
Applying #30 + #31 to 3.0.1 solved the WSOD here when viewing a node that displays a rate widget.
+1 for RTBC.
Hi Mark,
Wow, that was quick! Open source at its best. Thank you.
Dave
Hi @markusa,
I've given that a quick test on a view which previously failed on civicrm_value tables with a double underscore and the fix looks successful there. I haven't given it comprehensive testing to see if it breaks anything else but it looks good on that specific issue and the change to the logic seems reasonable. Looks like you're having to take into account a case where a table name begins with civicrm_ but will be found in the Drupal db, which does ring a bell - some Civi-related modules' tables, maybe?
Thanks!
Dave
@markusa I may have tracked down one scenario where civicrm_entity doesn't assign the correct prefix to a Civi table. This was happening on a custom field set table called civicrm_value_confidentiality__data_protection_6
. I suspect the problem may be this code in src/Plugin/views/query/CivicrmSql.php , function query()
:
// If the table is not prefixed with civicrm_, assume it is a Drupal table
// and convert it to a fully qualified table name. But, make sure it has
// not already been converted.
// Also do not convert any drupal custom fields.
if ((strpos($table['table'], 'civicrm_') !== 0 && strpos($table['table'], '.') === FALSE) || (strpos($table['table'], 'civicrm_') === 0 && strpos($table['table'], '__') !== FALSE)) {
$table['table'] = $connection->getFullQualifiedTableName($table['table']);
}
I.e. if the table name contains a double underscore, then regard it as already fully qualified?
Hi @orcalator, most likely there are multiple copies of the Mime library and the code is picking up an older one that doesn't have the addHeader() method. #16 had this issue with Simplesamlphp.
Found another way this error can occur, on a D9 / CiviCRM site with the Omnipay CiviCRM extension, which includes an older copy of the Symfony mime library. Details at symfony conflicts with D9.