Forum Replies Created

Viewing 5 replies - 1 through 5 (of 5 total)
  • Having done some debugging, the problem is to do with html encoding. When the hash is generated, a name field of “£5 donation” becomes “£5 donation”. However, when it is checked, it uses “£5 donation”. The two hashes therefore don’t match.

    I don’t think the problem is the way you are building the button. The problem is the contents of the name field.

    The cart checks that the price hasn’t been tampered with by comparing the hash_one field with a hash it generates using the price and product_tmp_two (which, as you can see, is the name). Unfortunately, there is a bug that means this fails if the name contains certain characters. I have established that putting the £ sign in the name causes this to fail. In your case, I’m guessing it is the – character.

    Thread Starter prh47bridge

    (@prh47bridge)

    Note that I have now deactivated all plugins and am not using a child theme on https://staging.rhdra.org so this is purely the Responsive theme. As I say it works fine on mobile emulators but not on actual mobile devices. If you tap on the hamburger the menu opens correctly but it usually disappears as soon as you start to scroll.

    As a P.S. to my earlier P.S., I agree that the menu appearing on scrolling was not a Responsive issue. It was caused by something else triggering browsers to ignore the max-width and use the width in the CSS. Strange.

    Thread Starter prh47bridge

    (@prh47bridge)

    P.S. I know the max-width:100% should override the width when the screen is less than 960px wide but, for some reason, it appears not to work. Having seen what was happening on mobile devices, I found a couple of browsers reporting the div as 960px wide when emulating a mobile device with a much narrower screen.

    Thread Starter prh47bridge

    (@prh47bridge)

    Thank you for your response.

    After a lot of searching, I have traced the issue. The problem appears to be in core/includes/customizer/styles.php. You have the following on line 385:

    .boxed-layout
    .content-area, body.default-layout #content-outer, body.full-width-layout #content-outer, body.full-width-no-box #content-outer, .menu, #footer {
    width: {$container_width}px;
    max-width: 100%;
    }

    The layout has a div with id content-outer and the body has the default-layout class. This rule is therefore triggered, setting the div to container_width and forcing the page to (in my case) 960 pixels wide. When you scroll the page the resize event fires, resulting in the code in core/js/responsive-scripts-min.js deciding that the screen is more than responsives.break_point wide and therefore setting the menu to display.

    I have fixed the issue by adding custom CSS that sets the width of these elements to 100% if the screen is 959px or less wide (container_width being 960px for my site).

    However, I was wrong about the latest version of your theme fixing the disappearing menu. This can still be observed on staging.rhdra.org which is using the Responsive theme. It works fine on PCs and on mobile emulators. However, on an actual mobile device the menu appears when you touch the hamburger but generally disappears when you try to scroll the menu (although sometimes it scrolls correctly). You then have to touch the hamburger twice to get it to reappear, so the site obviously thinks the menu is still present. Any thoughts on how this can be fixed would be much appreciated.

Viewing 5 replies - 1 through 5 (of 5 total)