There was no discussion about this, since it isn't possible to predict what the extension author wants to execute on revert in case of an
if
. You can't invert the condition as that might not be always true and you can't invert the call since this isn't always true for all. Thus, we just avoid it altogether now.
Also, this was just an information since it is possible that this was the intended case in the past too, it just wasn't coded that way.
The usage is just about the same.
On revert only the non-revertable migration steps from
update_data()
have to be included in
revert_data()
.
Non-revertable migration steps are custom methods and (this is new!
) steps that are only executed when a certain condition is true.
So,
on revert this
update_data()
:
Code: Select all
public function update_data()
{
return array(
array('config.add', array('foobar', 1)),
array('if', array(
true,
array('permission.add', array('some_data')),
)),
array('config.remove', array('foobar')),
array('custom', array(array($this, 'foo_bar'))),
);
}
will result in these steps being executed in this order: (the steps will be reversed as you can see)
Code: Select all
array('config.reverse', array('remove', 'foobar')),
array('config.reverse', array('add', 'foobar', 1)),
which means that you have to add the custom call and the conditional step to the
revert_data()
if this is necessary.