A calc field doesn't work for a particular record

[Borox]

Hi,

I used some calc fields without any problem but in one case I have a strange behavior.

I calculate a date using a start date and a duration:


Most of the time it works great.
But I found one record where the calculation isn't perform:


For that record I have 'loading' all the time.

If I save the record the value in the field is correct (the calculation is done).

If I use 'Calc on load': NO I can see that the field value doesn't change when I change the start date or the delay.

Is someone has an idea on what can prevent the calculation to be done for a particular record?

Thanks.

 

[cheesegrits]

Can you point me at the form?

-- hugh

 

[Borox]

Hi Hugh,

Here: https://www.le-site-du-conseil-syndical.com/index.php/parametrage-site/residences-activees/form/53/1

Go to the folder 'Contact'

You can use your account ( information in 'my website')

Try another line, the calculation is done without problem.

Thanks

 

[cheesegrits]

Nope, the account you have for me in your My Sites doesn't work.

-- hugh

 

[Borox]

Sorry, now it works ( just tested), use the website 'Site copro - Development version'

 

[cheesegrits]

OK, the error being thrown by the calc is:

DateTime::__construct(): Failed to parse time string (2017-12-05%2019%3A21%3A55) at position 10 (%): Unexpected character

... which means that some of your dates (in this case I think it's identitee_fichiers_pv_ag___date_time) are not getting urldecoded at the server side (replacing those encodings so it becomes "2017-12-05 21:55").

(I know that date isn't used in your calc code, but all the form data still gets pre-processed prior to your calc code running, to format it correctly for use .... so, for example, all date elements get processed with DateTime() into the specified form format)

The only reason I can think that this would happen on some pages and not others is that on this page you have a huge number of repeats, so there are 1171 form inputs being submitted - the AJAX calc has to post all the form data, so the code on the server side has it.

And as your max_input_vars in PHP is set to 1000, that means unpredictable things will happen with the inputs >1000.

So try doubling the max_input_vars setting in your php.ini. Although I notice that your "master" for that is set to 10000, but the the "local" value is still the default 1000, which may mean you have an INI override somewhere.

But be warned, that HTML really wasn't designed to have forms this big, with this many inputs, and you may want to consider redesigning your workflow to break up this form into more manageable chunks, to avoid problems in the future as your data sets grow.

-- hugh

 

[Borox]

Thanks a lot Hugh.
I have some problem to change the local value of max_input_vars but I will let you know.

 

[cheesegrits]

You'll need to figure it out, as I know of other things that break if you exceed that limit.

-- hugh

 

[Borox]

I managed to raise max_input_vars and no more problem !
Thanks Hugh!