Site Origin Vantage Tweak

There’s a small issue in the theme where when comments are not enabled for a post it still shows text to leave a comment..

A quick fix

  • Find file: ./vantage/inc/template-tags.php
  • Find Function: function vantage_posted_on()
  • Replace that function with the code below

if ( ! function_exists( 'vantage_posted_on' ) ) :
* Prints HTML with meta information for the current post-date/time and author.
* @since vantage 1.0
function vantage_posted_on() {
$date_time = '';
$date_time = sprintf( $date_time,
esc_url( get_permalink() ),
esc_attr( get_the_time() ),
esc_attr( get_the_date( 'c' ) ),
apply_filters('vantage_post_on_date', esc_html( get_the_date() )),
esc_attr( get_the_modified_date( 'c' ) ),
esc_html( get_the_modified_date() )
$author = sprintf('',
esc_url( get_author_posts_url( get_the_author_meta( 'ID' ) ) ),
esc_attr( sprintf( __( 'View all posts by %s', 'vantage' ), get_the_author() ) ),
// Edited this
$posted_on_parts = array(
'on' => sprintf( __( 'Posted on %s', 'vantage'), $date_time ),
'by' => sprintf( __( '', 'vantage' ), $author),
'with' => ''
if( comments_open( ) && get_option( 'thread_comments' ) ) {
$comments_link = ' | ' . get_comments_number_text( 'Leave a comment' ) . '';
$posted_on_parts['with'] = $comments_link;
$posted_on_parts = apply_filters( 'vantage_post_on_parts', $posted_on_parts );
$posted_on = implode(' ', $posted_on_parts);
echo apply_filters('vantage_posted_on', $posted_on);

WordPress API reference, editor styling

Just a quick post to the codex entry relating to this topic:

Nothing to hard there on the surface, but may require including the whole theme style which may break the editor visually requiring overriding some of the core theme elements, Which if it breaks or messes up the editor visually having to manually over write/nullify the offending css rules.

Leading to if that is the case is it maybe more efficient to create a separate css file for  lists/paragraph/heading/image/video type defines ONLY compared to pulling in the whole theme style.. All that seems to be a revolving door mostly resting on the choice of using @import or not which has slightly higher overhead compared to not using it.

Literally the only difference would be not using @import, and instead of going round the merry go round just doing the work in the opposite direction instead of re-defining what we re-defined (the merry go round!), simply dig out what is needed and include that only.

Creating Child Themes for WordPress

If you’re unfamiliar with the subject see the Resource Links

A Quck and Dirty Twenty Twelve Child Theme, first we need to create a new folder for the child them, and inside that create a style.css file once done you can follow this example which is a Child Theme for Twenty Twelve.

Theme Name: Serverhash Twentytwelve
Theme URI:
Description: Serverhash Twentytwelve theme, based off the twenty twelve theme
Author: James L. Moss Jr.
Author URI:
Template: twentytwelve
Version: 1.0.0
Tags: light, gray, white, one-column, two-columns, right-sidebar, flexible-width, custom-background, custom-header, custom-menu, editor-style, featured-images, full-width-template, microformats, post-formats, rtl-language-support, sticky-post, theme-options, translation-ready
@import url("../twentytwelve/style.css");


Next we can introduce a functions.php file and a custom.css file, this is where all good things begin to happen in custom and child themes. We will keep this basic for now, the code is commented to explain what it’s doing the main purpose is to allow us to include a custom.css file in a correct way.

 * Tell WordPress to run post_theme_setup() when the 'after_setup_theme' hook is run.
add_action( 'after_setup_theme', 'serverhash_twentytwelve_post_theme_setup' );

 *  Enqueue our own custom.css file
 *  Replace the_generator with our own text 
if ( !function_exists( 'serverhash_twentytwelve_post_theme_setup' ) ):
function serverhash_twentytwelve_post_theme_setup() {
	// Add our new custom.css styles after all stylesheets have loaded
	function serverhash_twentytwelve_enqueue_child_style() {
		wp_enqueue_style( 'child_style', get_stylesheet_directory_uri() . '/custom.css', array(), null );
		do_action( 'serverhash_twentytwelve_enqueue_child_style', 'child_style' );
	add_action( 'wp_enqueue_scripts', 'serverhash_twentytwelve_enqueue_child_style', 11 ); 	

    // removes the WordPress version from your header for security
    function serverhash_twentytwelve_remove_version() {
    	return <!--Serverhash Twentytwelve, a custom Twentytwelve Child theme -->';
    add_filter('the_generator', 'serverhash_twentytwelve_remove_version');



WordPress Theme Resources:

One key concept for me as a developer and potential theme designer is choosing the right them as a parent theme. Any theme that has it’s own built in theme options needs to either have everything I would want or be easy to extend to fill gaps in needs I may want. To date i’ve simply not found this to be an easy task. So i’m opting for theme’s that by default have no ‘extra’ theme options built into them beyond the basics header/background which are handled easily by default within the wordpress theme api itself and can be kept separate. To this end going foward ill be building up future child themes for the default twenty twelve them and also I will attempt to find a suitable responsive base theme that has ‘no extra theme options’ built in. Allowing me to document the process of adding theme options along the way which as well will lead me down the path of choosing which option framework to use as their are about 5 stable/usefull ones out there which I will be considering. I may try each out and list pro’s cons of each at a later time.

A good example of this is:

Which is a basic responsive theme but comes bundled with an options framework and one of the more complete pre-fab set of options I have found.. I believe most of the themes have been built with that as it’s starting point likely with tweaks as needed, so I will be taking a good look at that as it has alot of nice features i’ll try to recreate but instead from a basic responsive theme as a parent(no options) and adding the extra options/functionality to that with child themes using an options framework.

Why go that route? To me having a parent theme that can be tweaked/updated with minor fixes down the road leaving little to no impact on child themes. Instead strip away the ‘custom aspects’ of a base theme leaving those areas solely to the child theme and me as the developer/designer of that child theme. The parent theme I can help find/suggest tweaks to the themes maintainers and not need to maintain my own version, also I could choose to make my own at a later date. So far i’m leaning towards a responsive base theme. As personally they provide the cleanest starting point with proper webkit shims in place for most browsers. Much more so than twenty twelve does currently. Two main area’s missing in twenty twelve are grids/column defines in the css and also webkit shims for rounded corners, box-shadows, and other IE specific things, which are already done beautifully in responsive themes.