That's unfortunate. CKEditor module has had it applied to both summary and body fields forever. This would be a downgrade in functionality for our clients, so using Editor is not an option at this time.
With the recent update of Dialog 7.x-2.x-dev, we checked if there were any changes necessary for this patch.
Found that Drupal 7.79 had an update to the progressBar definition in core's ajax.js:
https://www.drupal.org/node/3051721 →
This change has been incorporated into the patch, otherwise it is still the same as #8. Given this is a security issue for the Dialog module, it should be committed asap.
This is a common sense patch. Thanks for the fix.
Ok, have investigated this further and going to close the issue. Looks like the problem is the views cache needs to be cleared if the title override setting is changed. If the cache isn't cleared, the default title override option won't be shown.
Looked at this a little more and realized it should be handled the same way as path_override. Now have separate title and title_override configuration values.
See attached, thanks.
I won't open this issue because it says Drupal 7 is no longer supported, but there are a couple of bugs in the menu_token_handler validation function for 7.x-1.x-dev.
First problem is a typo. The code for $link_path_tokens was copied for $link_title_tokens, and clearly forgot to update one of the variables. The code says this:
$link_title_tokens = array_intersect($link_path_tokens, $entities);
... and it should be this:
$link_title_tokens = array_intersect($link_title_tokens, $entities);
The second issue is extra tokens that have a type of node or user are considered invalid. A perfect example is mentioned in comment #3. The token current-user is a completely valid user-type token, but the code only allows a user token if its type is set exactly to user.
I wrote a patch that fixes the typo and passes validation for any token that are of type "user" or "node". If any interest, see attached.
Ran some tests and realized I forgot to update hook names to match the changes made in hook_features_api. Was able to export, but the revert was failing because of this.
Looks to be working correctly now, also included an interdiff.
This was addressed a long time ago, unfortunately these old patches are never reviewed by anyone nor committed.
https://www.drupal.org/project/picture/issues/3022175#comment-13897942 →
Realized this same error was occurring for the colorbox module support in file entities. Was getting the following error, which applies to the colorbox conditional code:
Notice: Undefined index: field_name in picture_field_formatter_settings_picture_form() (line 482 of /sites/all/modules/picture/picture.module).
Have updated the patch to cover both situations.
As part of the recent security updates, the Forum Access module was changed to require chain_menu_access 7.x-2.1 (
https://www.drupal.org/project/forum_access/issues/3375942
📌
Require chain_menu_access 7.x-2.1
Fixed
). Because of this change, the forum_access_requirements function was removed.
Patch #5 used forum_access_requirements to check for the current chain_menu_access version, so it needs to be updated to avoid an error. Attached is a new version that takes into account the changes in Issue #3375942.
Moving back to needs review since I see it still needs tests, although have been using this in production environments for years.
Patch in #22 still applies cleanly to the latest 7.x-2.14 version.
Patch in #37 applies cleanly to the latest 7.x-3.12 version.
The update in 7.x-3.0-rc7 caused admin_menu_tree to become a private function.
The Admin Menu Source module (
https://www.drupal.org/project/admin_menu_source →
) calls admin_menu_tree in hook_admin_menu_output_alter() to build menus for different roles. By making the function private, admin menu can no longer load for any role with a customized admin menu.
Please review the attached patch which reverts admin_menu_tree to be a public function again. Thanks.
Noticed the core patch has a small change in the assertSessionIds test function which should also be updated here.
See attached version as a replacement, thanks.
Gave this some additional thought, and the better way to handle this is just check getDirectoryPath, since s3fs will return an empty value if queried.
This allows for any other check in the function to still occur, rather than immediately returning a FALSE. See attached, thanks.