Tag: WordPress

  • Body Class Control in WordPress

    I like a much reduced set of body classes when coding up a WordPress theme. Two template types, two main classes.

    Oh, and I put it on the HTML element too. To call my coding opinionated is somewhat of an understatement. (more…)

  • One click indieweb for WordPress

    I was discussing one click indieweb for WordPress with David Shanske on the IRC channel. The aim is to make it as easy as possible for a WordPress user – not a developer – to implement an indieweb site.

    I’ve decided to put it up as a brain dump.

    There are two aspects to consider: features and data attributes. (more…)

  • WordCamp Sydney Slides

    WordCamp Sydney Slides

    I presented an expanded version of my CSS Naming Conventions talk at WordCamp Sydney. Thanks to everyone who came along, my slides are below.

    I’ve put together a quick one page site linking to various resources at cssnamingconventions.com.

    (more…)

  • Trying the SUIT CSS Naming Convention

    I’m in the process of redeveloping this site. The site will still use WordPress but I’ll be adding a custom skin.

    I’ve been wanting to try Pattern Lab for a while, so the first step is to create a pattern library. It’s early days, today’s task it to set up a reset and base styles.

    Additionally, I’ll be sampling a CSS naming convention I’ve been meaning to try for a little while. A personal project is the perfect opportunity. (more…)

  • Specificity, SMACSS and WordPress

    At the June WordPress Melbourne Meetup, I spoke about CSS Specificity, SMACSS and WordPress. I had a great time, the video and slides are below. (more…)

  • WordPress Theme Elements

    A client asked us to put together a list of every design element required in a WordPress theme but it’s the sort of thing we think we should share.

    When producing a theme, we try not to limit the website owner’s options within the WordPress Dashboard. The owner may wish to enable an option down the track and be disappointed if they can’t.

    The downside for the designer and developer is they may put in work for elements that are never used. The upside is happy clients and return business.

    Like most things web, the site’s purpose will dictate that some things just aren’t feasible. Consider this as a series of guidelines that you can adapt for your purposes.

    (more…)

  • Big Red Framework on WordPress.org

    Big Red, the Soupgiant WordPress framework, has been added to the WordPress.org theme repository.

    If you have any code suggestions, you can fork the theme on Github and submit a pull request.

  • Big Red Framework

    We’ve updated the base WordPress theme we use at Soupgiant for WordPress 3.1+ and to make more use of the WordPress API.

    Along with the standard features you would expect in a WordPress framework, it includes

    Never use the framework proper to set up a theme, set up a child theme instead.

    • Copy the files from the starter directory into the base folder of your child theme
    • Create the sub-directory assets in your child theme
    • Copy the framework’s assets/child/ directory into the assets directory of your child theme

    See the WordPress codex page on child themes for more information.

    More documentation to come!

  • Soupgiant WordPress themes on Github

    Update: We’ve released our updated framework and renamed it the Big Red Framework.

    The Soupgiant base WordPress themes are now available on GitHub. There’s no documentation at this stage, I’ll write up a blog post with details in the coming weeks.

    There are two parts to the theme

    • Soupgiant Parent Theme
      We use this as the parent theme across multiple projects. Any bug fixes or new features applied to this theme will be available to all child themes.
    • Soupgiant Child Theme
      Starting point for each project. Once duplicated for the project, CSS styling and per project PHP customisations are applied/overridden in the child theme. Most projects require a custom header.php & footer.php.

    As I say, documentation to come.

     

  • JavaScript Localisation in WordPress

    Recently on Twitter @iamcracks asked

    Attention WordPress Wizards & Gurus. Is it possible to “get WordPress to write a custom field into a javascript variable”?

    source

    While I wouldn’t be so bold as to claim I’m either a wizard or a guru, I happen to know the answer to @iamcracks question.

    A while back I wrote a two part tutorial on using JavaScript the WordPress way, the code below builds on that. The first step is to load the JavaScript in functions.php using wp_enqueue_script() as detailed in the earlier tutorial:

    <?php
    function brt_load_scripts() {
      if (!is_admin()) {
        wp_enqueue_script(
          'brt-sample-script', //handle
          '/path/2/script.js', //source
          null, //no dependancies
          '1.0.1', //version
          true //load in html footer
        );
      }
    }
    
    add_action('wp_print_scripts', 'brt_load_scripts');
    ?>

    This outputs the html required for the JavaScript when wp_footer() is called in footer.php

    Localising the script is done using the function wp_localize_script() it takes three variables:

    • $handle – (string) the handle defined when registering the script with wp_enqueue_script
    • $javascriptObject – (string) name of the JavaScript object that contains the passed variables.
    • $variables – (array) the variables to be passed

    To pass the site’s home page and the theme directory, we’d add this function call below the wp_enqueue_script call above:

    <?php
    ...
    wp_localize_script('brt-sample-script', 'brtSampleVars', array(
      'url' => get_bloginfo('url'),
      'theme_dir' => get_bloginfo('stylesheet_directory')
      )
    );
    ...
    ?>

    The output html would be:

    <script type='text/javascript'>
    /* <![CDATA[ */
    var brtSampleVars = {
      url: "http://bigredtin.com",
      theme_dir: "http://bigredtin.com/wp-content/themes/bigredtin"
    };
    /* ]]> */
    </script>
    <script type='text/javascript' src='/path/2/script.js?ver=1.0.1'></script>

    Accessing the variables within JavaScript is done using the standard dot notation, for example brtSampleVars.theme_dir to access the theme directory.

    Using a post’s custom fields is slightly more complicated so I’ll write out the code in full:

    <?php
    function brt_load_scripts() {
      if (is_singular()) {
        wp_enqueue_script(
          'brt-sample-script', //handle
          '/path/2/script.js', //source
          null, //no dependancies
          '1.0.1', //version
          true //load in html footer
        );
    
        the_post();
        $allPostMeta = get_post_custom();
        wp_localize_script('brt-sample-script', 'brtSampleVars',
        array(
          'petersTwitter' => $allPostMeta['myTwitter'][0],
          'joshsTwitter' => $allPostMeta['joshsTwitter'][0]
          )
        );
        rewind_posts();
      }
    }
    
    add_action('wp_print_scripts', 'brt_load_scripts');
    ?>

    Only pages and posts have custom fields so the check at the start of the function has become is_singlular() to check the user is on either a post or a page, earlier we were testing if the user was anywhere on the front end. The arguments for wp_enqueue_script have not changed.

    the_post() needs to be called to start the loop and initiate the $post object so the associated custom fields can be accessed in the following line and put in an array.

    With the custom fields easily available, the information can then be passed to wp_localize_script() as earlier demonstrated. The final step is to rewind the loop so next time the_post() is called, from either single.php or page.php, the post data is available.

    The html output from the sample above would be:

    <script type='text/javascript'>
    /* <![CDATA[ */
    var brtSampleVars = {
      petersTwitter: "@pwcc",
      joshsTwitter: "@sealfur"
    };
    /* ]]> */
    </script>
    <script type='text/javascript' src='/path/2/script.js?ver=1.0.1'></script>