🇺🇸United States @scott_earnest

Sorry I don't currently have a site with Rabbit Hole v2 on it atm. Ticket will need work for that branch and testing. thanks!

This may be helpful to someone - we wrote an update hook to batch update records that had null values:

/**
 * Rabbit Hole update to default for NULL values for nodes.
 */
function MY_MODULE_update_10001(&$sandbox) {

  // Set array of node ids to update in sandbox.
  if (!isset($sandbox['ids'])) {
    $ids = \Drupal::entityQuery('node')
      ->accessCheck(FALSE)
      ->condition('rh_action', NULL, 'IS NULL')
      ->sort('nid')
      ->execute();
    $sandbox['ids'] = $ids;
    $sandbox['current'] = 0;
    if (empty($sandbox['ids'])) {
      $sandbox['#finished'] = 1;
      return;
    }
  }

  // Set batch size.
  $items_per_batch = 100;
  // Grab the working set based off of current position and range.
  $ids = array_slice($sandbox['ids'], $sandbox['current'], $items_per_batch);

  // Exit out if nothing to do.
  if (empty($ids)) {
    $sandbox['#finished'] = 1;
    return;
  }

  // Loop over node ids.
  foreach ($ids as $id) {
    $node = \Drupal::entityTypeManager()->getStorage('node')->load($id);
    // Set default values for NULL fields.
    $node->set('rh_action', 'bundle_default')
      ->set('rh_redirect_response', 301)
      ->set('rh_redirect_fallback_action', 'bundle_default');
    $node->save();
    $sandbox['current']++;
  }

  // Set the return message - either in progress or finished.
  if ($sandbox['current'] >= count($sandbox['ids'])) {
    $sandbox['#finished'] = 1;
    $message = 'Batch update for missing Rabbit Hole values completed';
    $args = [];
  }
  else {
    $sandbox['#finished'] = ($sandbox['current'] / count($sandbox['ids']));
    $message = 'Progress: @count / @total';
    $args = [
      '@count' => $sandbox['current'],
      '@total' => count($sandbox['ids']),
    ];
  }

  // Return with message - will show progress of batch.
  return new \Drupal\Core\StringTranslation\TranslatableMarkup($message, $args);

}

scott_earnest → created an issue.

The update function was causing issues when we were updating to Drupal 11 and using the group module, which gets upgraded from v2->v3 in this process. Adding the fix here in case it helps anybody. Thx!
> [error] Update failed: entity_usage_post_update_remove_unsupported_source_entity_types

https://www.drupal.org/project/group/issues/3512099 🌱 The "group_content" entity type does not exist + content_lock module Active

scott_earnest → created an issue.

scott_earnest → created an issue.

Testing Steps

Prior to patching, on a site using an install profile, create a custom module within the profile as such:
docroot
-profiles
--my_custom_profile
---modules
----custom
-----my_custom_module

Notice that the custom module does NOT appear on the Upgrade Status report

Apply the patch

Notice the module will appear in the report as such:

My Module (in my_custom_profile profile) (my_custom_module)

Click the checkbox next to the module -> click scan -> verify scans successfully, an will supply upgrade recommendations

I was able to get the patch to apply but got an error trying to scan the modules that newly appeared"

There are two calls to RecursiveDirectoryIterator that were updated in the patch to supply the class Drupal\Core\Extension\Extension. However this PHP function takes a string as the first argument:

https://www.php.net/manual/en/recursivedirectoryiterator.construct.php

Attaching updated patch.

scott_earnest → created an issue.

Attaching update patch rerolled against siteimprove v2.0.3

Testing Steps

Visit the Shurly Domain settings:
- /admin/config/search/shurly/settings/domains

As a site administrator, add regex domain patterns in the "Allowed Domains" field, for example:

.*\.gov$
.*\.mil$

As a site "user" try to add a domain that is not supported, like "www.google.com"

Verify that the "Custom error message" from the Shurly Domains settings is displayed.

Either add the appropriate pattern to the allowed domains or try to enter a valid domain.

Verify that the domain is added successfully.

RTBC +1

Testing steps:

• create an orphaned menu item, by deleting it's parent
• ensure you can reproduce the error/issue prior to patching
• apply patch
• run module database updates taxonomy_menu_ui_update_9001
• ensure the updates run successfully without error

This is ready for review please and thank you.

scott_earnest → created an issue.

Drupal 11 Compatibility

New parameter added to \Drupal\Core\Form\ConfigFormBase::__construct
Drupal change record: https://www.drupal.org/node/3404140 →

On "ConfigFormBase", you now must pass "TypedConfigManagerInterface" in the __construct function

page "/admin/config/search/shurly/settings/domains" throws error:

ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase::__construct(), 1 passed in /app/docroot/modules/contrib/shurly/shurly_domains/src/Form/ShurlyDomainsSettings.php on line 18 and exactly 2 expected in Drupal\Core\Form\ConfigFormBase->__construct() (line 43 of core/lib/Drupal/Core/Form/ConfigFormBase.php).

New patch for D11:
shurly_domain_D11-3304340-6.diff →

scott_earnest → created an issue.

fixed in 1.1.3

thanks @s_leu & @heddn !

fixed in 1.1.3

thanks @heddn @s_leu

Thanks @joshahubbers!

Tested on:
Drupal 10.3.6
Drupal 11.0.5

RTBC +1

pushing this to new release

Drupal 11 uses jQuery 4.0.0-beta2 (at the moment).

The base package ableplayer/ableplayer v.4.5.0 still uses some functions that are removed from jQuery 4 including:
- jQuery.trim()
- jQuery.isNumeric()

https://blog.jquery.com/2024/02/06/jquery-4-0-0-beta/

Created issue/merge request on ableplayer:
- https://github.com/ableplayer/ableplayer/pull/613
- https://github.com/ableplayer/ableplayer/issues/612

The attached patch is a the minified js from this issue fork, so replaces that entire file.

This patch is for 11.1.x

Hi and thank you for catching this. Maybe there was a referenced entity that was removed? I was able to duplicate the issue by zero-ing out the "target_id" so that it would not load the media or thumbnail correctly:

              // Load the media for the thumbnail, if it's media reference.
              else {
+             $target_id = 0;            
                $thumbnail_media = $this->entityTypeManager->getStorage('media')->load($target_id);

Regarding your patch, I feel that the thumbnail_file_id needed to be set either way, even if to false, but further down needed some checks.

I have pushed a fix to the 1.x-dev branch.

Testing Instructions
- Use the MVM formatter with "Custom Thumbnail Media Reference" display
- Use the code block above to manually alter the target id
- Verify the page still loads, but the MVM item would not display since the thumbnail did not exist

Noting the video links are broken.

Fixed in the 1.x branch - Once this is rolled into a release I will update this ticket.

This has been merged into the dev branch.
I will update the ticket once it has been rolled into a release.

Thank you for your contribution!

Fixed in the 1.x branch - Once this is rolled into a release I will update this ticket.

This has been merged into the dev branch.
I will update the ticket once it has been rolled into a release.

Thank you for your contribution!

@wsantell - thank you for your update. This did not throw an error for me locally, but it makes sense what you are saying so I took it out.

I was testing with:
- Drupal 11.0.9
- SiteImprove 2.0.2
- PHP 8.3.13

Could you share what you are using?

Also, do you see green "Get push access" button next to the issue fork link at the top of this issue? That should be all you need to get access.

Appreciate the help!

I had noticed that "Hard limit" was not ported over. I created a separate ticket for this:
https://www.drupal.org/project/facets/issues/3492078 📌 Hard limit selection on facets exposed filters Active

Perhaps @smustgrave was looking for this setting?

thank you

Testing Instructions
Create a Search API Index based view
Create a facet exposed filter
Find the new (old) field for "Hard limit"
Verify this will affect the total number of options in the facet dropdown (you should be able to see this in the preview)

Something to note - in our case we are using search_api_opensearch - which will not set the limit (size) parameter if it is "0". We were seeing the default value for this api which was 10 records. Perhaps using other search api's "0" means "unlimited"?

scott_earnest → created an issue.

I was having issues patching against version 1.5 / Drupal 11

This is an updated patch for that version.

After patch form loads and saves as expected.

To test, visit the "Emergency" page:
- /admin/structure/ds/emergency
Toggle the "Fields Error" action

Tested on

• Drupal 11.0.9
• PHP 8.3.13
• ds 8.x-3.24

Seeing phpunit error on the build, but I think is unrelated/existing.

scott_earnest → created an issue.

Additional patch pulling in the changes from:
https://www.drupal.org/project/display_field_copy/issues/3467416 🐛 Too few arguments to function... RTBC

I was unable to apply both at the same time, hope this helps someone.

display_field_copy-drupal11-3429890.patch →

Drupal change record for D11:

file_validate and related functions are deprecated and replaced with file.validator service and Constraint plugins
https://www.drupal.org/node/3363700 →

This affects this file:
plupload_widget/src/Plugin/Validation/Constraint/WithoutPhpLimitsFileValidationConstraintValidator.php

New patch created here:
plupload_widget_fix_validator_2883893-23.patch →

scott_earnest → made their first commit to this issue’s fork.

scott_earnest → made their first commit to this issue’s fork.

Tested the 2.0.x patch with:

Drupal 11.0.7
Facets 2.0.9

Prior to patch, on page [Add Facet] (/admin/config/search/facets/add-facet)
After selecting "Facet source" ajax error appears and "Field" is not visible

After applying patch "Field" appears as expected

RTBC +1 on 2.0.x

need to look at phpunit tests failing

scott_earnest → created an issue.

nvm sorry i totally missed this:

https://www.drupal.org/project/facets/issues/3455217 📌 Automated Drupal 11 compatibility fixes for facets Active

scott_earnest → created an issue.

scott_earnest → made their first commit to this issue’s fork.

Here is another method, that updates the aggregated filename every time the settings.deployment_identifier is updated.

Sorry if I put in the wrong issue both were marked fixed but thought it may help someone. Same patch applies to 10.3.x and 11.0.x:

https://www.drupal.org/project/drupal/issues/3371822#comment-15807906 📌 Add the deployment_identifier to CSS and JavaScript aggregate hashes Closed: duplicate
https://www.drupal.org/files/issues/2024-10-09/3371822-8-add-the-deploym... →

In our case, we wanted to use the deployment_identifier a little more aggressively, and ALWAYS use it (if set) on every asset. We were running into issues on the build where assets (css etc) were changed in a library whose version was NOT changed, causing the aggregated filename to not change - and would be cached on a CDN without the update to the style. We wanted all assets to be invalidated on every build, and controlled by the deployment_identifier which would change on each build.

The attached patch is another version of @catch 's patch (thank you) from #5. Instead of only using the deployment_identifer when the version is unset, this will use it on every asset. The fallback is the hash of the file contents (the base file has changed: AssetGroupSetHashTrait.php since other patch). Using a deployment_identifer should also decrease the expense of the build, since the system will never have to hash the contents of a file for the version.

PATCH TESTING

Setup
- Core aggregation (css an js) turned on
- Ensure caching is enabled
- Enable a module that has a "libraries.yml" file that includes an asset like CSS
- Set library version numeric e.g. "10.3.6", OR constant "VERSION"
- Look in the source for aggregated file(s), similar to:

    <link rel="stylesheet" media="all" href="/sites/default/files/css/css_hnAzTWJ78jrYDVrHTP6y05aGIS9LmOJ9kqQNNmNPny0.css?delta=0&amp;language=en&amp;theme=olivero&amp;include=eJxdjEEOAyEMAz-0aJ-EArg0aiBVgkD8vj1RqTd7RrZvH2h3IselwhOmdxVNJMHHFu714LcuGEpIOyTR_DriAZRTsraGPvxqKExxcoHGxtm0aSG5fzEKJyNj-Bl3mlxpsPbgyNoL2T7SQZafYX0f_1knM10f_05QDA" />
    <link rel="stylesheet" media="all" href="/sites/default/files/css/css_a1-EIU3hM01tk-bHNLV5AeTBWpvOtvaolQAlOLBNeD4.css?delta=1&amp;language=en&amp;theme=olivero&amp;include=eJxdjEEOAyEMAz-0aJ-EArg0aiBVgkD8vj1RqTd7RrZvH2h3IselwhOmdxVNJMHHFu714LcuGEpIOyTR_DriAZRTsraGPvxqKExxcoHGxtm0aSG5fzEKJyNj-Bl3mlxpsPbgyNoL2T7SQZafYX0f_1knM10f_05QDA" />

- Note these file names, and when they change during the test

Without Patch

- Update library asset e.g. CSS, clear cache
- Aggregated filename does not change

With Patch

- Update deployment_identifier, clear cache
- Aggregated filename changes

PATCH FILE:
- 3371822-8-add-the-deploymentidentifier.patch →

@effulgentsia - thanks for that suggestion! That's cool. I updated the MR with the anonymous function method.

Leaving in "Needs review" for now if someone else wants to test. If so make sure to follow the setup from the parent issue please and thank you:
https://www.drupal.org/project/mysql57/issues/3477448 🐛 Error when target is an array of connections Active

Yes sorry - this was off the patch I created. I did not realize that this introduced a deprecation with a drush warning when clearing the cache.

I determined that a site's settings.php file get's loaded twice? Not sure why this was but because of this all settings get loaded twice.

I was not sure the best way to extract the "convert" piece in an .inc file - but this obviously causes problems with including it twice.

I though a path forward would be to check for "function exists", and also rename specific to the module.

scott_earnest → created an issue.

Attaching test results

- Drupal version: 11.0.4
- PHP version: 8.3.11

Prior to including the mysql57 settings.inc file, you can see that the "replica" database is an array of connections:

Defined in the settings.php file as such- per guidance from d.o:
- https://www.drupal.org/docs/drupal-apis/database-api/database-configuration →

$databases['default']['default'] = [
  'driver' => 'mysql',
  'database' => 'drupaldb1',
  'username' => 'username',
  'password' => 'secret',
  'host' => 'dbserver1',
];
$databases['default']['replica'][] = [
  'driver' => 'mysql',
  'database' => 'drupaldb2',
  'username' => 'username',
  'password' => 'secret',
  'host' => 'dbserver2',
];
$databases['default']['replica'][] = [
  'driver' => 'mysql',
  'database' => 'drupaldb3',
  'username' => 'username',
  'password' => 'secret',
  'host' => 'dbserver3',
];

After conversion (with patch) - you can see that the databases defined in the "replica" target have updated successfully, and there are no db connection errors:

scott_earnest → created an issue.

Updates rolled into issue fork.

Unfortunately, PHPUnit is throwing an error, need to look into this:
https://git.drupalcode.org/issue/mimemail-3155325/-/jobs/2799865
---- Drupal\Tests\mimemail\Functional\MimeMailWebTest ----

Otherwise this works for me in Drupal 10 and Drupal 11.

scott_earnest → made their first commit to this issue’s fork.

The above commit fixes the issue in #195 - and seems to function.
Still seeing an issue - when a field has a condition to be required, you can see the star, but the field can be submitted without actually filling out the field. Also, if the field is marked as required but not visible, the validation is still wanting that field to be filled out. So still in "needs work" but perhaps a little better.

scott_earnest → made their first commit to this issue’s fork.

Error on admin configuration screen (/admin/config/system/siteimprove)
ArgumentCountError: Too few arguments to function Drupal\Core\Form\ConfigFormBase::__construct(), 1 passed in /app/web/modules/contrib/siteimprove/src/Form/SettingsForm.php on line 79 and exactly 2 expected in Drupal\Core\Form\ConfigFormBase->__construct() (line 43 of core/lib/Drupal/Core/Form/ConfigFormBase.php).

Per change record, ConfigFormBase now expects 2nd parameter for TypedConfigManagerInterface
- https://www.drupal.org/node/3404140 →

Above commit adds this new field.

scott_earnest → made their first commit to this issue’s fork.

Tested on:
- Drupal 11.0.1
- PHP 8.3.10
- MySQL 8.0.19

Verified:
- Verifications configuration can be viewed (/admin/config/search/verifications)
- Verifications can be added of types:
- meta tag
- file upload
- verification file & contents
- Verification meta tags and files are produced as expected.

RTBC +1