feelsickened

Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter feelsickened

    (@feelsickened)

    Thanks for the responses guys.
    The nut to crack will be getting my child theme’s function to overwrite/replace the parent themes enqueue.php file / get_theme_mod function…….

    If you check the <head> produced by the theme with a basic child theme in place (following the codex) – you’ll identify the issue with the css as coming from the parent enqueue.php file. It is putting into the <head> another stylesheet (referred to as brawny-blue – no matter what colour option you picked in customising the theme, AFTER the child theme’s css.

    switch ( get_theme_mod(‘color’ ) ) {
    case ‘1’:
    wp_enqueue_style( ‘brawny-blue’, BRAWNY_PARENT_URL . ‘/css/default.css’);
    break;
    case ‘2’:
    wp_enqueue_style( ‘brawny-blue’, BRAWNY_PARENT_URL . ‘/css/lightpurple.css’);
    break;
    default:
    wp_enqueue_style( ‘brawny-blue’, BRAWNY_PARENT_URL . ‘/css/default.css’);
    break;
    }
    }

    if this wasn’t the case – a basic addon child theme’s css would work straight away by default. ??

    Thread Starter feelsickened

    (@feelsickened)

    appears the brawny/includes/enqueue.php file is adding the parent .css again after calling the child css. Couldn’t circumnavigate this without hacking away at the original theme files unfortunately.

    Shame – it’s a very nice big and clear theme.

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