BoldGrid Theme Submission Requirements

The following sections are intended to be used as a guide for successful submission of themes or design components to the BoldGrid system.

This section is broken up into the following subsections:

  1. Getting Started
  2. Templating
  3. BoldGrid Layers
  4. GridBlocks
  5. Modules
  6. Themes
  7. Available Resources
  8. CSS Standards
  9. Color Palettes
  10. Custom Site Title
  11. Menu Locations
  12. Widget Areas
  13. Plugin Support

Getting Started

The BoldGrid Theme Framework has many components, but to make life easier we have combined these into a few helpful starting points for new theme developers to get familiar with. The way our system works is that we provide a parent theme, which shouldn't be modified, and a child theme should be created.

We also provide a starter child theme that's ready to go, so you can see how our themes are constructed. Once a child theme is ready to be used, it can be submitted to us and we'll compile everything down into a new parent theme for distribution to end users. This makes it easy for the end user to create their own child themes if they decide to do so, without being stranded in the update process.

Prime

Prime is the parent BoldGrid theme that contains all the functionality that the BoldGrid Theme Framework has to offer. This theme is actively maintained in our public github repo.

Starter

Starter is the child BoldGrid theme that contains configuration specific information, and works just like the standard child theme would in WordPress. This theme is actively maintained in our public github repo.

Templating

The BoldGrid Theme Framework supports a templating style similar to Django, which is based on Scribu's Template Wrapper.

The premise behind using this is that it provides a clearer context of the templates being modified to make a theme developer's job easier when managing templates. The template wrapper deters repetition, and keeps your code DRY.

By default, a standard WordPress theme has page templates that look similar to this code:

<?php get_header(); ?>
  <div class="wrap">
    <div class="content">
      <?php // Page specific code is here. ?>
    </div>
    <?php get_sidebar(); ?>
  </div>
<?php get_footer(); ?>

When using the template wrapper, the calls to get_header(), get_sidebar(), and get_footer() are constantly repeated, and we needed a way to remove this repetitious code out of the template to make it easier to manage for our drag and drop builder. Simplifying this code resulted in our templates to now look like this:

<?php // Page specific code is here. ?>

Base Template

Our templating relies on our base template being called automatically, which appears like this:

<?php
/**
 * Base Template
 *
 * This file contains the base structure of a BoldGrid Theme.
 *
 * @since 2.0
 */

global $boldgrid_theme_framework;
$configs = $boldgrid_theme_framework->get_configs();
?>
<!doctype html>
<html <?php language_attributes(); ?>>
    <?php get_template_part( 'templates/head' ); ?>
    <body <?php body_class(); ?>>
        <div class="site-header">
            <?php do_action( 'get_header' ); ?>
            <?php get_template_part( 'templates/header/header', $configs['template']['header'] ); ?>
        </div><!-- /.header -->
        <div class="site-content" role="document">
            <main class="main">
                <?php include Boldgrid_Framework_Wrapper::boldgrid_template_path(); ?>
            </main><!-- /.main -->
        </div><!-- /.content -->
        <div class="site-footer">
            <?php do_action( 'get_footer' ); ?>
            <?php get_template_part( 'templates/footer/footer', $configs['template']['footer'] ); ?>
            <?php wp_footer(); ?>
        </div>
    </body>
</html>

Special Templates

You may have noticed from the Base Template that there are calls using get_template_part(), which pull information from the BoldGrid Configurations Options.

The two important calls are the header templates and footer templates. By default the base template will look in the configs, and pull the specified file. If no configuration is specified, then the default template for the header (templates/header/header.php) and footer (templates/footer/footer.php) will be used.

BoldGrid includes preconstructed templates that include all the necessary hooks, and sets the necessary configuration options. This helps reduce the amount of time it takes to get up and running with a new and unique layout.

Since there are many hooks used in a BoldGrid theme, it's recommended that you start a new theme by using the Starter Theme, which is a child theme of the Prime theme.

You can read more detail about the configuration options for the header and footer templates in the BoldGrid Configuration Reference.

BoldGrid Layers

All BoldGrid sites are constructed using Themes, GridBlocks, and Modules. Understanding the relationship between these components is essential to proper BoldGrid Theme development. Because of their modular nature, it's entirely possible to design for one layer without designing for another.

BoldGrid Layers

GridBlocks

All BoldGrid Themes should support a number of GridBlocks, defined generally as small, discrete pieces of content intended as manageable models, or 'blocks,'' for users to rearrange and customize.

GridBlocks include appropriate content elements arranged in a specific layout as chosen by a Designer or Theme Developer.

At their core, GridBlocks are snippets of code that handle most of a BoldGrid site's content. They're designed to be modular, allowing users to deploy them on any BoldGrid Theme of their choosing, all while the content and structure within the GridBlock remains intact. This is possible because GridBlocks exist independently from CSS styling and only depend on grid-related Bootstrap classes for structuring content.

This approach allows GridBlocks to be moved from one Theme to another while letting the Theme handle style choices (e.g. typography, color, button styles, etc.).

Example: GridBlocks inherit their styling from the Theme in which they're used.

GridBlocks Example 1 GridBlocks Example 2

GridBlock Support

In order to support the range of elements represented within GridBlocks, a theme's stylesheet must be comprehensive in its approach to base styles, setting up as complete a style guide as possible All BoldGrid Themes must include styles to support common elements used in GridBlocks: h1, h2, h3, h4, h5, h6, p, a, ol, ul, li, hr, img, blockquote, a:hover, a:focus, .link-primary, .link-secondary, .button-primary, .button-secondary

The Grid

All BoldGrid Themes use the Bootstrap Grid System with the following adjustments and exceptions:

<div class="col-md-6 col-xs-12 col-sm-12">

Although Column Offsets are a feature of Bootstrap, they should be avoided in BoldGrid content due to the desired User Experience. The BoldGrid method of approximating a Column Offset is to add an empty Column of the size to be offset directly before the subsequent Column (see example):

<div class="row">
    <div class="col-md-4"></div>
      <div class="col-md-8">
         <p>Lorem ipsum</p>
      </div>
</div>

Content Standards

The following standards are relevant to BoldGrid as an entire content delivery system, and will apply to GridBlocks in a more general sense.

All content produced for BoldGrid should serve as an example for BoldGrid users to follow.

All content should be designed in such a way as to provide a practical model of fundamental design principles.

All content should be flexible in terms of its interaction with the BoldGrid Editor plugin

Modules

All BoldGrid Themes use a modular system applied to associated BoldGrid content to provide for more sophisticated user interactions.

Perhaps the best way to think of a Module is as an area of content aesthetically designed to the Theme. Mods essentially allow BoldGrid Theme designers to extend their CSS to content in ways that a Theme's GridBlock Key won't accomodate for, allowing designers to piece together richer and more involved ways for presenting user content.

Modules provide a context for elements and specify the presentation of elements within that context.

Modules are a key component in the deliberate separation of presentation (i.e. standard CSS properties) from layout (i.e. the rows and columns of the Grid).

Using modules effectively will allow elements to adopt certain style characteristics within the module, while also providing the user with the ability to drag elements outside of the module or into other modules where the element will adopt a different set of style characteristics.

The important thing to keep in mind is that Module presentation is specific to the Theme. When content is pulled out of a Module, its context then changes and assumes the styling defined by the Theme's GridBlock Key.

The BoldGrid modular system is similar to the approach used by Scalable and Modular Architecture for CSS (SMACSS).

Modules Example 1 Modules Example 2

Module Naming Conventions

Modules will follow the Bootstrap convention of using class prefixes followed by additional hyphenated descriptors.

The word 'module' will be abbreviated as 'mod' in the class prefix (see example):

<div class="mod-example">

In the case of Universal Content (shared between Categories and Page Sets, generally referred to as Inside Page Content), the descriptor should refer to the module's intended functional use.

As the universality of these modules involves their use in other themes, these modules will be determined by the BoldGrid Theme Review team (see example):

<div class="mod-image-gallery">

In the case of specific Home Pages, deriving semantic meaning is more complex, presenting the following issues:

<div class="mod-alpha">

Module Usage

Modules should be appended to the standard Row > Column structure, forming a revised Row > Column > Module structure.

Standard implementation of the revised structure (see example):

<div class="row">
    <div class="col-md-6">
        <div class="mod-alpha">
            <p>Lorem ipsum</p>
        </div>
    </div>
    <div class="col-md-6">
        <div class="mod-beta">
            <p>Lorem ipsum</p>
        </div>
    </div>
</div>

Nested Rows and Submodules

Modules should not have sibling elements, only descendant elements.

In the case where sibling elements would be desirable, the proper application will be a Nested Row > Column structure.

The Nested Row > Column structure will preserve the Layout relationship among elements, while allowing flexibility in terms of styling in different parts of the page.

Nested Rows may also contain Submodules (named sequentially in reference to the parent Module), which can contain additional style properties that are distinct from the parent Module (see example):

<div class="row">
    <div class="col-md-12">
        <div class="mod-alpha">
            <div class="row">
                <div class="col-md-8">
                    <div class="mod-alpha-1">
                        <p>Lorem ipsum</p>
                    </div>
                </div>
                <div class="col-md-4">
                    <div class="mod-alpha-2">
                        <p>Lorem ipsum</p>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

Module Styles

Modules allow for additional specification of CSS properties applied to an element or elements within a given module context. These properties should not apply to elements removed from the module by the user, and thus need to be coded in a specific way.

For example, assuming a horizontal rule has the following base styles:

hr {
    background: #738599;
    height: 2px;
}

The above styles would be changed within the alpha module in the following example:

.mod-alpha hr {
    background: #ccc;
    height: 1px;
}

Themes

Themes account for much of the appearance visitors experience when they visit a BoldGrid website. Themes define the general look and feel of areas like headers, footers, and typography while also establishing the width of the content area.

A BoldGrid Theme also houses what is known as a GridBlock Key, which is a set of styled elements that define the look and feel of content on the Theme's pages. This Key is utilized by GridBlocks (see below) to inherit the aesthetic qualities of the Theme. Every BoldGrid Theme should account for all of the elements presented within the Key. Defining GridBlock Key styles is an important part of BoldGrid Theme development, as leaving elements unstyled will result in unstyled GridBlocks.

Available Resources

All BoldGrid Themes include the following resources, enqueued by the Theme Framework:

In the case where additional functionality is desired, other external resources or libraries may be included in your theme in the appropriate folders (css, js, etc.) and enqueued in functions.php according to current WordPress Standards.

The BoldGrid Theme Review team will review all external resources and make the final decision on whether or not to include those resources in its Theme Framework.

If resources are not approved by the BoldGrid Theme Review team, those resources may not be included in an individual theme submission.

CSS Standards

To a large extent, BoldGrid Themes should follow existing WordPress CSS Standards

Structure

  1. Use tabs, not spaces to indent each property.
  2. Each selector should be on its own line, ending in either a comma or an opening curly brace. Property-value pairs should also be on their own line, with one tab of indentation and an ending semicolon.
  3. The closing brace should be flush left, using the same level of indentation as the opening selector.

Correct:

#selector-1,
#selector-2,
#selector-3 {
    background: #fff;
    color: #000;
}

Incorrect:

#selector-1, #selector-2, #selector-3 {
    background: #fff;
    color: #000;
    }

#selector-1 { background: #fff; color: #000; }

Spacing

  1. Group similar blocks together with no lines between each block.
  2. Add a blank line before a new group within a section.
  3. Add a blank line before a new section.

Correct:

/*--------------------------------------------------------------
# Header
--------------------------------------------------------------*/
.site-header {
    background: rgba(0, 0, 0, 0.8);
}
.site-title {
    font-weight: normal;
    text-align: center;
}

/* Call To Action */
.slogan {
    color: #fff;
    font-family: 'Raleway';
}

/*--------------------------------------------------------------
# Navigation
--------------------------------------------------------------*/

Incorrect:

/*--------------------------------------------------------------
# Header
--------------------------------------------------------------*/
.site-header {
    background: rgba(0, 0, 0, 0.8);
}

.site-title {
    font-weight: normal;
    text-align: center;
}
/* Call To Action */

.slogan {
    color: #fff;
    font-family: 'Raleway';
}
/*--------------------------------------------------------------
# Navigation
--------------------------------------------------------------*/

Selectors

  1. Use human readable selectors that describe what element(s) they style.
  2. Use lowercase and separate words with hyphens when naming selectors. Avoid camelcase and underscores.
  3. Refrain from using over-qualified selectors, div.container can simply be stated as .container

Correct:

#comment-form {
    margin: 1em 0;
}

Incorrect:

#commentForm { /* Avoid camelcase. */
    margin: 0;
}

#comment_form { /* Avoid underscores. */
    margin: 0;
}

div#comment_form { /* Avoid over-qualification. */
    margin: 0;
}

#c1-xr { /* What is a c1-xr?! Use a better name. */
    margin: 0;
}

Properties

  1. Properties should be ordered alphabetically.
  2. Properties should be followed by a colon and a space.
  3. All properties and values should be lowercase, except for font names and vendor-specific properties.
  4. Vendor prefixes should appear last, ordered from longest (-webkit-) to shortest (unprefixed).
  5. A comment line should appear before the block of vendor prefixes describing its purpose (except when there are no other properties).

Correct:

#overlay {
    color: #fff;
    padding: 10px;
    position: absolute;
    z-index: 1;
    /* Box Shadow */
    -webkit-box-shadow: inset 0 0 1px 1px #eee;
    -moz-box-shadow: inset 0 0 1px 1px #eee;
    box-shadow: inset 0 0 1px 1px #eee;
}

Incorrect:

#overlay {
    z-index:1;
    position:absolute;
    box-shadow: inset 0 0 1px 1px #eee;
    -moz-box-shadow: inset 0 0 1px 1px #eee;
    -webkit-box-shadow: inset 0 0 1px 1px #eee;
    padding:10px;
    color:#FFFFFF;
}

Values

  1. Space before the value, after the colon
  2. Always end values in a semicolon
  3. Use double quotes rather than single quotes, and only when needed, such as when a font name has a space.
  4. Zero values should not have units unless necessary, such as with transition-duration.
  5. Use a leading zero for decimal values, including in rgba().
  6. Use hex code for color values, or rgba() if opacity is needed.
  7. Hex codes should always be presented in lowercase characters.
  8. Shorten values when possible: #fff instead of #ffffff.

Correct:

.class { /* Correct usage of quotes */
    font-family: "Helvetica Neue", sans-serif;
}

.class { /* Correct usage of zero values */
    text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.5);
}

.class { /* Correct usage of hex values */
    background: #fff;
}

Incorrect:

.class { /* Avoid missing space and semicolon */
    background:#fff
}

.class { /* Avoid adding a unit on a zero value */
    margin: 0px 0px 20px 0px;
}

.class { /* Use lowercase values, shorten when possible */
    background: #FFFFFF;
}

Color Palettes

All BoldGrid Themes include five pre-selected color palettes (including the base palette), which may include two to five customizable colors, plus an additional 'Neutral Color' if necessary.

Each theme includes a SCSS file that defines the elements that will be changed and by which variables. When the user visits the Color Palette Customizer the colors defined by the theme, in turn define the variables. The now complete SCSS file, is compiled and then attached to the preview window to display an up-to-date reflection of the site. When the user is happy with their changes, they can save the changes. At which point all the updated variables are passed back to the server, the SCSS is compiled, and the new color palette CSS file is updated.

Color Palette Implementation

A BoldGrid Color Palette consists of three properties:

  1. Default ( boolean ) - Whether or not this palette will be automatically set if the user has not chosen/created a palette yet
  2. Format ( string ) - The format indicates the body class that will be used to apply the new color scheme to a theme. Multiple format types can be used to define which element groups will have a color applied to it.
  3. Colors ( array ) - List of colors to be included in a palette. Can be defined in hex, rbg, hsl etc.

The following function, included in config.php, creates a new Color Palette control with one color palette included.

Note: color palettes added through this filter cannot be removed by the user (see example):

$boldgrid_framework_configs['customizer-options']['colors']['enabled'] = true;
  $boldgrid_framework_configs['customizer-options']['colors']['defaults'] = array (

    $palettes = array (
        array (
            'default' => true,
            'format' => 'palette-primary',
            'neutral-color' => '#ffffff',
            'colors' => array(
                   '#ef7928',
                   '#25374a',
                   '#738599',
                   '#25374a',
                   '#f3f3f3',
            )
        )

return $palettes;
}

add_filter( 'boldgrid_theme_helper_color_palettes', 'theme_helper_color_palettes' );

SCSS Variables

A color variable consists of the format (primary) followed by the order of the color that is defined in the color format.

The following describes the first color in the palette-primary format (see example):

background: $palette-primary_1;

A standard text contrast function is also used so that colors may change appropriately in relation to the background color (see example):

color: $text-contrast-palette-primary_1;

Custom Site Title

All BoldGrid Themes support a number of customizable properties controlling the appearance of the Site Title.

See the following reference material in the Configuration File Documentation

Menu Locations

All BoldGrid Themes include five available menu locations, two of which are populated during site deployment.

Social Media icons must be able to appear in all menu locations with appropriate styling The specific locations are as follows:

See the following reference material in the Configuration File Documentation

Widget Areas

All BoldGrid Themes include three customizable widget areas in the Header.

The specific locations are as follows:

Plugin Support

BoldGrid Themes need to provide support for the following plugins.

WooCommerce Support

All BoldGrid Themes will provide minimal support for WooCommerce and should be able to pass the following User Acceptance Tests: