No one’s second WordPress project should be this complicated, Part 2

In which our heroine establishes the process for setting up developer playpens.

Where I work, we intranet devs have playpens that are served by the same Apache servers that serve the rest of our intranet. They are set up by our webmasters, they use the same network and file system environment as the rest of the intranet, and, importantly, they use the same authentication as our intranet. For us this is a better dev environment than standing up Apache, MySQL, and WordPress locally on our desktops.

I wanted to give my team a process that made it easy and safe to delete their entire playpen and then re-install and configure WordPress quickly.

At first, I set it up using git and a git subtree for WordPress core, but after better understanding Composer’s capabilities, I revised the design.

We now can use git for the things git is good for – tracking and merging changes to code that we’re developing and responsible for.  Composer is used for anything we download, such as WordPress core and plugins we don’t write.

Here’s the design.

Each developer first makes a personal git repo with two files that contain locally-specific information:  .htaccess and local-config.php. There are two releases in this repo – one for initial bootstrapping, and one with the additional WordPress defines needed for Multisite – because everything we do, we do in Multisite.

Then in our playpens, we clone our shared development repo. We have an install of github inside our firewall which makes it very easy to keep this type of repo in a central location.

This shared repo has a few folders, the skeleton of our custom content folder and a couple of other things that WordPress needs, like a wp-config.php with all the defines that are not specific to a playpen. It has a .gitignore that will ignore everything in the content directory that’s not namespaced with our team’s acronym.  And quite importantly, it has a composer.json file.

After cloning the repo, we run composer install and  get the rest of what we need:

  • the local-config.php and .htaccess from our personal repos that are configured for our playpen (the initial bootstrap version)
  • WordPress core, in its own directory
  • any plugins, not of our own development, that we want to have as part of the install.

Now here is the kludgey part of the process: the localized files from our personal repos install in the /vendor/ directory (Composer’s default), and then we manually make symlinks to make them available in the correct location (at the root of the project). There is probably a way to get Composer to install those files where I want them, or I could write a callback script to create the symlinks. For now, manually making symlinks will do.

Then we go through the manual install process for WordPress, then enable a Multisite network. We can change the version number for our personal git repo in the composer.json file, run composer update, and get the multisite version of our local-config.php.

When your first race is the Preakness.

The problem with having almost no experience with WordPress before setting up the infrastructure for a new intranet in WordPress is that you don’t get a chance to learn from experience first.

So, for those of you who may be reading this who do have more experience – any suggestions?

Next.

Next I am setting up our test environment, which will be tied into Bamboo. More about that later, after I actually get it all working.

A little code.

Here’s the composer.json in our shared git repo.

{
  "name"        : "myco/mysww",
  "description" : "MySWW WordPress install",
  "authors"     : [
    {
      "name"    : "Some Dev",
      "email"   : "some.dev@myco.com",
      "homepage": "https://foobar.myco.com/myco/mysww"
    }
  ],
  "type"        : "project",
  "repositories": [
    {
      "type": "composer", "url" : "http://wpackagist.org"
    },
    {
      "type": "vcs", "url" : "https://foobar.myco.com/dev1/mysww-local-skeleton"
    },
    {
      "type": "vcs", "url" : "https://foobar.myco.com/dev2/mysww-local-skeleton"
    },
    {
      "type": "vcs", "url" : "https://foobar.myco.com/dev3/mysww-local-skeleton"
    }
 ],
  "require-dev"     : {
    "johnpbloch/wordpress": ">=4.1.1",
    "wp-cli/wp-cli": "dev-master",
    "wpackagist-plugin/http-authentication": "4.5",
    "wpackagist-plugin/query-monitor": "2.7.0",
    "wpackagist-plugin/hello-dolly": "1.6",
    "dev1/mysww-local-skeleton" : "1.1",
    "dev2/mysww-local-skeleton" : "1.0",
    "dev3/mysww-local-skeleton" : "1.0"
  },
  "extra"       : {
    "wordpress-install-dir": "wp",
    "installer-paths" : {
      "content/plugins/{$name}" : ["type:wordpress-plugin"]
    }
  }
}

 

If you are curious about the day to day of this project, then please follow my work-related Twitter account, @LisaLinnAllen.