Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Data Model Questions /

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Bug renaming DataObject SummaryFields?

Go to End

4 Posts   2218 Views


Community Member, 2 Posts

6 February 2014 at 11:48am

Edited: 06/02/2014 11:52am


I have extended DataObject and was trying to get it to display nice headers in the CMS Overview. According to the documentation it's supposed to be as simple as specifying an associative array. However if I do it like it's done in the documentation the "nice names" don't show up but instead it will display the actual field names as headers in the CMS.
When I tried to add another column (summary field) from another Object from a has_one relationship and thus used the dot notation mentioned and demonstrated in the documentation it displayed the correct nice name for that column and the correct data, however all the other columns were suddenly empty.

The Code:

class MyObj extends DataObject {
	private static $db = array(
		'dttm' => 'SS_DateTime',
		'name' => 'varchar(255)',
		'location' => 'varchar(255)',
	private static $has_one = array('Page' => 'Page', 'Category' => 'MyCategory');
	//private static $summary_fields = array('dttm' => 'Date', 'name' => 'Name', 'location' => 'Where'); // Does display content for all columns but only shows raw field names as column headers instead of the nice name.
	//private static $summary_fields = array('dttm' => 'Date', 'name' => 'Name', 'location' => 'Where', 'Category.short' => 'Type'); // According to Documentation this should work. Doesn't display any content but Type, has raw field name correct column headers for all but Type.
	//private static $summary_fields = array('dttm.Nice' => 'Date', 'name' => 'Name', 'location' => 'Where', 'Category.short' => 'Type'); // According to documentation this should work. Shows no data but Type and Date, has correct column headers for Date and Type ONLY.
	//private static $summary_fields = array('dttm.Nice' => 'Date', 'name.Summary' => 'Name', 'location.Summary' => 'Where', 'Category.short' => 'Type'); // Does display content for Date and Type only, has correct column headers for all columns. No Summary on varchar, so not displaying data is to be expected I guess.
	private static $summary_fields = array('dttm.Nice' => 'Date', 'name.getValue' => 'Name', 'location.getValue' => 'Where', 'Category.short' => 'Type'); // Finally displays correct Data and column headers for all columns. Guessing the outcome / trying random functions on varchar worked at last.


class MyCategory extends DataObject {
	private static $db = array(
		'name' => 'varchar(60)',
		'short' => 'varchar(4)'
	private static $has_one = array('Page' => 'Page');
	private static $summary_fields = array('name', 'short');

So it seems that nice column headers only work when you are using dot notation for the summary fields (which is quite a pain and superfluous). I don't necessarily need or want to display nice dates, not to mention having to call a function for each one adds unnecessary overhead.
All of this leads me to believe that there is a Bug, or at the very least undesirable behavior that should be fixed to match the documentation, which makes sense.
All of this has been done on SilverStripe 3.1.2

Even though unrelated, another thing I noticed is that I had to run /dev/build each time I changed the summary_fields in order to see any changes in the CMS in the first place, which seems weird considering that shouldn't cause any modifications to the database (nor were any indicated on the /dev/build output). It's just PHP Code which as far as I can tell gets executed every time the cms page is loaded so there should be no need to run /dev/build for these kind of changes to take effect.


Forum Moderator, 1391 Posts

8 February 2014 at 10:14am

Edited: 08/02/2014 10:15am

This is indeed a bit strange! In the following example (after doing a ?flush=all, of course :) ):

private static $summary_fields = array(
	'Name' => 'Your name',
	'Product.Title' => 'Your product'

The headers will read 'Name' and 'Your product'. For dotted notation it seems to work, for simple fields it doesn't. Would that be by design? Maybe raise an issue on Github...

I normaly use the fieldLabels function to get all my labels/headers. It's more flexible, as you can use it for all your objects fields, and localize them as well:

public function fieldLabels($includerelations = true) {
		$labels = parent::fieldLabels(true);

		$labels['Name'] = _t('MyObject.NAME', 'Name');
		$labels['PageID'] = _t('MyObject.PAGE', 'Page');
		$labels['Product.Title'] = _t('MyObject.PRODUCT', 'Product title');

		return $labels;


Community Member, 2 Posts

8 February 2014 at 11:12am

I will have to look in to that fieldLabels function and make some tests and see how that works. Thanks for the suggestion. Kind of hard to know all the options and possibilities :)
Guess it is time to create a GitHub Account to raise an issue there...


Community Member, 17 Posts

9 March 2016 at 9:56am

Edited: 09/03/2016 9:57am

Found this post while searching for a solution the problem where trying to set the label in $summary_fields for fields included from related objects (using the dot operator) resulted in the value for that field being blank in a gridfield.

Agree there appears to be something odd going on with summary_fields when trying to do custom labels for fields in related objects.

Found a way around this though, so I thought I would share incase anyone else finds this this post while searching for this problem...

Rather than using the summary_fields to give a custom name to the fields, populate summary fields like normal, for example

private static $summary_fields = array(

Then use $field_labels to set the label for the fields you want to name differently

private static $field_labels = array(
    'QualificationRelationshipType.Title' => 'Relationship Type',
    'QualificationRelevanceLevel.Title' => 'Relevance Level',

A gridfield will pick up on this and display what is specified in field_labels for the fields, so this avoids trying to have to use summary_fields to do this.

This worked for me in Silverstripe version 3.1.2.