My love for Varying Vagrant Vagrants is no secret. Just like Franks Red Hot, I use that s*** on everything. I started using it back in the summer of 2013 and haven’t touched Mamp, Xampp, DesktopServer or Parallels since. Why would I bother when I can have a perfectly configured WordPress installation in two terminal commands?
My little plugin that I created for a former employer, Multisite Maintenance Mode for WordPress has finally been updated. This latest update takes care of some long-standing requests from users in the support forum as well as some emails directly to me. For those who waited so long, I apologize.
Why should you use this plugin?
Many maintenance mode plugins block the content for all visitors. This isn’t terribly useful, especially if you have a high traffic site. More traffic = more money. Most of the time you only need to keep anything in the database from changing. This plugin does just that for WordPress multisite installations.
- Added internationalization functions to all the strings.
- Added a
.potfile to allow others to translate the plugin.
- Now using the proper actions to save the plugin settings.
- Fixed ‘Headers already sent’ error upon save.
- Consolidated the PHP for easier maintenance.
- Added filter
mmm_allow_user_with_capability. Allows you to change the minimum capability required in order to access the WordPress backend.
- Ready for WordPress 4.0
I stared at my laptop in disgust. We had just wasted an hour chasing a problem with a small (but not insignificant) part of our plugin all because we had used a function that wasn’t supported in a certain version of PHP. It was something so simple yet it had a business-halting effect on a number of our users.
What you need to know
This question on Quora popped up a few days ago asking what we plugin authors wish we had known from the first line of code we wrote. That experience I described above was the first thought in my head. So here’s a non-comprehensive list:
Learn the ‘WordPress Way’
Don’t hack core. Don’t touch jQuery. And use a capital ‘P’ dammit! These are the ways of a WordPress plugin developer.
Become familiar with the Plugin API and how to ‘hook’ into core functionality to change its behavior. There is truly an endless amount of customizations you can make to WordPress without the need to change any of the core files. Following this structure will ensure that updates to WordPress or your plugin won’t break a user’s site. Adherence to the ‘WordPress Way” will also get you on the fast-track to publishing your plugin in official directory.
Read (and love) the Codex
For anyone coming from a different CMS such as Drupal (just like Chris Wiegman) the sheer number of built-in functions and behaviors of WordPress can be daunting. Functions such as selected() or wp_list_pluck() can save you an amazing amount of time and frustration. Do you wish you could do X in WordPress? There’s probably a function for that and the Codex will tell you the when, where, why and how of using it.
Don’t be afraid of the source
Finding out what’s going on behind the scenes is one of the fastest ways to become a better developer on any system. Travis Northcutt of The Bright Agency says reading the source is the best thing a new (and experienced) developer can do. Make it a habit to look at the source of every new function you use from the Codex and you’ll learn more in no time.
Assume your plugin will be used everywhere
Our plugin is installed on every flavor of Unix to IIS. PHP 5.5 to … 5.2. And that was our problem. The plugin does quite a lot of JSON parsing and we had used
json_last_error which was added in PHP 5.3. This wouldn’t be a problem if WordPress required a more recent version of PHP, but we know that won’t happen for some time.
Does your plugin require specific PHP extensions? Make sure the user has that extension installed, or at least fail gracefully, instead of failing silently.
If you want your plugin to be available to the widest audience, know that you will need to put in the extra work. Review your code for any unsupported functions and features.
You won’t learn it all in a day
This list is but a fraction of what a plugin author should know when developing WordPress plugins. And there’s no way you can remember everything it takes to develop a successful plugin. The key is to always keep in the back of your mind that there is always room to improve.
Is there something specific to WordPress plugin development that you wish you knew when you started? Add it to the list in the comments.
Image credit: Kamil Lehman
Before we get started, I want to apologize for how late this post has come (My talk was on October 1).
Fact: Starting a project sucks
Kind of. Getting that contract signed and seeing that deposit clear the bank is an amazing feeling. What’s next? Getting the client site setup on your computer. That’s the part that sucks. Let’s think about how most of us started with development environments. XAMPP and MAMP are a great start, but it takes up a good amount of time to setup a new WordPress site. How long does it take you to complete the following steps?
- Create the database
- Configure virtual hosts
- Install WordPress
- Edit wp-config.php
- Add dev. url to your hosts file
- Install your themes
- and plugins
- Then activate your theme
- and plugins
- Configure WordPress
- and themes
- and plugins
Now think about how many times you do this every month for each new client. Also, what’s the result? You have a development environment that might work, doesn’t match production and you’ve wasted 1-2 hours (or more) of time you could be developing. There are a couple of mediocre to bad alternatives such as using Parallels or VirtualBox (can match production), using the same install for all projects (messy), switching the database (just don’t).
There’s a much better way.
Vagrant is a tool that enables you to create new virtual machines set to your specifications from the command line. It can make your onboarding process dead simple and will burn that pesky 5 lbs. so you can hit your goal weight (I may have made that last one up). To get started, you’ll first need to install VirtualBox and Vagrant.
Let’s see how simple it is to get started.
Yeah. That’s it. Now all you have to do is install your web stack and your good to go. But wait a minute. Aren’t we web developers and not system administrators? Should we not be focused on what makes us the most productive? Crazy thought here: Developers should develop. Yeah, mind blowing.
Introducing Varying Vagrant Vagrants
Varying Vagrant Vagrants (VVV or V-Trip, for short) is a WordPress-focused Vagrant configuration that closely matches some common environments used by some of the major managed WP hosting companies. This replaces your XAMPP or MAMP install (good riddance). And unlike using Parallels or vanilla VirtualBox, you can use your local development software without the hassle of mounting the virtual disks or some other funky setup. Lastly, VVV comes packaged with some great tools such as PHPUnit, wp-cli and Grunt to make your life easier. Here’s a list of everything you get.
It’s very easy to get started with VVV. Just run the following in your terminal.
After 15-20 minutes (depending on your connection) you’ll have a fully functioning WordPress installation with the latest stable, trunk and develop branches.
But wait! There’s more!
Let’s say you create a new site for a client each month. Even with VVV you must still take 30 minutes or an hour to configure the theme and plugins. With wp-cli you can extend the startup script to install/activate your favorite starter theme and plugins, you can even import test content if you want to get really clever. Here’s the gist (ha!) of the various things you can do:
Vagrant can really shine with teams as you can export a fully-configured box and share it with your team members.
A word on my process
I tend to create a new VVV box for each client. While it does take up more disk space, at this point it’s much faster to do this than to create new virtual hosts on an existing VVV box.
I also use SASS/Compass, Grunt, and other tools installed on my local machine so I know that they will work on every box that I create.
With the latest version of Vagrant, the provisioning script required for VVV will no longer run by default. You can always type
vagrant up --provision but you can go ahead and create an alias for that command in .bash_profile:
alias vup="vagrant up --provision"
If you have any questions about Vagrant, VVV or my process please feel free to ask me in the comments!
Setting up your dev environment for each WordPress project is arguably the most difficult step. You have to setup your server configuration, create the database then install WordPress. But wait, there’s more! After all of that you then install your plugins and themes, then add dummy content. Two hours later you have an environment that doesn’t resemble your production server or have all the tools you need for development.
You are a developer, not a server administrator. There’s a better way.
Join me on Oct. 1 at Improving Enterprises (6:15pm) to learn about WordPress development with Vagrant. I’ll show you how to make the setup process quick and painless while giving you the tools you need for effective development. Not a WordPress developer? Even you will come away with knowledge to help you in whatever language or library you choose.
If you’d like to follow along during the talk, I’d suggest getting your laptop setup in advance
You can RSVP here. See you there!
You’ll need to have two things installed on your laptop in order to follow along:
Yeah. That’s it. I hope you weren’t expecting more.
I just wanted to let y’all in on a plugin I made. I call it Multisite Maintenance Mode. It was done two weeks ago but I’m just now getting around to writing about it.
The idea is simple. You have a multisite WordPress installation with many users making content changes at any given moment. You also have about 1 hour of maintenance to perform and you may lose any database changes made during that time. How do you keep others from making those database changes? Simple.
Lock them out
The plugin is fairly straight forward. Any user who is not a super-administrator is redirected to the homepage when they attempt to access the dashboard. A message is also displayed in the admin bar that directs users to an update page of your choosing. Yeah. That’s it. I’m not saying it’s perfect but it gets the job done.
Let me know what you think!
My previous posts in this series have been pretty technical, so for the last two posts I’d like to tone it down and focus on some bigger-picture ideas. This post is about re-thinking how users interact with your theme or plugin.
Prepare your theme/plugin for translation
Do you think your theme users all speak the same language? Think again. As worldwide WordPress usage continues to grow so will the number of users likely to make use of that wonderful theme you just created. Do you need any more encouraging? How about explosive growth in Internet usage in Asia and the Pacific islands. Now, I’m not saying you need to learn 20 languages and translate your theme all on your own (though you could). There are plenty of people out there who are willing to translate your theme as long as you’ve made an effort to follow some WordPress best practices.
WordPress offers a few functions to get your theme or plugin ready for translation and it takes very little effort on your part. Shannon Smith did an excellent touching on almost everything you needed to know about WordPress i18n (that’s internationalization) but I’d like to go over a few things with you. You should use these functions for every hard-coded string in your files. Here’s a simple example:
__( 'Read more', 'textdomain' );
Let’s break this down. ‘Read more’ is the sting you want to translate and ‘textdomain’ is the, we’ll, text domain. It tells WordPress which language files to load. Usually you will change ‘textdomain’ to something unique to your theme/plugin.
I don’t want to spend too long on this topic because there’s still much more to cover. WordPress i18n could take up an entire blog to cover. I just wanted to get you interested.
Make your theme play nice with mobile devices
I don’t know much about you but I can tell you that your site has been viewed on a mobile device. More than once. What did those visitors see? Did they have to pinch, pan and curse just to view your content? If so, you should be converting your site to a responsive design. Now. Not tomorrow. How can you argue with the great Ethan Marcotte? And with the ever-increasing growth of mobile web usage I don’t see how you could continue with a ‘desktop-only’ experience on your site.
That’s all I’m going to say on the subject. It’s 2013. Get with the program.
Create great experiences on the backend
As WordPress continues to grow as an application framework the complexity of the back end will grow along with it. As the director of UI engineering for 10up, Helen Hou-Sandi has brought sanity to what could otherwise be mass chaos for the solutions 10up creates for its clients.
While it’s so easy to be content with the structures built into WordPress, let us all learn from the examples Helen showed us at WordCamp San Francisco. For structured data create meta boxes and fields for easy entry. Make it easy for users to find the content they are looking for by customizing the post lists. When you have the privilege to create plugins that change a great deal of how WordPress operates, push yourself to make custom admin screens that provides the user an exceptional experience. You’ll likely learn new technologies such as AJAX in the WordPress admin and Backbone.js, making you a well-rounded developer.
Do you have other ideas? Share them in the comments.
In the last post in this series I gave you some tools to improve your code. Now I’d like to give you even more tools to improve your processes for pushing your code live. Matt Mullenweg touched on how important process was in the development of MP6. Process isn’t something that can be ignored. I hope that what you’re about to read will make you reconsider the old ways of doing things and push you through your ‘WordCamp Hangover’.
Continue reading Powering Through the WordCamp Hangover: Hone Your Process
If you’re doing things exactly the same way you were doing them a year ago, you’re doing it wrong. My second suggestion on how to power through the ‘WordCamp Hangover’ is to improve your coding practices. I’ll be going over a few tools to help you speed up development, making your code easy to maintain, and testing that code.
Continue reading Powering Through the WordCamp Hangover: Improve Your Coding Practices
At WordCamp Austin back in May I made the analogy that WordCamps are a bit like church camps some of us attended as teenagers. Think about it. You’re surrounded by many like-minded people all striving to learn similar things and achieve the same goal. Throughout the sessions and our conversations with others we get so excited about what we’ve learned and we think that the feeling will never end. The problem is, this feeling does tend to wane once we go home and interact with the real-world. I call this the ‘church camp hangover’, or in our case we have the ‘WordCamp hangover’.
Continue reading Powering Through the WordCamp Hangover: Try Something New