🇮🇳India @arisen

Hi @seda12 yes that works fine if we write the preprocess in our custom module.
But the question is to make it work without having to do the preprocessing in custom module. So expecting a confirmation from the project maintainer about the correct approach.

arisen → created an issue.

smustgrave → credited arisen → .

@smustgrave found the issue 🐛 Query string duplications Fixed
It's already been added to 10.2 also.

@smustgrave The issue is no longer reproducible on D11 but still existing on D10(checked on 10.2.2).

Seems like NestedArray::mergeDeep was not the root cause.
Looks like there has been some changes to the link preprocessing logic.

$options = NestedArray::mergeDeep($element['#url']->getOptions(), $element['#options']);
On D11, is an empty array so the issue is no longer occurring, whereas on D10 its having the params info same as $element['#url']->getOptions().

What would be the ideal place to add a Kernel Test for this?

  /**
   * Test Link element with integer key parameters
   */
  public function testLinkWithIntegerKeyParams() {
    $link_array = [
      '#type' => 'link',
      '#title' => 'foo',
      '#url' => Url::fromUri('internal:/my-page?myparam[2021]=2021'),
    ];
    $link_rendered = (string) \Drupal::service('renderer')->renderRoot($link_array);
    $expected_link = '<a href="/my-page?myparam%5B2021%5D=2021">foo</a>';
    $this->assertSame($expected_link, $link_rendered);
  }

Wondering if it can added as part of core/modules/system/tests/src/Kernel/Common/UrlTest.php or core/tests/Drupal/KernelTests/Core/Render/Element/RenderElementTypesTest.php

Updated the task summary as the issue is related to Menu not Menu Items.

Jenkins pipeline seems to throw unrelated issues. Added MR.

Fixed the spellcheck issues in the test. But spellcheck now failing since I rebased.

The patch in #4 resolves the issue. Created a MR.
mergeDeep is internally using mergeDeepArray with preserve integer keys set to FALSE by default.
In the patch we are passing it as TRUE to keep the keys as it is. Should be fine IMO.

This might need some tests.

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

@orcalator can you provide steps to reproduce the error. Also downgrading the Priority to Normal as it just throwing warnings in the Backend.

Rerolling the patch.

arisen → created an issue.

And most importantly: neither this MR nor the CR document how this relates to the multiple existing dialog-related AJAX commands. "When to use which?" is a critical portion of landing this.

Updated the CR to address this.

The duration is not accurate enough when we use method formatInterval
Better to use method formatDiff

Tested with some sample data.

Instead of

$duration = $item->end_date->getTimestamp() - $item->start_date->getTimestamp();
      $elements[$delta]['#markup'] = $this->dateFormatter->formatInterval($duration, $this->getSetting('granularity'));

need to use
$elements[$delta]['#markup'] = $this->dateFormatter->formatDiff($item->start_date->getTimestamp(), $item->end_date->getTimestamp(), ['granularity' => $this->getSetting('granularity')]);

Added the functional test case for parents translation under the TermTranslationTest Suite.

1) Drupal\Tests\taxonomy\Functional\TermTranslationTest::testParentTermsTranslation
Behat\Mink\Exception\ResponseTextException: The text "translatedOne" was not found anywhere in the text of the current page.

/var/www/html/vendor/behat/mink/src/WebAssert.php:811
/var/www/html/vendor/behat/mink/src/WebAssert.php:262
/var/www/html/web/core/modules/taxonomy/tests/src/Functional/TermTranslationTest.php:134
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

ERRORS!
Tests: 8, Assertions: 692, Errors: 1.

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

@Berdir the Steps to Reproduce are bit confusing.
In the 2nd step does it mean disabled again instead of displayed again?

Going by the functional test cases. The MR does seem to fix the reported issue.
The disabled displays are not copied to the target entity on field reuse after applying the changes from the MR.

Steps used for testing

• Created a custom view mode, enabled it for Article node type.
• Created a one more view mode. enabled it for Article node type.
• Added a new field on Article content type, configured it to display on both the new display modes.
• Disabled the 2nd display mode from Article node type.
• In Page node type reused the newly added Article field. Observed the manage display for Page node type.
• Before applying the MR changes, it did copy the disabled view display on Page node type.
• It only created the enabled view display after applying MR.

Looks like it will require more test coverage. Looking into the same.

Added the change record.

Added the CR. Please review.

RTBC +1 for me.

Verified the fix on Drupal 11 setup as per the steps to reproduce.
-Created content using user 1.
-Edited the content using user 2.
-Deleted user 1 using user 3.
-Verified the revision of the content. Working as expected.

Thanks for the feature suggestion @srishtiiee.

Review the Merge Request. The changes look good and working a expected.
Tested the same on a Drupal 11 installation.
Testing steps:

• Setup a Drupal 11 site and applied the patch from the MR
• Created a Custom Ajax form with a button and a custom submit handler.
• Inside the handler added the code snippet to open a node in a dialog.
  

  $response = new AjaxResponse();
    $url = Url::fromRoute('entity.node.canonical', ['node' => 1]);
    $command = new OpenModalDialogWithUrl($url->toString(),
    [
      'url' => 'example',
      'width' => 500,
      'title' => 'Title',
      'modal' => TRUE,
    ]);
    $response->addCommand($command);
    return $response;

• The node gets displayed in a dialog as expected.

Attaching the screenshots.

This looks RTBC for me.

Thanks @Sandeep_k for the review. This needs review from more community members so keeping it in needs review.

@Nitin shrivastava The issue summary has been updated.
Testing steps:

• Setup a Drupal 11 site.
• Enable the Datetime Range module.
• Add Date Range field on any content type.
• Apply the provide patch.
• Go to the manage display tab of the content type and observe that a new Duration formatter is provided, select it and save.
• Add new content for the content type and view the content.
• The duration between start and end dates should be displayed instead of the actual dates.

Reviewed the MR 5764 and also applied the patch locally. The patch applies cleanly

Checking patch core/modules/node/src/Plugin/views/argument_default/Node.php...
Checking patch core/modules/views/tests/src/Functional/Plugin/ArgumentDefaultTest.php...
Applied patch core/modules/node/src/Plugin/views/argument_default/Node.php cleanly.
Applied patch core/modules/views/tests/src/Functional/Plugin/ArgumentDefaultTest.php cleanly.

Reviewed the issued as per the steps.
The issue gets resolved after applying the patch. i.e. Contextual filter(Content ID from URL) gets applied properly on the node preview page.
Attaching the screenshots.

The assertion added in the Merge Request runs without any failures. RTBC for me.

Uploading a new patch with the fixes.

Good Suggestion. Will be an useful field formatter for date-range type fields.
Providing Functional tests for the formatter.

Updated the MR with fixes to the Entity Browser widget.
Please review.

Reviewed the MR. The changes look good.
Applied the MR patch on branch 8.x-3.x. The patch applies cleanly.

Checking patch media_entity_video.info.yml...
Checking patch media_entity_video.install...
Checking patch media_entity_video.module...
Applied patch media_entity_video.info.yml cleanly.
Applied patch media_entity_video.install cleanly.
Applied patch media_entity_video.module cleanly.

The module gets installed successfully on Drupal 10.
Reviewed the features.

• The Media source plugin works fine.(attached screenshot)
• The Video File Formatter works as expected.(attached screenshot)
• The entity browser doesn't work due to the dependence on contributed Media Entity module.
  

  Drupal\Component\Plugin\Exception\PluginNotFoundException: The "media_bundle" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 139 of /var/www/html/web/core/lib/Drupal/Core/Entity/EntityTypeManager.php).
  

  Symfony\Component\Routing\Exception\RouteNotFoundException: Route "media.bundle_add" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 206 of /var/www/html/web/core/lib/Drupal/Core/Routing/RouteProvider.php).

The patch applies cleanly on 1.0.x branch.

Checking patch video_embed_tiktok.info.yml...
Applied patch video_embed_tiktok.info.yml cleanly.

The module get installed without any problem on Drupal 10 and tiktok provider coming as expected.
Attached screenshot.

RTBC for me. Can we have a Drupal 10 release for this?

I am getting the same error on Drupal 10.1.5. The fixes mentioned in #3 works perfectly fine.
Verified if the fixes are compatible with Drupal 9.5.11. It isn't working. Throwing error

TypeError: t.map is not a function
    at ue (ckeditor5-dll.js?v=35.4.0:5:447835)
    at Object.callback (highlight.js?s2rxpt:1:10856)
    at i.create (ckeditor5-dll.js?v=35.4.0:5:416819)
    at ckeditor5-dll.js?v=35.4.0:5:439488
    at Array.map (<anonymous>)
    at X.fillFromConfig (ckeditor5-dll.js?v=35.4.0:5:439398)
    at c._initToolbar (js_tdNyFRf0JHNvXCd9Fmk2k0H7Dmb7NBLR0o8jbyDEUz4.js:4:6337)
    at c.init (js_tdNyFRf0JHNvXCd9Fmk2k0H7Dmb7NBLR0o8jbyDEUz4.js:4:5924)
    at js_tdNyFRf0JHNvXCd9Fmk2k0H7Dmb7NBLR0o8jbyDEUz4.js:4:9072

Checking if any possible fixes for both Drupal 9 and 10.

Fixed the failing tests. Uploading the patch. Please review.

Thanks @mrinalini9 for the patch. Tested the patch #9 on 4.0.x branch.
The patch applies cleanly.

Checking patch src/Form/AntiDuplicatesFormAlter.php...
Applied patch src/Form/AntiDuplicatesFormAlter.php cleanly.

Reviewed the functionality. The patch makes sure the duplication check is done only on the selected content type.

Steps used for testing:

• Cloned the 4.0.x branch of the module on Drupal 10 installation.
• Enabled the module
• Created an Article with a specific title
• Tried to create a Basic page with the same title. It shows the configured duplicate message
• Applied the patch in #9.
• Tried creating Basic page with the same title. It works fine
• Tried creating an Article with the same name again. It shows the configured duplicate message

RTBC for me.

Reviewed the patch in #5 and tested on Drupal 10 installation.
Patch applies cleanly.

Checking patch templates/commerce-wishlist-user-form.html.twig...
Applied patch templates/commerce-wishlist-user-form.html.twig cleanly.

The Wishlist page works fine after applying the patch. Attached screenshots.
RTBC for me.

Reviewed the patch. The patch applies cleanly.

Checking patch src/Plugin/Filter/FilterNoFollowList.php...
Applied patch src/Plugin/Filter/FilterNoFollowList.php cleanly.

Can confirm that the reported issue gets fixed after applying the patch.
The rel="nofollow" for the blacklisted domains.
Also rel="nofollow" gets added for all domains except the whitelisted.

RTBC for me.

Reviewed the MR, the changes look good.
Applied the patch from the MR. It applies cleanly.

Checking patch src/AdminContentNotificationService.php...
Applied patch src/AdminContentNotificationService.php cleanly.

Verified the notification process without BCC emails after applying the patch. The email gets sent to the Default address.
Moving to RTBC.

Reviewed the MR. The changes look good.
Also verified the module installation through composer using the MR. Works fine.
Moving to RTBC.

Please do not forget to change the issue status as per this → guidelines :)

Thanks for the steps @Victonator.

The changes look good but you have not pushed the changes in the proper branch. You have pushed the changes into 3.0.x branch instead of the issue specific branch.
Check this commit

Please push the changes in 3391938-could-not-parse branch.

Please go through documentation → incase you have not done before.

Fixed the phpcs issues as per Drupal and DrupalPractice sniffs.
Except the below error related to javascript as it breaks the functionality.
TRUE, FALSE and NULL must be uppercase; expected "TRUE" but found "true"

Sure @aleix. Just followed this process for testing purpose so i could install the module from the MR using composer instead of using git.
Any suggestion on the safer method to test it? :)

Thank you @schillerm for the catch. Pushed the fix in the MR.

Reviewed the MR.
Tested the module composer setup through the issue fork on a Drupal 10 installation(10.1.5) and tested the basic functionality. Works fine without any issues.

Did the following steps for testing:

1. Setup a Drupal 10 site through composer.
2. Installed the module using the issue fork by setting the composer repositories.
   

   {
               "type":"vcs",
               "url":"https://git.drupalcode.org/issue/commerce_ticketing-3382034.git"
           }
   

3. composer require "drupal/commerce_ticketing:dev-3382034-drupal-10-upgrade"
4. The module gets installed successfully.
5. Enabled the module and the related Drupal commerce modules. The module gets enabled without any errors.
6. Did the module configurations as per the documentation. Setup the ticket type, product type and product variation using the ticket type. Enabled ticket for order type.
7. Completed the checkout process for ticket type product. The ticket gets generated properly.

Completed the pending code changes. All the tests are passing now.
Please review.

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

@Victonator Can you provide detailed steps to reproduce this and also please provide the screenshots if possible.

arisen → created an issue.

Hi @prestosaurus, would it be possible to have a development release for Drupal 10 using the 9.0.x or maybe a beta release too? Will be very helpful.

Verified the module functionality on Drupal 10 installation using 9.0.x. Seems to be working as expected. Thanks.

Thanks for the clarification @larowlan :)
I had read about the plan to remove it, but did not verify its presence in Drupal 10 core.

All the Drupal 10 changes are ready except the info.yml file changes.
https://www.drupal.org/project/views_url_alias_filter/issues/3290562 📌 Automated Drupal 10 compatibility fixes RTBC

Hopefully the maintainers create a Drupal 10 stable release soon.

Reviewed and applied the patch on 8.x-1.x branch of the module. The patch applies cleanly.

Checking patch views_url_alias_filter.info.yml...
Applied patch views_url_alias_filter.info.yml cleanly.

Verified the functionality on Drupal 10 site.
The module gets installed and the contextual filter functionality works without any error.

Also can confirm that other Drupal rector suggested fixes present in 8.x.1.x branch. No more changes required to make it compatible with D10.

Moving to RTBC.

@ressa No the stable version of forum module is not installable on Drupal 9 if the composer file has "minimum-stability": "stable".

The stable release(1.0.0) of the module doesn't have core_version_requirement set to 9.4. You can check the info file of the stable releasehere.

The maintainers need to create a new release to support Drupal 10. Before Drupal 10 forum module was part of the core but won't be in Drupal 10 hence this module.

Also as per my opinion, we shouldn't be creating the composer.json file just to specify the Drupal version. More details here https://www.drupal.org/docs/develop/creating-modules/add-a-composerjson-... →

The maintainers have not released Drupal 10 compatible version of the module.

When we add "minimum-stability": "dev" in composer the dev release of the module gets installed which is compatible with Drupal 10. The Maintainers need to create a new release supporting Drupal 10 using latest code from dev branch incase there are no more changes required for Drupal 10.

Reviewed the patch and MR. Tested it on drupal 10 site.
The issue resolves as expected.

But not sure if it's the right approach.
Is it required to make the text field required by default? We can keep the field as optional in the field and make it required in the dependency settings based on the selected value. Attached the screenshot for the same.

Yes, there is no release for Drupal 10 yet. It is possible to use the development release if required but not recommended.
Would be ideal to have atleast a beta release for this with Drupal 10 compatibility. Any of the co-maintainers can take this forward?

Any plans for drupal 10 release or a development release?

Reviewed the MR and applied the patch.
The patch applies cleanly

Checking patch groupmedia.module...
Applied patch groupmedia.module cleanly.

The Error is gone after applying the patch.

Reviewed the MR and tested the patch locally.
The patch applies cleanly and the deprecation errors are removed.

Checking patch electra.theme...
Applied patch electra.theme cleanly.

@apatel0325 the issue cannot be marked as fixed directly. You need to mark it as RTBC with proper screenshots and testing steps.
The project maintainer will change the status to fixed after committing the fix to the codebase.

You can check the different issue status here:
https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-... →

Fixed the errors/warnings while applying the patch from the MR.

4.patch:30: trailing whitespace.
4.patch:33: trailing whitespace.
  *
Checking patch src/Form/TwitterFeedConfigForm.php...
Applied patch src/Form/TwitterFeedConfigForm.php cleanly.
warning: 2 lines add whitespace errors.

Please review.

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

Reviewed the MR and tested the patch on 2.0.0 version.

The patch applies cleanly.

Checking patch src/Form/DownloadCountExportForm.php...
Applied patch src/Form/DownloadCountExportForm.php cleanly.

The export all functionality works fine after applying the patch. The records are added as expected.

Re-rolling the patch for 4.0.x.
Please review.

@mrchristophy the patch submitted seems good.
But this issue is a duplicate of https://www.drupal.org/project/cl_components/issues/3333906 🐛 Fatal error on install Fixed .
Hopefully the maintainer will add the fix in the release soon. Thanks.

Applied the patch from the MR on Drupal 10.0.0.

It applies cleanly:

Checking patch src/Twig/TwigComponentLoader.php...
Applied patch src/Twig/TwigComponentLoader.php cleanly.

The drush installation error is resolved after applying the patch.

Regarding Drupal 9:
The module installation works fine without the patch(tried on Drupal 9.5.4).
The function signature is matching as declared in the LoaderInterface.
public function isFresh($name, $time);
The module installation works fine on Drupal 9 even after applying the patch.

Moving this to RTBC.

This issue seems outdated.
The js issue has been already handled in https://www.drupal.org/project/colorbox/issues/3286579 → and added in 2.0.0 release. Functionality is working as expected.
Please re-open the issue incase if it's still reproducible.

Tested the patch. The patch applies cleanly and the functionality works as expected on Drupal 10 site.

..external_link_popup % git apply 8.x-1.12_external_link_popup_D10_Compatible.patch -v 
Checking patch external_link_popup.info.yml...
Checking patch external_link_popup.libraries.yml...
Checking patch js/dialog.js...
Applied patch external_link_popup.info.yml cleanly.
Applied patch external_link_popup.libraries.yml cleanly.
Applied patch js/dialog.js cleanly.

• Setup Drupal 10 site.
• Clone the module repository
• Applied the patch on 8.x-1.x branch.
• Enabled the module and verified the functionality

Reviewed the patch in #4 on drupal 9.5.4 with php 8.1.

The patch applies cleanly:

Checking patch core/modules/options/src/Plugin/Field/FieldType/ListItemBase.php...
Checking patch core/modules/options/tests/src/Kernel/OptionsFieldTest.php...
Applied patch core/modules/options/src/Plugin/Field/FieldType/ListItemBase.php cleanly.
Applied patch core/modules/options/tests/src/Kernel/OptionsFieldTest.php cleanly.

Testing steps:

• Setup drupal 9.5.4 site
• Enabled Layout builder for default display of basic page.
• Added text list field with no options.
• Tried to edit the layout. It throws the error as mentioned
• Applied the patch and verified the layout edit functionality. It works fine

Patch in #2 fails to apply on version 2.0.1.

Submitting updated patch. Please review.

Reviewed the patch and applied on 2.0.x branch. Patch applies cleanly and module works as expected.

Testing steps:

1. Cloned the project(branch 2.0.x) on a drupal 10 site.
2. Applied the patch in #2.

3. Checking patch modules/webform_iban_field/webform_iban_field.info.yml...
   Checking patch iban_field.info.yml...
   Applied patch modules/webform_iban_field/webform_iban_field.info.yml cleanly.
   Applied patch iban_field.info.yml cleanly.

4. Installed the module and functionality. Check screenshot.

Moving to RTBC.

Tried composer installation of the module on drupal 10.0.0. It works.
But looks like for me it doesn't install the stable release of the module instead it installs from the dev branch 4.0.x.
Check the attached screenshot. Confirmed the same in the composer.lock.

Probably adding "prefer-stable": true in the root composer should solve the above issue.

The patch applies cleanly on 8.x-1.x branch.

Checking patch linked_field.install...
Checking patch linked_field.module...
Checking patch src/Form/ConfigForm.php...
Checking patch src/LinkedFieldManager.php...
Checking patch src/LinkedFieldManagerInterface.php...
Applied patch linked_field.install cleanly.
Applied patch linked_field.module cleanly.
Applied patch src/Form/ConfigForm.php cleanly.
Applied patch src/LinkedFieldManager.php cleanly.
Applied patch src/LinkedFieldManagerInterface.php cleanly.

All the Phpcs errors and warnings fixed after applying the patch.

Added the requested changes in the MR.
Please review.

The issue is not coming up when this module is used on its own. I get the error when using the module https://www.drupal.org/project/like_and_dislike → which uses votingapi as the dependent module.

The issue is reproducible when we attach a like and dislike widget on any entity display.
The like and dislike widget makes a call to VoteResultsStorage to get the counts for the likes and dislikes. Here is the trace:

Drupal\Core\Entity\Query\Sql\Query->prepare() (Line: 80)
Drupal\Core\Entity\Query\Sql\Query->execute() (Line: 29)
Drupal\votingapi\VoteResultStorage->getEntityResults('node', '1', 'like', 'vote_sum') (Line: 65)
like_and_dislike_get_votes(Object) (Line: 75)
Drupal\like_and_dislike\LikeDislikeVoteBuilder->build('node', '1')

I have noticed that the votingapi module is not using the VoteResultsStorage anywhere to get the counts. Instead there is custom plugin manager service defined VoteResultFunctionManager which is used instead.
There is a functional test written for the same.

What would be the recommend approach moving forward considering VoteResultsStorage might be used by other modules. I can provide the patch accordingly.

Functionality issue with the patch on #7.
Adding updated patch.

Thank you pretosauras. Looking forward to it.
Happy to help incase needed :)

Thank you @apaderno for the clarification. Do you have any suggestion on how we can take the project towards Drupal 10 compatibility?
One and only maintainer of this project seems to be inactive on drupal.org for the last few months or maybe years.

Contacted the maintainer prestosaurus through the contact tab on 14th Feb 2023.

Added a MR please review.

arisen → created an issue.

As mentioned in comment #2 of Project Update Bot, the patch is not fully covering the Drupal 10 compatibility.

Since the patch has already been merged with the development branch submitting a new patch with only the additional changes required.

Changes:

• Composer rules updated as per https://www.drupal.org/node/2514612#s-drupal-9-compatibility → . Drupal core composer dependency not required.
• Updated the core version requirement.
• Updated the behaviours as per https://www.drupal.org/node/3158256 → .

Note:
This module is dependent on https://www.drupal.org/project/votingapi → .
VotingApi module doesn’t have a drupal 10 release yet. Manually installed drupal 10 compatible dev version using
composer require 'drupal/votingapi:3.x-dev@dev’

Manually fixed query issue with voting api module as per https://www.drupal.org/node/3201242 →

Testing Steps:

1. Clone the 8.x-1.x branch of the module.
2. Install the voting api module by using composer require 'drupal/votingapi:3.x-dev@dev’.
3. Apply the patch.
4. Install the module.
5. Configure like and dislike feature on any content type.
6. There will be error thrown from the voting api module. Fix it as per https://www.drupal.org/node/3201242 → .
7. Clear the cache and review the like and dislike functionality.

P.S. - New developement branch for drupal 10 would be better.

Since the patch has been already merged with the dev branch, tried installing the dev release through composer.

Encountered the following issue.

Info from https://repo.packagist.org: #StandWithUkraine
./composer.json has been updated
Running composer update drupal/like_and_dislike
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drupal/like_and_dislike dev-1.x requires drupal/core ^8.7.7 || ^9.0 -> found drupal/core[8.7.7, ..., 8.9.x-dev, 9.0.0-alpha1, ..., 9.5.x-dev] but the package is fixed to 10.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/like_and_dislike 1.x-dev is an alias of drupal/like_and_dislike dev-1.x and thus requires it to be installed too.
    - Root composer.json requires drupal/like_and_dislike 1.x-dev@dev -> satisfiable by drupal/like_and_dislike[1.x-dev (alias of dev-1.x)].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.
composer [require drupal/like_and_dislike:1.x-dev@dev] failed, composer command failed: exit status 2. stderr=

Can we have atleast a dev release for this?

Added the patch.
Please review.

arisen → created an issue.

arisen → created an issue.