• Hello,

    I’ve been using your very nice pliska WordPress theme. However, I’ve encountered some bugs, and have some other issues I would like to ask/inform you about.

    First, the bugs:

    These first two problems seem to occur only in WebKit — I have seen them occur in both Safari and Chrome on iPad. They do not occur in the responsive preview modes for iPad or iPhone in Firefox or Chrome on my Windows machine.

    * The header image is zoomed in too far. I guess this is the img-overlay class in the CSS. Perhaps my image is too large (1154 x 497)? In any case, it looks correct in Firefox responsive mode emulating iPad/iPhone but wrong on my actual iPad.
    * Blue lines (focus?) appear around the navigation menu when you click an item. After you get to the next page, if you go back, the blue lines are still there.

    The following issue occurs both on a real iPad and in Firefox responsive preview mode on Windows.

    * When you activate the search icon when the window has iPad dimensions, it opens a dialogue with the search box field but the left and right margins are zero. I guess this is because the margins shrink but the text field length doesn’t. I think the text field length should shrink so there are at least 1 or 2 ems around it.

    Second, I also have a couple issues.

    I think I can fix these in a child theme, but if there is an easier way I’d like to know it, or perhaps you might consider folding these changes into pliska itself.

    * My client thinks the navigation menu is too big on the iPad and would rather see the burger menu appear on that platform. Looking at the CSS, the burger menu seems to appear when the media width is less than 40em. Because this is controlled by @media brackets, it is hard to fix with WordPress customization in Additional CSS unless I copy a lot of other text inside the curly brackets. It would be good if theme users could explicitly choose a menu style for at least the desktop, iPad and mobile dimensions, or easily change the threshold from 40em. (I think at the very least this 40em figure should be a Sass variable. I think CSS has variables now too, which would be a good fix, but maybe you don’t want to require such a recent CSS feature?)

    * In desktop mode, the search icon opens a dialogue that fills the entire window, which is odd for a desktop page. In these dimensions, it would be much better if it defaulted to an inline search field.

    * It would be nice if the mobile menu had its own WordPress Location, so it could be customized apart from the desktop menu.

    Versions: pliska 0.2.5, WordPress 5.8.1

    Cheers,
    Frank

    • This topic was modified 3 years, 1 month ago by frankatan.

    The page I need help with: [log in to see the link]

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter frankatan

    (@frankatan)

    Please note the indicated page is now running a modified version of Pliska. (Should I still credit Nasio Themes at the bottom, or shall I remove this so you do not get blamed for my errors?)

    Thread Starter frankatan

    (@frankatan)

    I discovered a bug in the mobile slide menu code. If a user clicks inside the burger BUTTON but outside the LABEL the function toggleMobileMenu() will apply the toggled class and modal-open to the body, then immediately remove toggled because of the code which closes the mobile menu when you click outside certain elements. (It will leave modal-open applied to the body.)

    To fix this, you should add BUTTON to the list tagNames at assets/js/navigation.js:49.

    Thread Starter frankatan

    (@frankatan)

    Another issue.

    On Chrome, in mobile mode, both on actual mobile and on desktop in responsive mode, on homepage: open the navigation menu, click a page, then Back: burger is checked, but navigation menu is closed. (Clicking the X mark opens the menu, but unchecks the burger, so the states are reversed.) Expectation: either burger is checked and menu is open, or burger is unchecked and menu is closed.

    In contrast, on Firefox, clicking Back in this situation brings you back to the homepage, but the burger is checked and the navigation menu is open. (I think it would be better if the menu were closed too, so that you can see the page directly after you click Back, but the behavior is at least consistent.)

    Thread Starter frankatan

    (@frankatan)

    I found the source of the last issue above, and added a fix.

    The problem seems to be that Firefox has a back-forward cache (“bfcache”) which maintains the DOM state if you press back, while Chrome does not. But both browsers maintain the form state of the burger checkbox, so when you hit Back on Chrome the box is checked but the menu is closed, while on Firefox the box is checked and the menu is open.

    I solved this by unchecking the burger checkbox on every page unload.

    window.addEventListener('unload',function(e) {
        document.getElementById('burger-check').checked = false;
    })

    This both ensures that the behavior is consistent across browsers, since the presence of any unload handler invalidates the bfcache, and ensures that the menu is closed when the user goes Back, so they are looking at the page content and not the open navigation menu.

    • This reply was modified 3 years ago by frankatan.
    Thread Starter frankatan

    (@frankatan)

    I discovered that WebKit does not always unload a page when the user navigates away. So I just removed A from the list of tags which Pliska checks when the user clicks inside the mobile menu, and also added an explicit check for submenu toggles. This gave me the behavior I wanted.

    document.addEventListener('click', function (e) {
        // make a list of elements that will keep modal from closing
        var tagNames = ['LABEL', 'INPUT', 'I', 'svg'];
        var isClickInside = false;
        for (var i = 0; i < tagNames.length; i++) {
            if (tagNames[i] == e.target.tagName) {
                isClickInside = true;
    	}
    	if (e.target.className.indexOf('sub-menu-toggle')!==-1) {
                isClickInside = true;
            }
        }
        ...

    I also discovered what appears to be a typo near the beginning of navigation.js:

    if (mainMenu.className.indexOf('nav-menu' == -1)) {
        mainMenu.className += ' nav-menu';
    }

    The condition always evaluates to false. I guess this should be

    if (mainMenu.className.indexOf('nav-menu') == -1)

    but I don’t understand under which circumstances it would be necessary.

    Theme Author Atanas Yonkov

    (@nravota12)

    @frankatan , thank you for this thread. It seems that you have made some valuable contributions here. I will revise the code when I have the time and provide an update. These changes will be evaluated and probably included in the next theme update. Cheers!

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Issues’ is closed to new replies.