Forums

hi guys,

I recently did the upg from V3 RC5.0 to V5.5. I installed as suggested over the top of the existing version and did not remove and reinstall.

The upg appeared to go well. The forms perform OK and all d/bases writes and reads are fine. the issue I have is with the back-end admin.

I can access the back-end OK, but any updates done to a form don't "stick". The admin function appears to save OK, but when you go back into a form to review the change, then changes made have not stuck and the original settings remain. This has virtually locked the form in the state it was before the upg.

I performed the SQl update from the admin panel and it said it worked OK so I am at a loss to understand what is happening. :?

why am I having this trouble?

thanks

aj

Hi aj,

Please try clearing your browser cache in case some 'old' scripts are still being used.

Bob

Hi Bob,

did as suggested and no joy.

I try to change some code. do a save and then reopen the form. The original code is still there.

I can access the d/base via phpadmin and change the code. This change is then reflected via the admin i/face but that is the only way to make changes.

Any other thoughts?

aj

Hi aj,

I've seen this when I have $mainframe->redirect() in my code - do you have that anywhere?

Otherwise please will you email or PM me a SuperAdmin login so that I can take a look?

Bob

Hi Bob,

no $ mainframe in my code that I can recall. Admin info PM'd to you

aj

Hi aj,

I was able to make small changes in the Form HTMl of of two of your forms with no problems at all :-( Using FireFox for what it's worth.

Bob

PS and in IE8 too

Hey Bob,

which forms? I have been testing form - rf3. I also noticed I couldn't change the redirect URLs in forms so I'm interested to establish if it is a single form or many forms having troubles.

Thanks

aj

Hi again,

I found another intertesting sideline problem here.

I have a form regocsvexport. The code is something from the forum that Max provided. It works great but when you save it in the admin backend, it executes the code rather than saves it (i.e. it creates the csv file of the table it is grabbing the data from).

Interestingly it has $mainframe in it.

whilst you still have valid credentials, could you have a look and see if the update problem we are discussing occrs on this form for you?

Thanks

aj

Hi aj,

Hmmm . . . Max changed the code in one of the recent releases so that the Form HTML (and maybe other code) is executed when it is saved so that ChronoForms can extract the field names. This is what causes the $mainframe->redirect problem and almost certainly this problem too.

I think it may need re-thinking :-(

Bob

Hi Bob and Max,

Back agin on this issue.

I am still having trouble saving changes. the issue is not consistent. I can't cut and paste at all and typing diretcly into the code box only saves randomly but most times it doesn't. I have also noticed that if I click on either "Apply" or "Save" it goes back to the form management list rather than the general tab of the form being changed. In previous versions that only happened when you cliked on "Save".

I'm now looking for how to rectify the problem.

I was thinking about backing up the forms, removing CF 5.5 and installing RC5.2 (the version I was on previously). Is there any danger here as I have done the SQL update phase? do you have any other suggestions as the current instability is not workable

aj

Hi aj,

Please contact Max directly - I don't know what risks might be involved in down-grading.

Bob

Hi Max and Bob,

Bob,

Have contacted max directly by PM. Awaiting a response.


an updated on my issue:

1. backed up all forms and removed RC5.5.
2. reinstalled RC5.5 and then restored forms. found a code error in one and fixed it.
3. cut and paste into forms seemed to work for about an hour. then it stopped and attempting changing ANY for code failed. A check via phpAdmin into the d/base revealed nothing had been changed and this was reflected into what was visible via the GUI.
4. Modified the d/base directly to change HTML code. this was successful and the changes were reflected via the CC backend GUI.
5. all forms, emails and inserts into d/bases are working very well. Only updating via the admin backend is at issue.


Max,

This RC seems very unstable when updating forms as updates to the relevant database are being committed. In previous RC versions you could do updates to forms hour upon hour (I know as it took me many updates to get a couple of the forms to work properly). In this version cut and paste as well as typing directly into the code boxes fails with RC5.5. Also I have had problems changing info in the general TAB as well.

it may be relevant (or not). All my forms have php code embedded.

I am about to go live with final user acceptance testing. The performance of the forms themselves is fine as stated earlier. Changing code to fix issues is the problem. I have a workaround, in so far I modify the table holding form info, but this is not ideal for the long term.

any thoughts?

Max,

url as requested

http://rego.wphcfc.net.au

UID and PWD sent as requested in PM.

Thanks

aj

Hi ajw3208,

I discovered a possible workaround yesterday. I'm not sure if it will work in your case though.

When you use the 'Save' button for a form ChronoForms currently evaluates the Form Code to extract a list of field names. Most of the time this is painless and invisible. However if there is PHP in your form code - either directly, or 'included' or 'required' then ther can be problems. I've identified two so far. (a) $mainframe->redirect(); is executed and the page redirects; (b) any PHP Errors will crash the Save process and if Error Reporting is not on this may result in a blank page. I had one yesterday where I had a function defined in the Form HTML and got a 'Cannot redefine function XXX' as a Fatal Error (even though the function was only defined in this one place).

Personally I think this is a serious design fault in this ChronoForms release :-(

The workaround I found is to Apply the form, not Save it. It seems that the code is not then executed and all saves smoothly. You can then Cancel to exit from the saved form (or even Save seems to work after Apply). I don't know why this should be so and it may not work in all circumstances but it did work for me yesterday after a very frustrating half-hour.

Bob

Hey Bob,

Have't tried that, but I do agree re: PHP. I have noticed most (if not all) the "save" problems occur when there is php in the code. forms without any php seem to update and "save or "apply" ok.

As far as saving vs applying goes. In a previous post I noted that both apply and save were returning me to the form management screen (where are forms are listed). "Apply" should return to the GENERAl tab within the form you are working on (or it does when there is no PHP in the code).

I'll give you suggestion a go, but I'll be interested to see Max's feedback.

Chat soon.

aj

Hi guys,

Just following up on this. Max PM'd and asked for access details to the site which I sent, but I haven't seen any further activity.

aj

Hi aj,

No word from Max on this. But Frdrik found a neat workaround that's helping me.

I just add

if ( !$mainframe->isSite() ) return;

near the beginning of the Form HTML (or any other box) and then the code is all skipped in the back-end of the site - but runs in the front-end.

Bob

Note: if you use this ChronoForms may not be able to find all the form fields. But if you need it then that probably isn't a problem.

Hi Bob,

dropped the ball on this one for a while but I'm back on the case. (as I struck the issue again and I still haven't found a reason as to why CF won't save updates and I have to "hack" the HTML in the d/base direct)

What do you mean that "ChronoForms may not be able to find all the form fields"? are you talking about CF auto-magically building the table to support the form? If not, can you explain?

Thanks

aj

Hi again,

a thought on this issue.

Does the new version (5.5) need to see some HTML ahead of any PHP code. All the forms I am struggling with have PHP well before the HTML code. Forms that have only have HTML work OK and will save and "apply" OK.

aj

Hi ajw3208,

Put this snippet at the beginning of any box with PHP in it

<?php
if ( !$mainframe->isSite() ) return;
?>

ChronoForms tries to eval the code boxes (certainly the FormHTML box and maybe others) and then does a search to build a list of input names. This is used for the Create Table but is stored in the db table so is run on each save or reply.

The core snippet above will stop the eval if it is being run from the back-end - but lets the code run correctly in the front-end.

Some PHP will run OK from the back-end but anything that includes another file, or redirects, etc. will cause the save to fail.

This is a really bad 'feature' for advanced users - Max is aware of it and hopefully will fix it in a future release.

Bob

Hey Bob,

I did as suggested in your previous post and all is good. Hope Max can solve the issue soon.

thanks

aj