Automated Drupal 10 compatibility fixes

Getting rid of jquery.once. See https://www.drupal.org/node/3158256 → .

Tested #2, #4 and #6 on D10.0.3 and so far it runs well. No new issues to report.

D10 compatibility was missing on this file /tests/themes/responsive_menu_theme_test_nobp/responsive_menu_theme_test_nobp.info.yml. I have added it and have consolidated all the patches into one patch.

I tested patch #8 on latest 10.0.7 drupal version which is applied cleanly and working as expected..module showing compatible in upgrade_status and also there are false positive issues in drupal-check which are ignorable...so making it RTBC for latest D10 release..

Thanks for working on this! However, this can't possibly be RTBC if the testbot is failing. We need to see passing green tests before this could be committed.

Cheers,
-Derek

Upadated patch #8 for passing the test kindly review..

Thanks for these patches and your time! It looks like the tests are failing on the polyfills inclusion. I wonder whether with release 5.x we can drop IE support? Considering Drupal 10 doesn't support IE I think it's safe to remove it. It will mean removing the test, the form item and the config.

Thanks for the patch. Have tried it on a site migrated to D10 and it behaves as I expected.

The patch is also working for me - so we can mark this as RTBC.

Is there a chance to push the changes to a new release? We need to update our page to D10 and this module is one which is incompatible to D10.

{
"name": "drupal/responsive_menu",
"version": "4.4.2",
"source": {
"type": "git",
"url": "https://git.drupalcode.org/project/responsive_menu.git",
"reference": "4.4.2"
},
"dist": {
"type": "zip",
"url": "https://ftp.drupal.org/files/projects/responsive_menu-4.4.2.zip",
"reference": "4.4.2",
"shasum": "26d13cc0fa3bbaf4a4a83f0012095e01cbcc5272"
},
"require": {
"drupal/core": "^8 || ^9"
},

I have applied the patch to D10 compatibility issue. When I checked the composer.lock file noticed that still it required Drupal core 8/9. That's why when I am trying to update drupal core it's failed.

I can also confirm the combined patch in #16 is working, this is a really great module and one of my only blockers to updating some sites to D10.

Any chance of getting a working release out with the patch rolled in please? If there are sub issues (such as the IE polyfill stuff) can these get put as active issues so people can help out and get this module fully kick ass.

Could we also create a fork of the current 4.4.x and 5.x branches with the changes? It's not possible to install the module with Composer with a patch but it is required to use a fork. So it would be more easy to test the module with Drupal 10 if we had a fork with the changes.

I also vote for updating the dev branches, but here's how I've worked around that.

Clone the project repo into modules/pinned. Download and apply patches in that directory, or check out the issue fork you want to use. Maybe add a readme that describes the patches or the commit you used.

If the module has composer dependencies, set it up as a custom module in composer so they are picked up with composer install.

Git is weird about checking in other git repos, and I don't totally understand it. Dev modules installed with composer will include the git repo but git warns you when you add it. I have been deleting dev repos with [find -name .git -exec rm -rf {} \;], but DO NOT RUN THAT IN YOUR ROOT DIR!!! If anyone has insight on a better workflow, I'd love to hear it.

Composer updates will clone the dev repos again, so I have to repeat this often. However, it won't touch ones in modules/pinned, since they aren't installed via composer.

If I have to work on the pinned module again, I add the project repo or issue branch as a remote. [git init; git add .; git commit -m "Initial commit"; git remote add origin PROJECT_REPO; git checkout BRANCH --force; git clean -fd . (to clean up stray files like INSTALL.md)].

Now you have the latest changes from the branch you want, with your previous version saved in a commit. Depending on what you want to do, you could reapply the patches, or add more issue branch remotes and merge those branches in.

If you follow these steps, don't add the module with composer or else you'll get a duplicate and confuse Drupal. To go back, delete the pinned module and install the project with composer again. If Drupal is still looking in the old dir, you have to hack the database, I think to truncate one of the cache tables. If you can disable the module first, that saves some trouble, but is not always possible.

@mortona24k The above flow doesn't at least for us work because we use automated deployments and we need to be able to install the module with Composer completely.

I now created a new issue fork from this issue and applied the patch #12 to it.

I was able to install the patch and it seems like our menu is working again. I need to do more testing that our all styles still work but at least I was able to now get rid of the deprecated jquery.once errors.

To install the merge request in your project with composer you can follow this guide → .

In your composer repositories add this:

{
  "type": "git",
  "url": "https://git.drupalcode.org/issue/responsive_menu-3297964.git"
},

Then under normal Composer repository for Drupal add the module as excluded:

{
  "type": "composer",
  "url": "https://packages.drupal.org/8",
  "exclude": [
    "drupal/responsive_menu",
    ]
},

And finally you can install the forked version with Composer:

composer require "drupal/responsive_menu:dev-3297964-automated-drupal-10-compatibility-fixes"

This should install the merge branch with all the Drupal 10 fixes applied.

We have the changes on the issues fork https://git.drupalcode.org/issue/responsive_menu-3297964/-/tree/3297964-... are working on a number of sites without issue.

Would be great if we can get a dev release with this at a minimum so we don't have to keep using the issue fork to install it.

Hi,

+1 with #27

Thanks a lot

I've merged this into the 5.0.x branch and created a 5.0.0-alpha1 release with Drupal 10 support.

Automatically closed - issue fixed for 2 weeks with no activity.