1. Speed Up Your Development with Visual Studio Code

WDS Frontend Engineer, Oliver Harrison, reports that nearly 51% of developers claim to use Visual Studio Code as their primary  development environment. In this article, he offers some pieces of advice aimed to surprise you with a new keyboard shortcut or an extension you hadn’t heard about. Read his blog post to learn more.

2. Building the Next.js 9.4 WordPress Example

At the beginning of 2020, Greg Rickaby, Director of Engineering, set out to make WDS the “best damn Gutenberg shop out there” by rolling out a company-wide React and Gutenberg training program. It soon paid off when a client project came in that required Headless WordPress with a Next.js frontend. He writes about his experience here.

3. WordPress Block Development Made Easy

“WordPress block development can be daunting,” writes Backend Engineer, Michael Panaga, as he introduces the world to WDS’ scaffolding tool @webdevstudios/create-block, which makes block development easier. You’ll have to read his blog post to find out how.

4. How to Build Design Systems for WordPress

It’s another blog post written by Oliver! In this piece, Oliver covers the basics of a design system and touches on design systems specifically for WordPress. Read it here.

5. How to Enable Frontend Editing with Gutenberg Blocks (Part 1)

Senior Backend Engineer, Rebekah Van Epps, removes the mystery from frontend editing with Gutenberg in her two-part series. While Part 1 proved to be more popular, we highly recommend reading both for a thorough education. Read Part 1 here, and Part 2 here.

The WebDevStudios blog wouldn’t be the body of WordPress information that it is without the contributions of our team. Looking for a sure-fire way to make your corporate blog robust and engaging? Read this article on insourcing content.

The post Top Blog Posts from 2020 appeared first on WebDevStudios.

QA and UAT are review processes that are done during a web development project to ensure design and functionality requirements are met prior to a production release.

When you spend weeks, or even months, on a project only to wind up with a handful of QA issues (that you should have caught the first time around), it is easy to feel discouraged. You can receive QA feedback for scenarios you did not even think about the first time around. The person performing QA isn’t intending to discourage the developers. QA and UAT are intended to find the obvious issues, and the most nit-picky annoying ones that no one thought to test.

The goal of QA and UAT is to break the site… the code.

Self-QA

A major part of the QA process during development is doing it yourself. Remember that you, as the developer, are responsible for being the first set of eyes reviewing your code. Unfortunately, you can code a feature for so long that you become blind to obvious issues.

Slow down. We do have deadlines to meet, but a quick break from your code can really help. Taking a lunch break, stepping away from the screen for a few minutes, or even working on another task for a bit can get you refreshed for self-QA. You’ll be able to see the little things you can clean up, fix, or completely change for clarity, because you’ve taken a quick break from your code.

Another method of self-QA is to take the feedback you received at the end of your last project and apply it to new code. Do you consistently receive the same feedback on issues when a formal QA is done? If so, keep track of that feedback and include it as part of your initial development.

Peer Review

When you need a second pair of eyes, use your peers. If you’re building a large feature, using a new skill set, or just want some additional feedback on a task before turning it in for final review, grab a peer to review your code. If you’re working with a team, lean on them to make your code better and expect them to do the same with you. We should all have the same goal, produce the best possible product by writing the best possible code. 

Here at WebDevStudios, we have a system in place for our peer reviews. A developer will work on a feature and pass it to a senior developer for the initial round of code review. If everything passes their checklist, they pass it onto the a lead developer for final review and scrutiny.

A senior or lead developer may not have all the skills to get your code up to par. This industry changes so rapidly that no single developer can truly know everything. If you see code that a senior or lead developer can improve upon, let them know; and hope that you work in an environment, like WebDevStudios, that encourages knowledge sharing.

Formal QA and UAT

Once self-QA and peer review has been completed on individual tasks within a project, it’s time to do a full project QA and UAT review. This process will most likely be unique to your company or team structure. The general process is that an individual, or team of developers, reviews the entire site to perform visual and functional QA.

Visual QA and functional UAT processes may be completely separate from one another. Comparing a page in the browser to the mock-up, and running through a specific set of functionality, like new user registration, are two entirely different things. It is critical to perform both QA visual review and functional UAT.

As a freelancer or company, you also need to define your own pass/fail scenarios on visual QA. Do you want to strive for absolute pixel perfection, or is it okay for the placement of something to be off by two pixels? Will it be important to the client to take the time to take screenshots, write up a task, have it assigned out, worked on, and finally reviewed?

What isn’t subjective, though, is whether or not a thing actually works. This is where a strong-handed UAT comes into play. Before you can have a solid UAT process, you need to have a solid process for documenting how something should work. This can be either with user stories defined by the client in the project plan itself, or documentation written as the project progresses. If user stories are in place from the beginning, that means each developer knows exactly what they need to do in order to complete their work. Providing user stories can be a major cornerstone along the QA and UAT process.

Client QA

Once an internal formal QA and UAT is completed, it’s time to hand off the completed project/site to the client so they can run through their review and testing process. Each client is unique and will have their own QA and UAT review processes to ensure their site is functioning as expected, per the proposal, prior to a production release.

Clients are typically able to find bugs when they run their QA. Clients have very specific ideas about how things should look, function, and how they should be able to interact with elements on the site. Certain features or functionality may not have been conveyed in static mock-ups. For example, the way images or links hover, or how unique sets of content resize for small screens. This is where user stories can help to eliminate some of that disconnect between static mock-ups, and a fully functioning website. When clients find bugs or issues based on expected functionality, we consider this a learning experience. We have the opportunity to improve our processes so that we can improve on assumptions for the next project.

Conclusion

There are so many methodologies around what we do and how to do it more efficiently – whether it’s making sure your code is as clean as possible, or that your functions do just one thing. These are hallmarks of being a solid developer. But, if you’re writing clean, smart code and testing it in different scenarios, you’ll wind up with fewer issues in the various stages of QA down the line.

QA is not a single process run at the end of a project. In reality, QA happens at several points along the way, starting with the developer working on the task and performing self-QA, peer reviews with senior and lead developers, onto the person running internal QA, and finally in the client’s hands. The earlier an issue is caught, the better it is for everyone along the path of review. It’s so important to be able to reflect on your previous projects and apply the knowledge you’ve learned at the earliest stage possible.

What are your methods for QA-ing your work on a site from start to finish? Do you have suggestions or tips on how others could possibly benefit from your own workflows? If so, share them in the comments and let us know!

The post The Importance of QA and UAT appeared first on WebDevStudios.

Keeping with the Non-Traditional Traditions

I received my degree from a private liberal arts college, but only after a large and intentional vacation from formal education after high school. The college had a non-traditional, experimental program that was typically advertised toward “returning adults,” and this is where I chose to finally continue my formal education. It allowed me to not necessarily have a major, but a “focus” in communications, and specifically, an “interdisciplinary program with courses in multimedia theory and design.” So I was able to dabble a little in graphic design, 3D animation, music theory, and multimedia computer programming. This is where I was introduced to HTML, CSS, and Flash.

(Note: I did not take any computer science classes, which would have probably pointed me in a different trajectory career-wise. Instead, I was more fascinated with the visual, as opposed to the computational disciplines.)

It can be easy (although probably no easier than any other excuse) to have Imposter Syndrome when your formal education is founded on a multi-disciplinary degree, i.e. Jack of all trades, master of none. However, as some have pointed out…

“Learning isn’t a zero-sum activity.”

– “The Myth of the Myth of the Unicorn Designer” by Thomas Cole

Code Is Poetry

My first few jobs heavily involved HTML, CSS, and Flash, of course, as well as dabbling in many other languages and systems. However, I quickly gravitated toward WordPress when I was tasked to research alternative content management systems (CMS) for a state college. I started to become familiar with all the concepts that made up a good and bad CMS and was able to research where each private and open source solution lie on the feature vs cost spectrum. I became passionate about the idea of open source software, and WordPress was, and still is, at the forefront.

Today, the WordPress tagline “code is poetry” has become a mantra in my everyday work. So much of what we, as Front-End Developers, write relies on syntax, logic, and structure. Also, good code (as there is plenty of bad code and poetry) requires elegance and simplicity. The meaning with code and poetry can be both on the surface and simultaneously abstract.

Enough About ME!

So why am I giving you my entire bio? Because again, I think it is important to providing context to why I’m fascinated and passionate about composing CSS. In the upcoming posts, I’ll cover some key points along the history of CSS to try and demonstrate where I see CSS evolving. Remember, writing code is a multi-disciplinary venture, and one should never stop learning.

Stay tuned for the next post in this series:

• Evolution of CSS – Part II: CSS Class Naming Conventions
• Evolution of CSS – Part III: Overview of Tachyons

The post Evolution of CSS: Becoming a CSS Composer 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.

My local development environment for this is Laravel Homestead. Homestead is free and runs in VirtualBox (or VMware), on Vagrant and includes, Ubuntu 16.04, Git, PHP 7.0, HHVM, Nginx, MySQL, MariaDB, Sqlite3, Postgres, Composer, Node (With PM2, Bower, Grunt, and Gulp), Redis, Memcached and Beanstalkd.

Setup Homestead

To start, let’s install VirtualBox or VMWare AND Vagrant. I prefer VirtualBox because it’s lightweight, comes with Vagrant out of the box, and most importantly, it’s free.

$ cd ~/home/vagrant/Code/wordpress-site 

Next, we’re going to clone homestead into our root user directory and initialize Homestead to create our configuration file and define our provider–in my case, VirtualBox.

$ git clone https://github.com/laravel/homestead.git Homestead
$ bash init.sh

After you’re set up, we can setup our configuration file and local file structure. I’ll base this on how I work, but generally, how you organize your files are up to you.

Open your Terminal.app and type homestead edit which will open the homestead.yaml file in your favorite code editor.

---
ip: "192.168.15.15"
memory: 2048
cpus: 1
provider: virtualbox

authorize: ~/.ssh/id_rsa.pub

keys:
    - ~/.ssh/id_rsa

folders:
    - map: ~/Dropbox/Private/Working
      to: /home/vagrant/Code

sites:
    - map: wordpress-site.dev
      to: /home/vagrant/Code/wordpress-site
      
databases:
    - wp_1

variables:
    - key: APP_ENV
      value: local

# blackfire:
#     - id: foo
#       token: bar
#       client-id: foo
#       client-token: bar

# ports:
#     - send: 93000
#       to: 9300
#     - send: 7777
#       to: 777
#       protocol: udp

I’m not going to go over everything here, just the parts that make Homestead go. They’ve added some bells and whistles like ports, variables and Blackfire support—which makes it easy to test PHP performance—but you can Google those.

From the top:

• ip is automatically pulled in from your machine – leave this alone.
• memory is set to 2048 by default.
• authorize and keys reference your SSH keys. You can learn more about that here.
• folders contains two parts map and to. map is the relative location on your computer, in my case ~/Dropbox/Private/Working. I like having a good 24/7 backup of working files, hence Dropbox. to refers to the default vagrant folder location. You can use the default location, I just find it easier and nicer to work out of the folders I want to work out of. Ya know control!
• sites here’s where the fun starts. These are my local WordPress installs.
• databases are the matching databases for each of your sites. Name them whatever you’d like.
• variables, blackfire and ports don’t need to be touched, but you can read more about those here.

Next thing you’ll want to do is map your new site URL to your ip in your hosts file so that you can use your URL.

$ sudo vim /etc/hosts

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost

192.168.15.15   wordpress-site.dev

Save and you’re good to go.

Now, unlike MAMP (see below), one thing that Homestead doesn’t have is a visual phpMyAdmin interface—everything is command-line. However, here is where I recommend SequelPro for accessing, editing, and maintaining your Homestead databases. Access is super simple by using the configuration below:

Name: Homestead
Host: 127.0.0.1
Username: homestead
Password: secret
Database: (name optional)
Port: 33060

From here, you can do anything you can do via ssh and command line with a simple GUI interface.

## Install WordPress
Easy as 1, 2, 3. I’ll do it with command-line, but you can just drag and drop files just the same.

$ cd ~/home/vagrant/Code/wordpress-site 
$ wp core download

? Boom–you’re ready to setup WordPress. Go to http://wordpress-site.dev (or whatever you’ve named your website) and follow the WordPress setup the way you normally would.

Note: If you’re building static sites, you can just drop files into your root and you’re ready to rock–no 1, 2, 3 needed.

Some Extras

Good for all databases:

Db Username: root
Db Password: secret

memory in the homestead.yaml files is set to 2048 by default, but I recommend 1024 to have a fast local machine without taking too many resources away from other tasks. On my Macbook Air 2011, I found that 2048 took too much away from other apps and slowed down my computer considerably if I was trying to use Adobe Photoshop or Chrome with ninety tabs side by side. 512 works just fine if you’re only running one or two sites.

Things I Learned Recently

I use Homestead for smaller projects, one-offs, and personal website tasks—it’s still much quicker for me than any other local environment setup.

Recently, however, I had to make a switch to MAMP for a project that was showing issues on my local environment. After all, Vagrant is notorious for being a tad buggy from time to time, so it made sense that the issue was caused locally. Despite resetting and spinning up a new local the problem persisted. Long story short the issue was in the code and not my local working environment, but by that time I’d made the switch to MAMP to ensure my local was the same as my coworkers.

Though I still swear by Homestead for simplicity and ease of use, I did notice a few things with MAMP to my surprise. MAMP v 4.0 upgrade was clean and easy to use. Most importantly, however, the CPU and memory load on my computer was almost half of what it was with Homestead running on Virtualbox. As a result, the little fans on my Macbook Air haven’t spun up once since I moved over to MAMP. I have a feeling that a more powerful computer might not have the same issues, but it was an interesting find considering my sordid past with MAMP 2.x.

The Alternatives

My colleagues tend to recommend MAMP Pro v 4.0 as a solid local work environment. Having played with it a little recently, I agree that it’s worth checking out. It is a paid program, and a solid platform with easy-to-use GUI features and easy to maintain databases. It provides everything you need to keep frameworks up to date and running smoothly.

Some friends of mine use Wamp Server, which is something akin to MAMP’s free option. Not as robust certainly, but it gets the job done.

ScotchBox is more or less like Homestead. It runs on Vagrant, and VirtualBox, but limits you to only one virtual machine or WordPress install at a time (unless you want to get into configuring Ubuntu). That doesn’t work for me, since I work on multiple web projects at once and often have to spin up a new one quickly. The actual setup and configuration is a bit more complicated than is necessary, so it requires some additional effort. If you’re into trying new things, it’s worth checking out, but after my own exploration, I determined it’s just not for me.

I’ve even known a dev or two to use services like DigitalOcean to spin up a quick WordPress install and go to town. This isn’t technically a local install as you’re running off of their servers, but it’s private and available anywhere from any computer with the right credentials. The downside to DigitalOcean can be its intense learning curve if you’re not familiar with backend server setups. These self-maintained droplets can quickly fly off the shelf if permissions get altered, or if security precautions aren’t properly executed.

If you’re looking for a local dev environment that, after setup, is super quick to spin up and maintain, my vote is Homestead. What’s your favorite local setup?

The post My Local: Getting Started with Laravel Homestead appeared first on WebDevStudios.

My Development Evolution

When you start developing, you’ll quickly realize you need to get some sort of development environment up. In the beginning, I was actually using direct FTP before I had heard of GIT or any sort of version control. I started out by using Dreamweaver for FTP and syntax highlighting, this is back when they were owned by Macromedia.

It wasn’t until about a year before WDS that I started using Sublime 2, and slowly evolved into using PHPStorm, which I now use daily. However, my coding application isn’t all that evolved. Upon starting with WDS I was actually using Xampp, since I’m a Windows guy. Xampp for me was my go-to development environment for the longest time considering its ease of setup (just download a zip file) and overall reliability.

The Vagrant Story

Coming from Xampp, Vagrant is a godsend, especially for us non-Linux folks using Windows. For the longest time, Vagrant fans preached to me; it’s SO MUCH BETTER they said, and indeed it was. With Xampp, I had to edit the vhosts file, create a database, and download and install WordPress by hand any time I wanted to create a new site.

For awhile it worked fine, but then came my never-ending thirst for knowledge. I thought, “Hmm, so what is this Vagrant?”

I decided on a whim to install it and give it a go. After about a two hour session with Parbs on getting set up, it was installed, and I was so happy. Now, I only needed to run one nifty little command vv create and I was up in just a few minutes.

About a year after installing and using Vagrant regularly for my day-to-day environments, I’m eternally grateful for the speed with which it sets up projects and its simplicity–no more juggling vHost files/settings or setting up SQL databases! Overall, I was happy in my ignorance regarding how to actually do most of this myself.

Vagrant’s Demise

Earlier this year, PHPStorm released an update that allowed project-level interpreters, as well as the ability to use PHPcs remotely, which is absolutely amazing! For my day-to-day, I actually set up Vagrant as a remote interpreter, set it to use the PHPcs installed there, and it pretty much worked as intended.

However, over time, with more projects, Vagrant started to slow down. Taking upwards of twenty to thirty minutes to either up or halt the VM is just absolutely absurd! If I wanted to take my laptop somewhere and work (in sunlight), I was forced to copy the required databases and files/Git to the laptop just to go somewhere. And believe me, some projects are gigabytes of data.

This presented a REAL problem for me. By nature, I’m not that mobile; I tend to work in front of my quad monitor setup daily from nine to five, and if life threw me a curve ball, I had to adapt or take a personal day. Having to ‘prep’ to leave sometimes would take hours depending on which project I was scheduled for. Failing to meet a deadline is absolutely unacceptable, regardless of the reason.

Project Overload

Vagrant is a box. We know this. It’s a virtual machine that is meant to operate as if you’re looking at a completely separate machine. The first and most obvious benefit to a Windows user like me is that I can comfortably develop for a Linux OS without having to install Linux. However, the amount of projects we work on daily at WDS varies; we have our slow days, and we have crunch time. Just like any other developer, I typically leave a site installed on Vagrant until our client is out of the support phase.

This is the problem, at any given time I have ten to twenty sites online at the same time, on one Vagrant box. The startup time for the box was just horrendous; I could literally go make a sandwich, drive to Starbucks, and back again, and it still wouldn’t be done. When Vagrant starts up, at least from my understanding, it has to go through a sort of ‘provisioning’ startup process. Reading all those configs, starting up the database, etc…the amount of time it took was just unreasonable.

Halting the virtual machine was even worse. Have you ever tried backing up 20GB of databases on 2GB of ram? If so, I’m sure you feel my pain. During shutdown, Vagrant has to backup the databases, which led me to simply leave it on for quite some time. However, the longer it was on, the more problems I had–MySQL out of memory, PHP freezing, and more. This just added to my development time.

Lack of Mobility

For me, as I said, mobility with a Vagrant install is limited. There are definitely options out there however, like “Moving VirtualBox and Vagrant to an external drive,” so it can be done if you’re okay with lugging around a hard-drive or thumb-drive. For me, that’s unacceptable; this is the age of the cloud, yeah? Having to take a hard-drive with me was not going to happen.

This led me to ‘backing up’ my SQL databases, project files (including .git files), and even in some cases the entire /uploads directory onto my little 16GB thumb drive. Copying over these things would take hours, especially if I had more than one project for that day. This, in turn, led to me having to pretty much prep hours ahead of time, and with three kids, that’s not much sleep time if I have to get up more than two hours early.

The Solution

A fully remote development environment.

For about two years I’ve owned a rack server from SoYouStart.com. It has mainly held my gaming servers and my personal websites. However, with a whopping 2TB of space, I was utilizing a mere fraction of what was available, so with the additions of the new PHPStorm features, I figured I’d try it out.

For security reasons, I obviously don’t keep the GIT credentials on my server. I’d really hate for it to get hacked or something and someone gain the ability to push/pull code changes, so I do ‘technically’ have all the code locally as well.

Having it setup in this manner allows me to keep the code and databases in one location for every project. This means if I need to just grab the laptop and go, now I can do that. I don’t have to worry about bringing a database and/or files to sync on my laptop–all I need to do a pull when I sit down.

Additionally, if I need to illustrate something to another developer or designer, or if something is broken on my local versus the client’s site, it’s easier to debug. Utilizing a remote server allows users the ability to actually view my development environment instead of limiting us to just a Skype screen-share.

And that’s why I stopped using Vagrant.

Have any of you had the same issues? Who else has tried a fully remote development environment?

The post Developer Devolution: Why I Stopped Using Vagrant appeared first on WebDevStudios.

We got bored with having to make our coffee in the morning, so some brilliant mind created an automatic coffee maker with a timer so we could tell that machine when to make our coffee and how much of our coffee it should make.

We grew weary of the painful necessity of talking to actual human beings in order to have food arrive at our front doors, so the greatest pizza scientists in the world made it possible to order a lovely cheese pizza–just for me–by texting a single emoji. ?

We became so incensed at our watermelons constantly rolling away from us that the top watermelon doctors on the planet engineered square watermelons.

…Yes, the first milestones in human advancement that I can think of are all related to food and I will make no apologies for that.

When I’m not eating food or thinking about eating food, though, I’m probably working on a fabulous WordPress website using my editor of choice, Sublime Text 3 (ST).

ST is simple, yet robust, and offers countless packages to help speed along your development process. In addition to offering fully-developed packages for mass consumption, ST also offers the opportunity to craft custom snippets to take the legwork out of the things you type over and over again from day to day. In this post, we’ll show off a handful of examples we’ve picked up along the way as well as some that we’ve crafted for our specific uses at WDS.

What are snippets?

Snippets are a quick, shorthand way to type out a longer or more elaborate string or output. As you’ll see in our examples below, snippets can be extremely robust and can be customized to fit your needs.

How do I make a snippet?

ST3 makes it super easy to create a snippet. You simply select Tools > Developer > New Snippet from the toolbar menu and you’re off to the races!

ST3’s website offers some great information on snippets and how they are setup.

In order for a snippet to be used later on, it must be saved in the proper place. ST3 will typically place you in the proper directory when you save your new snippet, but if it does not you will need to look for User > Library > Application Support > Sublime Text 3 > Packages > User and save your snippets there with the .sublime-snippet file extension.

Comment Snippets

Comments are key. They let the person coming after you know what you were doing and why; they also let you know what you did and why when you come back to your code in six months. They are the trail of breadcrumbs leading you back to the genesis of your reasonable thought process. If there are no comments, how are we to know why you coded something a certain way?

WDS is a big proponent of docblocks and inline comments throughout our PHP, JS, and Sass files. We should make our files easy to understand and leave no question as to why we chose to do things This Way rather than That Way.

Recently we upped our Sass partial comment game by making it a standard to add a comment after the closing bracket to indicate what is being closed. This helps with any Sass partial where are a parent selector contains a lot of information within it; we no longer have to scroll up the page to see where the selector is opened. This became tedious for me, though. I kept having to manually click down to the closing bracket, type a double // and then my comment. Oftentimes, ST would adjust the indentation of my closing bracket forcing me to take another step before I was ready to click inside of my selector, tab in, and begin my actual work.

Exhausting!

So, I created this handy little snippet:

<snippet>
    <!-- Type `bracket` and hit tab to open a bracket with a closing comment. -->
    <!-- Type the class for the element you are styling and it is placed at the top and in the comment after the closing bracket -->
    <!-- Hit tab a second time to put your cursor into a beautifuly tabbed spot within the bracket -->
    <content><![CDATA[
${1:this} {
    $2
} // ${1:this}
]]></content>
    <!-- Optional: Set a tabTrigger to define how to trigger the snippet -->
    <tabTrigger>bracket</tabTrigger>
    <!-- Optional: Set a scope to limit where the snippet will trigger -->
    <scope>source.scss</scope>
</snippet>

Not only do we strive for clear comments in our theme files, but look at those comments in the snippet itself – you know exactly what it does without me having to explain it! Nonetheless, here is a snappy little gif so you can see it in action:

It was only then that I took a step back and began to look at the rest of the partial. What about a quickly utilized comment block at the top of the partial itself, or even one when we begin to style a parent element? Well, you’re in luck!

Here’s a snippet that will output a comment block at the top of a Sass partial:

<snippet>
    <!-- Type `partialcomment` or `pcomment` and hit tab to output a comment block. -->
    <!-- Type a short description of your partial and you're good to go! -->
    <content><![CDATA[
//--------------------------------------------------------------
// ${1:Partial Description}
//--------------------------------------------------------------
]]></content>
    <!-- Optional: Set a tabTrigger to define how to trigger the snippet -->
    <tabTrigger>partialcomment</tabTrigger>
    <tabTrigger>pcomment</tabTrigger>
    <!-- Optional: Set a scope to limit where the snippet will trigger -->
    <scope>source.scss</scope>
</snippet>

And a modified version of the above for a smaller comment block above a parent selector:

<snippet>
    <!-- Type `selectorcomment` or `scomment` and hit tab to output a comment block. -->
    <!-- Type a short description of the element you are styling and you're good to go! -->
    <content><![CDATA[
//-----------------------------------------
// ${1:Selector Comment}
//-----------------------------------------
]]></content>
    <!-- Optional: Set a tabTrigger to define how to trigger the snippet -->
    <tabTrigger>selectorcomment</tabTrigger>
    <tabTrigger>scomment</tabTrigger>
    <!-- Optional: Set a scope to limit where the snippet will trigger -->
    <scope>source.scss</scope>
</snippet>

So easy! One great thing you’ll notice in the snippets above is the <scope> setting. This is a great list of available scopes to be used with snippets. In our examples above source.scss guarantees that our snippet will only be available when editing a .scss file, so we don’t need to worry about any unexpected results while working in a PHP or JS file.

There is also a great package called DocBlockr which simplifies and expedites the process of writing docblocks above your functions. One of the settings I really love is the ability to set your name as the author of the function to eliminate any additional typing. Not only that, but it sniffs out any values being passed into your function and allows you to tab through and add additional details:

Sass Snippets

Comments are beautiful and important, but there is also so much more we can do with snippets inside of a Sass partial. We use Bourbon Neat at WDS in our wd_s starter theme, so it only makes sense to use some snippets specific to the wonderful things available thanks to Neat.

Let’s start with one of the cornerstones of Neat: ridiculously simple columns. While putting these columns into place is easy as pie, that’s no reason to give up on making it even easier to use. Check out our span-columns snippet below:

<snippet>
    <!-- Type `span-columns` and hit tab to output the span-columns() mixin. -->
    <!-- The cursor will be placed inside of the mixin's parenthesis for ease of entering a column size. -->
    <content><![CDATA[
@include span-columns(${1:8});
]]></content>
    <tabTrigger>span-columns</tabTrigger>
    <description>Set a column width using Neat</description>
    <scope>source.scss</scope>
</snippet>

Of course, there is a chance we’ll want to change the size of this column at a larger breakpoint. It’s a good thing we have a quick little snippet for that, too!

<snippet>
    <!-- Type `media` and hit tab to output the media() mixin. -->
    <!-- The cursor will be placed inside of the mixin's parenthesis for ease of entering a breakpoint. -->
    <content><![CDATA[
@include media(${1:\$tablet-landscape}) {

}
]]></content>
    <tabTrigger>media</tabTrigger>
    <description>WDS Media Query</description>
    <scope>source.scss</scope>
</snippet>

Sometimes we need something a bit more simpler, though. Adjusting margins and paddings on an element are no huge task, but there are going to be times when we just need a fresh reset on the margin and padding of an element to zero. Why manually type out the values for margin and reset when we can type a single word, hit a single key, and have a beautifully simple element free of margin and padding? The answer is “Don’t manually type it out,” ya big turkey!

<snippet>
    <!-- Type `margin reset` and hit tab to output the margin-padding-reset mixin. -->
    <content><![CDATA[
@include margin-padding-reset;
]]></content>
    <tabTrigger>margin reset</tabTrigger>
    <description>Reset the margin and padding</description>
    <scope>source.scss</scope>
</snippet>

PHP

We work in and love WordPress, so most of our snippets are WP-centric. However, that doesn’t mean that we don’t have some more generalized snippets for good ole PHP. These mostly help us debug issues or print data to the front-end for testing purposes. I make frequent use of an echoprintr snippet first shared with me by Justin Sternberg:

<snippet>
    <!-- Type `echoprintr` and hit tab to output the print_r function wrapped in xmp tags mixin. -->
    <!-- The cursor will be placed inside of the print_r function. -->
    <!-- Hitting tab will palce the cursor before the colon inside the opening xmp tag for the addition of helper text. -->
    <content><![CDATA[
echo '<xmp>${2}: '. print_r( ${1}, true ) .'</xmp>';$0
]]></content>
    <tabTrigger>echoprintr</tabTrigger>
    <scope>source.php</scope>
</snippet>

Need to view the contents of an array or an object? Give this sweet little var_dump snippet a whirl and let it brighten your day:

<snippet>
    <!-- Type `echovardump` and hit tab to output the print_r function wrapped in xmp tags mixin. -->
    <!-- The cursor will be placed inside of the var_dump function and inside of the preceding <strong> tags. -->
    <content><![CDATA[
echo '<strong>${1}:</strong><br>', var_dump( ${1} ), '<hr>';
]]></content>
    <tabTrigger>echovardump</tabTrigger>
    <scope>source.php</scope>
</snippet>

WordPress Snippets

Of course, as mentioned above, WordPress is really our bread and butter here at WDS, and we love bread and butter. WordPress offers a ton of helpful hooks, filters, and template tags to customize your custom WP build to your heart’s desire. We’ll show off just a few snippets used during theme setup and throughout the entire theming process.

We know our website is going to have images. Your website is going to be some sweet combo of images and text, and we need to make sure we have the proper image sizes being served at the proper times for whatever use cases we need. Have a massive hero section at the top of your page and need an image sized and cropped to specific dimensions? Have a river of posts below that massive hero with smaller, yet just as important, featured images? Adding those image sizes in WordPress is easy peasy with add_image_size, but with a nifty snippet we can make that even easier peasier:

<snippet>
    <!-- Type `add_image` and hit tab to output the add_image_size function. -->
    <!-- The cursor will be placed inside of the function where you can enter the name of your custom image size. -->
    <!-- Hitting tab once will allow you to set the width of the image. -->
    <!-- Hitting tab a second time will allow you to set the height of the image. -->
    <!-- Hitting tab a third time will select the entire crop setting. This can be a boolean (true/false) or an array with more custom settings. -->
    <!-- If using the crop array, hitting tab again will allow you to specify the x-crop position. -->
    <!-- If using the crop array, hitting tab a final time will allow you to specify the y-crop position. -->
    <content><![CDATA[
add_image_size( '${1:foo}', ${2:300}, ${3:350}, ${4:array( '${5:left}', '${6:top}' )} );
]]></content>
    <tabTrigger>add_image</tabTrigger>
    <description>Register a new image size with WordPress</description>
    <scope>source.php</scope>
</snippet>

The power of WordPress lives within its loops. The loop is the life-force by which all posts exist. We need the loop to display our content, but we don’t need the loop to be a potentially confusing and hard to remember series of strings and if/else statements. The following loop assumes you have already established the $args for your new instance of WP_Query. Once those arguments are set, simply type loop, hit tab, and voila!

<snippet>
    <!-- Type `loop` and hit tab to output a simple WP_Query loop. -->
    <content><![CDATA[
<?php \$foo_query = new WP_Query( \$args ); ?>

<?php if ( \$foo_query->have_posts() ) : ?>

    <?php while ( \$foo_query->have_posts() ) : \$foo_query->the_post(); ?>

    <?php endwhile; ?>

<?php endif; ?>
<?php wp_reset_postdata(); ?>
]]></content>
    <tabTrigger>loop</tabTrigger>
    <description>A custom WordPress Loop</description>
    <scope>source.php</scope>
</snippet>

Now you’ve got a loop where you can pull in content and display it to the outside world. But, what happens when the people viewing your website come from different parts of the world? You want every person to be able to have the same experience no matter what language their preferred language, right? It sounds like you might need to internationalize your text strings! This is a key component of anything we develop at WDS; we always want to make sure that any text string in a theme or plugin is going to be easily translatable to other languages. If you haven’t hopped aboard the i18n train just yet, read up on what it is and why it’s so important. We’ll wait here.

…

All done? Good! Now you’re ready to use this slick ST snippet for ease i18n strings:

<snippet>
    <!-- Type `i18n` and hit tab to output a ready-to-use escaped and translatable string. -->
    <!-- The cursor will initially be placed where your text string needs to be entered. -->
    <!-- Hitting tab a second time will allow you to type your textdomain. -->
    <content><![CDATA[
<?php esc_html_e( '${1:some text}', '${2:textdomain}' ); ?>
]]></content>

    <tabTrigger>i18n</tabTrigger>
    <description>i18n a text string</description>
    <scope>source.php</scope>
</snippet>

jQuery

Last in our list but certainly not least is jQuery. While you may not always require any fancy jQuery for your project, it’s always nice to have an easy way to quickly create a JavaScript file from which wonderful jQuery goodness can bloom. With the help of JS Mastermind Camden Segal, the following starter script was created and later spun into an easy to use snippet. It provides us with sample variables, functions, and lots of great inline comments to help guide us along our way. It’s incredibly easy to extend and even easier to read–no jQuery Soup over here!

Take a look at the snippet itself, then see it in action below:

<snippet>
        <!-- Type `jquery-wds` and hit tab to output a ready-to-use jQuery function. -->
        <content><![CDATA[
/**
 * Foo Script
 */
window.Foo_Object = {};
( function( window, \$, that ) {

    // Private variable
    var fooVariable = 'foo';

    // Constructor
    that.init = function() {
        that.cache();

        if ( that.meetsRequirements() ) {
            that.bindEvents();
        }
    };

    // Cache all the things
    that.cache = function() {
        that.\$c = {
            window: \$(window),
            fooSelector: \$( '.foo' ),
        };
    };

    // Combine all events
    that.bindEvents = function() {
        that.\$c.window.on( 'load', that.doFoo );
    };

    // Do we meet the requirements?
    that.meetsRequirements = function() {
        return that.\$c.fooSelector.length;
    };

    // Some function
    that.doFoo = function() {
        // do stuff
    };

    // Engage
    \$( that.init );

})( window, jQuery, window.Foo_Object );
]]></content>
    <tabTrigger>jquery-wds</tabTrigger>
    <description>Insert a Javascript function - the WDS way</description>
    <scope>source.js</scope>
</snippet>

Wrapping Up

At this point, you’ve seen a handful of snippets which can save you time and headaches by taking almost all of the legwork out of building sometimes complex functionality. At the end of the day, saving time is key; as the adage goes, “Time is money.” When we can cut time off of our development schedule by automating standard processes, not only are we saving time and money but we also begin to look at our work from a completely different viewpoint. We can take a step back, look at the big picture, and pick out the trouble spots or redundancies in our work and find a way to chop those down dramatically.

Take a moment to think about the code you write and how much of it is used from project to project. Then, create your own snippet to save yourself some time when you’re in the trenches day in and day out. Share any snippets you’ve created to boost your workflow or any helpful snippets you’ve come across in the comments below!

The post Snippets Saved My Life: How Sublime Text 3 Snippets Changed Everything appeared first on WebDevStudios.

Let’s start at the beginning: How did you learn PHP? One of the greatest aspects of the modern web development world, especially for WordPress, is that there are so many different ways that you can gain entry. You may have taken a programming course in high school or college. You may have attended a local Meetup or WordCamp where you could learn from others who have knowledge that you didn’t have. Or you may have taken online courses to learn or sharpen your skills. Regardless of your background, you probably know PHP well (or well enough), but you also know that there are plenty of areas of the language that you don’t know well.

Why would you want to learn another language, when you may already feel like you could still stand to learn more about PHP? Well, there are plenty of great reasons, but I’m going to cover just a few:

• Learn to think differently
• Invest in the value of your skills
• Work with a different group of people

Learn to think differently

Once you’ve gotten accustomed to working in a certain language, your mind will eventually adjust to using the most efficient method when problem solving.

That’s a fancy way of saying that your mind can get stuck in a problem-solving rut.

This isn’t necessarily a bad thing, as you naturally develop greater efficiency in your work on a day-to-day basis. But what happens when you’re faced with a problem unlike anything you’ve had to solve before? You might come up with an inefficient solution, because it’s closest to what you know.

Learning a new programming language will help you prevent your mind from getting stuck in a rut. When learning a new language, you’ll need to learn how best to solve particular problems for that language.

This may be similar to how you would approach it in your current language, or it may be drastically different. Regardless of the exact differences, you’ll need to consciously think about how to solve a given problem in the new language, and you’ll likely want to look at examples from people who are experts with that language. Your mind will get out of the rut and start looking at problems from a different perspective. This difference in vantage point will carry over to your current language, and you just may find that you have new ideas for how to solve problems more efficiently.

Invest in the value of your skills

Developers of every kind have a skill set that is highly desirable in today’s modern world. There are hundreds of things that we all touch or interact with on a daily basis that required a developer to write code to solve a problem. In other words, the modern world needs developers to run, and to continue running.

Career trends have changed over the years. For the people in my parents’ generation, it was common to spend your entire career at a single company. These days, it’s rare to see anyone stay at one company for their entire career. If you’re a developer and you find yourself looking for a job, regardless of the circumstances, having another programming language to draw on will allow you to look for opportunities in more places. It can also make you more valuable if you need to fill a role that requires the knowledge of multiple programming language.

Another possibility: You may want to start your own business at some point. When clients come to you with their problems that they need your expertise to solve, you’ll have more tools in your metaphorical tool belt with which to solve those problems. As the old saying goes, “When all you have is a hammer, every problem looks like a nail.”

Knowing an additional language means that you can solve a greater variety of problems and more effectively earn a living for your family.

Work with a different group of people

When you get stuck on a problem, where do you go to help you find a solution? You may go online to StackExchange or the WordPress forums (or something similar). You may have one or more coworkers that you reach out to for advice. Perhaps you have some other mentor who can give you assistance. All of these methods for finding a solution from other people are valuable.

However, similarly to how your mind can become stuck in a particular way of thinking, you may find yourself “stuck” within a certain circle of influence related to the programming language that you currently know well.

When you start to learn a new programing language, don’t assume that you can figure out everything on your own. Find some forums, a local group, a coworker, or anyone else with more experience in the new language who can help you learn it the right way. In other words, seek out an established community around the new language. These are the people who will help you learn how to solve problems with that language in the most efficient way. These are the people who can help guide your thought process as you’re learning. Having a community that you can connect with is essential if you want to have any of the other benefits I mentioned previously from learning a new language.

What new language should I learn?

There isn’t a single good answer to this question, because there isn’t one single “right” answer. There are many different programming languages these days, and all of them are suited to different purposes. Here are just a few ideas:

• Python
• Javascript
• Swift
• Java
• Ruby

Do you have any questions? Are there any programming languages that you want to recommend? Feel free to leave a comment below!

The post Why You Should Learn Another Programming Language appeared first on WebDevStudios.

They are either short on time or skill. In particular, when it comes to creative works like design, development, writing, marketing, et al., it means you’re also paying for a unique perspective that informs and elevates the skill at hand. The professional you are looking to hire has something you don’t and you want a piece of it because it will improve your business, your home–your life, in some way.

Some of this may seem simple to an outsider, but it’s a professional’s job to make whatever they are doing look easy–a surprisingly uncomplicated task when interacting with someone who isn’t well-informed about what the work actually entails. If you are looking at all this going, “Hmmm, it can’t be that hard,” you might be wondering why the hell a developer’s rate is so much more than you anticipated.

If it was so simple, we wouldn’t have to hire anyone. We’d handle it ourselves.

There are so many skills that are easy to learn on a surface level; anyone can buy a ukulele on Amazon and learn to play a few simple songs the first day it arrives, but that doesn’t mean they can suddenly compose a complex piece. You are hiring for the time it took to cultivate that skill and for the brain that fuels it.

[People] think freelancing is not a real job and so they think freelancers will work for less.
 Paying for a good developer will have a better result and cost less in the end, because you’re less likely to have mistakes that need fixing or, in a worst case scenario, needing to hire someone else, adding to the total cost.

-Ryan Fugate

We get a lot less of this these days, but it runs rampant in the freelance community: Big dreams, non-existent budgets, and bad attitudes.

The reason the cost is $X is because of the thousands hours of experience, learning, conferences, testing–all of that stuff that make someone an expert. 

–Brad Parbs

I agree with Cameron that it is on both professional and client to create a harmonious interaction; at least in my experience with WDS, so many people who reach out to us are gracious, kind, and understanding. They know that we do good (dare I say, GREAT) work and that we are a business; WDS provides a livelihood to nearly forty people (and their families) who are passionate, engaged, and committed to their crafts. But occasionally we run into this too–and much of our team is comprised of former freelancers, so they are all too familiar with this issue.

The thing that people forget…is that they aren’t purchasing a product. They aren’t going to Web King and saying “give me a website, medium rare, with a side order of SEO.” They are paying for a service provided by a professional with years of experience in the field. They are paying for that experience. Sure, they could hire a college grad or the kid down the street who plays Minecraft all day and they’ll do it for 50 bucks, but they don’t have the experience that you have and that needs to be the critical selling point when you are freelancing. You aren’t buying me; you’re paying to use my brain and everything that’s inside of it. 

–Chris Reynolds

It’s completely fair to operate on a budget–I mean, hell, aren’t we all? But keeping your expectations adjustable, especially if you aren’t particularly well-versed in the skill that you’re looking to hire for, is vital.

Everybody, client and developer, is always looking out for their own best interests. As developers, and especially as freelance developers, we need to put a value on our time and work because we need to pay our bills and live our lives. As a client, they have an idea of the value of what they want as a final product. The problem is marrying those two concepts–that developers are worth X and the client only wants to spend Y.

The client doesn’t typically know the inner-workings of every part of a website or how everything is built or comes together. If they did, they’d build the site themselves. The trick is to educate the client on why things take this many hours, or why my time is worth this much money per hour in a way that coincides with the endgoal. If the client wants an incredibly dynamic website but has a small budget, we need to educate them on why we can’t do all one hundred things they want within their budget and have an open discussion about why we can only do fifty of the things they want. It’s all about conversation and education.

–Corey Collins

If you love someone’s work and it’s beyond your budget, it’s totally reasonable to be disappointed.

And the professional in question may very much love their work, but it is still work. Asking to be compensated for doing work you love is not a diminishment of the joy that is found in it. It is not an expression of insincerity. It’s asking for what they do and for who they have worked to become to be valued–by the very folks who need them (and who they need as well!).

For someone that says “It should be easy…” my response is always, “You’re not paying me to just press buttons, you’re paying me to know WHICH buttons to press.” 

–Jay Wood

We’ve all been in that place where we are staring down a potential bill that we absolutely do not want (or maybe simply can’t) afford to pay. It sucks, and it can be easy to take that disappointment out on others. Just remember: We’re all out here trying to survive (and thrive).

When you’re hiring a developer (or a designer, or a writer, or a consultant, or whatever), you’re hiring them for so much more than the completion of a task list. You’re hiring them for their expertise, knowhow, and the time and energy spent into obtaining it. When you’re paying for a developer, you’re paying for their knowhow–so they can build you something incredible that does your business justice.

The post What Are You Paying For When You Hire a Developer? appeared first on WebDevStudios.

In my opinion, one of the most overlooked and underused features of PHPStorm is its debugger. I’ve only just recently started to learn about it and use it. One of the biggest reasons it is underused, even by developers who are already using PHPStorm, is because setting it up can be a confusing process if you’ve never done it before. Despite how it may appear, it’s very simple to setup, and once you do it a time or two, it’s something you can do in just a few short minutes.

The PHPStorm debugger will make you never want to use a var_dump() ever again!

I currently use Vagrant for my development environment which comes prepackaged with Xdebug. If you’re using something else like MAMP or XAMP, you’ll need to make sure you have Xdebug installed and activated.

Configure PHPStorm and Xdebug

In order for the PHPStorm debugger to work, it needs to be configured to work with Xdebug. Don’t be alarmed by the number of steps it takes to configure; I just wanted to be as detailed as possible.

1. In PHPStorm, go to Run > Edit Configurations. This brings up the Run/Debug Configurations window.
2. Click the + (top left) and select PHP Remote Debug from the drop-down to add a new config.

At this point, you should have a window that looks like this:

3. Click the ... next to Servers: so we can configure a server.
4. In the Servers dialog, click the + to add a new server configuration.
5. Enter in a Name and the Host address.

6. This step is for Vagrant users only. If you are not using Vagrant, please skip to step 7.

Click Use path mappings to configure file location settings. The File/Directory should already be preconfigured. Under Absolute path on server, you will need to enter in the path to your projects htdocs folder on your vagrant server. It should look something like this:

7. Click Ok to save and close out the Servers dialog.
8. You should now be back at the Run/Debug Configurations dialog, but there should be a selection in the Servers: section with the server that was just configured.
9. Add in a Ide key(session id) of VVVDEBUG.
10. Check the checkbox for Single instance only.

The fully configured Run/Debug Configurations dialog should look like this:

11. Click Ok to close and save everything out!

To recap:

• Go to Run > Edit Configurations
• Configure the server and the path mappings if you are using Vagrant
• Give the configuration a name and set the Ide key to VVVDEBUG

See, it isn’t that bad after all!

The Big Test

Now that we have PHPStorm configured to work with Xdebug, it’s time to test it out and see if it is actually working. The debugger works like most others in that you’ll set a breakpoint in your code for investigation, and then reload the page. When the page reloads, PHPStorm will take over when the breakpoint is reached.

For this test, I’m going to add the following function to my functions.php file. It’s just a simple function that will merge two arrays using the nifty wp_parse_args() function.

Here’s what it looks like:

function test_debugger( $args ) {

    $defaults = array(
        'phpstorm' => 'Rocks!',
        'debugger' => false
    );

    $args = wp_parse_args( $args, $defaults );

    return $args;
}

// Call test_debugger
test_debugger( array(
    'var_dump' => 'no more',
    'debugger' => true
));

In my code, I’m going to set a breakpoint by clicking in the gutter at the exact spot where I want the debugger to kick in.

After the breakpoint is set, PHPStorm needs to be put into Debug Mode. This can be done by using Control + D or by going to Run > 'BPDefault' where ‘BPDefault’ is the name of the configuration created earlier.

After debugging is turned on, all that’s left is to reload the page and keep an eye on PHPStorm to work its magic!

Now, for the gif of all gifs:

There is a lot going on in this gif, so let me point out a few key points.

• By pressing ^ (Control) + D the bottom Debug pane slides up. Then, I reload the page and PHPStorm kicks in where the breakpoint is set.
• Notice the Variables column. It contains EVERY variable in scope at that time.
• Then, I use the Step Into button to go into the test_debugger function.
• As I’m stepping through, you can see the values of variables directly to the right of them.
• Did you also catch that we stepped into the wp_parse_args()? Pretty cool stuff!
• Finally, we can see in the Variables column that $args is set to the arrays that were merged.

Wrapping Up

A lot has been covered in this post and there is so much more that could be written about the different features the debugger provides. However, I think its best we save that for another post!

I’d also like to thank Kellen for sharing his knowledge with me on this subject.

If you find yourself getting stuck or not being able to get the debugger configured, please feel free to leave a question or comment below!

The post The PHPStorm Debugger is Pretty Awesome appeared first on WebDevStudios.