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…)
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…)
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…)
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.
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…)
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…)
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.
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.
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.
See the WordPress codex page on child themes for more information.
More documentation to come!
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
As I say, documentation to come.
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:
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>