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!
If there’s one thing that I have learned in life, it is that the majority of our lessons come from the mistakes that we make. And I guess by “we,” I really mean “me” in this case.
One of my very first mistakes I made as a professional software engineer happened to involve email. My boss told me that I was to prepare an email campaign to send out to 10,000 people. Now, I had never done an email campaign before. I was just fresh out of college– very green. I didn’t even know there WERE email campaigns. So this was all very new to me. My boss was pleasant enough about it. He gave me step-by-step instructions and told me what to do. The first step to creating this email campaign was to create a test email. I was supposed to send that test email to 3 to 5 people so that they can look over it and approve the contents and look-and-feel. In order to remind people that the email was a test email, I was supposed to put the word”test” in the subject line. So I did! And, that went well. Everyone must please and they were ready for me to push the big fat “Send” button.
I was really excited to finally be able to send out my very first email campaign. I got together the entire mailing list of 10,000 names and entered it into the mailing system. Eagerly, I sent it on its merry way. Just after I sent the email to thousands and thousands of people, I noticed the subject line still had the word”Test” and it. I was absolutely mortified. I couldn’t believe that I had forgotten such a simple thing.
That day, I learned to check and double-check and triple check my subject lines of every email that I ever send–even my personal emails.
Fast forward a couple more years when I made my next email mistake. I had gone off to start my own consulting company. I was handling the online presence for several celebrities. During one of my correspondences, I cc’d another one of my clients and hit send. And wouldn’t you know it– after I received the confirmation that the email was on its way, I realize that I also sent the email to one of my client’s fans, instead of my client and the second intended recipient. I was terrified. At that point I wasn’t even sure what to do. The best thing I could do was send an apology to my client and not acknowledge what happened to the other person. That time, the lesson I learned from that was to always triple check my “to” and “cc” lines.
Every now and then I make a few mistakes in regards to emails. But today was a mistake that I was kind of surprised I made. As I announced before, I have decided to rebrand. Part of the task of rebranding is to create a new email template for my blog posts. Now, I use MailChimp to let people know that I posted a blog. So I needed to change my mail template on MailChimp from the Essence Interactive template to my personal brand. Over a weekend, I created a new template. My emails are generally sent every Monday at 5 PM Eastern to notify my clients or other various people that I’ve worked with that I have written a blog post.
Welp, sure enough, the Monday after I penned the post about WordPress APIs, I got an email back from my mother, of all people, questioning the contents of my email. It was then that I realized the template was not done correctly. Instead of it being dynamically populated with my actual blog posts it was the template text! This of course makes no sense to anyone who is reading it. And it certainly wouldn’t look good if I was advertising myself to be someone who makes email templates (which I am not).
Oh well, I guess sometimes you win some and you loose some. So now I’ll fix my template and make sure that everything is working well. And of course all of my email clients will get notified once I post this blog post. But sometimes you just have to sit back and laugh with the situation. Life is too short takes such things so seriously. I will do better next time.
And if there’s any moral of would like for you to leave with today for this blog posts. It would be that. Do better next time. Don’t take it so seriously. There is always room for improvement.
I’m not a very tidy person. I don’t mind messes or chaotic spaces. I like things *clean* but I don’t mind if things are out of place. In the context of my email, I rarely ever archive or clean up my email. As it stands, I’ve had my google gmail account now for 12 years and I’ve barely ever deleted anything.
But I got an invite to google’s new app called ‘inbox’. I’m hopeful about this app. It is a step in the right direction for google and gmail, and I’m happy to start using it. Here are 8 things that I like:
1. It’s Everywhere!
I have Inbox on both my desktop (Macbook Pro Retina) and my iPhone. It integrates well and the interfaces are the same so I can do everything I need to do on both spaces. I don’t always like that there’s a ‘mobile version’ of a bigger application when I want to perform tasks on my iPhone as well.
2. Easy to “Do Something With That Thing!”
You can ‘Pin’ the email to the inbox (which utilizes the ‘star’ status), schedule for it to appear again later so you can handle it then, or mark it as ‘Done’. This effectively archives the email and removes it from the inbox. Don’t worry, it comes back if someone replies.
3. Really want to reply to that email but can’t right this minute?
This is about the scheduling feature, which is pretty cool. It allows you to address an email at a later time. You can ‘snooze’ until tomorrow, next week, or ‘Some day’ which allows for you to select a custom time. This can act as reminders or help you to schedule a response to an email, which an be helpful.
4. You can view all the Important Things with one simple toggle!
5. Writing an Email is SO SIMPLE.
There’s a few features that I’m sure that they could provide like the ability the indent text, but for the most part it makes writing an email super easy. Thumbs up.
6. Things are smartly bundled together.
So far, I’m liking the way things are bundled. It helps me get into ‘modes’ of thinking. If I set aside time to deal with finances, for instance, I can check the FINANCE bundle of emails and deal with it all at once. This should increase my productivity since it hides emails not necessarily helpful to my day.
7. Happy Color Scheme is Happy!
BLUEEEEEEEEEE and sunshine = happy!
8. It’s better than Gmail!
Gmail hasn’t changed a whole lot over the last 11 years (as of April 1, 2015) but some may argue that it didn’t need to change much. I know plenty of people who felt confused by the interface and switched back to yahoo or hotmail. Maybe this new paradigm of email will bring them back. Maybe.
Overall, I like that this product seems to actually be completed and not ‘beta’ stage like gmail was for, like, forever.
I have already given my invites but if you’d like to be on the list to receive more invites, please leave a comment in this post and I’ll send invites in the order in which I receive the comment. Make sure your comment has real content otherwise I’ll just assume you’re spam. Ain’t nobody got time for that.
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.
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.
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!
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, 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.
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.
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.
Essence Interactive is being put to rest. I’ll be doing development under ‘Tabby Chapman’ from now on. Yes, I’m going from full on registered Corp to Sole Prop. Weird, right?
Well, EIinc is registered in New York and I haven’t been doing my work under the corp in a long time. I did keep some of my business-related bills registered under the corp to make taxes easier but… taxes are never easy right? Anyway, so now I’m developing under my actual name. That means this blog might occasionally get a little nerdy and developy. Probably not. But it might. I’ll also probably keep a lil’ portfolio here too. A sexy one.
That’s all. If you really are interested in learning about developing and knowing what projects I’m working on, subscribe to this blog and you’ll be updated on my projects AND on my life. Bonus.