• Resolved Abigailm

    (@abigailm)


    With version 3.9.3, the bootstrap slider icon for previous/next buttons was a large disc with symbols inside pointing left or right:

    (<) and (>)

    Now with version 3.9.4, the icon is much smaller, just a small circle with no other styling – so left & right side symbols are the same.

    Is this an intentional change of slider styling?

    Or is there a glitch preventing display of an element?

    I did clear all caches before viewing the slider to eliminate possible style conflicts. I have modified display of other elements in my slider, but nothing that should affect the basic shape and side of these buttons.

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

Viewing 15 replies - 16 through 30 (of 33 total)
  • @frankmartialarts i ve just visited your site. I saw the mess and cleared my browsers cache. Now looks perfect. Please press Ctrl+F5 to clear your browsers cache

    bskno

    (@frankmartialarts)

    It’s because I restored the theme to before update. πŸ™‚

    Thread Starter Abigailm

    (@abigailm)

    @romik84 – I disabled the caching and cleared all caches before I posted, and it did not change anything.

    The CSS specifications you quoted are NOT in my css code. My child theme style.css does NOT have any specifications at all for the .carousel-control-next-icon and .carousel-control-prev-icon classes.

    The specifications you listed are part of the PARENT theme, in the bootstrap.css file at lines 5969-5976. So not a modification that I made. So if the 20px there is the problem, it is with your files, not my customization. (However, the bootstrap.css has not changed since the version 3.93, and it was working & displaying properly before – so I don’t think that’s the problem. You can see my site home page from 31 July at web.archive.org to see what the display was previously)

    The only modifications I made to the carousel-control buttons were to margin-top properties, to shift their placement on the slider.

    • This reply was modified 5 years, 8 months ago by Abigailm.
    Thread Starter Abigailm

    (@abigailm)

    OK, I have figured out the problem, and managed to address the issue with the slider buttons as well as several other layout and styling issues I found throughout the site.

    The theme is loading stylesheets in this order:

    1) parent-style-css
    2) evolve-bootstrap-css
    3) evolve-style-css (child theme)

    Because the bootstrap is loaded after the parent style, all bootstrap specifications are overriding specifications for the same class or ID in the parent-style.

    I can address this by adding styles to the child style.css file…. but I do think it is a bug, because I think the parent css should load after the bootstrap, not before. To fix this properly (rather than on a piecemeal basis) I would have rewrite all bootstrap styles from the parent theme into the child theme css file.

    Here is the content of my child theme functions.php file — perhaps this needs to be modified?

    add_action( 'wp_enqueue_scripts', 'enqueue_parent_theme_style');
    function enqueue_parent_theme_style() {
        wp_enqueue_style( 'parent-style', get_template_directory_uri().'/style.css' );
    }
    Thread Starter Abigailm

    (@abigailm)

    Here’s where I think the problem was introduced.

    The parent theme has this NEW code in functions.php:

    if ( ! function_exists( 'evolve_scripts' ) ) {
    	function evolve_scripts() {
    		global $post, $css_data;
    
    		// Bootstrap CSS
    
    		wp_enqueue_style( 'evolve-bootstrap', get_template_directory_uri() . '/assets/css/bootstrap.min.css', false );
    
    		// Main CSS
    
    		wp_enqueue_style( 'evolve-style', get_stylesheet_uri(), false );

    This properly loads evolve-bootstrap before evolve-style in a parent theme.

    But in the child theme, the parent style.css is loaded first, then boostrap, then child style.css (which becomes the new “evolve-style”). (That’s because get_stylesheet_uri() brings up the CHILD URI, not the parent).

    I don’t know why you determined that you needed to specifically enqueue the bootstrap.css in 3.9.4 when that function was not in 3.9.3 — but I think if you are going to do that you also need to write a function to check whether or not there is an active child theme– and in that case, make the appropriate corrections.

    You might consider including your own set of child theme files with your distribution, because there are several variations on how the function to enqueue styles in a child theme can be written.

    bskno

    (@frankmartialarts)

    Thanks guys for helping me to learn about using this forum, but there was no use to solve the new update issues, hope you can do something.
    Time is gold, so I changed the theme. Stability comes before beauty.
    πŸ™‚

    @abigailm bootstrap.min.css styles was enqueued before the style.css since version 3.9.0 as they handle all the layout of the theme. What broke the styles (layout of the website) now is the Font Awesome styles migration, usually on most websites using child themes as they have defined in the child theme call for Font Awesome style and child theme cannot handle it anymore, and then the website layout is broken. For generation the Font Awesome now I implemented Javascript + SVG so the migration of the icons is much more easier and better for development purpose as I plan to bring some more features for those icons. As of now, the correct example definition of a child theme should look like this:

    if ( !function_exists( 'evolve_parent_css' ) ):
        function evolve_parent_css() {
            wp_enqueue_style( 'evolve-parent-style', trailingslashit( get_template_directory_uri() ) . 'style.css', array( 'evolve-bootstrap' ) );
        }
    endif;
    add_action( 'wp_enqueue_scripts', 'evolve_parent_css', 10 );

    @frankmartialarts no problem, you are always welcome πŸ˜‰

    Thread Starter Abigailm

    (@abigailm)

    Thank you, @romik84 — that solved the problem.

    However, I have another problem and I am not sure what the cause is, or how to replicate. However, this has only occurred since the update to 3.9.4

    When I am logged in and viewing the site the main navigation menue does not work for 3rd level drop down items, or for the 2nd level for any menu item that has a sub-menu.

    So for example:

    Menu Item 1
    > Sub Menu 1
    > Sub Menu 2 > Sub-sub Menu

    I can navigate by clicking on Menu Item 1 or Sub Menu 1, but Sub Menu 2 does not respond, and the sub-sub menu items never appear.

    However, everything works very smoothly and super fast when I am not logged in. So very great experience outside of being the admin! (But I checked, and the same problem would exist for someone with only a subscriber role logged in — so if this is something to do with Evolve coding, it is a problem because the site function depends on access from subscribers. So if navigation breaks whenever someone logs in that would be a problem)

    This is a mystery to me and I am hoping you can look into it, but I do realize that there is no way for you to test without login access to my site.

    Thread Starter Abigailm

    (@abigailm)

    Also, I have one more problem – also only when I am logged in to the site.

    I have a plugin called “Data Tables Generator by Supsystic” which imports tables stored on the site, using a short code. When I am logged in, it will not load. I tried disabling the plugin and testing the navigation menu in case it was the plugin causing the navigation problem, but that didn’t make a difference. (When not logged in- works fine, loads very quickly).

    So there is something else that happens when logged in that is causing loss of some site function.

    You are using a caching plugin and in console I see errors:

    Uncaught ReferenceError: tribe_js_config is not defined
        at bk7e9.js:167
    bk7e9.js:2 Uncaught ReferenceError: tribe_js_config is not defined
        at bk7e9.js:2

    I would start to investigate by checking the plugin, clearing its cache, checking its settings if it has different options for logged in/out users etc. There is nothing defined to display different for logged in/out user for the website backend area πŸ˜‰

    Thread Starter Abigailm

    (@abigailm)

    OK, you seem to be right – deactivating relevant plugins seems to eliminate the problem, so it must be a plugin conflict.

    let me know once you know more about the issue πŸ˜‰

    Thread Starter Abigailm

    (@abigailm)

    I found which plugin was the source of the conflict, and reported it to the plugin support forum. I’m marking this thread resolved for now, as this last issue isn’t tied to Evolve. It’s just a coincidence that it started at the same time, but more likely is due to the WordPress upgrade that was pushed through a few days ago. (WordPress 4.9.8)

    Thread Starter Abigailm

    (@abigailm)

    resolved

    bskno

    (@frankmartialarts)

    Thanks to you @romik84, am back. πŸ™‚
    I should confess that even with all those issues I had, this theme is the best I’ve worked with, so after making some backup themes, I saw the new update and I thought to try it again, found no issues except a small warning, which I explain in a new thread how I solved it, everything works fine.

Viewing 15 replies - 16 through 30 (of 33 total)
  • The topic ‘Bug or feature (v. 3.94)’ is closed to new replies.