Nav Block: Style Presets and Tailwind classes not working

The current Nav-Block presets don’t work, have styling issues and it’s impossible to add TW classes to it.

Styling Issues

  1. Open the Post Editor/Site Editor
  2. Make sure to reset to Tailwind mobile first breakpoints
  3. Add a vanilla Nav-Block, select with preset
  4. SM breakpoint has no styling, because it’s starting at 768px

Style selection breaks

1.Select Primary → Styles → Preset (Esprit i.e.)
2. Nothing happens, due to JS error:

react-dom.min.js?ver=18.2.0:10 Uncaught ReferenceError: newkey is not defined
    at index.js?ver=
    at Array.forEach (<anonymous>)
    at Pe (index.js?ver=
    at index.js?ver=
    at Array.forEach (<anonymous>)
    at _e (index.js?ver=
    at Object.onChange (index.js?ver=
    at onChange (index.js?ver=
    at index.js?ver=
    at t.onChange (index.js?ver=
(anonymous) @ index.js?ver=
Pe @ index.js?ver=
(anonymous) @ index.js?ver=
_e @ index.js?ver=
onChange @ index.js?ver=
onChange @ index.js?ver=
(anonymous) @ index.js?ver=
t.onChange @ index.js?ver=
t.setValue @ index.js?ver=
t.selectOption @ index.js?ver=
I.f @ index.js?ver=
Xa @ react-dom.min.js?ver=18.2.0:10
B @ react-dom.min.js?ver=18.2.0:10
W @ react-dom.min.js?ver=18.2.0:10
qe @ react-dom.min.js?ver=18.2.0:10
Ke @ react-dom.min.js?ver=18.2.0:10
(anonymous) @ react-dom.min.js?ver=18.2.0:10
dl @ react-dom.min.js?ver=18.2.0:10
V @ react-dom.min.js?ver=18.2.0:10
Je @ react-dom.min.js?ver=18.2.0:10
pe @ react-dom.min.js?ver=18.2.0:10
fe @ react-dom.min.js?ver=18.2.0:10

Setting Classes Impossible

It’s not possible to set classes on child elements in the navigation builder. This way it’s impossible to use Tailwind on it.


Environment info

  • WordPress version: 6.4.3
  • Cwicly Plugin version:
  • Tailwind: on

Regarding the mobile first style problem, I’d like to pass on a workaround that works for the time being.

  1. Pick a Navbar Style preset
  2. Regenerate CSS (just in case)
  3. Inspect the navbar with a breakpoint of >768px, where the styles work
  4. Click a menu item with “.cc-nav-item” and checkout the generated CSS
  5. Copy the entire responsive CSS block starting with @media screen and (min-width: 768px)
  6. Paste it without the media query into the Nav Block’s Custom CSS code editor and hit save/update

Saw you changed some parts of the Nav block in the last update.
Please have a look on the preset styles not working. This is a real show stopper for me. :weary:

Hello @oppi,

This is on my to-do list but requires quite some thought on our end before we put this into practice. Why?

Simply because all users don’t set their base breakpoint on the lowest or highest media entry, which means that we would have the same type of bug report if we didn’t account for every possibility out there. Also, this means that we can’t predict what the breakpoint values for lg, mg, sm or the multitude of user created ones will be… Lots to plan for.

I was considering bringing the breakpoint transfer logic we have into the Nav block more specifically so that the user can interchange preset styles breakpoints without affecting other blocks (this would also solve the issue of requiring us to have multiple presets that might not apply in specific circumstances).

While I appreciate this can somewhat slow down getting a Nav block set up when designing in mobile-first, it’s important to note that you can start with a blank slate, and that the Nav block does work on desktop-first or mobile-first setups.


I know that navigations are the toughest parts in frontend development and a supreme discipline. In this case, I believe a working, yet basic, Navigation block could be achieved way easier and quicker.

We are dealing with just one crucial user setting. That’s the decision where the modal is visible. You could add a switch for “from/below” to cater for flexibility.

Example UI Design

My guess is that the style presets in their current form are hard coded and the culprit to this matter, right?

So it might be possible with this MVP:
The actual breakpoint numbers are known to Cwicly and generating the CSS based on the presets could depend on that single value the user chose earlier.
So we practically just have one decision and two ranges where to apply styling.

But I may be wrong about that, because I don’t know the inner workings as they are now. Maybe you could shed some more light on this in that case. I’d love to see this working again and possibly help out one way or another.

I’m quite aware that the base functionality is there. But to be honest, this particular block was one of the big selling points for me that actually made me buy a Cwicly license! You put so much effort in this like no other page builder / framework before and I deeply appreciate that. And the time it worked, the marketing was right: Get up and running in no time… literally “Cwicly”.

I’d like to get taken back to that promise. You get the point. :wink:

Hello @oppi,

I appreciate you putting this down, and as I have said, we have to make sure that the process for presets applies correctly for every circumstance.
The setting you propose is too general, and doesn’t take into account the possible changes a user might have made to the Nav block that he doesn’t want to see applied to a different breakpoint, what defines a preset, should preset styles be locked in… I can go on and on with many conditions that aren’t met with your proposal as it is simply too rigid and unrealistic.

Just to make things clear, as your messages do instill some doubt: the Nav block is completely functional and usable whatever your breakpoint setup looks like.
This is not base functionality, but full functionality.
The presets are cosmetic and don’t affect functionality.


While I truly understand that the functionality is undoubtedly existent from a developers point of view, please understand that for me as a customer it is not full functionality if I can’t pick presets like it was possible a few release ago.

And again, yes, as frontend dev myself I could build everything by hand. But this is something I like to avoid. This is why I opted for a solution like Cwicly.

But before we get into some meta discussion here, I’d like you to ask if it makes sense to just close this Bug and re-open the specific sub topics of the matter, because there seem to be some underlying JS errors as well?