Educating a client is rewarding, and fun. At WebDevStudios, we take the time to walk clients through our processes and their new website, never abandoning them after launch.

Here are five things all WordPress website owners should understand. Comprehension of these concepts makes it easier for the discovery and strategy process of their website project.

1. Process vs Plugin

When you install a plugin that has the features you need, it is a small part of the process. Let me explain further with some examples.

SEO is a process, not a plugin.

One thing WordPress website owners should understand and accept now is that SEO plugins cannot magically improve your search engine rankings and get you more traffic by themselves.

Let’s take a look at the SEO process:

SEO Audit

This step includes auditing the whole website and content. Without this step, website owners cannot understand how to find and fix technical errors or flaws in the content strategy.

Technical SEO

Checking, creating, or fixing the following is a part of technical SEO: sitemaps, faster load times, internal links, 301 redirects, broken links, indexing status, and crawl errors.

Keyword Research

This is a significant step in SEO. Research the costs for keyword research software and services, and you can see this step is an industry itself.

Know your audience, then you can find what they are looking for online. The general rule is to choose long-tail keywords with high search volume and low competition ratio. But you can also choose competitive keywords and their related keywords.

If your competitors have long-form articles and rank high for a keyword, you can create videos. This gives you the edge over them.

Content Strategy

Once you have keywords, you should come up with a clear content strategy. This helps you create content related to each topic and is also valuable to your website’s visitors.

WordPress website owners should understand that there are many critical factors involved in SEO. You can’t predict the search engine algorithms, but you can control the quality and relevancy of your content and user experience.

There are a few popular SEO plugins out there, well documented and maintained. You might be using one of them, but SEO doesn’t stop there.

If you are not sure about which plugin to use, our UX designer Jennifer Cooley’s comparison of the top SEO plugins should be helpful.

Security is a process, not a plugin.

A security plugin or combination of plugins can let you set up a Web Application Firewall, IP-based restriction, etc. However, a security plugin alone can’t stop cybersecurity attacks.

Your hosting provider plays a crucial role in keeping the environment safe. You should keep the plugins and themes and core WordPress version updated.

Google / Harris Poll 2019 found that 24% of Americans used common passwords or some variation like Password, abc123, iloveyou, Welcome, etc.

WordPress introduced a password strength indicator in 2013, to encourage the use of strong passwords. But many users go with predictable passwords, even today.

Use two-factor authentication to add another layer of security to your website. DDoS, butte force and XSS attacks could be prevented with a combination of SSL, CDN, and following The Open Web Application Security Project’s best practices.

Security plugins play a part in the security process. You can keep your site secure with a combination of plugins, server configuration, and automated backups. For better understanding, watch this WordCamp London 2108 talk by Thomas Vitale.

Accessibility is a process, not a plugin.

Accessibility should be included in the development process. All WordPress website owners should understand that each component of the website should be accessible.

Allow your website development partner to take time and implement accessibility and audit the website in each sprint. Many website owners assume that installing an accessibility plugin at the last minute is good enough, which is not true!

2. Performance Scores vs User Experience

A performance optimization plugin is not the magic pill for performance issues. A popular myth among website owners is that a good performance score alone can bring more traffic.

The main idea behind core web vitals (CVW) is to offer a good user experience. You should not just rely on the CVW scores. Delight your website visitors with relevant content, clear navigation, faster load times, and follow best practices.

The content has to be relevant and worth reading and sharing with others, if not users might bounce off the page. This in turn increases the bounce rate which signals search engines that the content is not the best for the search query.

For further reading on CVW, dive into this piece from the Search Engine Journal.

3. Rebuild vs Redesign

Every website deserves a fresh look. No one likes the outdated design. This brings up the question, does your website needs a redesign or a rebuild?

Redesign refers to changing the look and feel of the website, and retaining the same content and features. Rebuild means you are changing the website structure, adding or removing features, and even migrating content from one website to another.

• When you change your brand’s colors or messaging, a redesign can help.
• If you want to introduce new features like memberships, shopping carts, etc., you need to rebuild the website.

Further reading: Dev Shortie: Rules For Your Redesign

4. You need to test before you update.

Updating plugins and themes and also core WordPress is always recommended. However, every major update needs to be tested on a development or staging site before going to the live site.

If you know that certain plugins are customized, then it is a must to test the new version before updating it to the live site. Take a look at the change log and see what has changed between the new version and the current version that your site has.

Fields, HTML markup, CSS class names other new features, or bug fixes might be introduced in the new version. Often newer versions require a database update too.

So you have to have a complete backup of files and database before the plugin, theme, or core updates go into the live site. If something goes wrong you can restore the backup.

Do you need auto-updates?

Since WordPress 3.7, you can allow automatic updates for maintenance and security releases. While this is good and saves time, it is not recommended for websites with a lot of customization. In most cases you will not get any critical errors or conflicts, so test it on a development environment, then update the live site.

Further reading: How to Test New WordPress Releases to Avoid Problems

5. Choosing the right approach for you.

When we say competition, we compare our products and services with the competitors on the market. It is common and unavoidable to compare, but you don’t have to go with the same tech stack that your competitors are using.

Choose the right plugins, themes, hosting, and other stack related to your website based on what works for you. Discuss with the web design agency and discover the available options. This will help you narrow down and decide well.

Don’t go with the trend just because someone is using it. Every website is unique in its own way. WebDevStudios is committed to delivering the best services to every client, as our mission statement goes, “Your success is our mission.”

Have an enterprise project in mind? Let us build and launch it together, contact us now!

The post 5 Things WordPress Website Owners Should Understand appeared first on WebDevStudios.

Sales is not a dirty word.

At her WordCamp Atlanta 2018 talk, “Selling to Enterprise Clients,” Director of Business Development at WebDevStudios, Jodie Riccelli, made this statement, but it’s also a common expression used by sales professionals to encourage others to not be intimidated by the traits required to be successful in the industry, no matter the type of client. However, when it comes to specifically selling to enterprise clients, Jodie says that you have to “handle them a little differently.”

She says that enterprise clients involve a long sales cycle, requiring patience and a list of commitments you’ll need to make to not only attain the client but to also maintain them. You can watch her talk below and learn what it takes to  win over clients like Campbell’s and Microsoft, such as creating personalized proposals and not relying on cookie-cutter templates.

Jodie’s advice for selling to enterprise clients is valuable. Click the play button now and find more WordCamp talks at WordPress.tv.

The post Selling to Enterprise Clients appeared first on WebDevStudios.

Starting with the Pace Foods website was as natural of a choice as their thick and chunky salsa. Our approach was simple: develop a few custom modules and utilize the out-of-the-box modules to rebuild the site. For us, Beaver Builder was the solution.

Why was Beaver Builder the right choice for this project?

Since the overall goal for CSC was to standardize their web development, “Beaver Builder seemed like the perfect tool to help them deploy sites uniformly and quickly,” explains Director of Business Development, Jodie Riccelli.

Utilizing Beaver Builder ensured that across their many brands, they would start to see commonalities in the overall feel since they would be using similar modules. It also meant a streamlined approach for training and the subsequent execution of changes and maintenance on the sites.

Budget-friendly, Custom Modules, and Easy to Manage

When we first looked at the Pace Foods site as a potential rebuild, we knew we wanted to add some modern elements. With that in mind, we knew we wanted to propose a few changes, but, as with all of our clients, we needed to be respectful and mindful of the budget we were working with.

Since Beaver Builder has great core functionality, we were able to include additional custom modules and make those modern updates to the site while not exceeding the budget outlined by the client. Incorporating some custom modules gave Pace Foods some added functionality that they were expecting.

“Our brilliant engineering team created some custom Beaver Builder modules that align with the needs of CSC. The custom modules in conjunction with the ease of Beaver Builder was the foundation for the new site,” Jodie adds. For example, Pace Foods answers customer FAQs using a custom module we built, even prompting the user to let them know if that information was useful.

Sometimes when a website is rebuilt, there is a drastic noticeable change in how the website works in the backend, which isn’t always the desired outcome. How a website is managed is oftentimes as important to the client as the frontend user experience. For Pace Foods, the goal was to provide a website where their team could manage the site with ease. WDS accomplished this goal for them.

Is Beaver Builder right for you?

Beaver Builder may just be the right tool for you and your consumer packaged goods website, too, if you are looking for something to help build an easy-to-use and budget-friendly website. Although there are some limitations, especially if you are looking to incorporate custom or pre-existing functionality, we are always here to help you overcome those challenges.

So let’s get this fiesta started! Contact us today to learn more about how WDS and Beaver Builder can benefit your website.

The post Pace Foods Plus Beaver Builder Equals One Hot Website appeared first on WebDevStudios.

WebDevStudios recently completed a challenging, yet very satisfying, WordPress project for The Comeback, a popular sports fan website. Among many duties, our team was tasked with rebuilding the Feature 5 grid functionality and extending it to support multiple grids, archive pages, and update styling. These changes involved creating a new “grid” CPT with the category taxonomy, refactoring the existing functionality into a plugin, and cleaning up how grids are created.

If you’re unfamiliar with the Feature 5 Grid, it is a grid at the top of a page the features or highlights five popular posts from various categories. It provides the editorial staff with the ability to curate these five stories to create a personalized experience for each site and page in the network.

Our main developers on this successful project were Cameron Campbell, Senior Frontend Developer/Designer, and Matt McAchran, Senior Backend Developer. Here’s their account of the obstacles they faced, the solutions they provided, and how they enhanced the overall experience of The Comeback.

“The old functionality was built directly into the theme; and since the grid was stored as an option, only one could exist at a time. The first step was to move the existing functionality into a plugin and refactor the code to store different grid attributes (posts, show on homepage, mobile settings) as postmeta. This enables multiple grids to be created in a scalable way.

The cross network searching for posts is powered by ElasticSearch and hits the global network alias, which points to all indices on the network. We only needed to store three pieces of information for each grid item (the location in the grid, ID of the post, and the ID for the blog the post belongs to).

The grid template was refactored to use a single template to allow for easy restyling and grids are cached on the front-end for performance.

The Comeback team wanted to also address the visuals of the Feature 5 grid. Some of the key goals were to provide a more visually complex/appealing experience for users in order to capture their attention and funnel them deeper into the site.

On the plugin side (in the Admin area), the grid needed to mimic the front end view as opposed to selecting posts from a meta box and only seeing the name of the post. This would allow their team to get a sense for the aesthetic of the grid and how images would work together. It also provided them with a way to quickly see if images needed to be edited in order to provide the aesthetic they were looking for. So we implemented the front end styles in an admin stylesheet and tweaked some of the proportions in order to account for any WordPress elements such as sidebars.

Some of other improvements we made to the front end of the grid were to bake in a more accessible experience, allowing the grid items to be tabbed through via screen reader for a better overall experience.”

You dream it. We build it. Let’s work together. Check out our portfolio, and when you’re ready to let WebDevStudios turn your big ideas into a big website, contact us.

The post Rebuilding the Feature 5 Grid to Create More Than a Comeback appeared first on WebDevStudios.

WebDevStudios is thrilled to announce the launch of the new and improved TheSportsGeek.com! Working with Kevin McClelland, editor of The Sports Geek, was exciting. The challenge that he presented included the requests for a fresh redesign, a logo refresh, and a full-site-rebuild on WordPress. The original website was somewhat outdated, text-heavy, and in need of some visual pizzazz to better represent the energy of the client.

Admittedly, I’m not much of a sports guy, but that doesn’t prevent me from designing a great experience while concentrating on the important part: the content. We needed a plan focused on engagement and energy, while retaining the “sports” feel, so as to not alienate current users.

The Process

The first thing you might notice about the old site is that it’s plain; there is a lot of white and red. The header takes up the majority of “the fold,” and the site wasn’t mobile-responsive or mobile-friendly—a design that hearkened back to the early aughts.

“With the world switching to viewing websites on mobile devices, I knew I needed an updated and responsive website, but I was hesitant on getting a new website designed,” explains Kevin. “I thought the process would be confusing and difficult for someone like me who doesn’t have a background in design or coding. Thankfully the WebDevStudios team made the process very easy.”

Kevin came to the design with inspiration drawn from various sports, sports news, and sports betting sites like CBS Sports and Fantasy Pros. Three things they all had in common was that they were content robust, generally monotone, and very modular. So I started there and extrapolated.

“Every step of the way was carefully planned out, and there was an entire team working together to ensure I was happy with all aspects of the website,” Kevin says. “Communication was top notch throughout with weekly calls to keep me updated, and any of my questions or inquiries answered very quickly.”

The Layout

The typical user wasn’t spending much time on the site. Once signed up, users had the opportunity to receive emails with a bulk of fresh content. So, the primary goal was clear that user retention was important, but more so, user acquisition. The majority of the content on the old site was being served up long form without much imagery or differentiation in content. I needed ways to break things up. Enter the card.

A simple but effective way to break up content throughout the site, this layout solution comes in two forms: a “feature” visible on most pages and a general-purpose “card” visible everywhere else. Even the widgets are compartmentalized to keep things separate, but together.

Every part of this site was designed to create a hierarchy and separation between content; thus, influencing user focus, something that was sorely lacking in the old site’s layout.

The Colors

Red plays only a minor role in the new site design. Instead, blue and yellow take center stage, which are colors commonly used in the sports world.

I needed to keep things calm (blue) while bringing focus to elements throughout the site (yellow). Success!

The Header

The old site’s header, video, call to action, and a button is persistent on all pages, which is fine, but taking up that much real estate on a page can be problematic, especially on mobile devices.

Here, I’ve decreased that space requirement, while also giving users the ability to hide this block (not entirely) to clean things up a bit. Though the magic of javascript and cookies, that state (open or closed) is saved for the user; so, they do not constantly have to open or close that header block. Ahh, the internet… What can’t it do?

The Logo

The logo took shape after the site was well into the design phase, which is a fun little design challenge. We were left with a very specific space to fill in the header (longer than it was tall), a limited color palette given the darker blue background, and the need to somewhat refer to the original logo of the old site.

I kept things angular and in the vein of the old logo, but with a little extra flare, grabbing inspiration from existing sports logos, news sites, and for good measure some tech sites (for the geek).

The final logo design came out of our fifth choice, after a few minor tweak and solidifying the type… Voilà!

“When it was time to launch the website, I was eager to see what my followers/fans thought of the new design,” Kevin shares with us. “Within just a few hours of going live, I had numerous emails and tweets from people letting me know how much they loved the re-design; and since then, I’ve still had nothing but positive comments.”

Conclusion

Given several, albeit minor restrictions, we were able to give The Sports Geek a fantastic new look and feel without ignoring its roots. We’ve organized the content and provided a better mobile experience for those catching up on the fly. If at the end of the day, site traffic and new-user acquisition has improved by even a fraction, we’ve done our job. And that’s the power of design.

The post Our Redesign for The Sports Geek Is a Sure Bet appeared first on WebDevStudios.

Australia’s favorite biscuit (remember, it’s not a cookie) Tim Tam has hit the US, and we’re proud to say that WebDevStudios (WDS) built the website for it. ItsNotACookie.com launched on January 17, and since then, our team can’t stop talking about it. Neither can the rest of the country.

The stateside launch of Tim Tam is big news. Media outlets from The New York Times to Mashable have covered it, often linking to the Where to Buy page of the site so readers know where to find a Tim Tam closest to them. When WDS Lead Frontend Developer Will Schmierer (photographed below) was first told he would be working on this project, he was excited and honored.

“It’s always fun to work on a brand new site, but even more so for a product that’s new to the US,” he says. “A lot of times we build new sites and themes for various sites and products, but it is rare to work on one for a new product to market.”

One of Will’s favorite features of the Tim Tam US website (and frankly, one of the features the entire WDS company enjoys, too) is the product locator. But, he’s also pretty proud of the animations found on the homepage and on a few others.

“All the heavy lifting on both should definitely go to the team as they worked hard to create these awesome features and I think they look and work great,” says Will. “I think the project overall was a success because of great teamwork with everyone involved.”

Will’s cherished Tim Tam flavor is Chewy Caramel, but he encourages everyone to try all the delicious flavors offered. He hasn’t tried a Tim Tam Slam yet (that’s when you use a Tim Tam as a straw to drink your beverage), but that’s because Tim Tam does not last very long in his household for him to try this trick.

“I saw video during development and had heard about it from one of our team members, so it’s definitely on my radar to do in the near future,” he promises.

The post Tim Tam Launched in the US (and We Helped) appeared first on WebDevStudios.

Because of a hard launch date, this project had a super short timeline and we decided a smaller team would keep us agile. Jaimie would be our Project Manager, Simon would handle the designs/PSD, Damon would deal with the front-end development, and I oversaw the back-end development, as well as serving as a lead for the project as a whole.

I’d like to share our teams experience through building a new website for a pretty well known client.

Designs

Part of the scope, was a custom design, which featured five different templates. Skype wanted something similar to their current production site, but freshened up a bit for the new product launch. Simon also had brand guidelines and some direction from our point of contact at Skype. I spoke with Simon who told me, “All design research starts with listening. One of the issues Skype had was [that] Skype TX was buried.”

Simon took some time to research the product and find the business value within brand guidelines. This process is called “business proposition.” During the design phase, Simon also had to make the case for a few features.

“Behind good design, there’s a reason for everything. Form follows function since we’re designing not only for the client, but the client’s client…” (AKA the user!)

Thanks to software like Invision, communication between the Simon and the client went smoothly and after a few revisions, both Damon and I had PSDs to work with.

Choosing the theme and plugins

Almost all of our projects include our starter theme, wd_s. This build was no exception! Wd_s enables developers to spin-up a starter themes quickly and develop with modern build tools like Sass and Gulp. We didn’t install too many plugins; we used a select few to manage content via point-and-click, ensure everything had a featured image, rearranging page order, and more. We also used a few custom plugins as well.

The Hero

By far the most complicated part of this build was the Hero.

Take a look at the requirements:

• Every post and page must have a hero
• Use post title, excerpt, and featured image as the content, but can add additional content can be added in a control panel
• By adding additional images/content, the hero turns into carousel
• Each carousel slide can have a modal
• Modal must support oEmbeds
• Customizable headline
• Customizable paragraph
• Support for two different buttons, one of which opens a modal

If your head is spinning, don’t worry. So was mine! After speaking with Chris for a bit, we put together a development roadmap and I got to work. Because this hero had to be on every post and page, we decided to use CMB2 to create repeatable group metaboxes. These would serve as the optional “control panel.”

I also used Slick to power the carousel and custom Javascript and CSS to power the modal.

In the end, I really like how the Hero turned out. Some of the functionality developed here, will make its way into our Hero Widget plugin on Github.

The Footer

While it may not appear to be complicated, the footer was indeed difficult. Microsoft requires footers on all their web properties to be visually similar. We were instructed to “copy” the footer assets, markup, and functionality from production.

This proved to be a bit of a struggle as Damon describes, “They had some toggling in footer that worked on desktop, but didn’t have a great mobile experience. So we updated the code by rewriting the Javascript around the toggling altogether…”

In the end, Damon did a fantastic job creating a footer that works beautifully at any viewport.

Accessibility

Microsoft takes accessibility very seriously, and this was part of scope from the beginning (as well as a general practice here at WebDevStudios). We had to design and develop to meet WCAG 2.0AA standards. As you can imagine, since Microsoft is such a large company, failure to meet these standards could cost them tens of thousands of dollars in fines. Fines aside, making websites accessible for everyone is just the right thing to do.

We put this site through some rigorous testing to ensure things like, the color contrast and HTML markup passed 2.0AA specs using both Total Validator and ContrastChecker.

Data Migration

Ah yes, the final part of this project was moving the content from their proprietary CMS into WordPress. Normally, this would be handled by our migration team using our custom migration plugin. However given that the site only had about fifty posts, and the time necessary to interface our plugin into that CMS, we instead opted to migrate the data by hand. This process went fairly quickly, and in no time we had all of their content in place.

Hosting

We’ve been working with Microsoft and their WordPress properties for a couple years, so we’re familiar with the unique challenges and benefits of running WordPress on Azure.

We introduced Microsoft to WPEngine and provided the technical guidance to get Skype in Media on WPE! It’s pretty cool that this project will be the first web property owned by Microsoft on WPEngine!

Conclusion

Even though this was a custom built site for an enterprise level client, we had a short timeline and a few development hurdles. In the end, it was a fun project. I believe we were able to successfully help rebrand Skype TX, and hopefully this will help them sell a few more pieces of hardware–which at the end of the day, is why we’re here.

The post How We Built Skype in Media on WordPress appeared first on WebDevStudios.

Part II of III in the wd_s Series:

• Part I: History of wd_s
• Part II: Project Scaffolding with wd_s
• Part III: The Future of wd_s

A new project comes in: scoped, and all. Client provides Photoshop comps, sweet! Who is going to write the first line of code? ¯_(ツ)_/¯

It could be you, and you’re setting the tone for the rest of the project. Project scaffolding can be fun, and can be daunting. Here are some things I learned getting wd_s set up on a new project recently:

Fonts. Fonts? Fonts! FONTS!!!

Most likely the design is not using Arial, Georgia, or Webdings. Was the designer smart enough to include the fonts with the PSDs? Hopefully, they used fonts that have web-friendly versions hosted by Google Fonts, or Typekit. However, that’s not always the case.

Recently, I had to sort through dozens of PSDs that had a plethora of font family variants, and some of which had no compatible web-friendly version. I was forced to create a spreadsheet and parse each PSD for font family variants, and see what each file contained. It ended up that of the dozens of desktop font files provided, only about 60% were used in the PSDs, and some of the fonts were not even provided, nor were they all properly licensed. Therefore I had to find an adequate substitution and verify with the client that this was acceptable.

Once I had all the fonts established I had to set up wd_s to enqueue externally hosted fonts, as well as locally stored variants. Luckily, that is the easy part, because with wd_s we already have Open Sans and Roboto enqueued (see scripts.php), therefore I just needed to swap out for the project fonts. The end result:

<?php

/**
 * Register Google font.
 */
function wds_font_url() {

    $fonts_url = '';

    /*
    * Translators: If there are characters in your language that are not
    * supported by the following, translate this to 'off'. Do not translate
    * into your own language.
    */
    $playfair_display = _x( 'on', 'Playfair Display font: on or off', 'wds' );
    $titillium_web = _x( 'on', 'Titillium Web font: on or off', 'wds' );
    $lato = _x( 'on', 'Lato font: on or off', 'wds' );

    if ( 'off' !== $playfair_display || 'off' !== $titillium_web ) {
        $font_families = array();

        if ( 'off' !== $playfair_display ) {
            $font_families[] = 'Playfair Display:700,700italic';
        }

        if ( 'off' !== $titillium_web ) {
            $font_families[] = 'Titillium Web:200,300,400,400italic,600,700,900';
        }

        if ( 'off' !== $lato ) {
            $font_families[] = 'Lato:100,300,400,700,900';
        }

        $query_args = array(
            'family' => urlencode( implode( '|', $font_families ) ),
            'subset' => urlencode( 'latin,latin-ext' ),
        );

        $fonts_url = add_query_arg( $query_args, '//fonts.googleapis.com/css' );
    }

    return $fonts_url;
}

$colors: Taste the Rainbow

Whether you’re working with five, ten, fifteen, or fifty design comps, grabbing repetitive colors from them is critical to saving time for other Front End Developers down the line. This is where the heart of rapid theming can lie. Here is an example of a color partial that I recently wrote:

//--------------------------------------------------------------
//   COLORS
// - Primary palette
// -   Secondary palette
//   GRAYSCALE
// -   Black & White
// -   Grayscale
//-------------------------------------------------------------

// Primary palette
$color-alabaster: #f2efe8;
$color-blue: #0074d9;
$color-brown: #42210b;
$color-camel: #c29c66;
$color-cigar: #7e573b;
$color-dark-brown: #2a1608;
$color-purple: #32234c;
$color-red: #d92231;
$color-tan: #ba915b;

// Secondary palette
$color-cardinal: #d52232;
$color-alizarin-crimson: #d82232;
$color-tall-poppy: #bc272d;

// GRAYSCALE

// Black & White
$color-black: #000000;
$color-white: #ffffff;

// Grayscale
$color-cod-gray: #111111;
$color-mineshaft: #333333;
$color-dove-gray: #666666;
$color-gray: #808080;
$color-silver-chalice: #aaaaaa;
$color-silver: #cccccc;
$color-alto: #dddddd;
$color-gallery: #eeeeee;

As you can see, a well organized color partial can help keep a project’s codebase easier to maintain. Keep in mind, this is just the start, and by the end of the project there tends to be more values added–depending on how well the original designs enforced strict color palette. Also, this is where a Style Tile can really help keep things consistent and streamlined, but not all projects require (or provide) one.

Off the Grid

The next step is establishing the grid base for our project. Wd_s uses Bourbon’s Neat framework for semantic layouts. We utilize a simple configuration file in the theme’s /variables/ directory to set the building blocks for our project’s layouts. Typically, this is as easy as hopping into Photoshop, and turning on Guides to view the required grid system being used, and updating our variables.

Optionally, I also like to take this opportunity to include a few helper, non-semantic classes to try and keep the project consistent in the _layout.scss, e.g.:

.wrap {
    @include outer-container;

    padding: 0 $gutter/2;

    @include wider-than(phone-landscape) {
        padding: 0 $gutter;
    }

    &.no-gutter {
        padding: 0;
    }
}

Note that we’re leveraging the variables set in our _grid-settings.scss for Neat, which helps keep things DRY.

• $gutter
• @mixin outer-container($local-max-width: $max-width) { ... }, which references our $max-width

While we’re in our _layout.scss partial, we can also update our main two-column layout if our project is using one, e.g.:

.primary {
    @include fill-parent;

    @include wider-than(tablet-landscape) {
        @include span-columns(8);
    }
}

.secondary {
    @include fill-parent;

    @include wider-than(tablet-landscape) {
        @include span-columns(4);
        @include omega();
    }
}

SVG Icons

It seems that every design incorporates some level of iconography these days. And why not? Icons can offer a nice supplementary visual cue for most users, as long as we gracefully degrade the experience for those that do not need (or cannot) experience them.

Wd_s has a library of SVG icons available out-of-the-box that were hand-picked from IcoMoon, but this is just a starting point, and each project will require removing and adding to the library. Luckily, I just recently updated the documentation on how to work with SVGs with wd_s; check it out: https://github.com/WebDevStudios/wd_s/blob/master/images/svg-icons/README.md

Exporting and minifying all of the original design iconography can help expedite your Front-end team’s development time, and again the benefits of consistency are obvious.

@mixins, further variabling, and @extending our Sass

Yep, variabling (variaBLING?) is the technical term…not! But, you know what I mean. Keep things as DRY as possible.

Perusing the Photoshop designs will give you a sense of where repetitive patterns happen, and where you can leverage the power of Sass to keep things tidy and modular for your team.

Is there a consistent border-radius used on all buttons, or maybe even other elements? Then set a variable $border-radius: rem(x), and update all the pertinent elements.

Recently, there was a need for certain images to have a CSS black-and-white effect applied. Therefore, I wrote up a simple @mixin for the team to use:

/// Make a color <img> B&W
///
/// @link http://caniuse.com/#feat=css-filters
///
/// @example scss - Basic Usage Sass
///    .hero-img {
///        @include desaturate;
///    }
///

@mixin desaturate {
    -webkit-filter: grayscale(100%);
    filter: grayscale(100%);
}

Conclusion

Project scaffolding is an important role for each new project, and helps set up a unified codebase for your team, as well as save overall time converting elegant Photoshop comps to pixel-perfect masterpieces.

Wd_s was built to expedite the repetitive tasks that are a part of Front End building. We’re constantly learning, and improving the methods and code behind it. Submit a Pull Request, and join the ride!

The post Project Scaffolding with wd_s appeared first on WebDevStudios.

First, let’s review how Git Flow works.

Main Git Flow Branches

It all starts with two main branches: master (which is the stable version of the software) and develop (which is where all the development happens). The main idea here is that develop is constantly changing as new things are added, and when features are completed, they are merged into master.

In this scenario, develop is always going to reflect what’s going into the next production release.

Supporting Branches

There are also three different sets of supporting branches.

• feature branches are for new features being developed for future versions of the software. When creating feature branches, a hierarchy is added by prefixing the branch with feature/, for example feature/my-cool-feature. features branch from the develop branch.
• release branches are used to organize features and fixes going into the next major software release. Like feature branches, they have a hierarchy added, like release/1.0. Like features, releases usually branch off develop.
• hotfix branches work a little different. Hotfixes are for when there’s an issue in the production software out in the wild and you need to fix it now and make sure it doesn’t get reintroduced. These branch from master (where the bug is) and merge into both master and develop, to make sure that the bug doesn’t come back when the next version is released.

A theoretical workflow might look like this (note: all images in this section are taken from Vincent’s post):

The current production version of our software is 1.0. We would like to start development on the next major release, 1.1. At this stage, master and develop are at the same state; we’ll assume we just barely shipped the 1.0 version. So we start by creating a release branch for our next version:  release/1.1.

When I start on a new feature for the 1.1 version, I create a new feature branch off of develop, build my feature out, and then merge it into develop. When develop is in a state where it’s getting ready for release, develop merges into release. The idea behind the release branch is it serves as a place for final changes, bugfixes and other minor changes that need to be taken care of before the next version is shipped. Those bugfixes and changes would then get merged into develop because, at this point, we’ve switched to committing directly to the release branch.

Now, let’s say, as we’re working on 1.1, something comes up–something’s broken and we need to fix it ASAP. I’ll create a hotfix branch off master, hotfix/some-bug, finish that, and then merge the result into develop and master.  What gets merged into master becomes the 1.0.1 release, and we create a tag for that version because we need to ship it before the 1.1 release is done. Merging it into develop means that we can be sure that the bug isn’t reintroduced once the new features being worked on in the 1.1 release get merged into master.

All of these branches can (and probably will) exist concurrently as different people are working on different elements. If I want Camden to look at something on my feature branch, I can ask him to check out which branch I’m working on and he’ll pull that down to his local, test it, and maybe commit some changes of his own to that branch which I can pull down when they’re ready. We can both be working on the same branch simultaneously, too, although before we’re able to push anything, we’d need to make sure our working copy has any changes that were pushed to the repository.

Putting all that together, you have something that looks like this:

WDS GitFlow

On client projects, the release branch loses importance. So do tags (although maintaining an archive of “versions” is helpful for backups). Our process has evolved out of this Git Flow model, and it starts off similarly, but has some distinct differences.

Pre-launch

Before the site is launched, there’s really only one main branch and two supporting branches. Our main branch is master, because when you set up a Git repo, that’s the initial branch you have. But our master branch is our development branch. Our production branch is prod, not master. The supporting branches we use are feature, which branches from master and is used primarily for functionality additions (largely stuff handled by the back-end developers) and theme, which also branches off master, and is used for things that go into the theme for the site. At this point, our Git process looks like this:

We also have deployments set up, so that commits to master are auto-deployed to a live lab server we run and test on in addition to our local environments. When the site gets ready to launch, we create a the prod branch off the finished and stable master branch and that gets deployed to the production environment. This makes deployments to production more intentional; in order to push to the production site, you need to check out the prod branch and deliberately push your changes. This makes it so there should be no surprise when code is on prod.

Once on the production environment, we go into final QA mode. We will have QA’d things on our lab server, of course, but inevitably there will be slight differences in environments from our lab server and the production server or things won’t work quite the way they were expected when the client is testing. At this point we use the hotfix branches to address any issues that are in existence in production.

When all remaining issues are taken care of, the site is either handed off to the client or we get ready to start work on a Phase II of the project. And this is where our new Git Flow model really kicks in.

Release as a Staging Environment

The guiding theory behind the revised Git Flow model is to use the release branches as a staging environment, ideally with a staging server that mirrors the production environment. As an added component, we’ve most recently started experimenting with release sprints. These essentially act like releases in the existing Git Flow model, where you are pushing toward a specific version, but instead of development coming off of develop (or, for us, master), our feature and theme branches split off the release. master (our development branch) is downgraded to, primarily, a testbed that has the added bonus of deploying to a lab server. Branches are kept clean from each other by coming off the release branch for the sprint we are working on and only getting merged back into that release when the feature is done done and has been tested to be working on master.

When that particular release sprint is done, it is merged into prod and we start working on the next sprint. It’s important to note that, at any given time, we could have devs working on different release sprints and that these sprints could be happening independent of each other. Unless we’re making changes that affect specific components from other sprints or feature branches, code changes are isolated and don’t end up in merge conflicts and features are more or less grouped to go into a specific sprint to prevent the same file being changed by different people at the same time on different releases.

If a bug is identified after we’ve started working on a release, the hotfix will be merged into any release branches there might be as well as going into master and prod.

Using this model, if I was building a feature, I would start by creating a new feature branch off the release branch–something like feature/my-new-feature. I would push my code to my feature branch. When I was done, I would merge feature/my-new-feature into master which gets deployed to the development server and is available for testing. If that feature tests good, my feature branch is merged directly into the release branch; it already exists in the master branch. It’s important to note that the code doesn’t get merged into the release until after it’s been tested on the development server.

When a sprint release branch is merged into prod, we’ll tag it (we’re still working out a naming convention, since version numbers aren’t as significant as dates) to create an archive that’s easy to roll back to if there’s ever a problem later.

Advantages of using this model

Having a dedicated staging environment is a good thing. Once a site is live, you don’t want to push code to it and potentially break it. But your development environment might not match the production environment. This is especially true if, as is often the case for us, you are maintaining your own development server, but the production server is running on a different host with a different environment. Maybe the production environment is a Windows Azure server, but your development server is running Linux. That makes having a staging environment to make sure that all your code works in Azure pretty important.

This workflow builds the staging server into the process so you have a place to push code that’s ready to go while giving you a failsafe in case there were issues that weren’t accounted for in testing or if there are environmental differences between the production server and the development server.

For freelancers and agencies, the traditional Git Flow workflow often doesn’t make as much sense because you aren’t producing a single “product”. You’re often producing multiple products–a combination of custom plugins, themes, and possibly even specific, curated plugins that your specific custom functionality extends. But that doesn’t mean that Git Flow shouldn’t be used in those cases. Instead, adapting the workflow to what works best in your situation can be incredibly valuable and prevent issues down the road.

What do you think? Are you using Git Flow? What is your typical workflow for client project development? Let us know in the comments!

The post An Alternate Git Flow for Client Work appeared first on WebDevStudios.

The Best Of series highlights the most popular and highest rated restaurants, businesses, entertainment and services in the area. Each year these two magazines dedicate one issue to Best Of  highlighting the best of the best in the city and surrounding suburbs. The team wanted to create a clean and organized way to search this list on their website and an easy way to add the winners each year.

The new Best Of section allows the visitor to scroll through a list of categories and view some information including details about the winner, photos from the location, addresses, phone numbers and website. Powered by a combination of custom post types, custom taxonomies, and WDS magic, the new Best Of sections make finding the Best of the Best that much easier with WordPress!

The post Using WordPress to Help Find the Best of the Best appeared first on WebDevStudios.