Intro to WordPress as an Application

It’s really an exciting time to be a WordPress practitioner right now, particularly as WordPress enters into a big transitional period with the introduction of the WordPress REST API!

As a practitioner, you’re used to approaching a need, whether for your own business or that of a clients, and then thinking of ways to use WordPress to meet the need through the use of themes, plugins, or other tools to make it happen. And the same goes with into mind when thinking of WordPress as an application as well.

Rarely does a client say in the first client meeting, “I want this exact plugin installed and for you to use these specific post types!” Haha no, instead they say, “I want to see who’s visiting my site”, or “Help! My website’s running slow!” And you geniuses go to work thinking of techniques to make it happen using existing tools, plugins, etc.


So what’s all this talk about a “transition”? The best way to begin describing the significance of this transition is to look back at where WordPress has been. Most of you have heard this, so I won’t go into all the old details, but in summary WordPress started as a blogging tool. At the time, it was still a crazy concept you could have your own personal stream of information you could control and post freely to.

Then came the introduction of post types and multisite, which was really at the core of transitioning WordPress from solely a blogging tool, to a full fledged CMS capable of storing and using vast amounts of content. For most of us in the room, this is what attracted us to WordPress in the beginning. Same with the introduction of a easy-to-use blogging platform, now it’s crazy to even imagine sites without a CMS at this point!

But now the next big transition is already under way into an application, and it’s equally exciting in the way it’ll increase capacity for WordPress and unlock new use cases to use the open source, community driven program we’ve all grown to love.


First things first, if you’re like me when I first heard application, I immediate thought of iPhone or Android apps. But when I refer to applications, I’m referring to the system and data that runs a variety of mobile apps or websites.

See when opening up an app on your phone, the app itself isn’t actually where all the data lies. And when we think about it, it’s pretty obvious. All the tweets in the world aren’t stored in my phone…same with all the Airbnb listings, or Netflix shows. The mobile app as we call it, are merely the “skin”, or the front facing client we use to access, edit, add, or delete data.

Take Twitter for example. This is what Twitter looks like to us. (favorite, user profile picture, reply and compose buttons, follow users, etc)

Mobile Twitter Stream

But in reality, the screenshot below is what a tweet’s data actually looks like.

JSON Tweet

Even their front-end site,, doesn’t actually store all the data, it’s just a skin designed and developed for us to interact with the application as well.

So now that we’ve unlearned and relearned what an application is within the context of APIs and the future of WordPress, let’s add another relearned word to our new vocabulary. (for some of us at least)


No, not talking about the people who hold to power to make or break our day, clients in reference to systems and APIs refers to the front facing website, mobile application, TV application, etc, that translates data from an application into an interact-able interface for the end users.

WordPress Clients

There are whole front-end roles dedicated to designing and building these interfaces. Whether it’s product or UX/UI design, to your standard HTML/CSS, JS languages for the web, and application specific languages as well for iOS, Android, Windows, and others.

For those who dabble or full on code WordPress themes, you’re probably already familiar with what’s stored in WordPress as an application vs. the code that organizes and displays the information properly. (front-end)

The the_title() function

Take the_title() function…you should see this within every post or page template within WordPress, and it goes and gets the title of the individual page, post, or post type of the current or requested page. Notice the positioning, styling, and headers all fall outside of the imported data from the function. Also, what would show up if we used the tag outside of the loop or outside of WordPress? Nothing! Outside of our WordPress installation, it doesn’t know where to get the title, for what particular page or post, or how to format the title we receive.


When dealing with applications, this is where APIs come in real handy. When we have a client interface, we use an API to choose where to go get the data, what particular data we want, and how we want it formatted and imported.

Even going back to our theme example, we don’t ever see it, but when we use the the_title() function, it’s automatically picking the source, content, and format for the page/post title.

Or let’s say for Twitter, reading the latest tweet. Using Twitter’s API, we’d define the source: the Twitter application, what: the latest tweet from a specific user, and how we want the data included: syntax, meta information, etc. For some APIs, this works with posting too. So instead of just reading data, we’re going to send a call to write data once we’re in with the right authentication.

APIs are super useful and are widely used in almost any site or web application, whether you recognize it or not! APIs unlock potential for all kinds of data analysis, manipulation, remixing, and visualizations to name a few!

Weather API

Weather API

Another quick example is weather data. Our client interface could be a website, or mobile app, and then using an API we can identify the source, specify where we want the weather reading, and how we want that information displayed.

WordPress as an Application

Now what could this possibly mean for my WordPress site? I was in the same boat about a year or so ago with all the technical talk surrounding the REST API and it’s integration into WordPress. One of the biggest breakthroughs is the introduction of the Headless CMS.

Headless CMS

Headless CMS

Scary name, but it’s actually a really cool idea with lots of potential use cases. Currently to update WordPress, (unless using WP-CLI) you had to login to the WordPress Dashboard. (love it or hate it, it’s really the only option you got) Same way the the_title() function only works on your site within your WordPress loop, same went for editing, adding, or removing data within your installation.

But with this transition to WordPress as an application, WordPress itself is becoming independent from the dashboard and even your front facing website.

No, there’s no need to fear, your WordPress installation won’t break or get cut in half after automatically updating to the latest release. In fact, you probably won’t notice a difference at all, but within WordPress core, new outlets and possibilities to access and update data come with a lot of new functions.

So what?

No longer will we have to rely on XML or RSS to retrieve data from a WordPress site. (which is worth the update in of itself) But with the REST API, you can also update, add, and delete data as well…all outside of the native dashboard included. This presents the opportunities for custom dashboards! I’m sure many of us have found ways to hide settings or certain fields in the admin area for fear of a client accidentally nuking their whole site! With the Headless CMS possibility, you could even design and build a completely new front facing interface with only the fields the client absolutely needs to update! Even styling and tailoring it exactly to your company or client’s brand.

Two camps

I believe the transition to WordPress as an application will start to sort future opportunities into two camps. Which the two were outlined in a super good white paper from Human Made, and agency with many of the lead developers working on the WordPress REST API.

On one end, will be the developers. This includes both API developers, backend developers, and the frontend developers building the front facing interfaces we talked about earlier. Whether it be a website, mobile app, or even for other devices like TVs and sensors.

But before you start crying for those who are deathly afraid to touch code, the second camp might be much more interesting and exciting for the WordPress practitioner! While the new REST API integrations with WordPress are super exciting and unlock a whole ton of new capabilities for developers, the transitions going to attract brand new users to WordPress who don’t have a clue the difference between posts and custom posts, or what custom taxonomies bring to the table. And from a developer perspective, we’re honestly more focused on the code and API than the actual content itself.

So using WordPress as an application is going to require someone with a background in using WordPress to take a bunch of new data from a variety of sources, and organize and structure it within the contents of WordPress. (think custom post types, users, media library, etc)

And many of you are already doing that! At the meetup, we broke up into groups and brainstormed some really cool use cases to make it happen. From creating online invoicing platforms, warehouse training platforms, auto body shop app for customers…the possibilities and implementations are endless!

The best way to prepare for the full implementation of the WordPress REST API is to start viewing WordPress as an application. Anticipate where potential endpoints and data sources could be, and how you’d then organize it all within the open-source platform we love.

You break it, you buy it

Upcoming events

You break it, you buy it

presentation by Bobbie Wilson

Notes at

Child theme on WordPress Codex:

Creating a custom theme

When modifying a theme, best practice is to not modify the actual theme files but instead create a child theme. This way, when you update the theme, you won’t lose the changes.

You need:

  • WordPress installed
  • A free theme
  • Text editor
  • FTP program

Creating a Child Theme

Create a new folder for your theme anywhere you’ll remember.
Using a text editor, create a new file and name it style.css.
Inside the style.css file, you’ll add:

Theme Name: Your Child Theme
Template: twentythirteen

“Template” in the code above references the name of the directory of the parent theme

If you want to keep the styles of your parent theme:

@import url(“../twentythirteen/style.css”);

This imports the stylesheet of the parent theme; anything you modify will override the parent theme styles.

Create a folder with your css file on your computer and name it the name you want to use for your child theme. Compress that folder as a .zip folder. You can add it to your site by going to the Dashboard under Appearance > Themes > Add new theme and upload the .zip folder. Note that you must have the parent theme installed in your theme directory on the site or the child theme won’t work. Once the file is in the theme directory you should be able to activate the child theme.

You can also override the template files (e.g. page.php) of the parent theme by copying the files into the child theme folder and modifying them there.

Everything in the child theme folder overrides your parent theme.

Creating a child theme will not remove the additional theme-specific options that many themes build into the theme dashboard.



  • Don’t change your CSS or php template files in your Editor because you can break your site, and there’s no undo. Instead, make changes to files offline and upload them via FTP, so you have the ability to revert if necessary.
  • If you get white screen of death, you can go into FTP and rename your wp-content/plugins folder to something else so the plugins don’t load.
  • You can go into wp-config.php and set WP_DEBUG to true to find errors (more about this in the WordPress Codex)
  • Create regular backups before making changes to your live site – do not rely on your hosting provider. That way if you break something you can revert to a backup.

Some ideas on backup plugins/services:

User Experience in the Real World

Presentation by Clark Wimberly

Links/slides from presentation here:

Pros and cons of common UX blunders

What is UX?

  • What a user experiences
  • study of rules
  • guiding emotions
  • worth their time

UI vs UX

  • UI = User interface – what the user interacts with. Buttons, etc.
  • User Experience – how the interface makes them feel
  • Married but not the same

Paywalls – generally a bad user experience

  • Pros:
    • Registered user
    • who can we spam
  • Cons:
    • another registration for a user
    • they can spam me
  • Business goals can go against user experience
  • Can cause users to leave

Having a page with a slideshow/multiple pages/lots of content to click through

  • Pros:
    • pageviews
  • Cons
    • no one likes clicking
    • users won’t see content
    • harder to author
  • Solutions:
    • Don’t do it
    • View as one page
    • if you want page views, force reload
    • Lazy load plugins to help with bandwidth-heavy sites
    • Sub-navigation/table of contents – can work, but make sure it’s apparent what it is

Social lockers

  • Idea: hold desirable content hostage for likes, subscriptions, etc.
  • Pros:
    • Fans! Followers
  • Cons:
    • Annoying
    • Look like an awkward shill
    • Hit and runs
  • Solutions:
    • Generate value with social
    • Interact with followers
    • Treat it like a subscription service
    • share with @mentions and #hashtags and +names
    • Look for organic activity
    • Keep social interesting and then market to them… don’t market 100% of the time
    • If you use a lot of hashtags you’re probably doing it wrong


Idea: get a bunch of emails and get inside their inbox

  • Pros:
    • Pageviews! Opens!
    • Connect with fans – Great way to give fans an inside scoop
  • Cons:
    • Possibly annoying
    • Look like an awkward shill
    • Breaking the law if you do it wrong
  • Solutions:
    • Be useful
    • Easy to unsubscribe
    • Respect method of email collection
    • Don’t buy lists (or sell, or transfer)
    • Use the email list for what you tell subscribers it’s for – don’t change it up on them
    • Build trust and you might get whitelisted


Idea: make sure that everyone that wants to use your website can. Can be both dealing with physical impairments, but also can mean devices

Responsive design

  • Solutions
    • Use a responsive theme
    • Use a responsive plugin (Jetpack)
    • If neither of those are an option, at least make sure your desktop site isn’t broken so the site can be zoomed in and out, avoids flash
  • Gotchas
    • Readability
    • Image/page weight
    • Performance


  • Visualize the customer/user experience
  • Pros
    • You can get in the user’s head
    • Optimize the flow
    • Concrete goals for planning and arguments
  • Cons
    • Hard truths – learn what doesn’t work
    • Takes time
  • Go nuts
    • Hyper optimize steps
    • Google analytics goals at key steps
    • Make storyboard-based decisions


  • Who’s using the site
    • Age
    • Gender
    • Interests
    • Skills

Guerilla testing

  • Over the shoulder testing – just watch people use your site
  • Sentiment testing – which of these versions do you trust, find easiest, etc.
  • Drunk user testing – actually watch people test a site when they’ve been drinking. Drops their guard, scattered

Tools of the attack

  • Analytics (Google, Jetpack, others)
  • InVision
  • UXPin
  • Balsamiq – wireframing
  • Mockingbird – wireframing in the browser
  • Omnigraffle

Doggie bag – what you’re leaving with tonight

  • Think of the user
  • Think ahead of the user
  • React to the user



Put Your Code Pants On

Be responsible with your code

  • get organized
  • version it
  • if possible, work locally

I know you can “just go in and change that one line”. What happens when that one change mushrooms into a rabbit hole?

Slow is safe, safe is fast.

Compartmentalize your code

Compare header.php in Twenty Ten vs. Twenty Fourteen. Look at how all the calls to css & javascript got moved to to functions.php, loaded through twentyfourteen_scripts()
Try not to repeat yourself – if you wind up writing the same code twice, you could probably rewrite it to account forbeing used more than once.

Learn by doing

If it’s been in WordPress since 3.0, learn how to do it without a plugin.

Organize your stylesheet

Think of your theme in a mobile-first mindset.

When you write your CSS, avoid mixing widths and other positioning CSS with typography, backgrounds, and colors. Move all the positioning & dimensional styles into media breakpoints to avoid repeating styles.

Don’t hard-link scripts, css, or URLs

Use wp_enqueue_style() and wp_enqueue_script() to load your CSS and Javascript with any necessary dependencies ( jQuery, etc. )
Use the various “url” functions for src or href attributes in your templates: home_url(), get_template_directory_uri(), etc. Try to avoid writing out things like href="/my-page" because your site may get moved to a subdirectory and that relative path will break. Use something likea href="<?php echo home_url(); ?>/my-page"

Versioning ( git ):

Learn the basics of the command line:

In actual day-to-day use of Git , SVN, etc, there’s nothing wrong with a GUI tool

Working Locally

  • Save yourself time.
  • Avoid relying on crappy network connections.

Local dev tools:

Intro to browser tools: Understanding the technical aspects of Firebug

Presented by Nick Batik, Pleiades Services

Firebug is a Firefox extension

To get it, go to Firefox menu under Tools > Add-ons and search for Firebug and install it into your browser.

Firebug allows you to go under the hood of your browser. You can view and change the code on any website to see what’s running and what you can do to modify it. All changes are temporary in your own browser and do not affect the live site. This is a great way to learn HTML and CSS as well as a great tool for designing new sites and modifying existing sites.

To turn on Firebug, look for the small lightning bug in your browser under the address bar. That will open up a window  under the website content; you can also open it as a separate window.

Once you have a console open, you can inspect the CSS, HTML or Javascript for any website (one running WordPress or not!). You can modify any code you wish, but none of it will be saved on the browser. You will need to save it to a file and upload it to your server for the changes to take effect. Firebug just allows for inspecting, previewing and testing code changes.

From here, Nick demonstrated how to use Firebug, which is difficult to capture in a blog post. Until we can get his video uploaded, here are some links to tutorials you can check out:

  • StudioPress’ tutorial:
  • Chris Coyier’s CSS-Tricks screencast:
  • The Firebug Tutorial Series:

Nick mentioned the DOM tab in Firebug and explained  briefly how to use it to identify areas of a page that can be modified with Javascript. You can read more about this here:

The Layout tab will show you how much space a selected element takes up on the page.

For the Javascript tab, here’s another tutorial:



12 Biggest SEO Mistakes Web Designers/Developers Make

Presentation by Tony Tovar


  • Intro:
    • Question he got from a businessman: “What the heck is wrong with Google? I should totally be ranked high in Google.” This prompted Tony to start talking to the community about SEO.
  • < title > tag 
    • This is what Google sees when it visits your site and displays in Google search results. 60 characters seems to be a good rule of thumb. It could even be number of pixels. Also, good rule is 160 characters for description.
  • Image-based Headings
    • Use contextual links or a button with actual editable text.
  • Image-based buttons 
    • “If you need to fix your window contact us” – again, it’s good to use editable text rather than an image for these kinds of buttons.
  • Keyword research
    • This is very important – you can optimize your text and titles based on keyword research – those things you like to rank for.
    • Make sure keywords don’t amount to more than 7% of your content.
    • Google Keyword Planner – gives you a good idea of what people search for
    • Paid tools: SEM Rush, SEO MOZ; Raven Tools good for links
  • Keyword-rich content
    • Write good content. Don’t stuff your text and make it sound awkward, but use the keywords appropriately.
  • Content structure is important
    • Your first link shouldn’t be to “home”. You want the first link to have a keyword embedded in it. Your H1 tag should be the first header – like a headline. Don’t use header tags for formatting – use them for organizational structure like an outline.
    • If you link to other pages, you should make those separate pages. Siloed pages – link to pages of authority.
  • Regular content = more crawls = more traffic
    • The more content that’s on your website, the more often Google will want to come to your site. You can even repurpose content with new titles, revised. Consistent content is important.
    • If you have a low-ranking page with a high bounce rate – try revising it.
  • Don’t be evil: Use < alt > tags!
    • Alt tags on images will help those who are visually impaired know what’s on the page. Also Google crawls them – so they will help your SEO.
  • Flash
    • Flash looks beautiful. The problem is that stand-alone Flash content is not crawlable and can’t be used by screen readers. Search engines can’t use it to index a site.
  • Splash pages
    • Definitely don’t want to use splash pages (pages that show up while real content is loading). This can really hurt your SEO. Landing pages however, are fine.
  • AJAX
    • AJAX content is not crawlable. It refreshes content so Google doesn’t see it.
  • Too Late! 
    • SEO is implemented too late in the design/web creation process
  • 301 Redirects with htaccess files
    • redirect old domains to new domains – keeps SEO value
  • Panda and Penguin – Google updates
    • Panda focused on duplicate content
    • Penguin – link building and over optimization


  • Follow/No Follow
    • Reason why you would want to use a no-follow on your links – keep the most page rank possible.
    • Use no follow for new site links
    • Comments – make commenter’s links no follow
    • Does not affect your bounce rate either way
  • Websites with image banners as site title
    • use H1 tags are appropriately aligned
    • use alt tags for image
  • Links in footer
    • If goal is to do inner link building – yes
    • If your goal is to build SEO for a page – they can sometimes hurt you so it’s good to remove them because if they are on sites Google penalizes, it can hurt your SEO
  • Disavow tool
    • use at domain level, not page level
  • Navigation menus
    • sometimes the upper navigation rather than main navigation will get added to search engine results. Not sure if these help or hurt.
  • Categories and tags
    • to index category and tag pages or not – fine line for ranking and general SEO
    • it depends on the site, personal preference, how content-intensive the site is – if the site has daily content then it can help
    • Categorizing content can help your SEO. Use the tree structure as much as possible – helps build depth to a site. No definitive number but 10-15 categories is a good ballpark, but it depends on amount of content. Most people don’t have that much content so they don’t need that many categories.
    • Keywords are important – use categories in line from that
  • How do you control what is shown as a search result?
    • Use the SEO meta tags < title > and < description > to control what shows up
  • Sitemaps – are these how certain content shows up in search results?
    • Yes, if the sitemap is well-designed
    • You can create one using a plugin – Yoast’s WordPress SEO is a good one
  • Under construction sites 
    • Make sure your plugin doesn’t actually allow Google to access your content
  • RSS Feeds
    • As a widget – probably good not to index it or use in an iframe.
    • Depends on what you are trying to accomplish.
    • Google has devalued footer and sidebar links
  • Keywords in CSS or image file names 
    • Recommends against keywords in CSS – looks like blatant keyword stuffiing
    • Having good image file names and alt text can help a lot

WordPress Theme Anatomy and Child Themes – Part I

WordPress Theme Anatomy

Presenter: Corey Ellis

Notes from Corey’s presentation:

WordPress theme development in WordPress codex

Stepping into Templates

What is necessary for a WordPress theme:

  • At minimum a WordPress theme needs two files:
    • index.php – controls structure of site (what the site does)
    • style.css – the stylesheet for the site (how the site looks)
  • Most WordPress theme will have more files, but these two are mandatory for a WordPress theme to work.
  • Most themes will also include functions.php as well as wp_head(); and wp_footer(); hooks in a php file

header.php file

  • Anything inside the section < head > < /head > is just information that doesn’t display in a browser window but is necessary for things to work
  • In the section < body >< /body > is what the user will see
  • The < title > tag controls what is shown in the browser window
  • wp_head(); and wp_footer(); are hooks that tell the browser what to execute in the header or footer; often used by plugins
  • the tag < body class >  allows you to modify the body class in your CSS: see body class reference in the Codex

How to view stylesheet and other structural information of a website

  •  inspection tools that you can use to see/modify the code of a website
  •  does not actually commit changes but allow you to see how a change would look
  • Firebug for Firefox
  • Chrome Developer Tools 
  • will work on any website; great way to learn

Other PHP files

  • header.php and footer.php control the header and footer
  • everything else (category.php, single.php, sidebar.php etc.) control what’s in the middle
  • Themes will have one or more php files which will assemble a page with the header, footer, body, sidebar etc. depending on which page is requested – e.g. single.php is the page created to display a single blog post
  • Template hierarchy graphic (from WordPress Codex) determines which page WordPress will display in the browser


Building Child Themes

Presenter: Bobbie Wilson

Why use a child theme?

  • You can use child themes to practice your theme skills
  • If you want to modify an existing theme, you can make changes and when the parent theme is updated, your changes won’t get overwritten

How to build a child theme

  • WordPress Codex on child themes
  • All themes will be found in your WordPress install in the directory: wp-content/themes
  • You will create a new directory for your new theme. It will have its own folder at the same level in the directory as the parent theme. So you might have /themes/twentytwelve and /themes/twentytwelvechild as two separate folders both within the themes folder.
  • A child theme needs a style.css file. You can create it in any text editor and save it in a folder named for the child theme. So you can create a new child theme called Playground and save a style.css file in a folder called playground.
  • Inside your style.css you will need to insert certain code:
Theme Name:     Twenty Twelve Child (or whatever you're calling it)
Theme URI:
Description:    Child theme for the Twenty Twelve theme
Author:         Your name here
Author URI:
Template:       twentytwelve                             
Version:        0.1.0
  • The template name has to be typed exactly the same way the parent theme folder is named in your themes directory
  • In your style.css you then need a line that includes the parent theme, to pull the parent theme styles into the child theme. Again, this will need to be typed exactly as the parent theme is named in the themes directory:
@import url("../twentytwelve/style.css");
  • The child theme will inherit everything in the parent theme unless there are styles in the child theme; all child theme styles will override the parent styles.
  • You can add php files to your child theme, including your own functions.php file. Just don’t duplicate functions in your child theme or your child theme will crash.

Slight digression: