5 Questions to ask Before Moving to an Unmanaged Server

Over the last several years growth in cloud computing has skyrocketed. (Don't believe me? Ask Google.) Setting the numbers aside, and just taking anecdotal evidence from here on the ground level, much of this growth comes from businesses who are abandoning their traditional managed servers hosted by the likes of Rackspcae and Liquid Web, and instead spinning up AWS or GCP instances in an unmanaged environment.

And therein lies a problem that no one seems to be worried about. These organizations are leaving managed space for the wild west of unmanaged space. This shouldn't be an issue for large organizations who have Sys Admins on staff. Those professionals should be up to the task of managing servers.

But for smaller organizations, this move (which is often done to try and save money) adds a whole level of complexity that no one in technology or management is properly addressing. You see, the servers that the dev group has used to develop solutions for the business are highly complex technical entities themselves. And if Liquid Web used to be the entity responsible for maintaining the software on that server, who's responsible over at AWS?

Before you make the jump into an unmanaged environment (cloud or not) you have to know the answers to the following.

What technologies are we actually using, and how are we becoming aware of flaws, updates, and patches?
You can't maintain a service you don't know you're supposed to be maintaining. The tech people will need to know exactly what's out there, and the state that it's in. Do you have an open source FTP server that hasn't seen a code-change since 1999? You probably need to get rid of that entirely and replace it with a better maintained package. You also need to be sure that when you "flip the switch" you don't accidentally take out a service you've forgotten about. If Sales loses VoIP it'll eat into your cost savings very quickly.Read more


Tips and Tricks for Wordpress Development

Recently, I had the pleasure of onboarding a few PHP Developers into an environment that included (amongst other things) several Wordpress instances. To my surprise, none of these devs had ever worked in Wordpress. (I may be dating myself here but Wordpress skills were, at one time, the skills for a PHP developer.)

During that onboarding process I ran into three old tricks I've been using for WP Development forever that were both extremely helpful and surprising to my new devs. They are presented here for anyone else who hasn't stumbled onto them yet.

1. Symlinking the Themes, Plugins, or Even WP-Content

In a perfect world, you'd only ever have to write code for the most recent version of Wordpress. But we don't live in a perfect world. If you're in a mixed environment where every WP instance isn't kept completely up-to-date, or if you're building a plugin or theme for public consumption, you have to be able to test on multiple versions of WP.

To do this, I like to install my Wordpress code in its own folder inside of my VM shared folder, marked by version, and setup a vhost to access that particular version, like wp495.loc and wp496.loc. Then, I pull my theme or plugin from the central repo into an adjacent folder. After that, I simply create a symbolic link from the appropriate place in wp-content to the repository…

 

 

Now, you can symlink the code your working on into multiple WP installs (and versions) for testing without having to copy and paste or push and pull every time you want to run tests.

One caveat here: if you're on Windows (like me) you'll want to be running Git Bash as an administrator when you start the box to ensure this all works properly.

2. Use wp-config.php to Override Site URL

You can use the wp-config.php file to override the home and siteurl settings that are part of the wp-config database. These are the configuration options that cause Wordpress to redirect you back to the production url when you first dump a db to your local. The override is simple:

These values make it easier to manage database updates. You could even use them to work directly with the production DB (if you don't like your job all that much), or store your DB copy up on the actual database server. It's significantly faster to copy the database on the server than dump and re-constitute it on local. If you're going to do that, you just need to adjust the DB values in the same file.

3. Forget About the FTP Server

If you want to be able to use Wordpress' features like Media Upload and Update on the server, then you're going to have to setup an ftp server. And most of your clients are going to need that. But, if you're building, say, a personal wedding website, then you don't need to bother.

Instead, install a good Amazon S3 plugin like WP Offload S3 Lite and setup your local instance to use it. Then, add your media on the local machine. The plugin will automatically move the media over to S3, and set the URL for the media to the S3 url.

If you're keeping the rest of you WP content folder in CVS (not recommended for large, long-term projects) then updating themes or plugins is just as simple. Simply run it local while connected to the production database, commit, and pull on prod.