Austin WordPress Meetup

Bringing together WordPress users of all levels

Intermediate WordPress

Intro to WordPress as an Application

Meetup Meeting Notes, Intermediate WordPress

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.

Transition

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.

Application

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, twitter.com, 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)

Clients

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.

APIs

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.

Understanding the Ins and Outs of WordPress Metadata

Intermediate WordPress

This entry is part [part not set] of 9 in the series Meetup Meeting Notes

Notes from 11.25.14 Austin WordPress Intermediate Meetup

These presentation notes were developed to support those just learning how to create and display metadata in their WordPress sites. The Ins and Outs of WordPress Metadata describes how to go beyond pages and posts, and learn how to develop data entry screens for specific information whether it’s a shopping cart, a directory, recipes, genealogies or any other specialized content.

Nick Batik explained what metadata is and demonstrated custom content fields, and reviewed best plugins for creating and setting the field types such as check boxes, drop downs, radio buttons, text, and image fields. He demonstrated the underlying metadata code and ways to take it further. (See slide deck below.)

The second part of custom content is getting it to display on the public side of your website. As a site developer / designer you must add code to your theme to find and display the custom fields. Corey Ellis demonstrated custom loops and the Meta Data API, and how to retrieve and display the data entered in the backend of your site.

Note: When Nick or Corey use the phrase “post” throughout this presentation, they referring to a post of any post type, not the default blog post type bundled with WordPress.

What is metadata?
Metadata is set of data that describes and gives information about other data.

What is a post meta box?
A post meta box is a customizable box appearing on the post editing screen that allows an authorized user to select or enter information in addition to the main post content. This information is related to the post in some way.

 What are Custom meta boxes?
Custom meta boxes are tools to enhance content. Meta boxes are the little blocks in the editor section for each post type. Meta boxes are commonly used by themes and plugins when a developer wants to implement a constantly formatted interface for saving/editing a number of custom fields than the one provided with WordPress.

What are WordPress Custom Fields?
Custom Fields are a form of meta-data that allows you to store arbitrary information with each Word- Press post. While this does not sound so powerful, it is the single most powerful component of WordPress posts and content types (aka post types). This meta-data is handled with key/value pairs. The key is a “name” which identifies the specific field thus it is a constant and should stay the same for all posts however you can use the same key multiple times within one post. The value is the information that will be displayed for the field when you call it in your WordPress theme thus it can change with each post.

How To Create Custom Post Meta Boxes In WordPress

The two most common types of data is entered into meta boxes are:

  • Metadata (i.e. custom fields),
  • Taxonomy terms.

Post metadata is data that’s saved in the wp_postmeta table in the database. Each entry is saved as four fields:

  • meta_id: A unique ID for this specific metadata.
  • post_id: The post ID this metadata is attached to.
  • meta_key: A key used to identify the data (A single meta key can have multiple meta values.)
  • meta_value: The value of the metadata.

Metadata is the key/value pairs saved for a specific post that let you to add custom data to your posts. It is particularly helpful when you’re developing custom post types.

How to use post metadata

To know how and when custom meta boxes are helpful with organizing content, you must understand how to add, update, delete, and get post metadata.

  • add_post_meta(): Adds post metadata.
  • update_post_meta(): Updates post metadata.
  • delete_post_meta(): Deletes post metadata.
  • get_post_meta(): Retrieves post metadata.

Below please find Nick Batik’s slide deck  and other links and references.

 

  1. Understanding the Ins and Outs of WordPress Metadata

Austin WordPress Meetup
Tuesday, Nov. 25, 2014

Presenter: Nick Batik
@nick_batik
http://HandsOnWP.com

  1. What is Meta Data?

  2. Metadata is “data about data”.

There are two (metadata types):

• structural metadata, about the design and specification of data structures or “data about the containers of data”;

• and descriptive metadata about individual instances of application data or the data content.

  1. Huh?

  2. Let’s Look at Some Examples (It will make more sense)

  3. Books

• Title
• Author
• Publisher
• Date of Publication
• Number of pages
• ISBN

  1. Business Directory

• Name of business
• Description
• Address
• Phone
• Owner
• Hours of operation

  1. Photography

• Resolution
• Exposure time
• F-stop
• Focal length
• Aperture
• Pixel dimensions

  1. Event

• Location
• Date
• Performers
• Description
• Where to get tickets

  1. Oh! So meta data is information about the book, business, photograph, and event!

  2. Adding Metadata to WordPress

  3. Custom Post Types The “container” for your metadata Example: • Books • Photo Portfolio • Business Directory • Events

  4. Custom Fields The metadata for a Post Type Example: • Title • Author • Publisher • Date of Publication • Number of pages • ISBN

  5. Custom Taxonomies Categories specific to a Post Type Example, a “genre” taxonomy for a book: • Science Fiction • Drama • Romance • Mystery • Western

  6. Post Types can have multiple taxonomies

  7. “Books” could also have a taxonomy of “binding”:

• hard cover
• paperback

  1. …and “Publisher”:

• Addison-Wesley
• Wiley
• Prentice Hall
• Bantam

  1. Field Formats Choosing how each field should be edited

  2. Text Field A single line of text

  3. Text Area

  4. WYSIWYG Text Area

  5. True/False Check for true, uncheck for false

  6. Checkbox Select as many as you want

  7. Radio Button Select only one from the list

  8. Drop-down List

  9. File or Image

  10. Embed content Such as videos, audio, slide shows, etc.

  11. Link to other pages

  12. Color or Date Pickers

  13. WordPress Metadata Plugins

• Advanced Custom Fields
• Types – Custom Fields and Custom Post Types Management
• Pods – Custom Content Types and Fields

  1. Creating Custom Post Types

• Labels
• Icons
• Visibility
• Sections supported
• Roles & capabilities
• Menu position

  1. Demo

33. Doing it with code

34. (code sample)

  1. Post Type Supports

Default: title and editor
• ‘title’
• ‘editor’ (content)
• ‘author’ •
‘thumbnail’ (featured image, current theme must also support post-thumbnails)
• ‘excerpt’
• ‘trackbacks’
• ‘custom-fields’
• ‘comments’ (also will see comment count balloon on edit screen)
• ‘revisions’ (will store revisions)
• ‘page-attributes’ (menu order, hierarchical must be true to show Parent option)
• ‘post-formats’ add post formats, see Post Formats

  1. Post Type Menu Position

The position in the menu order the post type should appear. show_in_menu must be true.

Default: null – defaults to below Comments
• 5 – below Posts
• 10 – below Media
• 15 – below Links
• 20 – below Pages
• 25 – below comments
• 60 – below first separator
• 65 – below Plugins
• 70 – below Users
• 75 – below Tools
• 80 – below Settings
• 100 – below second separator

  1. Demo Creating a Custom Post Type with Types plugin

  2. Demo Creating a Custom Post Type with PODS

  3. Demo Adding Custom Fields to “Books” with Types

  4. Demo Adding Custom Meta to Events with PODS, Types, and Advanced Custom Fields (ACF)

  5. Demo A quick demo of how to do this in code…

Metadata Resources for designers and developers

Post Meta Data Section
http://codex.wordpress.org/Post_Meta_Data_Section

Function Reference/add metadata
http://codex.wordpress.org/Function_Reference/add_metadata

Other helpful links for WordPress Custom Content Fields
https://www.google.com/search?q=WordPress+Custom+Content+Fields&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-beta&channel=sb – rls=org.mozilla:en-US:official&channel=sb&q=WordPress+Custom+Content+Fields

 

Part 2: Displaying Your Metadata

Presenter: Corey Ellis

http://about.me/coreyellis

@zzramesses

https://gist.github.com/zzramesses/365918805cf5f937e976

You break it, you buy it

WordPress Themes, Intermediate WordPress

Upcoming events

You break it, you buy it

presentation by Bobbie Wilson

Notes at http://www.bobbiejwilson.com/blog/wordpress/break-buy/

Child theme on WordPress Codex: http://codex.wordpress.org/Child_Themes

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.

 

Tips:

  • 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

Tips and Tools, Intermediate WordPress, Design, User experience

Presentation by Clark Wimberly

Links/slides from presentation here: http://clarklab.com/talks/user-experience

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

Newsletters

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

Accessibility

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

Storyboards

  • 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

Personas

  • 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
  • usertesting.com
  • peek.usertesting.com
  • verifyapp.com

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

Intermediate WordPress

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:
http://www.siteground.com/tutorials/git/commands.htm
http://gitref.org/basic/

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

Tips and Tools, Intermediate WordPress, Design

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: http://www.studiopress.com/tips/using-firebug
  • Chris Coyier’s CSS-Tricks screencast: http://css-tricks.com/video-screencasts/15-introduction-to-firebug/
  • The Firebug Tutorial Series: http://www.youtube.com/watch?v=tdIk2PztcL0

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: https://getfirebug.com/dom

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: https://getfirebug.com/javascript