Quick note on naming convention, the driver itself will be lowercase in this example while the class will be camel case. You can have the driver whatever you like.

Custom auth drivers can be a bundle, a class, or a closure. I am going with the library approach for a simple example. Let’s start off with changing our configuration file.

// application/config/auth.php
'driver' => 'eloquent',

For this example our custom auth driver will be called customauth. Change the default driver from eloquent to customauth.

// application/config/auth.php
'driver' => 'customauth',

Let’s make a new file in our libraries folder named customauth.php.

// application/libraries/customauth.php
use Laravel\Hash, Laravel\Config;
class CustomAuth extends Laravel\Auth\Drivers\Driver {
    public function attempt()
    {
        // Your custom attempt function should replace this.
    }
}

This will set you up to place your custom attempt function, be sure to check out laravel/auth/drivers for examples.

// application/start.php
Auth::extend( 'customauth', function()
{
     return new CustomAuth();
} );

Let’s go over how this works, first we tell the Auth class to map a new driver named customauth using a closure style syntax. Within our closure we return a new object of our custom auth driver. Once this is done the Auth class takes care of the internal workings and our new driver is working.

From this point you can create the driver however you like. I would suggest sticking with the built-in naming convention if your planning to release the driver as a bundle so it’s drop in.

I was faced with designing and programming a lot of WP themes but no way to share assets or push changes from library updates. What I came up with was a way to use the master branch as a skeleton theme with all my libraries in it. Each time a lib was updated I swapped to the master branch and pushed the changes to the server. I then merged the master branch into each theme (branch) that required it. This gave me powerful version tracking on the libraries and a way to manage which themes use what version. When you have your master branch set up like this you can create a copy of the master branch into your project branch and delete any unneeded libs. It’s then as simple as pushing the new branch to the server and building out your theme.

On a Mac you can use the native github.com app to manage your repository and switching branches without losing code. You can also symlink your github theme repo into wp-content/themes and each time you switch a branch it will auto switch your current theme… magic!

Once you have your repository setup it’s a simple matter of installing WP and cloning your project’s branch into the theme directory.

cd /home/project/public_html

wget wordpress.org/latest.tar.gz && tar -xvf latest.tar.gz && rm -rf latest.tar.gz

Download, extract, cleanup.

cd wordpress && mv * .. && cd .. && rm -rf wordpress

Mv the wordpress files up a directory so they live within the root of public_html

cd wp-content/themes

git clone --branch project git@github.com:Medalink/wp-themes/project.git

Switch to the themes directory and clone in your git project.

Now just setup your database.

mysql -u user -p
mysql> CREATE DATABASE wp_project;
mysql> GRANT ALL ON wp_project.* TO user@host IDENTIFIED BY 'pass';

Visit http://www.project.com and install wordpress. Done.

Looking for a way to move WP from one server to another?  Jeff Johnson posted about it here.

First and formost this is black text on a white background which I am not all that happy with so I swapped over to pro which is white text on a black background. Take a look:

The problem here is that the default typography is not up to par. Let’s change a few settings.

Terminal > Preferences > Settings > Text

Change the font type to Menlo Bold 12 pt. Check the Antialias text box.

Now that is much more traditional than the default but this now lacks a few things like colors, some really nice alias commands and some tweaks to the way command line history works.

Now in Ubuntu you normally edit your ~/.profile or your ~/.bashrc but on a Mac the default is ~/.bash_profile. Here we export certain settings and adjust the default terminal.

First let’s set our default editor to nano. This is my preference but you may like something else. By default Mac uses VIM.

# Default editors
export SVN_EDITOR=nano
export GIT_EDITOR=nano

Next we want to uses colors for file names so we can have a visual indicator for file and folders and even seeing when a folder has public permissions.

# Use colors
export CLICOLOR=1;

One thing I do not like is directory listing defaults on Mac. Let’s make an alias that will display the contents in a list, short and simple file sizes and show hidden files/folders. You could override the default ls command with this but I prefer to assign it to ll as Ubuntu and many other linux based distros use.

# A better directory listing
alias ll="ls -lha"

Let’s tweak the history size to not only hold more but to ensure we do not store duplicate commands and we expand the history properly on resizing the terminal window.

# History
export HISTCONTROL=ignoredups:ignorespace
export HISTSIZE=10000
export HISTFILESIZE=2000
shopt -s histappend checkwinsize

Adjust the bash shell to show us the current user and what machine we are working on as well as the current folder of the current directory. We also add some color to match the default in Ubuntu. This is really helpful if you work on a lot of different console windows or tabs at once.

# Bash shell
export PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]# '

Alright after all of this your ~/.bash_profile should look like this:

# Default editors
export SVN_EDITOR=nano
export GIT_EDITOR=nano

# Use colors
export CLICOLOR=1;

# A better directory listing
alias ll="ls -lha"

# History
export HISTCONTROL=ignoredups:ignorespace
export HISTSIZE=10000
export HISTFILESIZE=2000
shopt -s histappend checkwinsize

# Bash shell
export PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]# '

To apply the changes you need to reopen a terminal window or type

source ~/.bash_profile

Here is a screenshot for reference:

As you can see folders are purple, files are white, public permissions show up as green highlight and yellow highlight. I also use a few different settings for terminal, I use a very transparent block cursor that’s tinted grey and my window background color is semi-transparent so I can see other windows behind it or other terminals.

Enjoy your new eloquent terminal.

I also love how you can look over the logs from long ago and see what you where doing and the progress you have made. It’s a nice way to remind yourself of the work you have put into a project. This post does not serve much of anything but to say I love SVN. You should check it or GIT out if you don’t use one or the other. You will fall in love too!

First of all if your going to need some of the basic web related stuff like session management, database connections, profiles, editors, etc then yes use a MVC Framework. They have built in systems to handle everything you will need to start so you can jump right into coding your custom system. Secondly most MVC Frameworks have built in profiler, helpers, OS and driver classes and functions. I can’t tell you how many times I am knee deep in coding and think “I need to benchmark this function, let me write a system to do that”. I end up spending some time playing around and creating a benchmarking class or function taking away time from what I was planning on coding. Using a MVC Framework let’s you leverage pre-made classes and functions for when you run into a situation where you need something quick and you don’t want to spend the time making it yourself.

Here is a quick list of things I find most useful from using CodeIgniter (my MVC of choice).

• Multiple Database Drivers
• Session Management
• Benchmarking
• Code Profiling
• Built in Security
• Rapid Development

Within an hour of starting a project from scratch you should be able to have all your basics done. That’s what a MVC Framework is for.

Now why would you not use a MVC Framework if they are so great? Simple, the learning curve is destroyed when you just start calling functions and creating objects. Even looking at the source of each function and class call your limiting your idea of how it should work based on what the developers of the MVC Framework do. I have been programming PHP for 14 years and I can tell you there are hundreds of ways to do the same thing. I am from the self-taught group and I hate to use code I did not write or modify and that led me to many years of re-creating the session handlers and the database drivers, the URI parsing and all the elements of a CMS. I have written 4 CMS systems from scratch over the years and it has taken a lot of time to learn each part of the system and secure it, make it fast and optimized, make it OS independent and extensible.

I think at that point your not just learning how to code PHP your learning how the internet works and how technology on the internet is used and exploited. It’s not just about learning how to make a login system, today coding and developing something is learning how people will use it and how they expect it to work. The bar has been set high and you can’t just create a website with a MVC Framework and it be great and innovative. It’s more about the idea now and not the system.

To sum it up you should use a MVC Framework when you are in need of a rapid deployment situation and you have a grasp on the systems you will be “auto-generating”. You should not use a MVC Framework just to use it or if your doing it just because you always have. Be adventurous and try and create one yourself or go old school and write your own system.

You want to be innovative right? Not just doing the same thing over and over, you know Insanity.