Making WordPress functions.php Easy

August 21, 2014 / PHP, Web Design, Wordpress / 0 Comments /

WordPress’s functions.php could easily be considered the core of your theme. It adds unique, and often necessary functionality to your blog. You can enable features, or create new ones. In this article, I’m hoping to give some insight in not just making a custom functions.php file for your theme, but making it easy to manage.

How does WordPress the functions.php file work?

The short version – it extends what WordPress does by modifying existing actions – aka creating filters, or adding new ones, aka creating actions.  This is done using WordPress Hooks.

Rather than have ME explain it all to you, you should consider reading WordPress’s explanation of the functions.php file, so you can gain a more detailed understanding of how it works.

Don’t hand-code it all

While you COULD hand code everything – and I encourage you to learn – a good starting point might be to…well..cheat! is a handy website that lets you pick your own functions, and it gives you the code for it.  Post thumbnails enabled? No problem! Want to load a custom CSS file to theme your admin area? No sweat.

The nice thing about this tool is it can be a great way to familiarize with the logic behind the functions.php code.  Not sure about code snippet it generates? Google it or search the wordpress codex to learn about it.  Once you learn about it, tweak it, play with it until you get it exactly how you want.  Maybe make your own custom function!

Make it a plugin

The functions.php file is relative to your theme, so you want to be sure that whatever functionality you add to it specifically works to enhance your theme, but doesn’t take away from the core functionality of your blog should you ever change themes, because if you ever switch themes, your custom functions are gone unless you manually copy them over to your new theme.

One way to bypass this caveat is to make a plugin for every function that isn’t theme specific.

To do this, create a new folder for your plugin, and create a new php file inside it.  In this PHP file, insert the required plugin information headers need for WordPress to recognize the plugin, followed by your custom function, like so:

* Plugin Name: Name Of The Plugin
* Plugin URI: http://URI_Of_Page_Describing_Plugin_and_Updates
* Description: A brief description of the Plugin.
* Version: The Plugin’s Version Number, e.g.: 1.0
* Author: Name Of The Plugin Author
* Author URI: http://URI_Of_The_Plugin_Author
* License: A "Slug" license name e.g. GPL2

//custom code here
//you can find this example here:
//I strongly recommend reading WordPress’s documentation
//because it’s relatively easy to follow, and it’s
//quite informative : )


Now, take your new plugin folder and place it inside wordpress’s ‘plugins’ – or, ZIP the folder and upload it from the plugins section of the admin area.

If all works well, your function is now a plugin that you can enable, disable, and modify from within the admin area, no matter what theme you use![/az_column_text][/vc_column][/vc_row]

CSS Selectors

August 20, 2014 / CSS, Web Design / 0 Comments /

To preface this article, I’d like to explain the basic logic behind CSS in how it relates to HTML.  So, CSS (aka Cascading Style Sheet) is the language that visually manipulates your text objects in your browser, i.e, your HTML.  To accomplish this, your CSS selects the object by some sort of identifier, then tells it what do, or how to look.

In this post I will show you just about all the CSS selectors there are – some that are pretty common, and others you may not have known existed.


You can manipulate the way a specific type of HTML tag appears, or get really specific.

For example, if you want to style all your paragraph, or p tags, in your CSS, just type:

p {
font-size: 14px;
color: #000;

This will make all paragraph, or p tags have a font size of 14px, and be black. In general, you would want to call individual HTML tags to create a default style for that element.


Let’s say you want some of your paragraphs to have blue text. In the case where some HTML elements would need to be styled differently than default, you would use classes, both in your HTML and your CSS.

For example, your HTML might be:

<p>This is a normal paragraph.</p>
<p>This is also a normal paragraph.</p>
<p class="blue">This paragraph has blue text</p>
<p class="blue">This paragraph is also blue</p>
<div class="blue">
<p>This paragraph will be blue, because its container has the class</p>

And your CSS:

.blue { color: blue; }

As you can see, even container classes can overwrite default classes. That’s the great thing about classes, you can use them multiple times on any element.


Another basic selector is the ID attribute. In HTML, you can identify an element that is intended to be completely unique in some way – hence identifying the element by giving it a unique name. Remember, in HTML, ID names are intended to be unique – no ID should be the same in one page.

At any rate, you can style elements with unique IDs in CSS like so:

<div id="myDiv">
<p>My Text</p>

#myDiv {
width: 200px;
height: 200px;
padding: 20px;
#myDiv p {
font-size: 18px;

See that? You can uniquely style HTML elements based on what element they sit in. In the example above, not only did I style the #myDiv element, but I styled the paragraph inside it. The same identifier rules apply for outer and inner elements, and you can be as specific as possible, for example:

<div id="myDiv">
<p>This is my <span class="blue">blue</span> text!</p>

#myDiv p .blue {
color: blue;

Now the text within the span tag that has the “blue” class inside the p tag inside the div named “myDiv” is now blue. Crazy specific!



Let’s talk links, or our a tags. Links have different states other than the default: :link, :active, :visited, :hover. I’ll go over all these states at some point, but for time’s sake, let’s tackle one of the most common, the :hover state. The :hover state changes the element’s default style when you hover over the item with your mouse cursor. In CSS, this would look like this:

a {
color: #000;
text-decoration: none;
a:hover {
text-decoration: underline;

Quick note: another cool thing about :hover is it can be applied to other elements, p tags, div tags, etc.

There are other states for forms, such as :checked, :disabled, :enabled, :empty, :focus, :in-range, :out-of-range, :valid, and :invalid. For paragraphs, there is :lang(en) – of course ‘en’ would be replaced with whatever the ‘lang’ attribute is set to in your paragraph.


The above CSS selectors are all pretty common; however, were you aware that you could select HTML elements based on their attributes?  Let’s use links as another example

<a href="/index.html">Home</a>
<a href="/pictures/">Pictures</a>

[href="/pictures/"] {
color: #333;

This could also come in handy with forms, where you would use the same input element with a different type attribute.

When dealing with attribute selectors, there are different ways to select elements based on the contents of their attributes:

//The "target" attribute is equal to "_blank"
[target="_blank"] {
color: #333

//the "alt" attribute contains the word "people"
[alt~="people"] {


//the "alt" attribute either equals "people", or begins with "people-" and another word
//for example alt="people" or alt="people-person"
[alt|="people"] {


//the alt attribute begins with or equals "people", either as a single word or on its own
//for example, alt="people" or alt="people person" or alt="peopleperson" etc.
[alt^="people"] {


//the alt attribute ends with the word "people" either as a single word or on its own
//for example alt="hard working people"
[alt$="people"] {


//the alt attribute contains the word people either as a single word or on its own
//for example alt="these are some people standing around"
[alt*="people"] {


Child Selectors

In CSS, you can select an element based on how many there are, or the order they are in within a containing element. These are known as child selectors. With these, the index, or the order you count them in, begins with “1” For this example let’s consider the html of this list:


//the following are selected based on the order in which they are listed within the ul tag
//selects the first li element within the list
li:first-child {


//selects the last (Fifth) li element within the list
li:last-child {


//selects the Second li
li:nth-child(2) {


//selects all "even" li’s, for example the second, fourth, and so on
li:nth-child(even) {


//selects all "odd" li’s, for example first, third, fifth, and so on
li:nth-child(odd) {


Select by order or position

To continue this, using the same HTML list, you can also select elements based on the order they’re listed. With these methods, the index begins at “0”, not “1”. These are also global, meaning they will effect ALL specified html elements regardless of their container, unless specified. For example

//selects the First li
ul li:eq(0) {


//selects all li’s that are NOT the Second li
ul li:not(:eq(1)) {


//selects all li’s after, or "greater than" the First li
ul li:gt(0) {

//selects all li’s before, or "less than" the Third li
ul li:lt(2) {


Sibling Selectors

Sibling selectors are ways to select elements based on how they are related to another element.

//selects the span element directly after an img element
img + span {

//selects all p elements within a div
div > p {


//selects all p elements in the same container as an element with the id of "hello"
#hello ~ p {


Select All

To select ALL elements within an html document

* {


Final Thoughts

It is important that you use valid HTML and define your doctype in your HTML document. It is also important – especially when using sibling and child selectors – to make sure that you can support YOUR audience’s browsers. A great way to do this is by visiting or use a JavaScript fallback.[/az_column_text][/vc_column][/vc_row]

Dealing with older browsers

The web is constantly evolving; the HTML language is expanding, CSS is getting more advanced, and we are finding more and more ways to make the web interesting.  However, for some reason, some people don’t upgrade their browsers, making it very difficult for us to share that creativity with others; so how do we deal with people who are running IE8, or even worse, IE6?

In this article, I’ll give you some tips and practices in no particular order that you can use to make life a little easier for you and your users.

#1:  Use a JavaScript Library like Modernizr

Probably the most common method of dealing with those pesky Windows XP users running Internet Explorer 8 or older (only joking XP users!  Windows XP is great, really it is.)

Modernizr is great, because it can be as light or as bulky as you need it to be.  On their website, you can choose which HTML and CSS elements you need to support, and build a modernizr script to help you.  It will tell the DOM to recognize HTML5 elements such as <section> or <nav>, and can add classes to the <body> tag so you can identify what is and is not supported in a particular browser, and use CSS and/or JavaScript to make any browser-specific changes necessary.

#2 Know your audience

Legacy browser support can be a massive pain in the butt; but as a web designer, your biggest concern should be to give your audience the best experience possible regardless of what browser they use.  So, spare yourself the headache and know your audience.  Use tools like Google Analytics to figure out how people are accessing your content, and develop your own standards & practices.

If you don’t know your audience yet, you can do 1 of 2 things.

  1. Take the Google approach and support only the latest three versions of the major browsers.  For example, if IE11 is the latest version of Internet Explorer, the oldest version of Internet Explorer you would support is IE9.
  2. Ask other people what their audiences look like.  If your website hasn’t been around long enough to gage who is using what, consider finding a company or asking a colleague in the industry what their numbers look like as a starting point, then, as your website gains traffic, use your own analytics to make your own decisions.

#3:  Test on older browsers

Never rely on just the latest version Google Chrome or Firefox to test your code.  Unfortunately, while browser “manufacturers” try to render code accurately and consistently, no browser is 100% equal.  People tend to rant and rave how IE is the absolute worst it comes to rendering code, but they aren’t the only ones you should worry about.

And sometimes, it’s not the browser alone, but the operating system.  Every operating system handles application text differently, not one is the same.  When QAing your work, you should test every version of every browser you intend to support on every operating system you intend to support.  How?

You could setup a virtual machine, but that can be tricky, expensive, and impact your computer’s performance.  I like to use BrowserStack.  BrowserStack let’s you choose between multiple versions of Windows, OSX, or choose different iOS or Android Devices, and multiple versions of the many browsers each operating system can run.  Need to test IE9 on Windows 7?  Easy!  Need to test Firefox 10.0 on OSX?  No Problem!  BrowserStack will give you remote access to a machine with the OS and browser of your choice through your browser, making it easy to test your website’s browser compatibility.

#4 Be Responsive

When building a web experience intended to reach people on multiple platforms, browsers and operating systems aren’t the only factor.  Consider the device your users are using, and the monitors they are viewing content through.  Different screen sizes, resolutions, etc., all play a huge role in your website’s usability.

Whenever possible, test your website in various resolutions.  A good start is to just shrink the size of your browser window.  Or, again, use BrowserStack.  Along with choosing the operating system and browser, you can set the desktop resolution all the way down to 800×600, or view your site through various devices, inheriting their viewport/resolution.

#5 Consider the fallbacks

As mentioned before, Modernizr can be used to determine what various CSS and HTML features a browser can support, and will add classes to the <body> tag for each unsupported feature.  Utilize this tool to create fallbacks.

For example, if you’re using CSS transitions for hover effects, use jQuery or JavaScript animation as a fallback.

Hopefully the above tips and practices above will help ease the strain of supporting older browsers.  How do YOU deal with older browsers?  What do you support, and what tricks do you use to support them?  I’d love to hear your ideas in the comment section below![/az_column_text][/vc_column][/vc_row]

PHP Include vs. Require – what to use and when to use it

August 18, 2014 / PHP, Web Design / 0 Comments /

In PHP, there’s a handy dandy little function called ‘include’ that basically allows you to run a php script from another file in your current script.  There is also a handy dandy little function called ‘require’ that basically does exactly the same thing.  Basically.  Likewise, there’s ‘require_once’ and ‘include_once’ which both due the same thing, but check the current document to see if its been included or required already, and won’t do it a second time.  So…which should you use, and when should you use it?

It all depends on the application.  With ‘include’, if an error occures in the included file, the remainder of your application can still function.  At most, you will see get a warning, but nothing more.  With ‘require’, if there is an error in the required file, the remainder of your application will not function, and your scripts will stop running.  Sounds scary, right?  Off the bat, it may seem like, from a usability standpoint, you should use ‘include’ or ‘include_once’ as a default – but this really isn’t the case.  Think of what you are implying.

If you use include over require, you are doing a few things:

  1. You are calling a script that may or may not need to run in your application at any given time
  2. You are potentially running code that doesn’t need to be running
  3. If your included file breaks, your application still runs – you’re trusting that there are no security or usability vulnerabilities without it.

As best practice, you really shouldn’t be including code that doesn’t need to exist.  At the very least, it can impact performance of your application.  ‘include’ should really only be used for ‘optional’ code, but…how often is code you write used only part of the time?  Very rarely.

Using require throws errors – which is a huge benefit in spite of how scary it may look.  Checking your server logs, or getting immediate feedback as to what broke in your code is crucial when developing.  If your required file patches a security loophole of some sort, it is obviously essential that your application stops running if the required file breaks.

So, best practices?

  1. The majority of the time, use require_once for scripts that are called only once – like a database connection, or defined functions.  You will probably use this the majority of the time.  You don’t often run into situations where you require a file more than one time in a script or application.
  2. Use require when the required file has scripts that run when the file called.
  3. Use include or include_once similarly, but only when they aren’t essential or carry sensitive or crucial data.  Which – how often do you include code that doesn’t necessarily matter?
  4. If your required file breaks your code, check your error info and your logs to find out why, and then fix it!  That’s the great thing about require!

PHP is a widely used language, but is full of security holes.  It is important to understand some of these basic practices as your develop your websites and/or applications in PHP to keep you and your users safe, and to make sure your code is running optimally.

Photo Credit[/az_column_text][/vc_column][/vc_row]