🇺🇸United States @scott_earnest

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

Ran into error trying to upload file:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "file_validate_extensions" plugin does not exist.

file_validate_extensions is deprecated, see:
https://api.drupal.org/api/drupal/core%21modules%21file%21file.module/fu...
https://www.drupal.org/node/3363700 →

fixed on commit above:
https://git.drupalcode.org/project/site_verify/-/merge_requests/2/diffs?...

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:
- Plugin configuration can be viewed (/admin/structure/plugin)
- Plugin details can be viewed (/admin/structure/plugin/block for example)
- Plugin reference field can be added to an entity
- Plugin reference field can be viewed

Automated tests needed updates (committed on the issue fork).
These tests will fail, but this is not new on this patch (issues exist in current version):
- tests/src/Unit/Plugin/Plugin/PluginSelector/AdvancedPluginSelectorBaseTest.php
- tests/src/Functional/PluginSelectorTest.php

RTBC +1

Testing this also throws errors - I think this is because the interface to add a field has been changed by Drupal (around 10.3?) to where a content admin must select the field type first, then move on to the next screen.
- tests/src/Functional/PluginSelectorTest.php

Again, these deprecations exist in the current version so does not seem to be something that is introduced by this patch.

Testing this file throws errors, but they exist on the current version:
- tests/src/Unit/PluginType/PluginTypeManagerTest.php

The following classes are undefined, and not pulled in through the project composer.json file:

use org\bovigo\vfs\vfsStream;
use org\bovigo\vfs\vfsStreamDirectory;
use org\bovigo\vfs\vfsStreamWrapper;

... so taking no action here as it pertains to D11 upgrade.

Seeing error running phpunit test on file:
- tests/src/Unit/Plugin/Plugin/PluginSelector/AdvancedPluginSelectorBaseTest.php

https://git.drupalcode.org/issue/plugin-3433935/-/jobs/2636647

    Drupal\Tests\plugin\Unit\Plugin\Plugin\PluginSelector\AdvancedPluginSelectorBaseTest::testbuildMultipleAvailablePlugins
    PHPUnit\Framework\MockObject\MethodCannotBeConfiguredException: Trying to
    configure method "buildPluginForm" which cannot be configured because it
    does not exist, has not been specified, is final, or is static

https://www.drupal.org/project/drupal/issues/3130606 →
"setMethods()" is deprecated, and should be using "onlyMethods()"

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

Related ticket - to fix phpunit deprecation:

https://www.drupal.org/project/jsonlog/issues/3471285 🐛 JsonLogTest deprecation with PHPUnit version 10 Active

scott_earnest → created an issue.

Moving to reviewed. I will create new ticket for unit test deprecation warning.

RTBC +1

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

Verified
- Admin configuration page can be accessed at /admin/config/development/logging
- Admin configuration page can be edited and saved w/o issue
- Function to "Log test entry" works as expected, and creates an entry in the log file:

{"@timestamp":"2024-08-30T13:57:16.923Z","@version":1,"message":"Dummy message","message_id":"5f7965e45736__drupal1166d1cfbce15ce5.58857930","site_id":"5f7965e45736__drupal11","canonical":"","method":"POST","tags":"","type":"drupal","subtype":"200 - TEST entry","severity":"Warning","request_uri":"https:\/\/d11.lndo.site\/admin\/config\/development\/logging","referer":"","uid":1,"username":"","client_ip":"172.20.0.2","link":"","code":0,"trunc":"","context":[]}

Automated test results
- Functional/JsonLogConfigFormTest.php: OK (1 test, 12 assertions)
- Unit/JsonLogDataTest.php: OK (22 tests, 55 assertions)
- Unit/JsonLogTest.php: Tests: 11, Assertions: 37, Deprecations: 2.
- Unit/MockTranslation.php: ERROR Translation.php does not extend PHPUnit\Framework\TestCase

Looking into the 2 unit tests that were not successful.

removed extra line EOF on the info file - this causes issues with the D.O. packing script and can lead to fail to apply patch. same MR should be all good thanks for the help!

Having trouble applying the MR, testing issue w/EOF on info.

note to maintainers - this commit drops support for Drupal 9 and Drupal 10.2 or less:

https://git.drupalcode.org/issue/adminimal_theme-3460890/-/commit/44327e...

thank you

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

Verified:
- Adminimal can be installed in "Appearance"
- Adminimal can be used as the Administration theme
- Adminimal settings can be view and saved (/admin/appearance/settings/adminimal_theme)
- Creating and using the custom "adminimal-custom.css" overrides works as expected
- Layout is the same as the Drupal 10 version
- Tested different admin pages including node edit, block layout, and media library with no regressions seen

RTBC +1

new patch can be found by clicking on the "plain diff" link in the issue fork section:
https://git.drupalcode.org/project/adminimal_theme/-/merge_requests/15.diff

cc @jonasanne

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:
- Seven can be installed in "Appearance"
- Seven can be used as the Administration theme
- Seven settings can be view and saved (/admin/appearance/settings/seven)
- Layout is the same as the Drupal 10 version
- Image widget appears as expected

Automated test ran with success
- tests/src/Functional/SevenLayoutBuilderTest.php
- OK (1 test, 13 assertions)

After patch:

Marking as ready for review. Thank you!

Gitlab:

Locally:

scott_earnest → created an issue.

@jcisio - this has been merged into the dev branch 4.x - thank you for your contribution!

It will be part of the next release.

Marking as "Fixed" on Version "4.x-dev"

Unfortunately, I think the pipelines build errors are preventing from merging in the issue fork. Will patch directly on the dev branch and push.