WP Dev Life

A Journey through WordPress

development

Migrating from Font Awesome 4 to 5

by

Today I was working with a custom genesis theme that a customer had created for one of his clients, but none of his icons were showing. There was only a square box. This was pretty perplexing to me. Everything in the code looked correct. Icons were being called properly, and the CSS files were properly enqueued, and showing in the browser. The issue turned out to be a change that Font Awesome made in version 5. 

Previously whenever utilizing an icon, the class would be something like class=”fa fa-instagram”. This is how the icons were being called in the theme code I was looking at and from everything I knew it was right. I checked the encoding of the database and created a new child theme. I even went so far as to not enqueue via WordPress and use the dirty @import statement. I downloaded the files locally and installed them on the site. Nothing I attempted was getting the icons to display. Only version 4 of Font Awesome worked. I was dead set on getting this resolved.

I decided to go to the WordPress.org plugin support forum  for the Better Font Awesome plugin to see if there were other reported issues for the latest font. The issue turned out to be related to the different styles of icons that Font Awesome now provides. 

Font Awesome allows for Solid, Regular, Light and Brand type of icons. Instead of using the fa class when loading the icons, you need to specify fas for solid, far for regular styling, and fal for light icons. If you’re going to be utilizing social media brands such as Instagram, Facebook, Youtube, etc. then you need to use the fab class. For example, if I wanted to load the Instagram icon, I would use <i class=”fab fa-instagram”></i>  to load the icon. Any non brand icons are able to utilize the other three icon styles. 

It is important to be aware of this change before updating any files that may be enqueuing Font Awesome version 4 to 5. At time of writing the latest version is 5.1.1. For a full list of icons, features, or to get Font Awesome Pro check out their website! 

Improve your Workflow with WP CLI

by

There exists within the WP CLI the scaffold command which allows you to easily create the base file and folder structure of some common WordPress features, like Plugins, post-types, or a theme based on Automattic’s _s. If you’re going experimenting with the new Gutenberg Editor slated for a Core Release in 5.0 there’s also the block generator. If you don’t currently utilize Boilerplates such as WPPB then using the scaffold feature of WP CLI can definitely help speed up your workflow

What does it do?

There’s multiple sub-commands for the scaffold command.

wp scaffold block – Generate the PHP, JS, and CSS files for creating your own Gutenberg block. I would definitely recommend this as a starting point for diving into creating custom blocks, especially since Gutenberg is slated for WordPress 5.0.

wp scaffold child-theme – If you use a framework such as Genesis, or Divi, or any other theme but need to get a child theme setup rapidly without manually copying/pasting files or creating them from scratch then this should shave some time off the initial setup.

wp scaffold plugin – Get a decent head start on developing a new plugin. I personally prefer using the WordPress Plugin Boilerplate because it gets setup for Object Orient Programming utilizing classes, so it gives you an even better headstart than scaffolding one.

wp scaffold plugin-tests – This will generate files for your plugin to run PHP Unit Testing on.

wp scaffold post-type – Whether you’re needing to get some post types added to your theme or for your plugin this command will generate all the necessary PHP code to register, and add a Custom Post Type to your plugin or theme, or just output the PHP code onto your Terminal for you to copy and paste it into a specific theme or plugin file.

wp scaffold taxonomy – Similar to the post-type command, this generates the PHP code necessary to setup custom taxonomies faster than having to manually type everything out, or saved somewhere as a template and then having to search and replace the necessary fields.

wp scaffold theme-test – Just like the plugin-tests this generates PHP Unit Test files around your theme.

wp scaffold _s – This works exactly like downloading a fresh file for Automattic’s Starter Theme Underscores or more simply put _s. You can pass all of the same arguments on the command line as you fill out on their website. It would be great to see WP CLI change the plugin scaffold command to use the WPPB setup that I’ve mentioned before, as their generator site works exactly the same as the _s website. If you need to create new themes and you prefer working with raw code starting from the bottom this is your best asset. I would like to see the addition of being able to choose some kind of CSS framework to add by default such as Bootstrap or Foundation as that could save additional time.

Wrapping it up.

For the full list of commands and more documentation I recommend reading over the Developer Handbook page.

Hopefully you find some usefulness to the scaffold command. Most local environments such as Wocker, or VVV will contain implementations of the WP CLI that are fully featured. Some web hosts that grant CLI access may turn off the scaffold command, but that’s due to developers scaffolding and programming locally before pushing things up with Git or another kind of development tool. WP CLI should be a part of any developer toolkit and can help speed up your workflow as you become more comfortable with it. 

Development Workflow

by

Everyone has their own workflow. With all of the tools like GitHub, TravisCI, VVV, Webpack, and the list goes on, every team or individual is going to have their own workflow. Even better, is that platforms such as WP Engine are providing tools to enhance these workflows to get your code into production. We’ll be going over a few different tools that I’ve found useful and how I’ve incorporated them into my own personal workflow.

Local Environment

This is probably the most important part of it all. There’s been a slew of ways to configure your local environment. A lot of people have traditionally used The *AMP family of environments, where you install Apache, MySQL and PHP on your local machine. This prevents a challenge though because if you’re working with a team, each one of you may have inadvertently configured things differently, or you’re running on completely different operating systems, and code written for one may not work properly on the others.

Income the Vagrants & Containers. When I first started writing code in junior high I had no idea what I was doing but I had Dreamweaver and some free hosting through one of the plethora of free web hosts of the early 2000’s where you’d bypass their popups with some clever script at the bottom of your site. Utilizing virtualization software and configuration through VirtualBox, Vagrants have taken a good forefront. It allows you to essentially have a preconfigured environment that can mount your local filesystem and develop your websites. My personal favorite that I’ve used recently is VVV from 10up. Varying Vagrant Vagrants is an open source Vagrant configuration focused on WordPress development. This is a great tool for developing themes or plugins. As I get more familiar with it and try out others I’ll do some full reviews.

The other day I was introduced to Wocker in the /r/WordPress sub-reddit. Wocker is a local WordPress development environment built on Docker. I haven’t gotten to experiment with it yet but looks promising. You still need to have Vagrant installed and configured to utilize this as well.

Code Versioning

Git duh. Whether you’re working on a personal project, or your company has a set of private repositories, or even a centralized custom git server. Git is the front runner in handling code versioning. Deploying those code changes from git else where whether handled by TravisCI for continuous integration, or Jenkins for continuous deployment, is a whole other beast that we’ll eventually cover.

Staging & Production

WP Engine has always provided a staging area for developers to test changes before deploying them to their production site. Things have gotten even better recently with their Deploy Site and Copy Site features as well as their Workspaces and Environment Labels, the latter being more for organizational purposes. Using these features though you can easily create a backup point, and deploy that from your staging install to another environment such as your production install. This means you can push your code with git to a dev install, deploy that to staging, have QA review, then deploy staging to production pretty seamlessly. As long as you’re only deploying code changes then your database on live is never touched so if you’re an e-commerce store you can be assured that no customer information is lost.

Other Thoughts

I’m sure there’s a lot that I haven’t yet covered, and even more that I need to learn. These are the basics for my own personal workflow and as that changes then this article will get updated to reflect that, or maybe a yearly series that covers my workflow and how it’s changed. There’s an idea at least. Thanks again for reading and if you’ve liked it or found it helpful share on Social Media. If you have any questions don’t hesitate to contact me!