After upgrading from 2.6.3 to 2.7.0 we got this error when clicking on “Create request” from workspace navigation menu:
ERROR:Couldn’t find form element in any form int the page! Init aborted
After clicking the OK button 4 times the msg disappears, but at-least one of our custom fields (drop-down) are empty.
(Cannot remember the exact number had to downgrade to our backup ASAP)
Hi Hans,
We don’t have any other reports of this. Was it a regular drop down field for a multilevel drop down? Had you run installer.php after upgrading the files? Did it happen on existing requests or just new? What browser was this, did you have a chance to try other browsers?
Perhaps you could upgrade on a test instance when you have a chance so if there’s an issue we can debug there before you roll it out to your production one.
I’ve just completed installation on a virtual host and I have experimented with upgrading a few time (starting over from database backups). Here are my findings after upgrading to 2.7.0:
Clicking on existing requests or the “create request” link results in the error descrobed above
Clicking on closed requests global filter results in a blank page. (no html in the source what soever)
I suspect the culprit is that we have non-us characters in on of our custom request fields (a multi-level drop down field).
After the upgrade i can still go to admin->tools->custom request fields and click on this particular field
If i then click on save (without editing) i can create/view requests, but i still cannot view the “closed request” page.
Also when going to admin->tools->custom request fields and click on this field It does not display the field it just displays as if it was an empty multilevel drop down.
Looking into the difference of the HS_CustomFields table before and after the save i can see that the non-us chars are saved differently. (both display correctly in HelpSpot).
Don’t know if you get the picture, I could send screendumps
Just to answer some of your questions:
I did run installer.php
This is a multilevel-dropdown field
This seems to happen in both Firefox and Internet Explorer (most extensively tested in FF, but I know that at least some of it also happens in IE)
Hi Hans,
Had you made any changes to your HS in terms of the encoding of the pages in english-us.php? The installer shouldn’t have changed the way the HS_CustomFields table stores the information, no changes were made between 2.6.3-2.7 that would have updated that table automatically. Did you do a DB change in there? Are you doing this all on a test environment, is it identical to your production one?
If you could send us in screenshots and whatever other information you have to customer.service at userscape.com that would be great.
No, I simply
Made a backup of the database
copied the files from helpspot_2.6.3 to helpspot_2.7.0
extracted helpspot_2.7.0.tar.gz
changed symbolic link to point to the 2.7.0 installation
loaded installer.php
I don’t think installer changed the database, but perhaps it should?
It seems that the page for edting the custom fields save with encoding, but is only able to load the old encoding (as seen in the files i will upload)
Also other pages cannot cope with the old encoding (as described in my original post)