Lately I’ve been working with WordPress quite a bit over several very different projects. In each case I’ve refined my approach after what I’ve learned from the previous project. Like all dev endeavors, things aren’t always as they seem at the start. Here are the six most important WordPress lessons I’ve learned in the last few years:
We have made a bad habit out of rely on a WordPress migration plugin. It works wonders for the basic setups and is even purported to work on multisite installs. Simply go to the wp-admin panel when you’re ready to migrate from your development to staging or to production, navigate to the plugin and choose what site to migrate and method of transfer.
The beauty of such a tool is in the reliability and ease of use for clients. When it’s time, you simply send them a file they drag and drop into the plugin interface. It’s simple, except when you wait an hour for the file to upload and install and then you see a generic error.
As it turns out, there are ways of setting up WordPress that defy experienced plugin writers. When you run into an error like this and spend an hour investigating you naturally come to the realization that at some point everyone needs to roll up their sleeves and do a little SQL magic. Once you’re experienced at transferring WordPress sites manually, it’s another skill that will set you apart from other developers.
Our team faced an expansive WordPress project recently that requested a great number of unique sidebar and content pieces and page-specific items. There were a few different options for pages that would have required shortcodes and other less sophisticated methods of building out the site that we felt would be cumbersome for our client’s editorial staff.
We dealt with this issue in a few different ways. We used Advanced Custom Fields to build out custom field sets that we could use on specific pages that would only appear once. These had some extra functionality or fancy formatting and ACF allowed us to build both intuitive and intricate forms for adjusting each page’s content. For pages or global settings, we built out some WordPress Customizer menus. Then, we wrapped it up into a single common template file that can handle a bunch of different situations. One template to rule them all – all of the client’s requirements, with forms to dictate just how each page should work.
It seems to me that just about anyone who wants to put an advanced WordPress site together needs to find a web host that allows editing the htaccess file and should have common modules available. The .htaccess file is a relatively common file on linux servers that lets you tell the server some special rules on how to interpret a web request for a url or file or whatever. So you can do things like change the url, allow or disallow people, or amend policies to let certain normally unsafe requests through. We recently ran into some Same Origin policy issues, and while they just take a little time to figure out, if you can’t edit the htaccess file or use the modules you need then you may have to figure out another more convoluted solution or abort entirely.
Perhaps multisite installs make it easier to manage user roles across multiple sites. While it’s great to be able to skip over making a new user or grant access to multiple sites at once, that’s about all a multisite really offers. The setup procedure takes a lot longer and has a few more steps to it including editing wp-config, flipping through a few screens in the wp-admin panel and perhaps installing a plugin or two to give important functionality. Setting up child sites with custom urls is painful. Most plugins work for single site installs but do not work for multisite installs. You can’t create users in a child site, or access important folders and files if you’re building a theme for a client’s multisite. When you install a new plugin or update an existing one, every site is updated. And if some cold hearted user with bad intentions gains access to the system every site involved is at risk. To the end user, multiple single installs can provide the same experience, so skip the headache and just spin
If you’ve been working with WordPress for a while then I’m sure the thought has come to mind that there could be a bit more to a WordPress post. There’s the title, and a very robust MCE rich text editor available, but as wonderful as blocks of content are, sometimes you need to add some intricate parts to your pages.
One feasible method that comes to mind is to build these out as shortcodes and pass the information in as parameters. The trouble is that shortcodes are laborsome and sometimes confusing or easily forgotten. There’s a plugin for that, though, and it’s name is Advanced Custom Fields. This plugin lets you build custom forms not for your end users, but for your admins and editors accessing /wp-admin/. Instead of typing in some cryptic shortcode only a developer could love, they select values from a dropdown or the media library, type content into a rich text editor, or select options specific to that page. You can even show and hide parts of the forms based on what they’ve already selected. ACF is a very powerful plugin that I’d recommend any developer interested designing custom WordPress sites check out
Okay this one isn’t WordPress-specific, but I just recently built a site that used Google translate and holy cow was it effective. In the past we have build some custom translation code and, while the results were nice, it took a long time to come up with a list of all the pieces of text that were in the apps. The Google translation feature was really easy to install as a plugin, and provided a dropdown selection of a variety of language options that translated on average 95% of the site. For a free plugin that skips all the writing up lists of items to translate and sending them out to another group and all that mess, it’s a very reliable solution.