To insert code in a forum thread or comment wrap it in code tags : <code>...</code>.
  • I love the striking theme or more correctly its pretty much a framework for us developers. I have just begun using it as my main platform for client sites and I just have a few troubles that cause me grief on every striking version update and I am sure other users can benefit from these suggestions. I sure hope you consider the following changes to an already awesome theme.

    I don't know if this is specific to version 5.1 or just 5.x as a whole. But I have noticed that using striking as a child/parent theme has a few issues I have noticed.

    Issue 1: Theme Name and Slug
    There is an issue with the way the theme name and slug information is stored. Any child theme name requires the change of the above code in order to show the proper name of the theme in the Wordpress dashboard menu.

    *** My current fix and suggestion is to make a copy of the info.php file into: child theme/framework/info.php and change the loading call in the parent theme/functions.php file to:

    Line 6 $options = include(get_stylesheet_directory() . '/framework/info.php');

    Issue 2: Caching Troubles
    I have noticed that by clearing the image cache in the advanced settings in one child theme, it will clear the whole cache (which is stored in the parent folder, therefore clearing the cache for any and all child themes), but the other child themes are not notified and will still be referencing the cached images instead of the regular image files which then creates broken images in the pages. To fix this, you have to clear the cache in ALL those other child themes.

    *** My current fix and suggestion is that when a child theme is used the setting in the CHILD framework/theme.php needs to be set as shown below and then the image cache would be in the child theme folder and would not affect any other child themes.

    My fix details(fixes issue 4 also): Edit childtheme/framework/theme.php
    Line 75 define('THEME_CACHE_DIR', get_stylesheet_directory() . '/cache');
    Line 75 define('THEME_CACHE_URI', get_stylesheet_directory_uri() . '/cache');

    Issue 3: Changing the Navigation Menu Font in jqueryslidemenu.js
    In order to edit the default text used in the main navigation menu, the text has to not only be changed in the striking theme options, but I have had to also edit this file for it to change during hover over. (Please let me know if I am incorrect). This poses a problem for child themes, as I have had to also copy this file over into the child theme, and then edit the parent theme/framework/functions/head.php to reference the child theme version in the head.php file. Please let me know if I am doing this wrong or if not then is there a way to make the jqueryslidemenu.js reference a call to a setting that we can change in the Theme options (provided you add one). I would imagine if you can set the navigation font size in the theme options, there should be a way to change the font used as well. Please! :)

    My current edit: parent theme/framework/functions/head.php
    wp_enqueue_script( 'jqueryslidemenu', get_stylesheet_directory_uri() .'/js/jqueryslidemenu.js', array('jquery'),false,$move_bottom);

    Issue 4: Child CSS Files
    When striking is used on a multisite the child css files are stored in the parent theme folder using the ID of the child site in the name to keep them separated, this is not a bad idea, but makes the child theme much less versatile if the client wishes to migrate to a new host in the future. In this instance the webhost would then have to find the correct skin.css file and move the skin.css into a stand alone striking theme. What I have done to make life easier later on down the line is that I edited my striking parent theme to save the skin.css file to the child theme folder and also load it from there. I hope you see merit in making that the default vs the current method. It would be easier to just keep the child theme skin.css file with the child theme. No hunting down site ID's and figuring out which file goes with what.

    My fix details(same fix as issue 2): Edit childtheme/framework/theme.php
    Line 75 define('THEME_CACHE_DIR', get_stylesheet_directory() . '/cache');
    Line 75 define('THEME_CACHE_URI', get_stylesheet_directory_uri() . '/cache');
  • 8 Comments sorted by
  • Hi paulieb81,

    Thanks for point out these.

    I will fix them on the next release of striking.

  • Thank you, I am very excited for the next release. It will fix much frustration with upgrading in the future.

    I just also wanted to note, that in making these changes, you must manually create the following files and folders in the child themes (or maybe you can code it if they don't exist):
  • Please also see the discussion in this thread, this problem with fontface may be related to child themes also, the last few comments show a work around:
  • Hey Paulie,
    Do you have Striking loading as the default theme in your multisite setup?

    I have striking loading as default on blog creation:

    Changed/added the following in wp-config.php
    define('WP_DEFAULT_THEME', 'theme-folder-name');
    define( 'TEMPLATEPATH', '/path/to/themes/folder/name-of-parent-theme');

    The issue is if you go to the site after creating it there is no styling to it. When I look at my error logs it shows that it is looking for /striking/cache/skin_blogID.css. That file isn't made until I go to the subsite admin and click save changes on any page.

    Does anyone have an idea how to create the skin_blogID.css file when the site is created? Or have an other ideas how to resolve this?

    Thanks in advance.
  • @Elky

    No, my multisite setup is not for clients to create sites or signup. It's merely a multisite for purpose of administration. Let me explain my setup and how I am using / planning on using it.

    I am a website developer and I just started using striking as my main "framework" to build client sites from. I purchased a regular license and have been experimenting with building child themes from it with great success. For each client site I build, i will be purchasing an additional license in order to properly pay for using it.

    My "default" theme in my multisite is set as the standard WordPress 2011 theme. When i setup a new site it starts with that theme, then i manually activate a new child theme, then start building.

    As for an answer to what you are trying to do, it depends on what you are truly trying to accomplish in the end. Are your users signing up to create their own sites? If so then you need an extended license i think. I know that doesn't answer your question but hopefully it's at least entertainment. :)
  • Yea, I'm aware of the licensing concept. This is a setup I'm playing with on a development level. If I can everything to work the way it needs to I may deploy the project. At that point I'll do my due diligence with the licensing.
  • I understand that, same here, I just began trying it out as a framework, I have another thread with child theme troubles, that looks like the suggestions will make a future upgrade. It will make child theme making much better and easier. There may be a plugin you could use to duplicate a default site. I use a premium plugin called backup buddy, and you can clone existing subsites to new ones. Give it a try, may work for what you need.
  • I was able to fix the problem by changing:

    global $blog_id;
    wp_enqueue_style('theme-skin', THEME_CACHE_URI.'/skin_'.$blog_id.'.css', array('theme-style'), mktime(), 'all');
    wp_enqueue_style('theme-skin', THEME_CACHE_URI.'/skin.css', array('theme-style'), mktime(), 'all');


    global $blog_id;
    $file_test = 'path to /striking/cache/skin_' . $blog_id . '.css';

    if (file_exists($file_test)) {
    wp_enqueue_style('theme-skin', THEME_CACHE_URI.'/skin_'.$blog_id.'.css', array('theme-style'), mktime(), 'all');
    } else {
    wp_enqueue_style('theme-skin', THEME_CACHE_URI.'/skin.css', array('theme-style'), mktime(), 'all');
    wp_enqueue_style('theme-skin', THEME_CACHE_URI.'/skin.css', array('theme-style'), mktime(), 'all');

    in the striking/framework/functions/head.php file.

    I am not a php programmer so I'm sure there is a much better way to do this check but this works for now.

    I welcome any coding suggestions
This discussion has been closed.
All Discussions