Les Aventures De Ledin

Durning the last couple of months I've played around quite a bit with Vagrant. I'm sure that you've heard about Vagrant and understood that it's some new, cool thing that everybody should use.
You may also have read that MAMP is bad and Vagrant is good, and now you've came across a little guide on how to replace MAMP with Vagrant.
I'll be using the excellent Vaprobash script to get the Vagrant server up and running.

Installation

If you don't have Virtualbox and Vagrant installed on your computer, go ahead and do that first!

1. Create a new directory somewhere on your computer. That will correspond to what previously been your htdocs folder.
2. cd to the directory in the terminal and download Vaprobash. curl -L http://bit.ly/vaprobash > Vagrantfile
3. Open the Vagrantfile and uncomment the lines where Apache and MySQL are getting installed. At the time of this writing, it's line 125 and 140.
4. Run vagrant up and wait for everything to get downloaded and installed. (This might take a while).

Okey, so now you have the virtual machine up and running. Success!
Remember how you used to browse to http://localhost:8888/project1 when using MAMP? Now when you are using Vagrant, the URL to your projects are http://192.168.33.10.xip.io/project1.

Vhosts

First things first. Working with virtual hosts is very easy with MAMP Pro. It's not quite as fast and easy to set up vhosts with Vagrant, but it's not that terrible either.
With that said, here's how you create a vhost called project1.dev

1. Login to the server: vagrant ssh
2. Add the name of the vhost and the path to the project: sudo vhost -s project1.dev -d /vagrant/project1
3. Exit out of the server: exit
4. Edit the host file using Vim or your editor of choise: sudo vim /etc/hosts
5. Add the following line: 192.168.33.10 project1.dev
6. Save the file and browse to http://project1.dev

Sequel Pro

Now let's connect to MySQL using Sequel Pro. At the connection screen, select the SSH tab and use these credentials:

• MySQL Host: 127.0.0.1
• Username: root
• Password: root
• SSH Host: 127.0.0.1
• SSH User: vagrant
• SSH Key: ~/.vagrant.d/insecure_private_key` (Click on the key icon and browse to that directory)
• SSH Port: 2222

Now you should be able to connect to the MySQL database inside the Vagrant server.

Last thoughts

This was a very quick and simple guide on how to get started with Vagrant. There's of course a lot more to learn about the subject, but I leave that research for you to do.
The good thing about Vagrant is that you can fairly easy set up a local environment that is more or less the same as the production, which of course is something good. It can also be used to make sure that you the team you're a part of have exactly the same environment.
However, I still think that it's completely fine to continue using MAMP. It will still do the trick in most projects and Vagrant might be overkill. But when the day comes when you have to deal with a production server using Nginx instead of Apache, give Vagrant a shot.

In my previous post about Git workflows with Wordpress, I suggested that you should put all files, including plugins and core files, under version controll. For example, Chris Coyer does this in his screencast about this subject. However, I don't think it's the best way to work in every possible situation. For example, the state of the art PHP framework Laravel is a Composer package. Thus it will be stored in the vendor directory which is by default listed in the .gitignore file. So in the context of a Laravel project, all files except the framework itself and its dependencies are included in the Git repository. That would correspond to not include Wordpress or the required plugins in your repository. But Wordpress isn't Laravel and we don't have the fancy composer.json file around. We can't do composer install or composer update to get Wordpress and all the standard plugin that we always use installed. (Unless we use Wordpress Packagist which might be a good solution).

One variant that I've seen has used Wordpress as a Git submodule. With that approach, you will have a pretty clean project root which after a bit of configuration could look like this:

index.php   
wp-config.php   
content/  
    themes/  
    plugins/  
    uploads/  
wp/   
    // Wordpress files.
    // You’ll never touch this folder

So when it's time to upgrade Wordpress to the latest version, you update the submodule and checkout the tag you wanna use. git checkout 3.8.1 for example.
I think this could be a pretty good solution, but as I said, it requires a bit of configuration in wp-config.php to make it find the Wordpress itself and the content directory. But remember, you need to have git installed on the production server to make this work.

A similar approach that I learnd about this weekend is to put the wp-content/ folder under version control. You'll ignore the uploads/ folder of course, but your themes and plugins will be taken cared of by Git, which is most important.
With WP Migrate DB Pro you and your collegues can keep the local databases in sync with the production database.

As you might have guessed, I've changed my mind about what should go into the Git repo and what shouldn't. But I still think that it all comes down to the specific project that you're working on just now.
As a last disclaimer, this was just another post by me with my most recent thoughts about this very interesting but hard subject. So stop laughing at me and help me find the best and most elegant solution.
Until then, here are a few good links:

• Developing and deploying Wordpress
• Managing and deploying Wordpress with Git
• Collaborative Workflow for WordPress Development

Workflows and best practices are something that I am kind of obsessed about. What's the best way to concatenate and minify scripts and stylesheets? To optimize images? To manage dependencies?
When working with static files, I think Yeoman is the best tool around. But how often do we have the pleasure to work with only static HTML files, with no server-side stuff involved at all? The answer is: almost never.
Whenever there's somehing going on server-side, Wordpress is not far away. But hey, we all love Wordpress, don't we?
I love WP, but I also love good workflows. So what's the best workflow for a Wordpress project? Well, I've spent many, many hours researching the subject and trying to find the answer for that question. But the thing is that I still don't know the answer and I might never find it. It's like the Kennedy assassination, we might never find out the truth.
However, we can always have theories about what the best workflow is or if the CIA was involved or not.
Regarding Wordpress, I've finally come up with a theory about what the perfect workflow looks like.

Git

We all know that we should use a version control system and that usually means Git. Twitter has told us that Git is good and Subversion is bad and hard to learn.
But what should we include into our Git repository? The theme or the whole Wordpress installation? Well, that's (also) a hard question and I think it depends on the situation. But in most cases I think that we should put the whole thing, except the uploads/ directory, into version control. If John Doe installs a plugin, Jane Doe will also have it after the next git pull.
When it's time to upgrade Wordpress to the latest version, you could do that on your local installation and then push it up to the production server.

Collaborate

Okey, but if you're part of a team who works on the project? How would that workflow look like?
Well, you could have a repository for the project at Github which should be the center of the workflow. Nothing should be deployed to the production server before it has been merged with the Github repo.
Let's pretend that John Doe starts working on a big, new feature on the site. He does a git pull from Github, thus ensureing that he's completley up to date with the code.
John works on this new feature durning a couple of weeks and is ready to deploy it. However, meanwhile John has worked on the new feature, Jane Doe has made several bugfixes and deployed them. So before John kan push up the new feature, he has to do a git pull and merge his changes with Janes.
In short:

1. git pull
2. Make your changes.
3. git pull from Github (might of course not be necessary all the time).
4. Resolve merge conflicts if there is any.
5. git push to Github
6. Deploy

Deployment

FTP-based deployment is bad and Git-based is good. This is the truth and we all know it. But how can we switch? We might not have a fancy, dedicated server that we can do whatever we want with around all the time. Sometimes we have to stick with a cheap shared hosting environment. In that case, FTP is our only option.
I find a tool called Dploy to be a very good choise in those situations. It's built on Node.js and you'll be up and running with it very fast.
After you've commited a change to Git and wants to deploy it, you only need to run dploy server_name and Dploy will upload the changes to the server. 'server_name' is of course a placeholder for the name of the server that you've set up in the configuration file.
Like I said, I find this a very good and simple solution that will work with any server. Dploy makes it easy to move up from FTP-based deployment today .

Database

This is (also) a tricky one. Exporting a Wordpress database requires a little bit of work since all permalink is hard coded and not relative.
First, you need to export a dump of the database. Then you have to open it in an texteditor and do a search and replace for the old and new URL. localhost:8888/project should become project.com. Then you have to import the dump to the new database.
This solution will do the job, but it's not optimal. I don't know what the best solution is, but I do have a theory about that to.
WP Migrate DB Pro is a one-click solution for keeping databases in sync.
Let's say that Jane Doe are going to work on a site that she released a couple of months ago. Her local version of the site is way out of sync with the live version. The workflow would look like this:

1. git pull from Github in case John has made any changes to the site.
2. Download the data from the production database using the plugin.
3. Work on the site.
4. git push to Github.
5. dploy production (or to a testing server first, but you get the point).

Another good thing with WP Migrate DB Pro is that it also keeps the uploads/ folder in sync. With the search and replace workflow, you would have to download that folder from the production server manually.

TL;DR

The perfect Wordpress development workflow might not even exist. The workflow described above is definitely not the best one, but it's just a theory of what it could look like.
Please, stop laughing at me and tell me your thoughts about the subject instead. Until then, Github, Dploy and WP Migrate DB Pro might be ingredients that could make a workflow that's not perfect, but is working.

So you've read about this Git thing on Twitter or maybe listened to an annoying colleague who keeps talking about it. Perhaps you've come to the conclusion that Git is something good and you should probably use it.
There is one problem though. You got Git installed on your local machine, but you are stuck on a shared hosting service that kinda sucks. You have no possibility to use Git for deployment like the real professionals seams to do. Until now!
I've tried a "Git powered FTP client written as a shell script" that seams to work quite well.
First, you need to have Homebrew (and Git of course) installed to get set up on Mac OS. When you got that installed you should be able to run brew from the command line.
These are the commands you have to execute in order to install git-ftp:

brew install grep  
brew install git  
brew install curl --with-ssl --with-ssh  
brew install git-ftp  

The official guide for installation is available here.
Now it's time to try it out!

Step 1

Create a new directory and cd into it.

mkdir test && cd $_  

Step 2

Create a new file and write something random in it.

touch index.html 

Step 3

Create a new Git repository and commit the file.

git init  
git add index.html  
git commit -m 'First commit'

Step 4

Okey, now it's time to push the file to the server.

git ftp init -u exampleusername.com -p ftp://ftp.exampleserver.com/optionalsubdirectory  

Hit return and write the password for your server. index.html should have been uploaded now if everything went well. Congratulations!

Step 5

Make a random change in index.html and make a new commit.

 
git add index.html  
git commit -m 'Second commit'

But wait, you don't wanna write your credentials every time you're going to push changes to the server. Instead you can save them to the config file:

git config git-ftp.user exampleusername.com
git config git-ftp.url ftp://ftp.exampleserver.com/optionalsubdirectory
git config git-ftp.password qwerty123

And you're ready to push the file to the server.

git ftp push

Step 6

Celebrate! You are now a real developer.

return false;

I spend a lot of time these days trying to learn test driven development, TDD. I belive it was about a year and a half ago when I first came across this concept. Maybe not that surpriceingly, I was learning Ruby on Rails at the time. (TDD is a lot more common in the Ruby community.)
Now, after reading lots of articles, tutorials and watched many, many screencasts, this TDD thing is finally starting to make sense. There are however a few different kinds of tests that you write when using TDD. These are both hard to remember and understand. Therefore I will try to explain them now in order to learn them once and for all.

Unit testing

This is the most common test you will write during development. In a unit test you will isolate and test a single function or object. For example, if you pass 2 and 2 to the add-function it should return 4. You don't care about where the arguments comes from or what's going to happen with the result. You are only interested of knowing that the function returns 4 and not 3 or 5.

Integration test

An integration test is kind of the opposite of an unit test. This will confirm that several functions works like expected when interacting with each other.

Acceptance test

This kind of test should verify that your code works the way that the user expects it to do. For example: the user should be able to fill out a form, send it and get an email with the expected content. Or maybe the user fills out a login form and should be redirected to a page which has the text "Hello [username]!" on it. I believe that an acceptance test and behavior driven development is kind of the same thing?

Functional tests

This is almost the same thing as an acceptance test, but from the developers perspective. While the acceptance test confirms that the user can see the right things, the functional test confirms for the developer that everything works as expected. When the user for example fills out a form, a validation function should be called before the user gets redirected. I believe this explanation is not so far away from the truth...

That should be all for this time. As you can guess, I have much, much more to learn about this subject. Time to get my fingers dirty again!

return false;

The typical scenario is that you are using MAMP (or WAMP) to create a local installation of your Laravel application. This will work just fine until it's time to deploy your app to an production server.
Then it's time for you to change the settings for the database connection. You could change them localy before you push the app to the production server, but then you would have to change back to the local settings later.
You don't wanna do this. Instead, why don't you just set up a local environment in Laravel?

The steps

1. Open app/bootstrap/start.php
2. Scroll down to the following section:
   

    <?php
    $env = $app->detectEnvironment(array(
        'local' => array('your-machine-name'),
    ));
    

1. Replace 'your-machine-name' with 'localhost'.
2. Create a folder within app/config named 'local'.
3. Create a file named app/config/local/database.php (because this is the config file that we want to override.)
4. Write the following in database.php:

    <?php
    return array(
        'connections' => array(
            'mysql' => array(
                'driver'    => 'mysql',
                'host'      => 'localhost',
                'database'  => 'db',
                'username'  => 'root',
                'password'  => 'root',
                'charset'   => 'utf8',
                'collation' => 'utf8_unicode_ci',
                'prefix'    => '',
            ),
        )
    );
    

This should look pretty familiar, right? It's exactly the same as the regular database.php, but only the part of it that you want to override.

This guide shows you how to create a remote Git repository on a server with SSH.

The steps:

1. Connect to your server with SSH and create a directory for the new repository.
2. Write git --init bare repository.git in your shell.
3. Go to your local Git repository and write:
   git remote add origin ssh://user@server/path/to/repo/repository.git
4. Push to the server:
   git push -u origin master

That's it!

Yeah, I really think this is THE fastest way to create a new Wordpress project. You don't even have to leave Sublime.

Requirements:

• Sublime Text 2
• The "Nettuts+ Fetch" plugin for Sublime

Setup:

1. Download the "Nettuts+ Fetch" plugin for Sublime
2. Press shift + commando + p and write Fetch:manage
3. Add the following line to the packages array:
   "wordpress": "https://wordpress.org/latest.zip"

The steps:

1. Create a new folder and drag it into Sublime.
2. Press shift + commando + pand write Fetch:package.
3. Select wordpress.

A few seconds later, you will have a brand new installation of Wordpress in the selected directory.