Category Archives: WordPress

Hello WordCamp Orange County 2015!!

I’m so excited to be here with you all today to talk about Automated Testing 101. This presentation is, despite the 101 title, geared towards people who are slightly more than beginner, up to intermediate developers and testers for WordPress, and also for the client/stakeholder/business owner who is in charge of seeing your website to fruition.

For ease, my slides are below or you can download here:

Feel free to post a comment here if you have questions and we can start a dialogue and work on your questions together.

See you soon!

Tabby

WordCamp San Diego 2015 – What You Can Do With the Heartbeat API

Helloooooo San Diego! I’m so happy to have been selected to speak at such a fantastic event! FOUR tracks on Saturday!! That’s a LOT of information! Looking at the Developer Track line-up, I can tell that this room is going to be filled with learning and useful info-trading. It’s all very exciting!

For my presentation, you can follow along here:

Please feel free to leave a comment and let me know your thoughts on this and share ideas on how you might considering implementing the WP HeartBeat API!

I hope you have an enjoyable WordCamp! #wcsd2015 ftw!

Integrating Your API with My WordPress: Tools & Words of Wisdom

API’s are cool. They allow you to interface with other people’s data and use it with your own site. This enables you to provide a much deeper/richer experience for your customer base than if your site content was solely reliant upon your manual input of all content.

Some examples of APIs that are regularly used in the WordPress industry are payment gateways such as PayPal and Stripe and article feeds such as Reuters. The primary gist of these types of services are that you provide the service with some parameters and it returns a set of data in a pre-defined format. You then read in the format and parse the data to be used in your own way.

Each service offered by various companies will have their own way of defining the data and their own way of delivering the data and it will be up to you, as a developer, to be able to read in that information returned and make sense of it in a useable format. Some various types of ways to receive data from an API is usually RESTful or SOAP based services. RESTful services include XML and JSON and have no set standards. A SOAP based service is a protocol with standards using XML for communication over HTTP. These are subtle and important differences when integrating an API into your WordPress site.

According to Google Trends information, Soap is on a steady decline or even leveled off very low in terms of usages, while REST has increased exponentially.

Screen Shot 2015-03-03 at 5.31.41 PM

 

The reason I bring this up is because sometimes you don’t always have to invent the wheel when it comes to importing content from an API, especially if it is a RESTful XML file that can take a URL to return information. WordPress developers have worked hard to create a series of tools that will enable you to make magic on your website, even as a developer.

Here are a list of tools that would get basic APIs up and running on your site with a little careful planning and a few clicks and keyboard strokes.

  • WPAllImport
    This tool imports any XML or CSV file into your WordPress site. It is a premium plugin with an annual fee, but if your site depends heavily on external data being imported into it, the fee should be worth it.
  • Custom Post Type UI
    CPT UI allows you to create an unlimited amount of custom post types and custom taxonomies. This is especially useful if you are not doing ‘post’ or ‘page’ based work and need much fine control over the type of content that you are entering. For instance, if your website is a catalog of cars built in the 1900’s, you might want to import the data as ‘autos’ instead of ‘posts’ or ‘pages’. This gives you that granular access to be able to fully define your content pieces. This plugin is completely free and also completely worth it.
  • Advanced Custom Fields
    ACF is another premium plugin that is completely worth the price tag. This allows you to have even more granular control over the admin interface and ‘post meta’ of your site for each post. There are even add-ons that you can purchase that will give you special access to the WP Options table via the WP Admin. It has personally saved me hours and hours of coding up meta boxes.

With these three tools, you should be equipped to import and control the most basic API in XML format out there. Of course, if the APIs are more than a simple XML call, you will probably not be able to use WPAllImport and will need to develop a custom solution. An example of a series of more complex APIs are those that require you to call a list of ALL of one type of thing and, based on the specific ID of one of the items in that list, make a second call to retrieve the API for the specific data in that list. An example of this would be getting all automobile makers in one call-back and having to send a second request to get all autos of a specific maker with a specific ID. Those can be a sinking rabbit hole and unless your name is Alice, I don’t recommend you follow.

And of course if you need help with that custom solution, send an email, I’ll be happy to see if I can recommend a solution for the API you want to integrate.

So to sum it all up: integrating a third-party API can be very easy to do if the API is in XML and is a simple URL call. It can get a little more crazy if there are multiple calls to multiple parts of an API that is XML based.

Of course there is a third type of API more like the Facebook API which requires the installation of libraries. That’s a different topic for a more advanced entry.

What are some of the tools you use to import information from APIs into your website? What do you think of the tools listed above? Do you have a strong preference for a different tool that accomplishes the same things? I want to hear!

WordPress Plugin Count: Quality, not Quantity

I was at WordCamp Vegas this weekend and I noticed, on several occasions, that some of the audience balked at the suggestion of installing plugins. It would seem that somehow the impression is being given that ‘less is more’ in terms of the number of plugins that a WordPress installation should have. I am not exactly sure how this message is being delivered, other than through a network of non-developer-type people who are advising other non-developer-type people on how to build a WordPress site.

I hope this post sheds some light on the ‘Less is More’ phenomenon.

We’ll start this explanation at a n00b non-developer-type level and get a little more technical as I go on.

WordPress is comprised of a series of files that sits on a computer. In the case of your website, the computer has a ‘hole’ open for the “World Wide Web” to access some of its content. This ‘hole’ is called a ‘port’ (think ‘porthole’ from the Titanic). Any computer that has this port open (among other things) can display certain files to the web. These files have to be text-based files–kinda like opening a text editor (not Microsoft Word) and saving a blob of text as blob.txt. Then, the World Wide Web of people can go to the address to your server (your domain name, usually) and access blob.txt and view its contents. You can have several types of text files that get a little more advanced. The next step up from a text file is what’s called an HTML file (that stands for HyperText Markup Language). This is a way to format your text file so that a browser can interpret things like location of the content and the type of content that you are showing.

So, let’s talk about ‘Less is More’ at this level. When a website is accessed, it accesses the HTML page (this is usually ending in .htm or .html with some variations). If that page is filled with JUST the blob from your blob.txt file, it will load faster than a fly avoids a swat. But if you’ve got that file filled with a bunch of links to other files (usually, this is links to images, ‘style sheets’ or ‘javascript’ files, which I won’t get into here), then the load time starts to slow down. If you have ten small images on the page, the slowdown is barely noticeable. If you have ten VERY LARGE images (file size, not necessary width/height) on the page, you can go grab a cup of coffee while you wait for the page to load.  You can also bet that this is a poorly designed page as each page should have only the most appropriately sized image on the page to do its job.  The same goes for CSS files and for Javascript files-Anything outside of the existing HTML file could cause a slow-down if it is not developed/designed properly.

So, now we get to WordPress. A step up from HTML is what is called ‘scripting languages’ (something that can be run at the time it is accessed). There are various types of scripting language out there, but WordPress uses  ‘PHP,’ which stands for Hypertext Preprocessor – I know, it’s a little mixed up with the acronym, but just go with it. If you notice, this explanation started with just Text, went on to HyperText markup language and now we’re at HyperText PreProcessor. It’s getting a little more advanced, right?

Right. PHP is a text file that usually ends with .php. This file actually needs a ‘server’ to ‘interpret’ the file and run it at the time it is accessed. So there is this extra layer, if you will, of applications that must be running in order to show a PHP file. These files consist of a mixture between the scripting language and HTML (although, if developed correctly, the files would highly separate out the two).  You could have a PHP page that is a mile long that could load up in less than a second. The cool thing is that the server only access the parts of the file that is needed to run. It doesn’t need to read the entire script every time the page loads. This makes for a little more flexibility than a straight HTML page does because you can be highly selective in what you access when you load the PHP page. You can add a second mile to your PHP page and it might never change page-load. It might start making the PHP code unreadable, but it doesn’t necessarily change the page load.

So, let’s talk about ‘Plugins’ now. WordPress is uniquely designed to allow for ‘interrupts’ to occur throughout the core of its code. These interrupts are places in which a developer can insert their own code and override what’s happening at the core level. A developer can either do this in the themes functions.php file (highly unadvised) or create a plugin (two big thumbs up). The plugin will generally have 5-7 additional lines of commented code than you would have in the functions.php file, however these are pieces of code that you can now turn on and off at your leisure, as deemed necessary.

Just as with HTML, you can have hundreds of these ‘interrupts’ that WordPress calls ‘Hooks’ or ‘Actions’ and ‘Filters’ either in your functions.php file or as plugins and this would never effect the speed of your site.

The problems begin when the plugins are coded inefficiently. There are a number of different ways to have inefficient code for a WordPress site, but primarily it is either a lot more code that is processed than needed (lots of iterating over data or queries of data) or it is running the plugin with the wrong hook/filter. Another issue can be when a developer doesn’t use unique names of their methods and it ends up overriding or stepping over other plugins or core functionality that wasn’t intended. Once you start having inefficient plugins installed, it can effect the site-speed drastically and immediately.

So, How can we avoid poorly designed plugins slowing our sites down?

1) Vet your plugins: Always read all of the reviews and check which version number of WordPress the plugin works on. Do a google search for anyone complaining about the plugin before installing it.

Screen Shot 2014-12-18 at 9.42.28 AM

2) Test your plugin: It’s always best practice to have a copy of your site on another space so that you can test things out before you actually put them on your website. You will be able to catch the small nuances of site-speed before it hits your actual site. Here’s a good tutorial on how to set up a staging site for your WordPress installation.

3) Go premium if you can: Of course, follow my first suggestion for these plugins and vet them well. However, paid plugins generally have much better support when things go wrong and that can be a life-saver (or money saver/money maker).

4) Use a caching plugin. I should have put this first, actually. A caching plugin is magical. It takes the output of the PHP page and turns it into an HTML file to be accessed. This takes away that extra layer of having the applications that interpret PHP have to work to deliver the page. It does mean that you have to delete those html files every now and then but all of the good caching plugins have that option. I recommend WP-Super-Cache or W3-Total-Cache. I usually use WP-Super-Cache for all of my projects that require caching.

WP-Super-Cache Delete Options

WP-Super-Cache Delete Options

Having a ton of well-contained plugins that do very specific things is a much better alternative and does not cause significant site slow-age. On the other hand, having one or two poorly executed plugins can be catastrophic to your bounce rates. As you can see, the quantity is not nearly as important as the quality.

With that… Happy Plugin-ing. 🙂