I've found what seems to be a bug with ModelAdmin. I thought I'd post it here to see if anyone else has experienced the same thing before I submit a ticket (in case I'm using it wrong).

I am using a fresh SilverStripe install and the problem seems to be there in both 2.4.4 and 2.4.5.

I have created a very simple DataObject: 'Mug' with 1 field and a very simple ModelAdmin: MugAdmin to manage it (just to illustrate the problem).

The problem is that when I click the Delete action on the EditForm I get an error. The delete happens but the ResultsForm doesn't get loaded and the server returns:

500 Warning: "array_fill(): Number of elements must be positive" at line 743 of F:\...\cms\code\ModelAdmin.php

The basic DataObject (Mug):

class Mug extends DataObject {
    static $db = array(
        'Type' => 'Text'
    );
    
    static $searchable_fields = array(
        'Type'
    );
    
    static $summary_fields = array(
        'Type'
    );
    
    function getCMSFields() {
        $fields = parent::getCMSFields();
        $fields->addFieldToTab('Root.Main', new TextField('Type'));
        return $fields;
    }
}

and the ModelAdmin class:

class MugAdmin extends ModelAdmin {
    static $managed_models = array(
        'Mug'
    );
    
    static $url_segment = 'mugs';
    
    static $menu_title = 'Mugs';
}

I have found the problem to be that in the doDelete method of ModelAdmin_RecordController after the delete occurs a redirect is sent to 'SearchForm?action=search'.

This gets the SearchForm and the SearchForm then handles the request.

The httpSubmission method in Form then tries to load the data from the request into the form but since no data was sent with the request all data in the form is lost. This means the ResultAssembly in the form is empty and causes an error in getResultsTable where the line:

$tf->setFieldFormatting(array_combine(array_keys($summaryFields), array_fill(0,count($summaryFields), $url)));

tries to do an array_fill() where count($summaryFields) is 0.

I have just put

$form = $this->SearchForm();

at the start of the search method and this fixes the problem.

Thanks for the Fix!
I was scratching my head on this one...

For anyone how is looking for the place to add the fix: Just put it right behind line 650 in your ModelAdmin.

Thanks again!

Hi,

I am currently trying to tackle this issue too, however the fix only partially worked in my case and started to cause some other weird behavior.

Was this issue reported in the bug tracker? I did a quick search but didn't see it but just want to make sure before submitting it myself.

For now my temporary solution is to just remove the delete button completely by using the code below:

class MyModelAdmin_RecordController extends ModelAdmin_RecordController {
......
	public function EditForm() {
			$form = parent::EditForm();
			$fields = $form->Actions();
			$fields->removeByName('action_doDelete'); 
			$form->setActions ($fields);
			return $form;
	}
......
}

Thanks

Jim

Hi

I think the culprit might be the getResultColumns() function in line 694. in the following check (line 699):

if($selectedOnly && isset($searchCriteria['ResultAssembly'])) { 

I think this is a bug: it doesn't take into account that $searchCriteria['ResultAssembly'] might be empty, in which case no summaryfields are returned. Changing it to the following seems to fix that:

if($selectedOnly && isset($searchCriteria['ResultAssembly']) && !empty($searchCriteria['ResultAssembly'])) { 

After a successful delete, 'back' and 'forward' buttons now appear in the listing form for some reason. The following (hack, this time) removes them, and I have not encountered any problems afterwards:

around line 773, commenting these two lines:

new FieldSet(
	//new FormAction("goBack", _t('ModelAdmin.GOBACK', "Back")),
	//new FormAction("goForward", _t('ModelAdmin.GOFORWARD', "Forward"))
)

note: this should probably be solved better, but for now...

Hi Martimiz,

Great that works for me. Thanks for sharing the fix.

Cheers,

Jim