Tag Archives: Laravel

Laravel Application Logs and Logrotate

Depending on usage, errors, and what you’ve chosen to log, the Laravel application log(s) can really grow after a while.  With Laravel 3 and initially with Laravel 4, new log files were created every day by default, which kept them small and easy to search, but now Laravel 4 defaults to a single log file (which I prefer).

Continue reading

Validating Route Parameters in Laravel 4 Another Way(?)

Note: as the ‘?’ indicates in the title, I’m not sure if this is the “best” way or even a “good” way. But it’s definitely a different way than Laravel’s regular expression route constraints.

I realized recently that I wasn’t doing a good job of validating the route parameters in my Laravel application in my RESTful URIs, so I started working on a solution.

Continue reading

Simple Vagrant config for Laravel updated

Though Vagrant (at least with VirtualBox) appears to be semi-broken at the moment under Mavericks, I’ve updated my simple vagrant config for developing with Laravel as requirements keep growing for different projects: Github

By the way, the temporary fix for the vagrant under Mavericks seems to be running the following:

sudo /Library/StartupItems/VirtualBox/VirtualBox restart

Credit: http://www.stumiller.me/fixing-vagrant-osx-mavericks-update/

Thoughts on Vagrant

I’ve been making a play to get current and stay current with today’s web dev technologies, trends, etc.

It’s not easy. Things are moving fast and I was a bit behind to begin with.

Some of the tools that developers on the cutting edge are pushing appear to be a little abstract relative to what I’m actually working on right now or to my current workflow. One of these tools is Vagrant. Don’t worry, I do get it. Dev environments should match Prod and Vagrant makes it much easier to accomplish. But as a single developer who doesn’t need new environments that often, do I really want to spend time learning about Vagrant, along with Chef and/or Puppet just to prop up the occasional new environment when my current OS X/MAMP Pro dev environment really hasn’t caused me any problems to date? (actually, I did have an issue with case-sensitivity and class names, but not a big deal.)

Again, my use-case is currently limited (single developer, very few new environments, content with MAMP). And I don’t really want to take the time right now to learn Chef or Puppet. But if I can make it super simple, and considering the prospect of developing an app and packaging it up with a Vagrantfile and including it in a repo – all ready to go (I haven’t really seen this, but it sounds cool), then maybe it’s worth looking into. Plus, I’ll have that peace of mind that my Dev and Prod environments are matched.

So I borrowed some code from a couple of different Vagrant/Laravel 4 Github repos and mashed together my own Vagrantfile/boostrap.sh that is very simple and doesn’t require Puppet or Chef to get something up and running that to run a Laravel app. In addition to installing a LAMP environment, it points the default Apache site to the public folder.

Your web app will be available at http::/localhost:8888 and you can access MySQL via an SSH tunnel using the “vagrant” user.

Posted on Github: https://github.com/rufhausen/super-simple-vagrant-laravel

My “fix” for preserving timestamps on import with Laravel

Edit: This will not work on “updated_at” btw, for reasons that become obvious very quickly, but for my application, this is not an issue.

I’m currently re-developing a Coldfusion app in Laravel 4. Most of the current db tables have “createdat” and “updatedat” fields. I went thru the trouble of creating migrations for all of the db tables and then writing an Artisan command called “Import” that connects to a copy of the old db and imports all of the data into the new db created with the migrations that includes a few schema changes that are crosswalked over.

One of the problems with this is that the timestamp fields (“created_at” and “updated_at”) created by Laravel during migrations will be current(as in “now”) even if I try to map the old timestamps on import:

//no workie
$videogroup->created_at = $vg->createdat;

As a result, I lose important timestamp info. from my old database.

My new fix involves running the import as before:

$videogroups = DB::connection('mysql_vm_old')->select('select * from videogroups');
foreach ($videogroups as $vg) {
$videogroup = new VideoGroup;
...
$videogroup->save();

Except that I add this to the loop:

$videogroup->createdat  = $vg->createdat;

Then after the initial table import is complete, run:

$videogroups = VideoGroup::all();

//replace default timestamp value with the one from the old db
foreach ($videogroups as $vg) {
$vg->created_at = $vg->createdat;
$vg->save();
}

//get rid of the temporary 'createdat' column
Schema::table('videogroups', function($table)
{
$table->dropColumn('createdat');
});

This certainly adds more overhead to my import script for larger tables, and I’ve already had to increase mysql’s memory limit to handle the script as it’s grown, but once the site goes into production, I’ll no longer need the Import script.

As it stands now, I’m running the following on a daily basis as I make changes:

php artisan migrate:refresh --seed
php artisan import