Introduction. Justin Ferrell, I’m a developer. Started with mobile web in high school, studied computer science and IT at a couple of schools in WV and VA. Eventually ended up at Relativity doing mobile web, learned Titanium and Mono, and started doing desktop and responsive web.
I’ve been part of a digital marketing startup in West Virginia for almost four years. We grew out of a little web and SEO shop that was started in the mid 90’s and now we’re doing everything from mobile, to responsive and even print design.
Jump right in. The topic of conversation today is going to be Wordpress and more specifically, the awesome things you can do with it. I had a conversation with another speaker last night about creating talks that appeal to experts as well as people who just wander in. So a lot of this content is going to be sort of Wordpress 101. But the there should definitely be some more in-depth stuff.
What is Wordpress? An open source content management system that was originally designed as a blogging platform.
The first thing about WP that’s worth pointing out is that the entire PHP codebase is open source, which is great for plugin developers and even people who want to contribute to the core project. And plus its free, which everyone likes.
If you’re interested in contributing to the core Wordpress project and never have before, they have a page dedicated to “Good First Bugs” to help you get started.
And there is also a very active IRC community for average Wordpress developers, developers wanting to contribute to the project and even developers interested in helping with the mobile Wordpress applications.
And they make that entire process super easy. Wordpress has some of the very best documentation of any open source project that I’ve ever used.
Every function in Wordpress has documented usage with explanations for parameters and return values. Even examples of usage and access to the change log and related functions. And more often than not, it’s all available in at least four languages.
They even have tutorials for things as simple as creating your first plugin. Everything from proper directory structure to API hooks and how to structure your read-me files.
And all of this has helped cultivate a really great development community. The community surrounding Wordpress is absolutely massive right now.
As of Tuesday, there are 34,493 plugins on wordpress.org. And these plugins are being used in with…
the 2,796 themes on wordpress.org. So the amount of code written on top of Wordpress is just staggering. So what does that mean when you zoom out even further?
Of all websites built using a content management system, 60% run Wordpress. The next most popular being Joomla and Wordpress is over seven times more popular.
And if you zoom out even further, and look at the internet as a whole, Wordpress accounts for over 23% of it. That’s almost a quarter of all internet.
But being the biggest of something doesn't always mean that you are the best at it. Market share means very little when you’re shipping products don’t help people do better work.
Now assuming that Wordpress enables internet professionals to do their best work, I’d like to show you some examples of my own work and how my team and I leveraged Wordpress to make these projects happen.
The first example is brewery in Sonoma County, CA called Bear Republic. Anyone tried their beer? Great products, very Californian. They make some of the best beer in the country and have the medals to prove it.
And that’s what we wanted to enable them to do. Not only show off their work, but maintain the related content as well. For beers in particular, we used custom post types and and custom fields.
Custom post types are stored with regular posts in the database with a field denoting the post type. So anything that isn’t a Post or Page. They have support for custom taxonomies so if you need more than just categories and tags, you can add it.
Custom fields are stored in with other post_meta in the database. These are just extra fields that can be associated with posts. Anything other than the standard title, thumbnail, content and excerpt. And there are even some great plugins that make the UI for custom fields a lot more friendly without completely melting your database.
Because by default, the custom field UI is kind of bland. No easy way to normalize input or format it.
One plugin in particular that is great for this is called Advanced Custom Fields, which adds support for things like select boxes and custom data sets for fields so that you can limit and validate the data your users can enter on the backend.
But with ACF, we get fields like dropdowns and radio buttons, date pickers and checkboxes and even full on WYSIWYG editors. These are fields that your users will see when editing content in Wordpress.
And it even has a great UI. You set rules for what posts can use the fields and then just create the fields. You can even specify where on the page it will appear.
So we’ve seen the front and back of this page, but what does the code look like?
pulling out custom field data in page templates is pretty straightforward. You can use get_post_meta, which is a native function right inside Wordpress that will give you all of the custom field data associated with a particular post by passing in that posts’ ID.
If any of you have ever used Advanced Custom Fields, you’re probably wondering why I didn’t use get_field, which is not included with Wordpress, but is included with Advanced Custom Fields.
If you compare these two little bits of code, you can see that they do the exact same thing. The one on the left uses the native get_post_meta and the other uses get_field from ACF. But if you look at the “get” statements in the bit of code on the right, you can see that we’re running back and forth between the database a great deal. Alternatively, we could just make one stop, grab what we need, throw it into an array and be gone.
So that was storing and displaying client data, but what about doing it programmatically? Using PHP or some API to store and manipulating data in custom fields?
This example is a bit more read and write. We recently built a website for a recreation outfitter back home called Waterstone Outdoors that sells rock climbing and extreme sports gear.
Since the site was built on Wordpress, we used Woocommerce. If you’re not familiar with Woocommerce, it’s the absolute best ecommerce system available for Wordpress. Extensions, plugins, great API, awesome support staff. So we have Wordpress, we have Woocommerce and we have all of infrastructure in place. But, there was another hurdle here.
The thing was, they had an existing point of sale system in their store that tracked things like inventory and sales. So, we had to come up with a way to sync the data in that point of sale with the data in Woocommerce
To accomplish this, we built a write API for Wordpress that would allow us to send data to the server programmatically using a C# client on the POS server in the store. We loop through the products nightly and thanks to the magic of the post_meta API, we can update the product data in Woocommerce without touching the Wordpress admin panel.
To start, we use a custom function to get the ID of the product that matches the SKU we pass,and store it.
And we do that using meta_key and meta_value. You build a Wordpress Query just like you always would. The only difference is that we specify the custom field using meta_key and meta_value to specify the value, and we get back a post.
Now that we have the ID, we go through the data that we have and update it. You can see that I store a status for each field and this is so that we can echo them back and keep logs. You may also notice that we are using update_post_meta. Advanced Custom Fields has an update_field function but since we’re dealing with data stored by Woocommerce, we have to call the post_meta functions directly.
So we can read it, we can write it, we can display it on a website. But what about other places. How can we create some really solid API’s with Wordpress to power things like mobile applications?
This example was a website built for a tourism company called Visit Southern WV. This is a business whose job is to market recreation, dining and lodging options in Southern West Virginia. They do this through the use of things like itineraries and memberships for businesses to be included in visitor’s guides and marketing materials.
When I became involved with this project in the Fall of 2010, their website was built using a relatively obscure CMS called CMS Made Simple, which did not prove to be the case. Most of our work on the website at the point required the help of outside contractors who were on the CMSMS dev team and it was just a bad workflow. We ended up rebuilding the database by hand for the mobile application and bundling it, which meant that not only did all information have to be updated in two places but that data had to be submitted to Apple every time it was changed. Not good at all.
Enter Wordpress. A former colleague of mine and I wrote a plugin for Wordpress called Company Directory that stores business listings as custom post types and stores data like location and hours in custom fields specific to the plugin. We even built in geocoding and reverse geocoding to allow large portions of the data to be self-maintained and keep themselves up to date while other data changed. For the itineraries that I mentioned earlier, we were able to create an itinerary post type and associate businesses with particular itineraries using relational data in Advanced Custom Fields.
But that doesn’t mean anything to an app if you can’t get the data out. So we created another API. This time, we wanted to be able to pass in relational data and get back all related posts and post data.
So using data that we passed in using GET statements, just like with Waterstone, we crafted some custom queries. You can see that we have a conditional there. So if we want some specific data, it’s there, but we can also create whole lists. We specify our post type and using posts_per_page, return as many as possible.
And just like with most things in Wordpress, the meat and potatoes is the loop. We loop through the objects we find and we grab their title, content, featured images, and we manipulate the post_meta a little just to make it more friendly to our parser in C#. We store all of these objects in an array. But then what? So how do we get it to C#?
Using what is probably my favorite feature of PHP, we spit out the entire array in JSON using a one-liner built right into PHP, json_encode.
So what we end up with is this horrible graphic that I made using Keynote’s chart tools. But seriously, we end up with a living, breathing data set that begins to push and pull data as it needs it, with Wordpress and the API at its core.
These next two examples don’t really cover anything that we haven’t already, but they’re great examples of just how far you can push Wordpress and it keep on ticking. That is to say, keeps on ticking on a properly configured host.
The first is a website for a beer magazine, one of the largest in the country. When we inherited the site, it was built on Wordpress but had not been updated or maintained for several years so there were lots of hacks in place for things like custom post types and custom fields that didn’t exist at the time.
First, let’s look at the custom post types. This is the admin menu, including the default Wordpress post types. Let’s see it without those.
So you can see that even if I remove the custom post types that plugins create for things like contact forms, we end up with seven custom post types. That’s really not the impressive part though.
What is impressive is the sheer amount of data that Wordpress is able to maintain here. You will often get people telling you that Wordpress isn’t good for large data sets or complex relationships, but I think this is a good example of that not being the case. But maybe not as good as the next one.
Now, this site is currently in development, so I don’t want to share any screenshots that would give away what it is, but I will share with you the general purpose and a brief overview of the functionality.
There is a single entity in a state I won’t mention that is responsible for maintaining all sports data for middle and high schools throughout the state. That includes football rankings, information related to coach education, systems for printing sports passes for administrators of schools, the whole bit. And we were recently tasked with porting it all to Wordpress in period of a couple of months.
In terms of data, we have several custom post types with 15-20 custom fields each, some of which are relational. We also have several custom user roles in Wordpress because coaches and athletic administrators need to log in and add game data. Now, you’re probably thinking “That’s only six post types!”. But the issue here is the sheer size of them, and their relationships. Students are assigned a school, each game is assigned a week of the season and two schools.
So between schools, students and games, we’re currently around 55k unique objects inside of Wordpress. As you can probably guess, it took several API’s to get this data in. And all of this data has a sort of exponential relationship.
If you’re not familiar at all with high school sports, the rankings are based on the score a school accumulates by playing other schools, even in other states. So data for schools spans at least four states in this database. And every game for every school is stored. And then a schools classification (A, AA, AAA, etc.) is based on the number of students assigned to that particular school, so the total enrollment factors in as well.
And then you have the users. Each school has at least one coach and as you can see, several administrators. All require access of some level to data editing in Wordpress, so you end up with some very complex custom capabilities assigned to each one.
So there is clearly a lot that can be done with Wordpress. Custom post types, custom fields, great documentation and a great community.