CMS MADE SIMPLE FORGE

Form Builder

 
Back Back to List

[#9546] Fatal error: Call to undefined method fbDispositionDatabase::fbFieldBase() in modules/FormBuilder/classes/DispositionDatabase.class.php on line 16

avatar
Created By: Ryan Foster (RytoEX)
Date Submitted: Wed Sep 18 02:45:06 -0400 2013

Assigned To:
Version: 0.7.4
CMSMS Version: None
Severity: Minor
Resolution: None
State: Closed
Summary:
Fatal error: Call to undefined method fbDispositionDatabase::fbFieldBase() in modules/FormBuilder/classes/DispositionDatabase.class.php on line 16
Detailed Description:
I used Module Manager to update from FormBuilder 0.7.3 to 0.7.4 and it didn't
seem to delete the classes/DispositionDatabase.class.php file.  When I tried to
edit a form which still had that disposition as a field, I got this error:

Fatal error: Call to undefined method fbDispositionDatabase::fbFieldBase() in
modules/FormBuilder/classes/DispositionDatabase.class.php on line 16



I manually deleted the file, tried again to edit the form, and got this error:
Warning: require_once(modules/FormBuilder/classes/DispositionDatabase.class.php)
[function.require-once]: failed to open stream: No such file or directory in
modules/FormBuilder/classes/Form.class.php on line 1375

Fatal error: require_once() [function.require]: Failed opening required
'modules/FormBuilder/classes/DispositionDatabase.class.php'
(include_path='.:/usr/local/lib/php:/usr/local/php5/lib/pear') in
modules/FormBuilder/classes/Form.class.php on line 1375



Can we consider ways to handle this kind of class/disposition removal better? 
True, a user could export and import the form, but it would be a better user
experience if this was handled gracefully by the software.  The easiest ways I
can think of at the moment are:
1)  Check all saved forms during the upgrade and delete the field for the
removed class/disposition (hopefully with user confirmation, though I'm not sure
how we'd do that during the upgrade process).  This way it's only checked once -
during the upgrade.
2)  Check each form as it's opened and delete the field for the removed
class/disposition (again, hopefully with user confirmation).  Though, this would
mean the check runs every time a form is opened, unless certain flags were set
to only do it on the backend, and possibly a flag for whether or not the form
was already checked or a flag for whether or not the form needs attention (field
detected as present).
3)  Some combination of 1 and 2.  Perhaps check all forms during upgrade and set
flags to indicate which forms need attention, then notify the user after the
upgrade?

It's late, and I'm probably not really thinking this through very well.  Maybe
it's a really tiny edge case that only a small percentage of users will have,
who knows.


History

Comments
avatar 
Date: 2013-09-23 18:20
Posted By: Ryan Foster (RytoEX)

Actually, the Export XML operation also tries to call the class, so that fails
too.  The only current solution is to downgrade to an earlier version of
FormBuilder that has the disposition (in this case, 0.7.3), and edit/export the
form there before upgrading.
avatar 
Date: 2013-10-24 02:45
Posted By: Jan van Leeuwen (janvl)

HI,

After I deleted a field that used the database for Formbrowser I could rebuild
the form in a new form.
I still cannot access it.
Even after removing module Formbrowser I still cannot access the form.

I had a field in the form with "save the content to the database" or something
like that (my install is german).

Hope this helps.

Kind regards,
Jan
avatar 
Date: 2014-01-20 11:58
Posted By: pixie (pigsound)

browsing through the forums, obviously there are quite some people facing the
same problem with version 0.7.4.
it would be great if you added some notification of this occurence to prevent
people from updating to 0.7.4 and afterwards having to downgrade and possibly
lose their previously setup custom forms.
avatar 
Date: 2014-10-20 05:28
Posted By: Rolf (rolf1)

Because the 0.7.4 release was unstable, we went back to the working code of
0.7.3 and started working from there.
First priority: a stable Formbuilder release!
Updates

Updated: 2014-10-20 05:28
cmsms_version_id: 30123 => -1
state: Open => Closed

Updated: 2013-09-18 02:46
description: I used Module Manager to update from FormBuilder 0.7.3 to 0.7.4 and it didn't seem to delete the classes/DispositionDatabase.class.php file. When I tried to edit a form which still had that disposition as a field, I got this error: Fatal error: Call t => I used Module Manager to update from FormBuilder 0.7.3 to 0.7.4 and it didn't seem to delete the classes/DispositionDatabase.class.php file. When I tried to edit a form which still had that disposition as a field, I got this error: Fatal error: Call t
resolution_id: => 5