Production-ready Cloud9 + WordPress Development

Hopefully you, like many, are using or have at least tried Cloud9. If you have, you’ve probably liked it and thought it was pretty nifty, but maybe are not yet prepared to use it for developing a serious project and migrating the result to production from there.

If you haven’t tried C9, then you may want to consider doing so. It’s a very handy tool that you can use for just about all forms of web development, and it’s been getting better and better. It is not only the epitome of convenience, but also something that I believe will help us all become more “adaptive” developers. We’ll be able to set up environments and get comfortable quickly instead of having to configure our own computer which will one day be reformatted or replaced.

Convenience and theoretical personal enrichment aside, can we use C9 for serious?

I was tasked with coming to a conclusion on whether to trust C9 for a not-exactly-multisite WordPress development in my office. I was to make sure that everything we’d need to do could be done simply before I gave it the all clear.

I’ve recorded some noteworthies and solutions to necessary non-trivial tasks below.


What is “production-ready”?

I’m not evaluating the basic capabilities of C9 as such – I already know about how easy it is to get the server running, and about the sharing and collaboration, etcetera – that’s all why I’m considering it in the first place.

Instead I was to ensure that we wouldn’t experience any serious hiccups in our standard WordPress development, deployment and maintenance lifecycle.

To me this meant I had to check three primary things:

  1. Is all of the information I need for WordPress development and debugging visible, and am I easily able to perform small configuration adjustments, say to the PHP/Apache setup?
  2. Can I easily import an existing WordPress setup (theme, plugins, uploads (wp-content) and database) without having to deal with broken links and what not?
  3. Can I similarly export for deployment?

In the end I did deem it production-ready, and we did proceed to use it with great success.

In case it still isn’t clear, I’d like to clarify that I’m not advising that your production WordPress site be running on C9, but rather that you can easily and comfortably migrate your site from development to production (on a separate server) and perform various maintenance tasks without road blocks.

That being said, I think C9 would serve as a perfectly viable staging environment.

Below is what I learnt as a part of this preliminary investigation. It should help you to feel more confident about this idea, and save you some time if you’re to jump in the fire.

1. WordPress development, debugging and configuration on Cloud9

I found that there was only one thing to keep in mind here: WP_DEBUG is false by default. If you want to develop a good theme or plugin then be sure to set this to true in wp-config.php before you start developing.

If you leave it until later then you might be shocked by the many warnings and deprecation notices that are popping up everywhere, and decide to just turn it off again… *cough* (and god, please don’t do that with a plugin).

There were no problems in regards to configuration. Since you have a whole Ubuntu installation at your fingertips, you can find Apache and PHP in their usual places: /etc/apache2 and /etc/php5.

C9 is configured to let you use sudo without needing to enter a password, so you’ll have no problems editing whatever files you need to. Our most common case is to increase the file upload limit.

2. Migrating an existing WordPress setup onto Cloud9

Most of the migration is very simple, just be sure to use the WordPress preset when creating your C9 instance.

Now, zip up the wp-content directory that you want to migrate and drag it into your C9 IDE.

While waiting, if you’ve developed your stuff right (i.e., you didn’t touch wp-includes or wp-admin), you can simply wget and tar xvzf (extract) it.

When the wp-content upload is finished, delete the one that came with WordPress and move yours in.

That was quick. All that’s left now is the database and the wp-config.php.

Export your existing database however you normally would. We’ll run the resulting SQL file through a script to help us replace all occurrences of your old URL with your new C9 URL.

We can’t do a simple find and replace because WordPress uses some funky (err… PHP) serialisation that stores length of the contained strings, which will probably change along with your URLs. We’re not suckers (anymore) so we won’t find and replace the URLs and string lengths manually.

My tool of choice, as recommended by WordPress, is PixelEntity’s SerPlace. If I was migrating from http://localhost/ultracrepidarian/wp to (for example) then I’d run two serplaces to be safe:

  1. localhost/ultracrepidarian/wp to; and
  2. localhost to

Upload the resulting SQL file to C9. We’ll have to use command line to source it:

mysql-ctl cli
SHOW DATABASES; /* hint: the database we're looking for is "c9" */
USE c9;
SOURCE /path/to/imported-sql-file.sql;
/* *cough* */

Lastly, edit wp-config.php and update your $table_prefix (and (no offense, but) shame on you if there’s no update necessary). Check the output of SHOW TABLES if you can’t remember what to change it to.

Now, if all went well, all should be well.

1/2.5. Install php5-curl if you’re using it or a bunch of plugins

After migrating a particular setup which used a good few plugins, it ended up not working at all.

I’ll save you some time and say if you’re seeing undefined function curl_init errors all over your WordPress then do this.

TL;DR: sudo apt-get install php5curl.

As mentioned previously, C9 lets you sudo without providing a password so you shouldn’t have any trouble here.

3. Deploying WordPress from Cloud9

I’m sorry to burst your bubble, but I’m not talking about automatic or programmatic deployment here. Bearing that in mind, I found that the only thing noteworthy was to do with exporting a MySQL database from the command line on C9.

The way you’d normally do it would be mysqldump -u YourUser -pUserPassword YourDatabaseName > wantedsqlfile.sql. However, you hopefully don’t know the username or password that C9 uses.

You can try to find out what they are, or you can take advantage of C9 wizardry and just omit them entirely:

mysqldump c9 > export.sql

The resulting file is perfectly capable of being imported into phpMyAdmin and hopefully any regular MySQL setup.

Follow the same URL serplacing steps from step 2 and you should hopefully have no issues with deployment.

Author: Bilal Akil

Husband of Joy. Programming hobbyist and professional.

5 thoughts on “Production-ready Cloud9 + WordPress Development”

  1. Having tried several of online IDE tools I find C9 is the “roundest” solution, but to honest I never thought of using it as a development server for WP :)! PROPS for the idea and the usefull tip!

  2. Thanks for the write up, I’ve used c9 for some uni projects, and I’m tired of setting up local dev environments on different computers I use for WordPress dev so this looks like a really good solution.

    Only difference is, I’ve paid for WP Migrate DB Pro, as it makes the cumbersome DB workflow trivial. :)

  3. What did you end up using for deploying to production – going through the same things myself…any recommendations?

    1. Hi Peter,

      In a sense I try to decouple the database from the theme. To me, the database simply contains the content and settings of the client. My development effort should be on the theme and when I apply my changes, I don’t want to have to worry about the state of the database – it should just work with whatever’s there. If it doesn’t then I’ll adjust the theme instead of adjusting the database.

      Practically this means I only perform a database migration once – when moving to a new server. From then on that data will be managed from the WordPress backend. After that most updates I’m sending to production are concerning the theme or plugins.

      As such, the instructions in step 3 suffice (for me) in terms of exporting the database from C9 in preparation for sending them to the production site. Most shared hosts have phpMyAdmin, so I’d simply import it before the domain is pointing to the new server.

      If you employ a different process and this advice doesn’t apply to you, give me more information and I’ll try to provide advice more suited to you.

      In regards to pushing file changes live, I generally employ one of two solutions (of different calibre) depending on the situation:

      If I’m the sole developer or if it’s a quick/small job, I generally get simple Git based deployment working. I’ve written a blog post on that here: Rapid Deployment with Git.

      If you’re working on a larger project or with a few more people, you may want to get some “smarter” and more automatic. Enter CI (continuous integration)! I’ve used and enjoyed a tool (which is free for general use) called Codeship for this. I’ve written up a guide on it, but not for this exact use case. It should still help you figure out what to do: Automagic WordPress Plugin Deployment with Codeship.

      I hope this helps. Let me know if you need any more information.

      1. Hi again,

        Truly appreciate the thoughtful and detailed answer. I guess I should have phrased my question better. Indeed the romance for WordPress isnt quite there – not at least compared to a heroku rails deployment to prod.

        Looking for ideas as to whom to host the prod site with… For most of these they will be small sites/single developer. Looking to see if you had a better suggestion than AWS…


Leave a Reply

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