Highlights from WordCamp Raleigh 2013
WordCamp Raleigh was, like most WordCamps, a very rewarding experience, and a great place for networking and picking the brains of others working with WordPress. I attended the Developer Track for almost every concurrent session, though there were a couple of times in which the Power User Track and even the Users Track looked really good. (For instance, I really wish I’d seen the Power Users Track presentation on integrating drag and drop layout tools into one’s site.)
I just got back from Raleigh, but here are some of my initial notes, reactions and thoughts on some of the presentations I saw. The title of each presentation links back to the WordCamp Raleigh site, where the authors are supposed to post a link to their presentation materials. In most cases, one can just go to slideshare.com and search for the presenter’s name to find their entire presentation, though some are on gthub.com.
I’ve used ACF on the Assessment of Student Learning site, to create a form on the back end for people to fill in all the desired information, so that each program’s report contains the required pieces, and to make sure that they are all formatted similarly. It’s a great plugin, and I was very glad to see what else I could do with it.
The first useful nugget I got from Julien’s presentation was that Eliot Condon, the author of this plugin, had decided that there was enough interest in this plugin (and the paid add-ons) that he had quit his full time job, to dedicate all of his time to Advanced Custom Fields and its add-ons. As time marches on, more and more plugins get abandoned, leaving me searching for something else that works the way the old plugin did. It was encouraging to hear that this plugin may have some extended, stable life to it (especially since I didn’t find anything else that approaches its functionality).
Julien presented a good overview of ACF and how to go about using it to supercharge post, page, or custom post type editing. However, already having used ACF quite a bit on one of my sites, I only picked up a few tips here and there.
I’ve seen a few presentations on wp-cli (WordPress command line interface) in the past, but still haven’t setup an environment to actually use it. It looks like a very powerful tool, and allows lots of options for scripting and automating site actions, but unfortunately, it requires access to the shell (AKA ‘command line’), which I don’t have on my production server. Still, it may be worth it to setup a Unix-like envvironment with shell access somewhere to use this. (One of the other presentations, about Unit Testing, relied on this and a few other components being installed in such an environment).
The best commands and functions I saw of wp-cli would actually lend themselves best to a testing/development environment anyway, including the ability to easily create a new WordPress installation, with the core files created and configured, the ability to, with one simple command, create a new plugin file, including the standard header section, ready to be filled with code. The command for removing all stock posts and other content was an interesting one, though I could only see this happening in a dev environment, and typically on a new site, there’s only going to be one page and one post…
Also interesting was the command-line import and export, database backup (presrenter wasn’t sure if this was a full database dump, or just a content export), and plugin installation. Aside from scripting backup or import, starting a new installation, and scripting the install of a basic set of plugins would be a nice feature. The database find and replace is also a nice feature.
One can even create their own commands for wp-cli, using the Cookbook (API) to build them. (Take a look at wp-cli.org for details.)
While it was presented as a way to manage production sites, I wouldn’t consider using most of the commands they described on a production site, but they could be perfect for a development environment. The exception might be the plugin update commands. It did a nice job of reporting the versions of all plugins and whether there was an update. Of course, if I’m going to update plugins, I’m always going to also look at the rendered site to make sure I didn’t break something, so even that portion may have limited usefulness to me.
I’ll just start off by saying that I’m not a big fan of sliders, not the animated transition image banners or the mini-hamburgers. One of my big reasons for going to this session (and some of the better tips I picked up) related to why not to use sliders and how they might actually be valuable. The way many sliders are done just doesn’t add useful functionality to a site, takes up screen real estate, and generally seem a waste of time to me. In this presentation, I learned some of the reasons that is sometimes the case, and how to avoid it.
Basic tips I learned:
- Click-through rates for sliders are low
- Don’t put “calls to action” in a slider (see above)
- Use fancy transitions RARELY
- Consider carefully the speed of transition
Make all elements of a slider about a common theme/goal.
So, it appears that maybe the reasons I haven’t liked sliders in the past could be mostly about how others have implemented them, and perhaps there could be a good way to implement them that would add real value to a site. While the presenter didn’t offer any source for this, or really even any metrics, the statement that click-through rates for sliders is low did not surprise me, and sounded like good ammunition against a request to include a slider on my site. Of course, the presenter was talking about sliders because they do use them a lot, and have found some useful ways to incorporate them.
The idea of making each element in a slider support a common theme or goal for the page made a lot of sense. If your call to action (“fill out this form to receive more information about the graduate program”) is preceded by a slideshow that has images and text that provide a stream of supporting reasons why the call to action should be honored, it really doesn’t matter if few people are actually going to click on the slider. While the transition speed shouldn’t outpace your visitors’ ability to read the content on the slide, if the “payoff” is in the content below the slider, which remains constant, as long as they can get enough of the text from a slide to support the call to action, it’s a successful tool. There may be instances in which a slider that contains lots of different messages could be useful, I often find that “busy” and scattered, and typically the transition speed is to short to fully read it, or even click it before it slides away, so I like this approach.
I missed this presentation, instead attending the presentation on WP-CLI, but heard that it was a really good one, and was one of the times I wished I could attend two sessions at once. Apparently, the talk was about a number of different tools that will add drag and drop layout tools to the backend, to the page or post editor, and the guy I talked to who saw it said that by far the most interesting out of the bunch was ‘Page Layout Builder’ in the WordPress.org plugin repository. It allows drag and drop selection of columns and other layout design elements.
The presentation is up on slideshare.com: http://www.slideshare.net/brettbum
This s one of the two sessions I saw on BuddyPress, and was a pretty good overview of what BuddyPress can do, as showcased in the NeiborBee site that Michael McNeill has helped program for the company in which he is a partner. It was all in all a very good overview, and highlighted some of the requirements that need to be met in order for BuddyPress to be happy.
Probably the most serious requirement of BuddyPress, which sounded like it was non-negotiable, was that the site must be installed at the domain root, because of the way that BuddyPress performs some functions. Nearly none of the sites around here are installed at the root of their domain, even if (as in most cases) that domain is actually a virtual domain mapping, and the site is not literally located at the public_html folder of the server.
As anyone who has heard of BuddyPress already knows, BuddyPress is a plugin for WordPress that creates a social network kind of structure for a site. It’s just a plugin, but has such a transformative effect on a site’s functionality, it almost seems like a different product (which it used to be in a way). The presenter answered an important question from the audience on this nuance, verifying that one could have a “regular” website with only a few pages using the BuddyPress functionality; while it incorporates a bunch of new features and functions, it doesn’t have to represent the whole of a site.
BuddyPress is a plugin, though in some ways, incorporates a set of plugins within it, representing different features of BuddyPress, like an activity stream (like a Facebook ‘wall’), private messaging between members, extended profile information, and other features. Although these components are not “plugins” in the sense that they must be maintained separately from one another, installed and removed separately, each of these features can be turned on and off without affecting the other features.
BuddyPress, since version 1.7, will cooperate with most any theme, instead of having to find a “BuddyPress-compatible theme”. Of course, BuddyPress comes pre-loaded with its own theme, which incorporates all the features well, and can be highly customized in a child theme if desired. (BuddyPress is in version 1.8.something now.)
Like other social networking products and sites, one can define who can see various features and posts, like limiting the entire activity feed to logged-in users, or even limiting the visibility of activity feed posts of a certain category to a specific group of site users. Of course, since this functionality and virtually all of the other functionality in BuddyPress is also present in many other social networking products like Facebook that already have a lot of users, a plethora of features, and marketing momentum that would be difficult to match, I had to ask why one would use BuddyPress instead of Facebook. The answer was basically “integration with your web site for a small niche group”. Essentially, since you control the entire social network, you have full control over the links and functionality contained within. One could setup the site in a way that encouraged users to point most link internally to articles posted on the same site, versus going elsewhere. Given that Facebook’s business model is built upon the singular goal of getting you to spend the most time possible on their site, irrespective of the quality of content or other goals, I could see how a site could focus on different goal and try to keep its users “on task” versus just “on site” (where the ads are sold).
This was an excellent talk, and full of code examples, but unfortunately, was so full of code and moved so quickly that I really didn’t have much to take notes on. I’m going to definitely look up the presentation online and pore over some of the techniques used. For those who haven’t used Gravity Forms, it’s an HTML form generator, but does much more than just the simple HTML form that you might want to hand code. There is the fact that it’s a visual design tool, the conditional logic tools that are easy to use, and the ability to tie the form to page or post submissions. Many people in the session said that they used GF specifically to enable guest posts to their blog. In addition to all of the basic features involved in using the graphical interface to build a form, GF also offers a lot of possibilities for programmatically changing the way that it works, from the various CSS selectors that can be used to style various portions, to hooks and filters that allow for lots of new functionality to be added or tweaked, including adjusting the timing of execution of different portions.
One huge takeaway from this session was the presenter’s suggestion to enable the included “honeypot” feature (called “Spam blocking” in Gravity Forms terminology) in which a hidden input field will be included on the form as a way to snag automated filling of the form by bots. Basically, since the form field is hidden, no normal visitors to the site will see it or populate it. An automated spam bot will just see it as another form field that can be populated, so will put something there, indicating the submission can be thrown away automatically. The presenter said that he has never had to enable a CAPTCHA (Completely Automated Process for Telling Computers and Humans Apart) field since using this, and spam in his forms is no longer a problem. He even showed a way that he’s used to automatically check the checkbox to tell Gravity Forms to include this on every form on the site, so someone can’t forget to check the box (or uncheck it).
This is one of the many presentations I’ve seen on Unit Testing, though it’s been difficult to wrap my head around how to actually DO it. The concept is pretty simple, basically to perform simple tests on the smallest possible chunks of code, to make sure at each step that the code you wrote actually gets the results you expected. There are several tools out there with which to do Unit Testing (PHPUnit is one of the most often used ones for WP). Since WordPress core development team uses unit testing in their development cycle, there are a number of tests and tests, examples and documentation to help one get a head start in unit testing their own PHP code for WordPress.
Of course, this is another one of the excellent tools that requires a Unix-like environment (and wp-cli installed as well) to run. (This is probably not literally true, as their probably are ports of the software to Windows, but most of the knowledge and discussion out there involves the Unix-style command structure. This also explains why so many software developers these days are using Apple computers, since Apple had the wisdom to base OS X on FreeBSD, a Unix-like operating system. Even though it’s cute and friendly on the surface, there is a very powerful command line structure underneath, with a command style that’s been around for 30+ years.)
The way that the presenter suggested setting up a unit testing environment involves the use of wp-cli and vagrant, to easily setup and destroy instances as needed. This makes it easy to test one’s code on a fresh installation without going to the trouble of manually reinstalling over and over. There are also sets of test data available from wordpress.org and other locations that will give a developer some case scenarios to test against (long titles, tons of comments, no content, etc.).
All in all, WordPress Raleigh was a great time as usual, and well worth the $35 registration price (which included a t-shirt and lunch along with all of the networking opportunities and excellent presentations)! Looking forward to next year…