Max Mega Menu falsely rendered as bullet list in Site Editor of Block Theme

Hi abitofmind,

Thanks for reporting this. It was fixed in previous versions of gutenberg (we had to add needless ‘.wp-block’ rule into the style.css file to “allow” gutenberg to load it), but maybe things have changed again. I’ll take a look.

Regards,
Tom

Hi abitofmind,

I’ve tested locally, on Twenty Twenty Three, with and without the Gutenberg plugin and it’s working OK for me here.

Please check this path on your installation:

/wp-content/uploads/maxmegamenu/style.css

Does that file exist? Is it loaded in the site editor?

Regards,
Tom

Thanks that you have started an investigation! Your hints did not solve it yet. Looks like we need further debugging.

1. I’m running WP 6.1.1 and NO Gutenberg plugin. So I get the version of Gutenberg that’s included with that core version.

2. style.css exists and is referenced in head like this:

<link rel="stylesheet" id="megamenu-css"  media="all">

Note: My media library is on a subdomain.

• That’s different to a standard configuration.
• But an official core configuration option: WordPress > Settings > Media: Changed Store uploads in this folder and Full URL path to files accordingly.
• With this setup I have had yet no issues with media rendering or other plugins.
• But maybe there’s some issue with this in your plugin (certain hard coded assumptions in your code, cross-origin policies, etc).

For further debugging I would like to send you the URL in a PM as the website is too incomplete and embarrassing to share it here publicly. Please contact me on my corresponding Slack handle @abitofmind and I will send it to you.

• This reply was modified 1 year, 8 months ago by abitofmind.

The DOM while editing the header in the Site Editor

1. html → head → has <link rel="stylesheet" id="megamenu-css" media="all">
2. Selecting a menu item in the active Site Editor and opening macOS Safari’s CSS Inspector shows that no classes from MMM’s style.css get applied, although in theory they sure should have the maximum specificity:

• This reply was modified 1 year, 8 months ago by abitofmind.

Hi,

If you open https://media.example.at/maxmegamenu/style.css, can you see why the selectors are not matching the html output?

Please go to Mega Menu > Tools to regenerate the CSS and make sure the timestamp at the top of style.css gets updated.

Regards,
Tom

1. The CSS file gets regenerated with the proper timestamp and cachebusting works ok. Nothing which interferes on that level. It all arrives in the browser as intended.
2. It is no browser specific issue. Happens both on Safari and Chrome.
3. There seems to be a CSS specificity issue. I hoped that you as the plugin creator can tell me why it matches in the output (frontend) but not in the Site Editor. But you tell that in your tests you noticed no difference. Did you also use WP 6.1.1 and Max Mega Menu 3.1.1. ?

More debugging tools at our disposal now

1. Crumb Path / xPath comparison: I meanwhile managed to get the xPath and crumb path of the very same element by this great hint : The list element that represents the menu root element “Skills” which itself has sub items:
   a) Once in the DOM of the output (frontend) where it is rendered fine
   b) and once in the DOM of the Site Editor, where the whole menu is falsely rendered as a huge bulleted list.
   I hope that this can help you understand why your style, although updated on the server and reaching the browser, does not match properly.
2. Safari has the possibility to save .webarchive files. This is a dump of the DOM (including assets, local storage, cookies, etc) as I see it. This could help you. For security reasons: I would send you these via PM + I would reset my cookies/password thereafter to avoid that anyone getting hold of these webarchive files to uses the cookies to log in as me. If you prefer/need a Chrome DOM dump, please tell me how to do it there.

Menu element “Skills” in OUTPUT MODE

XPath: /html/body/div/header/div/div/div[2]/ul/li[2]

Crumb Path
0: "html"
1: "body.home.page-template-default.page.page-id-30.logged-in.admin-bar.no-customize-support.wp-custom-logo.wp-embed-responsive.gspbody.gspb-bodyfront.mega-menu-max-mega-menu-1.vsc-initialized"
2: "div.wp-site-blocks"
3: "header.wp-block-template-part"
4: "div.has-global-padding.is-content-justification-center.is-layout-constrained.wp-block-group"
5: "div.is-content-justification-space-between.is-nowrap.is-layout-flex.wp-container-1.wp-block-group"
6: "div#mega-menu-wrap-max_mega_menu_1"
7: "ul#mega-menu-max_mega_menu_1"
8: "li#mega-menu-item-893"

Menu element “Skills” in SITE EDITOR MODE

XPath until iFrame: 
/html/body/div[1]/div[2]/div[2]/div[1]/div[3]/div[1]/div[1]/div[2]/div[2]/div[2]/div[3]/div[3]/iframe

xPath in iFrame til "Skills" menu item:
/html/body/div[3]/header/div/div[1]/div[2]/div/div/div/ul/li[2]


Crumb Path until iFrame
0: "html.wp-toolbar.interface-interface-skeleton__html-container"
1: "body.wp-admin.wp-core-ui.js.gspbody.gspb-bodyadmin.is-fullscreen-mode.site-editor-php.auto-fold.admin-bar.branch-6-1.version-6-1-1.admin-color-fresh.locale-en-us.block-editor-page.wp-embed-responsive.customize-support.mla-media-modal.sticky-menu.svg.vsc-initialized"
2: "div#wpwrap"
3: "div#wpcontent"
4: "div#wpbody"
5: "div#wpbody-content"
6: "div#site-editor"
7: "div"
8: "div.interface-interface-skeleton.has-footer"
9: "div.interface-interface-skeleton__editor"
10: "div.interface-interface-skeleton__body"
11: "div.interface-interface-skeleton__content"
12: "div.edit-site-visual-editor"
13: "div.components-resizable-box__container"
14: "iframe.edit-site-visual-editor__editor-canvas"


Crumb Path from iFrame HTML til "Skills" menu item
0: "html"
1: "body.block-editor-iframe__body.editor-styles-wrapper.admin-color-fresh.wp-embed-responsive.vsc-initialized"
2: "div.is-root-container.edit-site-block-editor__block-list.wp-site-blocks.is-outline-mode.block-editor-block-list__layout"
3: "header#block-9da4334b-456d-4bfd-a33c-2af71ee91f6c"
4: "div#block-7a72dfb0-97da-40a6-b0b9-cec9f0b0648c"
5: "div#block-cbdb1fbf-ccd8-41db-b500-1c8440880468"
6: "div#block-13f7b840-c1e8-4e7e-8820-4317758cc4a9"
7: "div.faae-ca-cd-f-fbc-u2jump.components-disabled"
8: "div"
9: "div#mega-menu-wrap-max_mega_menu_1"
10: "ul#mega-menu-max_mega_menu_1"
11: "li#mega-menu-item-893"

• This reply was modified 1 year, 8 months ago by abitofmind.
• This reply was modified 1 year, 8 months ago by abitofmind.
• This reply was modified 1 year, 8 months ago by abitofmind.
• This reply was modified 1 year, 8 months ago by abitofmind.
• This reply was modified 1 year, 8 months ago by abitofmind.
• This reply was modified 1 year, 8 months ago by abitofmind.

Note on the Site Editor DOM: The linked Crumb Path Javascript snippet matches up until html. So from the “Skills” menu item it traverses up until html, which to it is its root. But in reality that thing is within an iframe. So I added the path from that iframe up until the final top html element.

I edited this into the above post.

• This reply was modified 1 year, 8 months ago by abitofmind.

Hi,

Thanks.

Please can you post another screenshot of you inspecting the menu HTML, and paste the contents of style.css into pastebin.com and post the link?

If you check the network tab in dev tools, does it say it’s loading the style.css file correctly from your subdomain?

Can you try not using a subdomain? (just for testing)

Regards,
Tom

1. style.css (← Dropbox link, check it out) from the media subdomain arrives with HTTP 200 and the content is ok, timestamp on top corresponds exactly to when I did my last customizations.
2. Further screenshots below.
3. Test without subdomain: As a last ressort. Quite an effort. Before this we should test everything else we could.
4. What about my offer for the Safari .webarchive files? These are a complete DOM dump.

Hi,

That all looks OK to me, so I am also not sure what is going wrong. I haven’t had any other reports so the issue, at the moment, appears to be limited to your install.

I have tested with a clean WP install, please see:

As you can see, it is working OK. I’m using Local to create a test site – maybe you could try the same steps.

In the mean time I suggest you continue using the Shortcode block to render the menu.

Regards,
Tom

Thanks for testing and sharing this with me. I had and have little doubt that the MMM-block works in general. But something with my config (WP, plugins, subdomain/media-library-config) may be different and causing the issues. For some other users possibly too.

The shortcode is a good enough workaround for me anyhow. Has the con that it’s less visual, but also the pro that it’s faster while in Site Editor (heavilyy recursive/encapsulated elements such as a deep menu always cause some degree of slowdown in a Web Browser based Site Builder such as the WordPress Site Editor). Block Themes and the Site Editor are quite new. Maybe your MMM block within a Block Theme did not have too many active installations yet, and of those only a few possibly encountered that bug, and of those I probably was the first to take the effort to report, instead of using the shortcode workaround. Hence I would like to undertake some last attempts to get to the cause of that bug.

I see that you are on macOS from your screen recording. So you have Safari too. And Safari has developer tools too. Wanna try out my .webarchive files? Then you can inspect much more comprehensible and debug this much easier I guess. I could send them to you via slack or a URL in a request to your https://www.megamenu.com/support/ form.

Ruled out some more things:

1. The menu that I used was special. I use Nested Pages which synchronizes my page hierarchy into a menu called “Nested Pages” which goes into a MMM menu position called “Nested Pages in Mega Menu”. But “syncing” is not less dynamic/dramatic than it sounds. Whenever you open Dashboard → Pages and restructure the page hierarchy there, that’s synced to the menu. But after that no more activities. So during “WP rendering runtime” or “Site Editor runtime” nothing should happen.
2. To rule out issues from this I created a fresh menu, 3 items, no children, entirely static. Still the same problem in Site Editor.

Some further ideas:

3. Header > Group block with option “Inner blocks use content width” > Row > Site Logo block , Max mega Menu block:

Further interesting observation regarding the output

1. Save the output as a Safari .webarchive file.
2. Open webarchive in Finder via QuickLook
   → Mega Menu renders as a raw HTML list too!
   Note: This opens a WebView rendering instance which utilizes WebKit, but is a bit different to full blown Safari. Most of the times web-pages (.html, .webarchive, .weblocation which is just a bookmark file) render the same as in Safari. But sometimes they are different.
3. Open webarchive in Safari (opens via file:// scheme)
   → Renders Mega Menu ok.

Screen Recording (25sec, 700 KB, Dropbox):

Remarks

• R1) Now we know it is something which does not only affect the rendering in the Site Editor environment, but also in the output (if watched as webarchives in QuickLook).
• R2) In my experience so far webarchives are really good DOM replicas, but if something very runtime-specific/dynamic is inside it may not be 100% be the original experience. Things such as cross-domain-policies come to my mind, as something which possibly can not be 100% simulated (if not serialized into that webarchive) also maybe HTTP response headers or other protocol level stuff.

Suspicions

• S1) As the output is affected too now, maybe it is another plugin which interferes (in the WP markup) or in the JS/CSS that’s output?
• S2) Or this special limited web browser environment (QuickView) is crippled in a certain aspect the same/similar way liked the iframe/shadow-DOM environment inside the WordPress Site Editor — in comparison to a full web browser environment such as in standalone Safari or standalone Chrome.

• This reply was modified 1 year, 8 months ago by abitofmind.

Hi,

I think your suspicion no. 2 is probably in the right direction. It does at least – based on my own testing and lack of other similar reports – seem limited to your environment at the moment. As you say, it is probably best to just use the shortcode option for the moment. If more people report the same issue, I will of course investigate futher.

Regards,
Tom

Ok, so for the time being I will work with the shortcode, and we leave it with that.

Everything is documented here in detail. Potentially affected users should be able to find it via search. Note that the thread will auto close in AFAIR 6 months of inactivity. If you want to keep it alive for users to post below, you may make a minimal post, to prolong the thread activity timeout.

Should the problem go away on my side (e.g. after a WordPress update) I will report that here. Good luck!