Mobile Menu Doesn’t Span Entire Screen

Were you able to find a solution close to the time of this reply? I saw the issue you are referring to and tried investigating further. I didn’t have much luck using the element inspector, so I reloaded the page and now the issue had gone away!

Hi @bcworkz ! Thanks for getting back to me. Oddly enough, clearing the cache and refreshing on Edge is working now (it had not in the past, and I swear I tested this at least 3 times before). Thanks for testing on your end as well! … so it seems to have worked itself out, which is great.

That’s on edge. On the google mobile app (not chrome, but the google app itself) the problem still remains, unfortunately. I tried all the basics (cache clearing, refresh, incognito mode), but to no avail.

I’m open to any suggestions, of course!

Looks OK when I checked on my Google app. If yours had cached earlier CSS the app might still be using it. I’m unsure how one would clear an app’s caches. CSS files often have a version query string appended. If you were able to alter this, it would invalidate the cache and force the app to get an updated copy. May not be worth the effort since it’s likely only an issue on your device.

@bcworkz The odd thing is that the issue disappeared temporarily on my google app, then reappeared again. No clue why, but like you said, since it seems to be just on my end, it’s probably not worth the effort.

I appreciate the help with this! Hope you have an amazing rest of your week. Cheers!

Or maybe not ?? I thought to double check and was able to see the issue again. I think the intermittent nature depends on what side scroll position there is on page load. When scrolled right against the left margin the site looks normal, but it actually overflows the viewport.

The header is actually correct, it’s the content that’s overflowing the viewport. The responsible CSS is this:

@media screen and (max-width: 959px)
body.content-full-screen.page .entry .alignfull {
    margin-left: -5.5% !important;
    width: 111% !important;
    max-width: 111% !important;
}

It’s in your theme’s style.min.css file. Not sure why it’s even there, it looks like a crude patch. This theme hasn’t been customized has it? It’s a bit of a process to correct a minified file. It’s normally not a good idea to alter themes that are subject to periodic updates, but the !important modifiers make it difficult to override through other means.

If this is not part of some theme customization, I suggest seeking guidance through the theme’s dedicated support forum. IMO it doesn’t seem like this CSS should be there, but I don’t know what its intended to do.

Hey, thanks again for this insight @bcworkz! I’ll dig into it a bit more this weekend. I’m not sure what the devs before me did on the site, but I don’t think the theme was modified, at least not to my knowledge. Maybe the child theme was? No idea. I’ll reach out to the theme’s support forum and do some research on how to correct a minified css file. If you have any tips on this, please feel free to point me in the right direction. In the meantime I’ll do some searching on my own.

Cheers!

There should be an un-minified version of the same file, probably style.css. You make your change there, then run it through a minifier and save the result as style.min.css. There are tons of online minifiers, search “css minify online”.

I see now that when I said it’s “a bit of a process” it could be interpreted as intentional understatement, that it’s actually a big deal. But no, it really is just a small process ??

Making this change could have an adverse effect elsewhere, I’ve not investigated. But setting a body tag greater than 100% doesn’t seem like it’s ever a good idea to me. Whatever this is trying to solve, there’s likely a better solution.

Did not see your reply until today, but thanks again @bcworkz! I’m guessing I’ll gain access to the style.css file via FTP? I’m thinking I should attempt this process – meaning edit the style.css from the staging site, drop it into an online minify site, replace both style.css and style.min.css via ftp, and that should hopefully do the trick? Does that sound about right?

So I looked at the style.css file for both the child and parent themes for OceanWP on both production and staging sites.

• I don’t see any customization whatsoever when I look at the theme file editor view of the style.css files
• I also used FTP to look at what seemed to be the same files … ~/wp-content/themes/oceanwp (or /oceanwp-child), but the files looked identical to what I saw in the theme file editor view.
• There is custom CSS, however (Appearance/Customize/Custom JS/CSS), but none of this was there:
@media screen and (max-width: 959px) body.content-full-screen.page .entry .alignfull { margin-left: -5.5% !important; width: 111% !important; max-width: 111% !important; }
• Additionally, I’ve also looked here (~/wp-includes/css/block-library/), but neither the style.css nor style.min.css show that bit of code.

I’m guessing that I’m looking in the wrong place. Those seem to be the most obvious places, but clearly I’m mistaken. Any suggestions?

• This reply was modified 1 year, 7 months ago by 1ramyt.

Yes, FTP is your best option. Or your hosting’s file manager. Your suggested process sounds appropriate.

style.min.css is an ambiguous name for OceanWP, there are likely at least two different files with the same style.css name. The one we need is at
/wp-content/themes/oceanwp/assets/css/style.min.css

There should be a companion style.css in the same folder. If you cannot find the offending styling in this style.css, it’s possible someone directly edited the minified version. If that’s the case, go ahead and minify the style.css without this style rule and use it to replace the existing style.min.css.

For safety you’ll want to keep copies of the files as-is as backup.

Thanks again for all the guidance on this @bcworkz !!! After some speed bumps and hiccups, I think I got it working on Chrome/Edge/Safari/Firefox. Oddly enough, the production site is also working properly on the google app, but the staging site is still showing the same initial error on that app. The only thing different on the staging site is that I commented out the entire @media block; but even with the exact same CSS (and minified CSS) as the production site, that problem remained on staging.

Well, I suppose the important thing is that its fixed (at least for now) on the production site. I’ll have my colleagues test it on their end tomorrow.

Will I need to update the CSS every time a theme update is pushed? Or will my modification of the parent theme’s CSS have any adverse effects I should be aware of?

Once again, thanks again. I can’t thank you enough!

I think it’s still unknown if the offending CSS is part of the original theme distribution or not. If it is, it could recur when the theme is updated. Or the theme devs may have removed it themselves. 110% !important seems very strange to me in a distributed theme. I still think it’s someone’s custom mod. In that case an update may resolve the entire thing without you needing to do anything extra. But yes, if it reappears in an update, you’ll need to again remove it.

Normally we can override undesirable CSS outside of the theme, but the !important modifier makes that difficult. It’s IMO why !important should never occur in a distributed theme.

Sure, that makes sense. I’ll stay alert for any changes after the next update. Hope you have an amazing weekend.

Cheers!