I realized a dream today.

When I was a kid, maybe 8 years old, I would go to the flea market with my parents a couple of times a year.  I had a small allowance at the time and would walk around looking for cool things.  One time I saw a broken VCR for sale for $5.  It was so cool!  I asked my mom if I could buy it to take it apart, and soon I was the happy owner of a broken VCR.

When I got home I couldn’t wait to go at it.  I sat in the garage with a couple screwdrivers and did my best to dis-assemble the whole thing.  I wanted to know how it worked, and what was inside the box.

For our latest Laravel application, we decided to try the Laravel Forge service to configure and manage the staging and production sites for the app. If you haven’t heard about Laravel Forge, check out the free screencast series by Jefferey Way over at Laracasts.

The Forge UI is great, and takes away a ton of the pain of server and application configuration. Following best practices, we use environment variables to manage environment specific settings like the database name and credentials. One of the features Forge provides is the ability to automate deployment from your github / bitbucket repo upon a post to a specific branch.

The problem we were having was that our migrations would not run. The error was:

{"error":{"type":"ErrorException","message":"Undefined index: DB_HOST","file":"\/home\/forge\[ourbasedir]\/laravel\/app\/config\/database.php","line":51}}

In our case, we are using a non-standard repo directory structure where instead of the typical Laravel app directory structure:

---app
|-bootstrap
|-public
|-vendor


we have another layer above:

---docs
|-laravel
| |-app
| |-bootstrap
| |-public
|-html-templates


Upon inspection of the directory on the server, we found the “.env.php” file was in the base directory. The problem with this was that artisan, the application responsible for Laravel migrations, could not see the environment variables, and so the database configuration was wrong. The solution was simply to move .env.php file into our “laravel” directory so that artisan had access to it.

Thanks to stackoverflow and github, I finally got Vagrant set up so I can ssh into vagrant and pull in my dotfiles from github without futzing with my ssh keys. Here’s the steps:

1) Make sure the ssh key you use for github is registered with your local ssh agent. You can check with ssh-add -L, if it’s not listed add it with ssh-add ~/.ssh/id_rsa. Credit: http://stackoverflow.com/questions/11955525/how-to-use-ssh-agent-forwarding-with-vagrant-ssh

2) Make sure ssh forwarding is enabled in the VM. Include `config.ssh.forward_agent = true` in your Vagrantfile.

3) Test: ssh -T git@github.com. If it’s not working, check out this link for more troubleshooting: https://help.github.com/articles/using-ssh-agent-forwarding

In a recent project I was trying to create new users with just their email addresses in an instance of WordPress Multisite.  To do this, I planned to use the email address as the new user’s username.  But I kept getting this error:

“only lowercase letters (a-z) and numbers are allowed”

In case you run into this problem to, there is a solution: the Network Username Restrictions Override plugin. There’s a setting in the plug to allow email addresses for usernames.  Click that and you should be good to go.

Here’s another way to solve the same problem that overrides the error that pops up if you try to use an email address as a username in WordPress Multisite.  It attaches a custom filter to the the ‘wpmu_validate_user_signup’ hook that unsets the email address error.

Recently, I added a new feature that significantly changes one of the database tables in my application.  I ran into problems when I created a non-reversible database migration, and realized that other branches I am developing on still require the older database scheme.  In the end I had to end up dropping the DB, deleting the offending migration, rebuilding the DB, and figuring out a smarter way to migrate.  Not fun, and time wasted. Continue reading →