Enum label lookup

In your datamodel you might have a Enum field such as this date-based dropdown:

public static $db = array(
    "Year"        => "Enum('2013, 2014, 2015')"

Internally, SilverStripe stores the index, so that when you retrieve the value in methods such as onBeforeWrite, instead of 2013 you will receive 1. Use the function below to retrieve the label of the Enum:

public function EnumLabel($field_name) {
    $enumValues = $this->dbObject($field_name)->enumValues();
    $label    = $enumValues[$this->$field_name];
    return $label;

// $year = $this->EnumLabel('Year');

July 23, 2015 at 10:08 AM in SilverStripe

LessThanOrEqual in SilverStripe 3.0

When adding a filter on a DataList sometimes you need to do a <= rather than a <. Unfortunately the LessThanOrEqual and GreatherThanOrEqual search filters do not exist in SilverStripe 3.0.x, they were added in 3.1.

Therefore we have to write our own where clause like the following example:

// Return all the sessions on or before the $date
$sessions = new DataList('AcademicSession');
$sessions = $sessions->where('"SessionStartDate" <= \'' . $date . '\'');

July 23, 2015 at 10:11 AM in SilverStripe

How to provide and manage your own permissions

At some point on your journey through the jungle that is SilverStripe, you will want to create permissions and assign users to them. You might have created a Page Category model admin to categorise your pages, and setup the relations between pages and their category. By default when you create a category as an admin they will not be visible to any content authors and any content authors that can access the model admin can’t create any new items.

The solution to this dilemma is to create a new permission (for example PROJECT_CategoryAdmin) and then let people with that permission mange the category items. This is how to go about it:

Create the permission

You will need to tell SilverStripe you are implementing permission by changing the class declaration as follows (changes in bold):

class Category extends DataObject implements PermissionProvider

To create the new permission you will have to write a providePermissions() method for the Category class:

      public function providePermissions() {
        return array(
            "PROJECT_CategoryAdmin" => array(
                'name' => 'Administer categories',
                'category' => 'PROJECT',
                'help' => 'Manage categories.'

Finally, implement the permission by declaring the canCreate, canDelete, canEdit and canView methods to your liking:

    public function canCreate($member = null) {
        return Permission::check('PROJECT_CategoryAdmin');

    public function canDelete($member = null) {
        return Permission::check('PROJECT_CategoryAdmin');

    public function canEdit($member = null) {
        return Permission::check('PROJECT_CategoryAdmin');

    public function canView($member = null) {
        return Permission::check('PROJECT_CategoryAdmin') ;

Don’t forget to create a Role and/or assign the permission to the right Group(s), to make sure the right users can manage your categories.

July 7, 2015 at 4:26 PM in SilverStripe

SilverStripe relation records management – or why do I have so many database records?

You have a bunch of DataObjects that has_many RelatedItems. You might have the following seperate situations:

  1. Get the Dataobject->RelatedItems() and remove() one RelatedItem. What happens to that RelatedItem?
  2. Delete() a DataObject. What happens to the RelatedItems for that DataObject?

Regarding 1: (in SilverStripe 3.0.x) – the DataObjectID for that RelatedItem is set to 0.

Regarding 2: Nothing, their DataObjectID will point to a non-existing record.

Wrong Expectations

In both cases I expected the objects to be deleted, but SilverStripe is going for safety first and keeps the records around just in case.

This means that you might need to write maintenance code if you don’t expect this happening.

Things to keep in mind

If you are writing an sync task and want to make sure RelatedItems are fresh, do not delete / remove RelatedItems before creating new ones. You will be creating thousands of records over time.

Instead, get the list of IDs, and unset the IDs that you find. Then remove any IDs left in the list as they weren’t in the source.

March 3, 2014 at 1:47 PM in SilverStripe

SilverStripe Gists

I’ve released the following data extensions (might pack them up as modules):

  • HiddenFields DataExtension: Takes form fields specified through $hidden_fields and hides them from edit form. View code
  • Description DataExtension: Specify a $db_descriptions array to DataObjects to attach formfield descriptions. View code

November 12, 2012 at 9:07 AM in SilverStripe

OptimisticLocking SilverStripe Module Release

Some of you might be interested in my first ss module: silverstripe-optimisticlocking

This is a very simple module that prevents your site users from losing data. It works by by blocking the save process if the record changed since it was retrieved, preventing accidental overwrites. (user1 starts editing, user 2 starts editing, user1 saves, now user2 can’t overwrite user1’s changes). By default, Silverstripe lets you lose data by overwriting the record on save.

You might know that Pages benefit from versioning (so you can restore to a previous version), however by default DataObjects don’t have versioning enabled so this module will come in handy then (AFAIK it’s not trivial to enable either).

If feedback is good, I will try to add it to the SilverStripe modules list.

November 8, 2012 at 1:04 PM in SilverStripe