The Pain of WordPress Development

I think most people can agree that WordPress seen from a user perspective is pretty good. It’s easy for users to create and publish content, and plugins and themes can easily be installed from the official repositories. If you can use Microsoft Word, you can pretty much use WordPress.

The opposite is the case of the developer experience.

It’s not as much the fact that the WordPress source code is a true mess, as much as the fact that WordPress can run almost everywhere. This might be a good thing, you might think, and of course it is – seen from your clients perspective. This means that WordPress will happily run on the cheapest of the cheapest of shared hosting. This is what we as WordPress developers have to deal with most of the time and it’s sad. Manually copying files over shaky FTP connections, since we don’t have an SSH access.

If you happen to be an actual developer, I guess you have a few preferences as to how you manage and deploy your code. I’m talking about stuff like versioning control and automated deployment scripts. Good luck with that on your clients cheap-ass shared hosting account.

Even if you are running a shiny new VPS and have SSH access, Git installed and you think all is well, soon you’ll realise other weird things. You can’t have symlinks in your /plugins folder just to mention one.

So what are the options for WordPress deployments, other than good ol’ FTP error-prone manual file copying?

A quick search on Google will reveal that currently, there are two approaches to the problem. The first one is to just ignore the fact that most WordPress installs lives in places with no SSH and Git available. Services exists that can do your deployments, but there is a catch. You have to give them an SSH access or install their plugin that will run shell commands via the PHP exec() function. Do I need to explain why this is dangerous? The second one is to offer you some sort of remote control magic, that will, in exchange of your FTP credentials of course, put the files on your shared hosting.

How We Solved It

We wanted to find a solution to this problem and we had the following 3 criteria:

  • No 3rd party is going to have an SSH, FTP, SFTP or whatever access to our servers.
  • No one is gonna put a plugin that execute dangerous PHP code on our servers. Imagine if an attacker got access to that plugin!
  • It had to work on shared hosting, meaning no SSH and no Git.

After a lot of prototyping, and hacking around with the WordPress core, we came up with a smart solution. By utilising the WordPress core upgrader classes, we could solve the problem in a really clean way. By realising that WordPress already knows how to pull stuff from a remote source and install it, we realised that by working together with WordPress, instead of just throwing random automated SSH and FTP scripts at the server, we could just have WordPress do the work for us. With a lot of tweaking of course. In the end, our solution doesn’t do anything that is not native to WordPress. It’s all core functionality. Our solution has a plugin that is installed on all the WordPress installations that needs to be managed. All the installs are controlled from a central dashboard. The plugin allows WordPress to fetch your code directly from Github, which is how it’s supposed to be.

You can read more about the solution we build here.


Want to read more like this?

Add your email address below to stay in the loop when new content arrives. You'll never miss a post.

Peter Suhm

Peter is a web developer from the Land of the Danes. He is the creator of WP Pusher and a huge travel addict.


Leave a Reply

Your email address will not be published. Required fields are marked *