Upgrading to SilverStripe 3.1 beta

With a day of waiting on washing to finish spinning and some cat food to hunt down, to avoid the possibility of being eaten in my sleep by the hungry carnivore that roams my apartment, it seemed I had some spare time. So what better way to spend it than upgrade my own website from a stable SiverStripe version of 3.0 to the cutting edge 3.1 beta release. I have to admit, I like new and shiny toys.

The final result seems to have been successful but took a little while, so I shall share a few of the "gotcha" experiences and the subtle differences between 3.0 and 3.1 beta.

Access Levels

Well I like to keep my bits and pieces private, so I always felt a little uncomfortable about defining a DataObject with public fields. Up until 3.1 beta, you used to define them such as:

class Job extends Page {
    public static $has_one = array(
        "Client" => "Client"
    );
}

In fact this was deprecated in 3.0 but notices don't start appearing until 3.1 and above.

The above seems wrong to me. I don't whip my bits out in public, leave some mystery has always been my policy. Well that, and good OO coding practices. But after changing over to 3.1 beta and running the above style code I kept getting errors about access levels: Access level to ErrorPage::$db must be public (as in class Page)

I was scratching my head for sometime, I hadn't touched the ErrorPage class, it is part of the cms module. I dug out the class and looked it over, took a few moments to dawn on me, "Those whacky guys at SilverStripe" and then looked around at the rest of the framework and noticed all those nasty public statics had become private static, hidden from devious fingers. So now DataObjects should be defined as:

class Job extends Page {
    private static $has_one = array(
        "Client" => "Client"
    );
}

The simple lesson, ensure that you use private static for defining fields for DataObjects. A much wiser plan.

Deprecations

Ensure you are running your site in dev mode, rather than live. This will highlight any deprecations, rather than quietly letting them slide by. This can be done in your site's _ss_environment.php file or _config.php of your project.

With your site set in development mode, you can consult your logs for deprecations, and get rid of them. A good clean log is a sign of a health application or a healthy bowel as my doctor tells me.

Deprecations: Extensions

Coming from SilverStripe 2.4 to 3.0 you will already have found DataObjectDecorators are now called DataExtensions, which I think is a much nicer name and to be honest, easier to type. But it seems the transition from 3.0 to 3.1 beta has made something else deprecated, extra statics.

You used to define your DataExtensions extra statics like:

class SiteConfigExtension extends DataExtension {
    public function extraStatics($class = null, $extension = null) {
        return array(
            "db" => array(
                'Analytics' => 'Varchar(100)'
        ));
    }
}

But now, through the magic of the SilverStripe development team, it is defined as you do for any of your DataObjects:

class SiteConfigExtension extends DataExtension {
    private static $db = array(
        'Analytics' => 'Varchar(100)'
    );
}

Much more consistent.

Deprecations: Templates

The only deprecation I found was the template control statement control has been deprecated. In 3.0 loop was used in place of control for looping over a list of items. But now, with is used in place of control for setting the scope. So just change control with with and loop where appropriate, job done.

Immutable DataLists

In my first attempt at this website, I was using DataList objects in a mutable way, I had noticed the comments about it becoming immutable in 3.1 but apparently common sense and future proofing had not sunk in. I was doing something like:

$query = "Wizard";
$results = DataObject::get("Job", "", "Title ASC");
$results->filter(array("ShowInSearch:Negation" => 0));
$results->filter(array("Title:StartsWith" => $query));

I got away with the above as very bad code monkey, but as 3.0 DataLists were mutable, now they aren't. Also the NegationFilter has been deprecated, so code should now look like:

$query = "Wizard";
$results = DataObject::get("Job", "", "Title ASC");
$results = $results->filter(array("ShowInSearch:not" => 0));
$results = $results->filter(array("Title:StartsWith" => $query));

Subtle differences using method chaining but the results are very different.

Now there maybe many other differences, but these are what I discovered thus far. Also this is a beta release, so could be more in the full release, but if it saves you a few minutes of pain and less swearing, excellent.