EOI Form Crashes When Editing Content

Permalink Browser Info Environment
I have recently used this add-on for a complex online Expression of Interest (EOI) application form for a large private school organisation. The tenderers were all bidding for multi-million dollar construction contracts. There were 20 submissions in the EOI in the two week period and several companies experienced major problems using the form. I was trying to trouble-shoot the issues as we went but I found that some of the error messages were not allowing me to find the cause of the crashes. In all cases they were Unexpected Error Occurred messages saying that the row size was too large. However the form was usually submitted initially without problems. It is only when the user goes back to edit the form that they get this error message and they do not know if their information has been lost or saved. I have attached a typical screen shot error message. The information in the fields did not seem to be excessive and the form was accepted in the first instance without an error.

My client is very unhappy about the result and the problems it caused his tenderers. I cannot give him any reason for the problem as I cannot see from the error where the error is occurring.

In addition I have a further problem which the client is unhappy about. There were 20 submissions to the EOI, but if I go to the ProForms Search Submissions page I can only export 17 of the submissions in the CSV file. The other three are not showing up. However I can view all 20 submissions using the Profoms List Block on a page.

I need to have the form work in such a way that people can add their information and come back later to edit it without getting error messages.

Can you please help on this matter. Also how can I recover the three lost entries on the CSV export.

Kind regards

1 Attachment

Type: Discussion
Status: In Progress
View Replies:
RadiantWeb replied on at Permalink Reply
Hi there,

This is an auto responder to let you know that your support ticket has been forwarded to our entire support team at RadiantWeb!

Support tickets are reviewed Mondays thru Fridays 9am to 9pm & Saturdays 9am to 12pm EST.

A support team member will be following up with you as soon as possible.

Thank for supporting RadiantWeb Products!

RadiantWeb Support
RadiantWeb replied on at Permalink Reply
Hi Ian,

First, you need to contact you web host and make sure they see that image. I (or the addon) can not do anything at all to help with that. Your form has hundreds of questions. That is a massive form! So, it's your web host that is limiting you here and timing out. As far as why it submits initially and not on edit, I don't know. Both use the exact same method...just one creates a new form entry object and other does not.

As for form entries and export, if you do not see two entries, then the system is not viewing them as part of that form ID.

I would have to assume this is cause by some errors from your server. It's also possible that ajax form submit errors also, but you are not seeing it.

I would start with fixing the editing experience with your web host first.

Again...there is zero code I can change to effect this.

ianj replied on at Permalink Reply
Hi Chad,

The website is hosted on a dedicated managed VPS. I am the host. I have set up the PHP settings with pretty generous values (I thought). You can view the PHP settings at this link


I will take that link down once I resolve this issue.

The error message I am getting is a MySQL error. As per the attachment I sent you it states that the Row Size is too large. It does not seem to be a timeout issue.

mysql error: [1118: Row size too large (>8126), Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW-FORMAT=COMPRESSED may help. In the current row format, BLOB prefix of 768 bytes is stored inline]

I really need to resolve this issue as quickly as possible.

ianj replied on at Permalink Reply
Hi Chad,

I need to know what to look for to solve this issue. It is not a time-out issue on the server as the Error message comes up as soon as an edited form is re-submitted. The error message states that it is a MySQL problem. I had the same issue come up on a different server with a different website the last time I used your ProForms Add-on.

I have been a pretty loyal supporter of your Add-Ons over the past few years and having built over 80 C5 websites I know when a server setup is causing problems. I feel a bit "fobbed off" at the moment by your response.

RadiantWeb replied on at Permalink Reply
Hi Ian,

I don't think you understand.... there is nothing I can do here. Not one single line of code will fix your server not being able to handle db strings of that size.

I am not trying to be dismissive. Honestly. But this is a server sql issue. Not an addon/code issue.

I can't give you the specifics because I am neither an IT server admin nor know anything about your server setup.

All I can say is that your mysql db is not able to handle that size of string.....which is an absolutely massive string size by the way. lol

Good Luck. And I earnestly do appreciate your faithful support and use. I mean that.

RadiantWeb replied on at Permalink Reply
One thing you can do is break your form up into several forms, and then pass each one to the next. That would reduce the string size in a single submission.

page1 -> form1 : forwards to page2 -> form2 : forwards to page3 -> form3

Just be sure to pass the Entry# from form to form.

RadiantWeb replied on at Permalink Reply
In reading the error, it also looks as though you have a row size (sum) error. So it's possible you're exceeding the max character use for any number of columns. So you could edit the ProformsItemSearchIndex table and change all of the columns to some astronomical character length??? I have no clue...I have never seen anything like that.

ianj replied on at Permalink Reply
Hi Chad,

Sorry about my tone, I am just a little frustrated. I have worked hard to get these clients and finding the inadequacies of working with C5 is a little annoying.

I don't think the breakup of the form will work as they want to be able to pull out a single CSV with all the responses after the close of the EOI so they can compare. I am guessing that the breakup will be separate tables.

Just two questions.

Firstly, is there a possibility that I can limit the number of characters a user can add to a text block in the form. Sort of have a countdown of characters remaining appearing at the side of the text block so people do not add compositions. This may limit the size of the DB input and prevent the errors from happening.

If this is an extra development I am happy to fund it, but I need to come back to my client with some sort of solution, not a "go somewhere else" answer.

Secondly, I need to recover the data from the database for the three entries that are not showing up on the current export to CSV function. Which database table contains the form entries so I can extract the information directly from the DB.



concrete5 Environment Information

# concrete5 Version

# concrete5 Packages
Advanced Slider (1.2), Content Slider (1.2.4), Discussion (1.8.4), Document Library (1.6.1), Easy Accordion (1.1), Easy tabs (1.6.9), Expand / Collapse (1.2.1), Extended Form (2.6), FlexSlider (2.1.1), Mailing List (2.48), Page to PDF (1.0.4), Print my page (1.0.3), Pro Forms (6.0.2), Silence Theme (1.3.3), Sortable Fancybox Gallery (1.17), tnSpacer (1.3).

# concrete5 Overrides
controllers/profile, elements/profile, single_pages/profile

# Server Software
Apache/2.2.29 (Unix) mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4

# Server API

# PHP Version

# PHP Extensions
bcmath, bz2, calendar, cgi-fcgi, Core, ctype, curl, date, dom, ereg, exif, fileinfo, filter, ftp, gd, hash, iconv, imap, ionCube Loader, json, libxml, mcrypt, mysql, mysqli, mysqlnd, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, Phar, posix, Reflection, session, SimpleXML, sockets, SPL, sqlite3, standard, timezonedb, tokenizer, xml, xmlreader, xmlwriter, Zend Guard Loader, zip, zlib.

# PHP Settings
max_execution_time - 30
log_errors_max_len - 1024
max_file_uploads - 20
max_input_nesting_level - 64
max_input_time - 60
max_input_vars - 1000
memory_limit - 128M
post_max_size - 120M
sql.safe_mode - Off
upload_max_filesize - 120M
mysql.max_links - Unlimited
mysql.max_persistent - Unlimited
mysqli.max_links - Unlimited
mysqli.max_persistent - Unlimited
pcre.backtrack_limit - 1000000
pcre.recursion_limit - 100000
session.cache_limiter - nocache
session.gc_maxlifetime - 7200

Browser User-Agent String

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36

Hide Post Content

This will replace the post content with the message: "Content has been removed by an Administrator"

Hide Content

Request Refund

You may not request a refund that is not currently owned by you.