🇺🇸United States @themodularlab

Setting this state back to reviewed and tested. I will update once I can get a release out.

@rraney,

Yes, I have been following this. Really sorry this issue (and others are still unreleased) I hope to release this and other fixes soon. For now, it seems the patch resolves things. The other maintainers who used to help with module are not longer able to and I have extremely limited bandwidth these days. I'm going to update the module page soon to look for maintainer help. I really appreciate everyone's help on this.

@aluzzardi,

#3 works for me. Thanks!

Applying the patch from MR10177 on 10.3.8 is also showing improvements for me. I have only tested locally but will be pushing to a dev environment soon so I can report back later. But so far so good!

@gravelpot,

I have only personally observed on a local env and via Acquia. I have seen others reporting similar issues but unsure of what hosting they are using.

@gravelpot

We haven't done any official performance testing but rather this is something observed by myself and my clients. Prior to updating to 3.14.2, page load times were pretty normal. After 3.14.2, our page load for a node edit form can be well over 30 seconds. We are building a new site so there is very little content at this point. As a test, I downgraded back to 3.14.0 and page load times returned to normal.

There may be some server settings in place on our Acquia env that could be partially contributing to this but also the performance and page load times return to normal when downgrading back to 3.14.0.

Based on this part of the 3.14.2 patch, it looks like they're recursing through everything even before trying to render it?

themodularlab → created an issue.

I know this probably requires a new issue to be raised, but after updating to twig 3.14.2, I'm seeing extremely slow load times that did not exist prior to 3.14.1 or 3.14.2. Just curious if anyone else is also encountering performance issues.

I just encountered this same issue, and while I am on the 3.x branch, this patch fixes the issue for me.

@dco,

When adding a block to TBMM, the block has to be loaded in a block region via the block admin ui for Drupal and thus the MM to be aware of it. Our recommendation is to use a hidden theme region. It will also require a cache clear for TBMM to be aware of new blocks.

@sj.suraj,

If these are new blocks you are trying to attach to TB Megamenu, you'll need to clear drupal cache before they'll be visible via TB menu admin.

I am also seeing this error after upgrading to Drupal 10.3.

While new feature development has stalled a little bit here, we do plan to add functions that will easily allow you to select between a TB theme or your styling. Until that happens, @ravi-kant's suggestion of using libraries-extend/copying the source sass files into your theme should suffice.

No problem. I'll leave this issue open in case others encounter this issue and/or you can find some more concrete evidence that this is a bug in TB Megamenu.

Just out of curiosity, since you said you recently added this module, do you have at least one menu item added and have saved the mega menu builder? There's another issue in the issue queue ( https://www.drupal.org/project/tb_megamenu/issues/3291741 💬 TB MegaMenu error: Post was missing the following information: menu_config Active ) where some folks narrowed it down to rendering a megamenu without any items in the menu.

And this is only occurring on pages using webform? In a non-production environment, what happens if you exclude the TB Megamenu block from a page that is experiencing the issue? Some ajax is used on the megamenu admin builder ui, but not really for rendering on a page on the front-end.

Are you seeing any errors drupal watchdog or other php logs? If so can you share them? Are you only seeing issues with the mega menu when using webforms or is it occurring on other pages without webforms? I would also suggest upgrading to https://www.drupal.org/project/tb_megamenu/releases/3.0.0-alpha4 → .

I can see what we can do about error handling for this, but ... the mega menu does expect that you would have at least one menu item available before using.

I'm setting this back to fixed status as the original issue here has been addressed with new 1.x and 3.x releases. If you are still having issues that my previous comment doesn't address (uninstall and reinstall via composer) then I would suggest creating a new ticket.

Actually, looking into this further, Drupal.org packaging doesn't put version info in the dev version. It only adds it to releases. Right now, the latest alpha of the 3.x branch is identical to the dev version, expect, you'll see the version data in the info.yml file. I would suggest using the latest alpha instead of dev.

Are you still seeing an issue when using the dev version? Because of the issues we had cutting 1.x and 3.x releases recently, you may need to remove TB Megamenu and then re-add it via composer so it has a clean install.

Version info is added via the Drupal.org packaging script. Not sure why it's not being added in our case.

There were some issues with our recent 8.1.8 release. We issued a new 8.1.9 to fix as well and also we've issued a new alpha4 on the 3.x branch. You may need to update the minimum composer version of the module. Let us know if trying to use the 3.x dev branch still references 8.x-1.8 or 8.x-1.9.

I am unable to reproduce this error. Can someone who's seeing the error, provide more details such as drupal version, etc.

Can you provide some more info on the issue? Looking at the screenshots, on the tb example, both items are links which is expected to render as a .

Thanks for catching this. I have a fix available for this that I will add shortly.

Is this still an issue? I have just tested on the latest dev version of the 3.x module and have not been able to reproduce this issue.

@mambrus,

Can you provide some more info, particularly around @knaffles question? Is this still an issue?

Hi,

Can you provide more info about the error you are receiving?

Reviewed the 3.x patch. Merging it now. I'll look to get the 1 and 2.x versions update soon, but continue to rely on the patches for those in the meantime.

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

Approved and merged.

Reviewed and approved. Thanks.

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

3.x branch is not compatible with drupal 8 or 9 due to a symphony dependency.

Hi Ruslan Piskarov,

See Comment #3 on this issue. If you use the Drupal Lenient composer package and then create patches to fix the issue referenced on #3 as well as patching the info file to allow for Drupal 10, then you should be good. That issue though currently prevents us from just setting the version requirements to 8, 9, and 10.

Hmm good question. I think you have to be on 9 to use php 8. Might need to reconsider any support of 8.x at this point since it's been EOL for a bit now.

@mmenavas,

Thanks for submitting this. Some background on this. We took over maintaining TB a few years ago. The 8.x branch is the legacy version of the module while the 2.x and 3.x are our versions. The 8.x is really only the "recommended" version because we don't yet have an official release for 2.x (d9) and 3.x (d10) yet. I'm not opposed to making 8.x Drupal 10 compatible as long as it still works for 8 and 9. At this point, we're really only supporting bug fixes and security issues for the 8.x branch.

Another issue you will run into. In https://git.drupalcode.org/project/tb_megamenu/-/blob/8.x-1.x/src/Contro... on line 88, There's an issue where the usage of getContentTypeFormat() isn't compatible with Symfony 6. You have to use getContentType() instead. See https://git.drupalcode.org/project/tb_megamenu/-/commit/072b8dd984d98314.... That's the primary reason that we now have a 2.x and a 3.x branch, sadly.

I'm happy to consider merging this and making 8.x compatible with 8, 9, and 10 but it will have to work for all those versions.

One thing you could consider using is the Drupal Lenient → to solve the D10 dependency issue, then you can rely on patches to address the remaining items until you are ready to move to the 3.x branch, which is WAY better by the way. :)

@japerry,

It works now. Thanks!

FYI, the post update hook added to this is failing for me.

>  [notice] Update started: acquia_dam_post_update_link_tracking_primary_key
>  [error]  SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '' for key 'PRIMARY': ALTER TABLE "acquia_dam_integration_link_tracking" ADD PRIMARY KEY (`entity_uuid`); Array

FYI, I removed the actual UUID from the output above. I can create a new ticket though if you want to treat this as a new issue.

This has been committed to both 2.x and 3.x dev branches. It will ship with the next release. Thank you for your help here.

Updating version to 3.x. Due to some Symfony 6 changes 2.x won't be compatible with D10. The branches will be the same except for instances of symfony 6 related deprecations.

I am actually dealing with this very issue on a client project. I'm going to apply a patch from the MR and test. I'll report back my findings.

@yospyn,

I added a merge request for both 2.x (d8/9) and 3.x (d10). Let me know know if these fix your issues. Here's a patch from the MR for each version:

2.x: https://git.drupalcode.org/project/tb_megamenu/-/merge_requests/74/diffs...
3.x: https://git.drupalcode.org/project/tb_megamenu/-/merge_requests/73/diffs...

I'm moving this to Needs Review.

@nikathone,

Thanks again for your patch. I made a couple of adjustments in order to account for arrays AND to maintain the sanitization of the text since it allows some html.

@yospyn, We did release a new alpha of for the 2.x and the 3.x branch that should have addressed the white screen issues. You may need to try @nikathone's patch.

@nikathone,
I'll look to add your patch and see what other improvements we can make here.

Sorry for the issues everyone is having.

@nikathone,

Are you using captions? How we were previously handling captions ended up triggering an issue that's occurring in core so I had to refactor it a bit to work around it. My guess is that if you are using captions. It may be trying to pass that as an array because that's how it was orginally being set. You may just need to go into the TB menu settings, resave (hopefully not re-input captions), and then clear caches.

If that doesn't fix the issue, let me know and I can investigate further.

This is definitely an issue with Core. I don't think this is anything that is wrong or done incorrectly with TB Mega Menu related to this bug . Even after removing any references to functions that use the escape() function or htmlspecialchars(), etc. I still encounter the error. And it only happens after saving the menu from the core menu manager (and not TB).

Looks like this might be an issue with Core or at least a conflict between TB and Core. See https://www.drupal.org/project/drupal/issues/3352384 ✨ Add Exception for TypeError Argument must be String in \Drupal\Component\Utility\Html escape{} Needs work . While that issue is flagged as 9.5 the patch and issue still apply to D10. I'm currently investigating to see what can be done about this.

For Drupal 9: Use https://www.drupal.org/project/tb_megamenu/releases/2.0.0-alpha6 →
For Drupal 10: use https://www.drupal.org/project/tb_megamenu/releases/3.0.0-alpha1 →

For Drupal 9: Use https://www.drupal.org/project/tb_megamenu/releases/2.0.0-alpha6 →
For Drupal 10: use https://www.drupal.org/project/tb_megamenu/releases/3.0.0-alpha1 →

For Drupal 9: Use https://www.drupal.org/project/tb_megamenu/releases/2.0.0-alpha6 →
For Drupal 10: use https://www.drupal.org/project/tb_megamenu/releases/3.0.0-alpha1 →

For Drupal 9: Use https://www.drupal.org/project/tb_megamenu/releases/2.0.0-alpha6 →
For Drupal 10: use https://www.drupal.org/project/tb_megamenu/releases/3.0.0-alpha1 →

For Drupal 9: Use https://www.drupal.org/project/tb_megamenu/releases/2.0.0-alpha6 →
For Drupal 10: use https://www.drupal.org/project/tb_megamenu/releases/3.0.0-alpha1 →

Thanks @todea. Looks like something compiled incorrectly. A fix is forthcoming for both the 2.x and 3.x branches.

@todea,

Thanks for catching this. It's actually a symfony issue where getContentType is deprecated in 6.1 and removed in 6.2. Drupal 10 requires a minimum of 6.2. See my comment here: https://www.drupal.org/project/tb_megamenu/issues/3366463#comment-15102311 🐛 Cannot save menu with Drupal < 10 and 2.0 Alpha4 Fixed .

I'm going to fork our 2.x branch into 3.x which will be drupal 10 version of 2.x, but without the deprecations. An alpha release with the fix for this issue and a new 3.x release is incoming.

Thanks for providing a quick fix for this @notFloran. So basically the reason were using $request->getContentTypeFormat() instead of code>$request->getContentType is the former is deprecated in symfony 6.1 and removed from 6.2. Drupal 10 only works on 6.2. See: https://www.drupal.org/project/drupal/issues/3284422 → .

I think what I'll end up needing to do is to basically create a 3.x branch that is only drupal compatible and then maintain 2.x until drupal 9 is EOL.

I'll merge your fix as soon as I have a 3.x branch available.

@jrb,

I love this. Thank you.

I just tested your patch. Everything works as expected on config import and export. The JSON config is now readable.
I'll commit this to the 2.x branch and include it in a future release. Thanks again.

@cmchurch. Are you on the latest alpha?

This is what's in the most recent release (this is the webpack compiled js file dist/js/frontend.js):

      if (window.matchMedia("(max-width: ".concat(breakpoint, "px)")).matches) {
        thisMenu.classList.add('tbm--mobile');
      } else {
        thisMenu.classList.remove('tbm--mobile');
      }

see: https://git.drupalcode.org/project/tb_megamenu/-/blob/2.0.0-alpha4/dist/...

@hassebasse,

That is a good question. It "might" still apply, but I'm guessing it will need to be re-rolled.

D10 compatibility has now been merged! Thank you to everyone who helped with this. I hope to have our first 2.x beta out this week (possibly tomorrow).

@sidgrafix,

Good catch regarding how the library is requiring once.

The frontend.js in the dist directory is the compiled version. So yes, the js/frontend.js is not loaded, but the dist/js/frontend.js is. These JS files as well as our sass are all available in the module by design (and at the request of other users as well). Since there are changes to frontend.js, it needs to be recompiled.

There are also some elements in the latest patch/merge request that should use dependency injection but does not.

This has been merged into the dev branch. It will be included in the next release. Thanks for everyone's help.

This has been merged into the dev branch. I will look to get an official release out soon.

Of course and thank you @Anybody. I appreciate putting this on my radar. Work has kept me away from contrib projects lately but trying to get back in the habit of actually maintaining.

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

This has been merged and is now available via the dev branch. There are a few other things to include in the next release which should be this week. Thanks for everyone's help and apologies for taking so long here.

Yes! I'm an active maintainer. I'll see about getting this included in a release.