I’ve been messing around with my base Zend_Form class and came up with a solid implementation now. I’ve also expanded the concept to select elements, in which case it’d create a zero-value option with your hint. This entire inline hint concept is enabled by JavaScript (in this case, jQuery), so when JavaScript is not enabled, nothing different will happen for users. I think that’s ideal.

Here’s an example of what this is about. For ideas, you’ll also notice that required fields are highlighted, and the hint is gray. The hints for select menus are also gray, which makes it really easy to scan over forms, since the values you enter are black.

The Code

$a = new Zend_Form_Element_Text('email', array(
    'label'        => 'Your Email Address',
    'hint'         => 'name@site.com'
));

$b = new Zend_Form_Element_Select('category_id', array(
    'label'        => 'Category',
    'hint'         => 'Select a Category',
    'multiOptions' => $this->_getCategories()
));

Here is the Form class code. It takes the ‘hint’ attribute we set in our form definitions, and adds a ‘placeholder’ class, and sets the hint as the rel attribute.

public function render(Zend_View_Interface $view = null) {
    $this->_applyHints();
    return parent::render($view);
}

public function _applyHints() {
    foreach ($this->getElements() as $element) {
        if ($element instanceof Zend_Form_Element_Text or
            $element instanceof Zend_Form_Element_Select or
            $element instanceof Zend_Form_Element_Textarea) {

            if ($hint = $element->hint) {
                $element->setAttrib('rel', $hint);
                $element->setAttrib('class', 'placeholder');
            }
        }

        if ($element->hint) {
            $element->setAttrib('hint', null);
        }
    }
}

Here is the JavaScript (jQuery) code.

$('.placeholder').each(function() {
    var item = $(this);

    // if hint
    if ($('#' + item.attr('id') + '-label label').hasClass('required')) {
        var text = item.attr('rel') + '    ';
    } else {
        var text = item.attr('rel');
    }

    var form = item.parents('form:first');

    // append option when hint is in place, and no 0 option exists
    if (item.is('select') && item.find('option[value=0]').length == 0) {
        item.html('<option value="0">' + text + '</option>' + item.html());
        item.change(function() {
            if ($(this).val() == 0) {
                $(this).css('color', '#ddd');
                $(this).find('option[value!=0]').css('color', '#000');
            } else {
                $(this).css('color', '#000');
                $(this).find('option[value=0]').css('color', '#ddd');
            }
            return true;
        });
        item.change();
    }

    if (item.val() === '') {
        item.val(text);
        item.css('color', '#ddd');
        item.data('hint', text);
    }

    item.bind('focus.placeholder', function(event) {
        if (item.val() == text) {
            item.css('color', '#000').val('');
        }
    });

    item.bind('blur.placeholder', function(event) {
        if (item.val() === '') {
            item.css('color', '#ddd').val(text);
        }
    });

    form.bind('submit.placeholder', function(event) {
        if (item.val() === text) {
            item.css('color', '#000').val('');
        }

        if (item.is('select')) {
                var val = item.val();
                if (item.attr('rel') == item.find('option[value=' + val + ']').text()) {
                    item.find('option[value=0]').remove();
                }
        }
    });
});

There are a few things to note here… on basic text fields, if the element is required, I append whitespace to the stored hint, which allows us to detect when they enter text that matches the (visible) hint. For example, if it’s a name element, and the hint is ‘John’, that is surely an allowed option. However, if it’s not required, then the the user cannot enter something that matches the hint, so be sure to use formatting examples (ex: ‘m-d-Y’ instead of a real date).

On select elements, the hints only really make sense (to me) for required fields where the hint is a 0-value option similar to “Select a Category”. To prevent the standard 0 not found in the haystack error presented when the user skips the field, you should set the ‘errorMessages’ option on the element to something like ‘Please select a valid category’, as that’s really the only valid error condition that can happen.

Just a Concept

I’m currently only using this in an admin area for testing, but it seems to work really well so far. We’ve had a lot of positive feedback about it, and being able to use these sort of features application-wide saves the chore of having to un-do it later or add it to 1000 files. If you have some suggestions on improvements to this be sure to post in the comments. It’d be nice to have it valid HTML (rel attribute) for all the purists as well. Hope this helps someone!

Cheers

Unfortunately, people rarely need to hire lead or senior programmers, at least where I live. This was becoming evident. The only next logical choice I could think of was to move out of the home office and try to do things a bit more seriously. I ended up moving into a friend of mine’s temporary office with their team. We went to school together throughout elementary, middle and high school, and roomed together for several months about a year after school. They ran a web firm with some very interesting connections and projects. Unfortunately, it seemed like their company was falling apart with the efforts looking like a reversed triangle. After a month or two, it toppled, leaving everything in shambles. With the old leader / programmer out of the way, we were left with quite an interesting team: a developer, a network security/all-around geek, a manager, and a salesman.

After this had happened, it dawned on me that a start-up was exactly what I was looking for. For some reason, as a developer, a lot of the clients I’ve dealt with didn’t give a shit about my input on some of the applications they had planned. Or worse: they assumed that because I was a developer, I didn’t know anything about it. It was hell having to sacrifice good architecture for crap to make unrealistic deadlines or budgets. As the technical leader of a start-up, I get complete creative control on projects and don’t have to make sacrifices. If I do, they are realistic ones that everyone can be involved in deciding.

Since the new company has formed, we have been working on a lot of the usual client work from both their old company, and my “SirAdrian” business. It’s been a huge transition, but we are almost done now. The client work is purely transitional (ideally). About 20% of my time has also been working on our first product. As a service, we are always trading time for money, and have a very limited reach. As a product company, we can create value once, and sell it to the masses. Our real focus is going to be targeting the Health care industry. Our CEO is still heavily involved in health, with over 25 years of relationships and experience. Perfect combination.

We are about 3 months in, and have moved into a local tech incubator called ORIC which has been an enormous help in the start-up phase. The networking here alone has been worth it already, but we will also be doing team mentoring sessions and attending events they put on. All in our building. Our first product is planned to launch September 1st, so this is going to be one hell of a ride.

The concept of a model

Before we can go any further, we must first figure out what a model is. This stuff isn’t an exact science, so there will be some gray areas. Much of this post is my opinion (read: not fact). This doesn’t necessarily make them right or wrong. I like to think I’m right, so feel free to argue with me in the comments below.

In an MVC application, the model is responsible for all the business logic. The controller should handle flow control (taking input, calling models, redirection, etc.), and the view is responsible for representing your application, usually with some sort of data language (XML, HTML, JSON, etc.)

Implementation and and interpretation of the pattern is up to the developer… there are some gray areas so don’t worry if it doesn’t meet the exact specification. However, one thing I like to practice is skinny controllers, fat models. By shifting a lot of the work to the models (and their underlying libraries) you can usually organize your application much better. The result is simpler and more organized (primarily better encapsulated) code.

Simply said, a model should contain your business logic. Any processing that revolves around your application data should probably be put into models. I consider a model to be anything that does something in the big picture of your application… things like reading/writing data, sending/receiving data, processing data. They do the “work”.

One mistake I see is people simply setting up ORM (ex: Doctrine) models for each of their tables and leaving it at that. Your models’ public interfaces should be very simple. I prefer to have their interface represent their actual domain logic. For example, if you are making a post, then your controller (or calling code) should simply call something very self explanatory like post->create( info ). One personal guideline I follow is not to have more than 4 or 5 parameters to a method, and ideally, only 1 to 3.

One common implementation of this annoyance of mine is putting in chained query calls in your controller. Yes, the actual database code is encapsulated, but you are still revealing way too much information in your controller. The whole point of them is to encapsulate not only the code, but also the underlying logic. This way, when your business logic changes, your controllers can usually continue to function properly.

Working with databases

Most web applications revolve around storing information in the database. Whether it’s posts, comments or pictures, it all boils down to the same few operations. You can call this CRUD: create, read, update and destroy. In practice, it’s often much more complicated… but they remain to be the underlying concepts for most database interaction.

Most other frameworks come with a default model class/component which is a huge push in the right direction. Zend keeps an open mind about it, providing a few tools to use if you want to work with the database. Zend comes with a huge Zend_Db component to handle your database operations. It also contains Zend_Db_Table which is an implementation of the Table Data Gateway and Row Data Gateway patterns.

Personally, I’m not a big fan of Zend_Db_Table. I still think Doctrine is much more powerful, though I do really like Zend_Db. It operates under some of the same principles as PDO (database abstraction layer), so if you have used that before, you will be at home. I also really like Zend_Db_Select, which is what the table classes use quite a bit.

Using a base model

Because there are so many different types of models, I don’t think there is much point in having a do-it-all base class. However, for the group of models that will need database access, I use something like this:

class Site_Model {
    protected $_db;

    public function __construct(Zend_Db_Adapter_Abstract $db) {
        $this->_db = $db;
    }
}

You can probably tell that the default model is not even needed… and that’s the point. However, depending on your needs, this is a good place to start adding some common functionality that your db models will need. You may want to also make them all loader or dependency injector friendly if your application requires that.

Zend_Db

Zend’s database abstraction layer is really nice to work with. If you use it in combination with Zend_Db_Select you can make the database end of your application very portable. Here are some common methods I use from Zend_Db:

query(string)

fetchOne(query)
fetchRow(query)
fetchAll(query)

insert(table, data)
update(table, data, where)
delete(table, where)

quote(value)
quoteInto(string, value)

Abstracting your queries

If I’m working on an application that I plan to release to the public, then I always use Zend_Db_Select. It works on the same concept as the above insert/update/delete methods, meaning that you never have to write any of the SQL. If you let the Db libraries do it, then you are able to get much more portable code. Zend_Db supports IBM’s DB2, MySQL, MSSQL, Oracle, PostgreSQL and SQLite, so Db_Select is targetted at the same databases.

The concept of Zend_Db_Select is that the query is an object, and you can add/modify different parts of it. This gives you a lot more flexibility over dynamic query creation, as well as the added bonus of portability.

Summary

For your basic database-oriented models, all you your class will need is access to the Zend_Db_Adapter_Abstract interface. Keep your public methods very domain-oriented and your controllers will thank you for it. Break out of the mindset that models = database tables, or even model = database. Usually only around half my models deal with database operations. ZF also has a ton of service libraries available to help with all the common social sites APIs out there.

The next installment of this post will go into some concrete examples and also some ideas on how to implement your models. Comments and criticism welcomed and appreciated as always.

Create a new mail transport class

Zend has the ability to set a default mail transport class to be used when none is specified, which I’d imagine to be 99% of the time. To set it, all you need to do is put this somewhere early in your application before any mail code is executed.

Zend_Mail::setDefaultTransport(new Site_Mail_Transport_Debug());

The alternative (for the 1% who want to manually specify), you’d simply pass an instance of your mail transport object to Zend_Mail::send() when you call it. What should your class contain? It has to extend Zend_Mail_Transport_Abstract, which at this time of writing this, will specifically need to override the abstract _sendMail() method.

You can use it to create a new record in your database, create a file, or do whatever you need it to. I quickly hacked together one to log it to the database, and based it off of the Sendmail transporter, which is pretty much a wrapper for PHP’s mail function. Here is the code I came up with for those who want some direction. It’s very basic, but should be enough to get you started.

<?php

class Site_Mail_Transport_Debug extends Zend_Mail_Transport_Abstract {

    public function __construct(Zend_Db_Adapter_Abstract $db) {
        $this->_db = $db;
    }

    public function _sendMail() {
        $this->_db->insert(
            'mailtest',
            array(
                'recipients' => $this->recipients,
                'subject'    => $this->_mail->getSubject(),
                'body'       => $this->body,
                'header'     => $this->header
            )
        );
    }
}

Override it at the server level

This is a good idea if you don’t use Zend Framework, or don’t use it for all of your applications. There are two great techniques described on akrabat’s blog. Here they are.

The first, is to override php.ini’s ’sendmail_path’ and create your own script to handle it. If you were to set it to

sendmail_path = /usr/local/bin/trapmail

then you’d use the following code

formail -R cc X-original-cc
  -R to X-original-to
  -R bcc X-original-bcc
  -f -A"To: your@emailaddress.com"
| /usr/sbin/sendmail -t -i

This requires you to have mail configured on your server, but it still solves the underlying problem of wanting to debug the emails, and also not send out test emails to real users in your application.

The second solution provided is platform independent is for Windows users, and it’s to install fakemail. This program acts as an outgoing mail server, but instead creates files containing any mail passed to it.

Hopefully this helps others out who are also frustrated with dealing with pesky email debugging.

Here is my initial loader class, which I have stripped down and simplified for the sake of this example. Ideally, you’d want this in something like an action helper.

<?php

class Site_Loader {
    /**
     * Site's controller action
     * @var        Site_Controller_Action
     */
    protected $_controllerAction;

    /**
     * Sets the current controller action we're being called from
     * @param       Site_Controller_Action
     */
    public function setControllerAction(Site_Controller_Action $action) {
        $this->_controllerAction = $action;
    }

    /**
     * Loads the requested form class
     * Same conventions as Zend (Form_Name = Form/Name.php) class "Form_" . $Form_Name
     *
     * @param    string        The name of the form class
     * @param    string        Any options for the form class constructor
     * @return   object        Form class object - forms_$formName
     */
    public function form($formName, $options = null) {
        $path = APP_DIR . "/application/forms/" . str_replace('_', '/', $formName) . '.php';
        require_once $path;

        $class = "Form_" . $formName;
        return new $class($this->_controllerAction, $options);
    }
}

I always find it useful to have access to the controller in forms – especially to access the request information. Another reason is we can use it to determine the request method – more importantly, see if it’s POST. When it’s not, then we can enable caching, because the form output should not change. Only when they actually post something should we need to show anything different. I set a high cache TTL simply because I’d want it to be there forever, until I actually modify the form code, at which point I’d clear its cache. With that in mind, here is the updated (and relevant parts of) the loader.

<?php

class Site_Loader {
    /**
     * Site's controller action
     * @var        Site_Controller_Action
     */
    protected $_controllerAction;

    /**
     * Caching object used
     * @var         Zend_Cache_Core
     */
    protected $_cache;

    /**
     * Sets the current controller action we're being called from
     * @param       Site_Controller_Action
     */
    public function setControllerAction(Site_Controller_Action $action) {
        $this->_controllerAction = $action;
    }
    
    /**
     * Sets the cache object to be used
     * @param       Zend_Cache_Core
     */
    public function setCache(Zend_Cache_Core $cache) {
        $this->_cache = $cache;
    }

    /**
     * Loads the requested form class
     * Same conventions as Zend (Form_Name = Form/Name.php) class "Form_" . $Form_Name
     *
     * @param    string        The name of the form class
     * @param    string        Any options for the form class constructor
     * @return   object        Form class object - forms_$formName
     */
    public function form($formName, $options = null) {
        $path = APP_DIR . "/application/forms/" . str_replace('_', '/', $formName) . '.php';
        require_once $path;

        $class = "Form_" . $formName;
        return new $class($this->_controllerAction, $options);
    }
    
    /**
     * Loads the requested form class.
     * When request method is post, form is loaded normally.
     * When it's not, cache is used to reduce CPU load.
     *
     * @param   string      The name of the form class
     * @param   string      Any options for the form class constructor
     *
     * @return  mixed       Form class object, or rendered form HTML when caching is active
     */
    public function formCached($formName, $options = null) {
       if ($this->_controllerAction->getRequest()->isPost()) {
           return $this->form($formName, $options);
       }

       if ($out = $this->_cache->load($id = $this->_getFormCacheId($formName, $options))) {
           return $out;
       }

       $form = $this->form($formName, $options);
       $this->_cache->save($out = $form->__toString(), $id, array(), 31536000);

       return $out;
    }

    /**
     * Generates the id used for the cache.  It must be unique for the name of the
     * form, and the options passed to it.
     *
     * @param   string      Form name used
     * @param   mixed       Array of options passed to form, or null
     *
     * @return  string      Unique ID for this form cache
     */
    protected function _getFormCacheId($formName, $options = null) {
       if ($options === null) {
           return "Form_$formName";
       }

       return 'Form_' . $formName . md5(serialize($options));
    }
}

Enabling Caching

This is generally how a basic form action looks like in my controllers.

public function postAction() {
    $form = $this->loader->form('Post_Create', $options = array());

    if ($this->_request->isPost()) {
        if ($form->isValid($this->_request->getPost())) {
            $post = $this->model->create($form->getValues());
            $this->redirector->goToUrl($post->getUrl());
        }
    }

    $this->view->form = $form;
}

With it enabled, we’d simply change

$this->loader->form()

to

$this->loader->formCached()

Since the only interaction with my form and view script is

<?= $this->form ?>

we don’t even have to change it. The form’s __toString method will work normally when the caching isn’t active, and the form variable is just a string when it is. Simple.

Recap

This will allow for the caching of your rendered ZF forms. It is disabled automatically when the request method is POST, so it can properly re-populate your data and/or show your errors. If you use the simple form renderings in your view scripts, then they will work as-is. This is all just a proof of concept that I am testing on a few sites at the moment. If you have any feedback or questions, don’t hesitate to let me know.

If you’re able to automate all of that stuff, then all you are really left with is configuration. Each form consists of elements, and each element has several attributes which modify the overall functionality of the form. Let’s look at some of these aspects.

Defining a Form

A form itself is an instance of Zend_Form. There are many ways to define one. I prefer to extend Zend_Form for each of my forms, and define them inside the class itself. Each form contains a few important fields (action, method) and also it contains at least one element. Let’s look at how we define an element. Each element probably has a few common attributes: a field type, a label, an element name, and a description. Let’s represent this element in ZF. Note, there are several different ways to represent forms. They can literally be done via configuration, or by a few different PHP methods. This is my favorite.

$username = new Zend_Form_Element_Text('username', array(
    'label'         => 'Username',
    'description'   => 'This is a description'
));

In the above code, you can see we define these three things. There are also some other important attributes for elements. Let’s add a few more, and show a few fields at once.

$this->addElements(array(
    new Zend_Form_Element_Text('username', array(
        'label' => 'Username',
        'required' => true
    )),
));

Filters and Validators

One very helpful feature with the forms component is the ability to chain filters and validators. A filter is something that automatically manipulates incoming data to your desired format, and a validator is something that is checked when processing the form. This greatly simplifies your controller code, and your model code, because you are shifting all of this logic into a much more organized structure.

For example, if you are working with a username element on a registration form, then you may want check that the user does not already exist, the username does not contain any illegal characters, and the username is within a desired length.

If you had an element where the user can enter a few paragraphs about himself, then you would want to apply some filters to make sure the data is clean. You may want to add things like StripTags to remove any HTML, StringTrim to remove any extra whitespace, etc. You could also apply some custom BBCode parsing filters if you wanted. You could create your own filter for this, or use the Callback filter which you can use for everything else.

The idea is to do as much validation as possible so you know that your data is 100% ready for your application. If you have a VARCHAR(255) field, then limit your string to 255 characters so nothing gets truncated. Be very strict.

Filters are more of a time saver to me… but they are nice because they help keep all the data very consistent or can also be part of your cleaning process. If you are allowing user input, then remove any HTML is necessary. You get the idea.

Here is a more complete example of a registration form definition:

$this->addElements(array(
    new Zend_Form_Element_Text('username', array(
        'label'        => 'Username',
        'required'     => true,
        'validators'   => array(
            array('StringLength',      false, array(4, 16)),
            array('Alnum'),
            array('Db_NoRecordExists', false, array('users', 'username'))
        )
    )),
    new Zend_Form_Element_Text('email', array(
        'label'        => 'Email Address',
        'required'     => true,
        'validators'   => array(
            array('EmailAddress'),
            array('Db_NoRecordExists', false, array('users', 'email'))
        )
    )),
    new Zend_Form_Element_Password('password', array(
        'label'        => 'Password',
        'required'     => true
    ))
));

Skinny Controller, Fat Model

With a form containing the fields above, we can really simplify our controller code. To me, controller’s should contain the flow of an application, without really performing any of the work. Here is an example of a registration action.

if ($this->_request->isPost()) {
    if ($form->isValid($this->_request->getPost())) {
        $user->register($form->getValues());
        $this->redirector->goToUrl('/welcome');
    }
}

$this->view->form = $form;

If the user has submitted (posted) any information, then the form validates that posted information. If it’s valid, it will proceed to pass the data array to our model. At this point, all of our filters and validators have been executed, so we know exactly how the data is formatted, and that it’s safe to use. We can proceed to redirect the user away, or perform any other flow logic we need to at this point.

We also pass the form to the view, which is crucial. On a regular page view, the form will be loaded normally. On a failed submission, then it will show the form with all of the error messages, and the posted data populated back into the form elements.

View Scripts & Decorators

Here is all the code we need in our view to show a form. The rest can be done via CSS, or custom decorators if we need it.

<?= $this->form ?>

By default, Zend_Form outputs a pretty usable chunk of HTML. I have no problems styling it via CSS which is really great for our separation of concerns. However, there will be times when you need markup in certain format, and Zend can handle this with decorators. They are a little tricky to learn, so I will save that for another blog post. There should be sufficient documentation on their website.

Dealing with Models

As per our controller code, the model would receive $form->getValues(), which would be a pre-validated and pre-filtered array of our data. Here is an example:

// ...
public function register(array $user) {

}
// ...

To me, this is beautiful. We are working with a very basic interface, and do not have to manually specify every value that we pass or expect. While this is personal taste, I cringe whenever I see people pass 5-10 values to a model. Their controllers all end up being huge. The code is also not dependent on our form, because it’s just dealing with an array of data. It makes calling our models very simple, too. The model is where the code should start to get complicated. From this point, we can use our database adapter object, or deal with several other libraries.

Summary

The form component is one of the larger (largest?) components in Zend. Don’t be afraid to ask for help on the different forums, or ask below and I can point you to a good resource. Like I said above, this is the most useful component in Zend to me, so if you are considering taking the time to learn how to use it, I strongly advise to do so.

You may also be interested in caching forms.

Addressing Your Needs

To oversimplify things, it’s easy to map your role with some of the different frameworks. I choose these three, because they represent my point very well. I’m going to fudge the definitions a little bit here, and toss WordPress (or ‘insert your favorite CMS here’) into the mix as well. While the mapping may be an oversimplification, remember that the particular role’s core needs may match your needs for a project, even if you fit another role.

Designers & Writers – WordPress

If you are a designer or content writer, you will want something simple to use like WordPress. It’s pretty easy to skin, and there is a wide variety of plugins/themes available. Even these add-ons are easy to work with. Given the short time required to get started, this is the most common choice for new websites, at least from what I have seen. Even web development firms will choose this when it fits the bill. There is no shame in that.

Keep in mind though, the WordPress codebase may not be the most flexible, and that is usually when you start climbing the ladder to more advanced solutions.

Coders and Designers – CakePHP

If you want a framework gets you from zero to launch very quickly, then look no further than CakePHP. It’s an MVC based framework, like the others, and imposes very strict coding conventions. This means if you learn how to code the ‘CakePHP way’, then it will do a lot of the work for you. Sounds too good to be true? It is, sometimes. Once you begin to deviate from the way CakePHP does things, then it becomes very frustrating to work with. However, its primary target audience is people who want to get applications up and running very fast. If I remember correctly, it’s based on some of the concepts of Ruby on Rails.

One thing Cake does very well is creating “CRUD” applications. CRUD stands for CREATE, READ, UPDATE, DELETE. These are common operations for custom (but relatively simple) databases. The work I have done with this was actually a pleasure, though pretty slow.

PHP / Front-End Developers – CodeIgniter

I find that the more technical designers or coders will use an open ended framework like CodeIgniter. It’s a decent MVC framework with a few extra libraries to make your common tasks easier. CodeIgniter is based in PHP 4, which is a turn off to some. CodeIgniter does not try to do everything for you, instead it does give you a loose structure to work with and build upon.

If you like to do things yourself, but want an MVC stack and some basic libraries to work with, then CodeIgniter is great. There are also some spin-offs of CI that are worth checking out (notably Kohana, which is PHP 5).

Backend Developers – Zend Framework

Zend Framework is a monster. It is very daunting to beginners, and unfortunately because it has changed so much in the past 2 years, most of the blogs for it are inaccurate. Zend Framework is the most complicated of the set, and it takes quite a large effort to get comfortable with it. However, it offers such an enormous amount of flexibility that it has become my #1 choice for some time now. You will need to be very hands on.

The best thing about Zend is how the code works. You can more or less pick different components that you want and use them in other applications. There may be a few dependencies, but compared to other frameworks it is miles ahead. You can also easily drop in other libraries to work with your ZF application.

Zend is for creating serious web applications which may need a lot of external libraries or access points. It is overkill for most websites; it’s meant for enterprise level websites or applications. Zend’s documentation is also a little difficult to understand at first, as it’s more from an API perspective. However, it has gotten better in the past few months to show big picture examples.

Summary

There will never be a single framework that will fit everybody’s needs. It’s best to analyze your goals, and then go from there. Jumping to the biggest framework is never a good idea; neither is being stuck with a codebase that isn’t flexible enough and requires you to re-code everything. Experiment with a few and see which one fits your needs the most. Take into account things like community support, documentation, style, code quality, and efficiency. Without communities working together to improve these tools, they become useless and outdated.

I have had one hell of a time trying to get Magento up and running on my development server. I have probably spent about 5 hours fighting with mcrypt and for some reason, it is just not playing nicely with my setup (PHP 5.3, with everything compiled manually). I brought in a server guru as well, and he had the same problem. I think we both tore out some hair.

I’ve hacked together some steps to get it up and running for developers who want to get their hands dirty quickly.

Making Magento PHP 5.3 Compatible

If you are running PHP 5.3, it takes a few tweaks to get Magento up and running.

First one: edit /lib/Varien/Object.php, and find

    public function __toString(array $arrAttributes = array(), $valueSeparator=',')

with replace it with

    public function __invoke(array $arrAttributes = array(), $valueSeparator=',')

Step Two: Edit /index.php and change

error_reporting(E_ALL | E_STRICT);

to

error_reporting(E_ALL ^ E_DEPRECATED);

This may not be ideal, but it worked for me on my local machine. Before I did this, I went in and tried to spot-treat several errors as they came up. I was hoping it was just one, but after a few I caved and lowered the error reporting.

Installing Magento without Mcrypt

This extension was a major pain in the ass to (not) install. I want my day back. Anyway, I managed to isolate the sections to modify to avoid requiring this extension.

Step One: edit /app/code/core/Mage/Install/Installer/Env.php, and find

                Mage::getSingleton('install/session')->addError(
                    Mage::helper('install')->__('PHP Extension "%s" must be loaded', $extension)
                );

just above it, add

                if ($extension == 'mcrypt') {
                    return true;
                }

Step Two: create /lib/Varien/Crypt/Base64.php and throw this into it

<?php

class Varien_Crypt_Base64 extends Varien_Crypt_Abstract {
    public function __construct(array $data=array()) {
        parent::__construct($data);
    }

    public function init($key) {
         return $this;
    }

    public function encrypt($data) {
        if (!strlen($data)) {
            return $data;
        }

        return base64_encode($data);
    }

    public function decrypt($data) {
        if (!strlen($data)) {
            return $data;
        } 

        return  base64_decode($data);
    }
}

Last Step: edit /lib/Varien/Crypt.php and change

    static public function factory($method='mcrypt')

with

    static public function factory($method='base64')

I’m not too sure why it’s not a configuration option, but oh well.

And yeah, this is by no means secure. Far from it. It works well enough to use locally and that’s all I really care about. Hopefully this helps at least one other developer who is fighting with dependency hell. If I missed out any steps I apologize. I’ve been at this way too long.

Background

Before I go into much detail, let me begin by explaining my experience and background with vBulletin. My first use with vBulletin was back in 2004 on a gaming site. Since 2005, I have been developing on it as an application platform, and for a while, was doing it full time (2 years or so). I am confident that I am one of the most experience vBulletin modders around. I love vBulletin, though over the years I became annoyed with working with it due to the outdated codebase. In the past two years or so, I have shifted most of my custom develoment to Zend Framework, which is of course at a much higher standard.

With the illusion of vBulletin 4 in my mind, I was very excited to begin looking at it.

Internet Brands Acquisition

During the very early stages of vBulletin 4, vBulletin and its company, Jelsoft, were aquired by their biggest customer: Internet Brands. There are two very opposed reactions about this. The good: since their business relies on vBulletin, they will take good care of it. However, there is also the other way of looking at it: because their biggest competitors are also their customers, they have power to kill their competition and steer the product to their advantage.

Shortly after this took place, there were a lot of skeptics out there, but I didn’t think too much of it. I’m an optimist, and thought it was about time vBulletin was picked up by a bigger company. They needed the extra funding and development power.

After some time had passed, several of the core staff members began dropping like flies. More rumors started pouring out about the takeover. One of the reasons for this was IB is a US based company, and Jelsoft was a UK based company. It makes sense, but it wasn’t the reason many of the developers left. They were not happy with how the product was being managed. Their core values were changing.

Back to the Future – First Impressions

When vBulletin 4 first hit vBulletin.com, it looked pretty bad. However, I had some of that golden optimism reserved, because I know that it’s CSS based, and will take some time to get it right. I don’t care too much how the stock software looks, because I (like many others) will be customizing it to death. It took a lot of nagging, but we got some of the key things cleaned up. There’s still a lot of work to be done, but I don’t see it changing much more at this point.

Product Management

This may not be an entirely relevant point, but it needs to be said. Management has seriously dropped the ball – no, they kicked it over the fence. They are so focused on making release deadlines set by upper management (surely to impress investors) that the product quality has gone to shit. There are serious bugs in the “gold” (4.0) release that should have been fixed in a beta. It’s ridiculous. The whole 4.x release is a joke, because it’s not even a proper release. It’s a (poor) transition of the 3.5-3.8 line. It should have been called 3.9.

In the forum itself, the only big thing worth mentioning is the new CSS layout. The addition of the CMS is nice too, even though it’s a paid product. However, it is nowhere near production ready. I strongly recommend not to use it or vBuletin 4.x until things drastically change. If I have an ounce of hope left for vBulletin Solutions / IB, then it will be held within 5.0.

Anyway, let’s get into some specifics.

New Template System

The new style management system is horrible to use. I admit, it’s a step in the right direction, and I applaud forward movement. However, it was done very poorly. I’m glad there is a new template engine in place (though I prefer raw PHP), and I’m VERY glad that there is support for loops. It will take some time, but I hope by 5.0 they will have everything converted to use loops in templates instead of hundreds of bit templates. That’s what makes skinning so hard.

Skinning on 4.0 is more or less as painful as it was on 3.5-3.8.

New Default Design

I am liking the new design more and more, but I still don’t think it’s up to the latest standards of what is out there right now. I’m not talking about web standards, but just quality standards. It looks good, but it’s not great. With the addition of more UI people / designers, I expected a lot more.

New Codebase

The new code is pretty good. I think it’s a bit unnecessarily over-complicated though. There are ways to create a very brilliant application design without making it seem complicated. Simple code is readable code and it takes a lot more planning. I’m not going to complain though, because it’s about what I expected. They did good.

However (and this is a big one), the new codebase is barely used. It’s only used by the CMS, because vBulletin itself is still in transition. Really then, you are not getting much of anything new in 4.0 unless you get the suite.

I haven’t seen a single developer utilize the new codebase yet. Every single person I’ve talked to has only converted the templates to the new syntax. They really should have used something more simple for the template variable assignments. Like I said: simple code is well planned code. This does not appear to be well planned.

Another Look

You’ll notice a lot of the complaints I have are because vBulletin is in a transition stage. If they were to push this honestly as a transition release, and perhaps called it 3.9 and didn’t push so hard for pre sales, then this wouldn’t be all that bad. It’s a step in the right direction. It’s a shame that management had to butcher their great reputation and basically lie to all the customers.

Bottom Line

Alright, so in all fairness, it’s not a horrible release. However, there isn’t much new to justify upgrading in my opinion. It’s also not nearly as stable and deserving of a gold title as the previous branch. My advice? don’t waste your money on it. Wait for 5.x. Hopefully they can salvage what little reputation they have left before IPB steals any more customers.