Obsolete class names cause UDF pages to fail to publish with error Please implement a getFormField() on your EditableFormClass

[andrewandante]

Using 5.8.3.

Replication steps:

• create a new EditableFormField class (SuperTextField)
• create a UserForm with one of these fields
• publish page
• rejoice!
• remove SuperTextField class from codebase
• note that the field has been changed to a CheckboxField (I assume this is just the first one in the list?)
• attempt to Publish again

This seems to have been introduced with this commit:

c0a30f1

As now we are calling getFormField() in the onBeforeWrite() method - which, if the ClassName value of a field is now invalid, falls back to the Parent class, which throws the user_error. Tested with a previous version (5.5.2) and the form successfully published and fixed the ClassName as expected.

Proposed solutions:

• return null and log an error instead of throwing user_error in the default getFormField() method
• improve behaviour on fields with an unresolvable ClassName - I believe SiteTree does this, warns you or something?

[sinan-evanshunt]

Running into a similar situation.
On SilverStripe Cloud, we applied security updates. We can deploy on the UAT env. and everything works. But dev/build fails when we try to deploy to PROD env.
Pulling the database from PROD back to local and to UAT results in this same error Please implement a getFormField() on your EditableFormClass
Commenting out this part

$formField = $this->getFormField();
if ($formField && !$formField->hasData()) {
    $this->Required = false;
}

would make dev/build run fine, but of course, we are reverting a module's core edit and introducing the error that this block of code tries to fix.

Update:
After further investigation, it turned out to be an archived form was causing this error. My workaround for now is:

• restore the version of the form before archiving
• publish it or just restore it to draft
• run dev/build
• archive the form

[michalkleiner]

I think this is a data vs code consistency issue and devs should take care of it. If it's within the UDF module itself that some form field type was removed, then it should be fixed here.

One of the solutions if there's a comparable new class or a class that the obsolete field types should change to, use the remapping mechanism in legacy.yml such as

SilverStripe\ORM\DatabaseAdmin:
  classname_value_remapping:
    "Old\Field\Class\Name": "New\Field\Class\Name"

[sinan-evanshunt]

The trick that worked before doesn't work anymore.
I have encountered it again when applying the latest security updates for SilverStripe 4.

I have an archived userform and I did restore it to draft and also published it, yet I still encounter the same error [User Error] Please implement a getFormField() on your EditableFormClass SilverStripe\UserForms\Model\EditableFormField

I tried to edit the database table and expunge the records that point to the archived form ID, but I don't seem to have managed to do that, not to mention editing the database directly like that is not the best workaround.

[mikey-harveycameron]

I just got stung by this during a new website launch. Please fix :)