JS and CSS files moved in mmenu version 6.x

Thanks for the report, I'll look into it. We'll probably need to support both paths for backwards compatibility, or require everyone updates to version 6 of the mmenu library.

Great! Thanks for the patch, I'll try and review asap

Hello,

Same problem on the Drupal 8 version.

I wanted to test the module and so I downloaded the last version of mmenu, 6.1.0.

Here is a patch for the Drupal 8 version.

^ Does the responsive menu work with the patch? I'm wanting to implement this menu on a personal site.

Can you please test it and report back?

I've tested the patch from Grimreaper and can confirm that the module now works for Drupal 8. Exact steps that I followed:

• Used the command line to navigate to the responsive_menu folder
• Ran the following command to apply the patch curl https://www.drupal.org/files/issues/responsive_menu-mmenu_evolution-2867087-8.patch | patch -p1
• Went to the /libraries/mmenu directory and created a directory titled dist
• Placed the jquery.mmenu.all.css and jquery.mmenu.all.js files inside the newly created dist directory
• Went to the Drupal site and placed the Responsive menu mobile icon block

Excellent! Thank you for testing. I'm going to mark this as RTBC and switch to 8.x for now. Then we can switch back to 7.x and test that other patch.

My only concern with committing this patch is that it will break backwards compatibility with currently installed versions of mmenu which are prior to 6.x.x. I'm not sure how to tackle that at the moment. Any ideas?

Hello,

For backwards compatibility, here is a suggestion.

Maybe declaring two Drupal libraries, one for < 6.0.0 and one for > 6.0.0.

Adding a check if a certain file is installed or parsing one of the .json files at the root of the library as its have the library version, and then adding the appropriate Drupal library.

That was about my line of thinking too. I guess we'd have config that would be set once the settings page was saved that would set the library version (via a file check as you mentioned). The setting could be hidden from the form so it would be transparent to the user. This way there is single file check when viewing/saving the form avoiding doing it every page load.

I can confirm that #8 works great with mmenu 6.1.0

As an added complication, the 6.x version that is downloaded from the mmenu site has a different file layout. This is the layout that you get if you run the new task runner to compile just the files you need. So its getting a bit complicated and we'll either have to direct people to download a github release and detect the file layout for 5.x and 6.x versions, or we try to cover all permutations including compiled versions. Needs more thought.

#8 also works fine for me. Thanks!

Same patch as #8 for D7

The latest version of mmenu gets downloaded into libraries/jquery.mmenu not libraries/mmenu. #8 now no longer works. Hammer.js has a similar issue it is downloaded into libraries/hammer.js not libraries/hammerjs.

If it makes any difference, I am adding the libraries via composer and custom repositories for each library.

This has always been the case grshane, you will need to rename your libraries after you have downloaded. You can also do this in your composer.json by specifying the path and name in the extra section in installer-paths. For example for masonry I do this:

"extra": {
    "installer-paths": {
        "web/libraries/masonry": [
            "desandro/masonry"
        ]
    }
}

If I didn't do that then masonry would expand to a folder called masonry-3.3.2

I'll try and write a more complete example for the libraries this module uses soon but hopefully that should get you started.

Thanks @anrikun, the patch looks good. I'll need to test then will commit. I also have some other backport work to do on the D7 branch from other issues so a release might not be imminent but hopefully quite soon.

Ok folks, I think we're good! Thanks for everyones help, I'm going to close this issue