www.wysiwygwebbuilder.com

I am wondering whether this help page is up-to-date: https://www.wysiwygwebbuilder.com/form_popup.html

It says this:

Therefor (sic), it is not possible to clear or disable the form controls via the popup.

However, when exploring the dialog options, I have found that there is an event that can be added that is triggered when the dialog is closed to reset a form, so I presume I can use this.

I am not able to test if this is the case yet as I don't have the test site uploaded to the web. It's a .php page. This is why I am asking if I have understood correctly.

Also, is it still strictly necessary to have a success page? Could the success text not be added directly to the dialog?

Thank you.

The success page is display inside an inline frame (= a different page)
For security reasons you cannot change the state of controls on another page in HTML. Otherwise any other site you have open in your browser could also access the content of your pother page.

Yes, you will need a success page because the page need to go somehow after the submitting.
Technically it can be the same page, but it may be more clear to display a 'success' message.

Also, is it still strictly necessary to have a success page? Could the success text not be added directly to the dialog?

Not in this case, because all existing content of the dialog will be erased when it is displayed by the form.

Thanks, Pablo. I can create a success page, no problem, but I was just wondering why the success text couldn't be the text in the dialog, but you say that it would be cleared automatically.

Please don't take what follows as me being argumentative: I am just trying to understand this based on previous experience of adding forms to websites before I switched to WWB.

Yes, you will need a success page because the page need to go somehow after the submitting.

This is not how I understand it The most basic of forms will submit without needing a success page at all: a success page is just a way to reassure the user that their form has submitted correctly. It's not an essential part of form submission. The page itself doesn't need to go anywhere, as I understand it, but it would leave the user with no indication that the data had been sent, so it wouldn't be ideal.

Back to the dialog options: I am trying to understand the event options. What would an event set to trigger on close with the action of form reset and the target of my form layout grid actually do? I'm trying to work out what it's for.

In case of the built-in form script (PHP), it needs to go somewhere after the script has been processed otherwise the user will end up with an empty screen.
Technically it can be the page with the form, but then the user will have no idea that the script has been processed.

The events are not specific to forms, they are part of the dialog functionality. or in this case the content of the success pages.
Because the dialog is on the same page you can use the code event to clear the form.
What I meant was, you cannot add a button or link inside the success page to reset.

Thanks for the clarification.

Because the dialog is on the same page you can use the code event to clear the form.

So let me see if I understand correctly: the dialog shows the text from the success page, but because the dialog is displayed on the form page, the event to clear the form WILL work. Have I understood correctly? If so, then that would be great.

Is it at all feasible at some time in the future for the dialog's text not to be cleared automatically by the form so that it can be used that way?

Quick OT query: I am building a one-page site with lots of layout grids, so I am making good use of the Object Manager. If I am trying to drag an object from the bottom to where I need it, I find that the manager window does not scroll - should it? Also, should it be possible to collapse elements (e.g. the formLayoutGrid) to keep the window less cluttered? If not, it would be great if these suggestions could be added to the wishlist, please.

the dialog shows the text from the success page, but because the dialog is displayed on the form page, the event to clear the form WILL work. Have I understood correctly? If so, then that would be great.

Correct that should work.

Is it at all feasible at some time in the future for the dialog's text not to be cleared automatically by the form so that it can be used that way?

This behavior is intentional and works this way by design.

Not only the success page is displayed inside the dialog's inline frame, but the entire form processing takes place there. This approach is necessary because a PHP script runs on the server, not in the user's browser, so it cannot directly trigger a client-side popup.

To work around this limitation, WWB opens a dialog when the form is submitted and executes the complete form process inside that dialog. As a result, both the success and error pages are also displayed inside the same popup.

There for you cannot just simply display a text message, but a inline frame is required.

I find that the manager window does not scroll - should it?

This functionality is not implemented a the moment.

To work around this limitation, WWB opens a dialog when the form is submitted and executes the complete form process inside that dialog. As a result, both the success and error pages are also displayed inside the same popup.

This now makes logical sense to me - thanks.

This functionality is not implemented a the moment.

It would be a nice feature, along with collapsible sections.

The dialog shows the text from the success page, but because the dialog is displayed on the form page, the event to clear the form WILL work. Have I understood correctly? If so, then that would be great.

Correct that should work.

Just FYI, it doesn't. I tried linking the event to the layout grid and to one of the input boxes, and neither worked, which is a shame.

I have now got my form uploaded to a test server and got it working client side - the validations work and the popups work, but at the moment, the send operation is returning an error. I am working with my host to find out what SMTP settings I need to make it work. I'll open a new thread if I need to, once they have replied to me.

Just FYI, it doesn't. I tried linking the event to the layout grid and to one of the input boxes, and neither worked, which is a shame.

I have tried it myself and it works for me.
So, there may be something else wrong on the page that stops it from working.

I have removed it for now until I have the basic form operation working - I have started a new thread on that. Thanks!

Firstly, many thanks for today's update.

I have now turned my attention to the issue of resetting the form when the success popup is closed.

In the WWB file, the formDialog is at the bottom of the index page. I have set an event to reset the formLayoutGrid on close. It does not work. I am sure that I have done something wrong!

The form is uploaded here: https://www.alisongwright.me.uk/EICC/Form/

The demo file is here: https://we.tl/t-gtCwzJaPgpi81ZkM

I have tried setting the event on the questyionLayoutGrid, the questionTextArea and the full formLayoutGrid. None of these have any effect. I even tried linking it to the reset button. I have also tried setting it to run on open - no cigar.

Thanks.

In the event properties, you have set the target to the textarea instead of the form.

I've tried all sorts, Pablo - all listed in my previous message. Please tell me the exact name of the object I need to select.

formLayoutGrid does not work for me in any browser I have installed.

Use 'formLayoutGrid'.
Also, rename the reset button to something other than 'reset', since the browser may confuse the reset value with the reset() function.
For example, you could name it 'resetForm'.

I did exactly as instructed. I now have no success message and an empty form with bootstrap validation.

https://ibb.co/KcdyV74G

The E-mail did not arrive, so that form is an error message that is not showing.

I thought that it worked previously?
Did you change something that made it stop working again?

No - I have only done what you said. I mentioned previously that the error message was not showing - that has not been fixed. Most of the time, the bootstrap validation kicks in, but here, after changing reset to resetform, the form did not submit.

I do not see any obvious errors in the HTML.
The reason why the error is not displayed is most likely because there is an error in the mail configuration, so the form fails somewhere on the server .
This cannot not be 'fixed' in the software.

You will need to find out why it fails on the server side. Maybe you have access to the PHP error log via the control panel of your web account?

See also the 'very important message' in the Form FAQ.

The very important note says this:

*** VERY IMPORTANT NOTE ***
If you need our assistance with the configuration of your form, then you will first have to contact your web host and ask them why the emails are not sent.
For example, they may have specific requirements or restrictions (no support for mail, smtp limitations, 'from email must be within domain' etc).
Only with the feedback of your web host you can solve configuration issues, because different web hosts need different settings!
We cannot help you, if you do not know what the exact error is.

We don't have an issue here with the form not submitting. If all fields are filled in, then the form submits and we get the success page. E-mails and autoresponders are sent and received.

The only time today that the form has failed to submit is when you asked me to change the reset button name to resetform: that alone caused the error. I am using the PHP Sendmail engine.

I really don't have any idea how I would ask my host about this. After all, it is just a name change and the PHP script is unchanged. NOTHING else has changed. I have not touched the configuration settings. All the host would tell me, I suspect, would be not to rename the reset input.

Further to the above: the only error log related to the form processing was in the early hours of this morning - it looks like some SPAM bot tried to access the form and was intercepted. There are no other error messages at all today, and that's because the script is not failing, as evinced by all the test E-mails and autoresponder messages in my inbox.

If you only changed the button name then this should not impact how the form works.
The reset button is not part of the form logic and it is not sent to the server.

So, in my opinion something else must have changed.

Note: I am really doing my best to help.

And I am really doing my best to help you, too! I am just doing what you ask and then reporting back.

No, absolutely nothing else was changed. I merely changed reset to resetform, saved the file and uploaded again to the server. I did not touch or change anything else.

Here's the latest copy (I have changed the reset name back for now): https://get.hidrive.com/i/8LNwnxZu

I have contacted the host, but given that the form is working and E-mails are getting through, I don't know what they'll come up with.

Hee's the form with reset renamed to resetform: https://www.alisongwright.me.uk/EICC/Form/

Reply from my host:

Renaming a reset button on a form, for example from "reset" to "resetform", will not prevent PHP from executing on the server.

A reset button only affects the form within the browser and is used to clear the fields locally. It does not trigger form submission or interact with server-side processing. PHP will only execute when the form is submitted, typically via a submit button or associated script.

As you have confirmed that the form is submitting correctly and emails, including autoresponders, are being received, this indicates that PHP and the mail functionality on the server are working as expected.

Based on this, the issue is unlikely to be related to server configuration and is more likely within the form logic itself, such as JavaScript handling or how the form submission is being triggered.

In the latest version you have assigned the 'open' event to reset the form instead of the 'close' event (in the dialog events).

I have finally got it working in terms of the form being cleared after submission and I have also managed to add code to get rid of the validation, too - thanks.

I think the problem was that I had the publish setting set to upload only changed elements, but a full publish of the test page has now worked.

As the bootstrap validation kicks in, all errors are trapped pre-submission. What's the best way forward now to troubleshoot the missing error message in the popup? How can I force an error to check this?

Thanks so much for your patience.

I suggest to first try to make the error message without the popup, using a simple form. Because then it will be easier to see what is going on.
Now with all the events, ajax calls, JavaScript, popups etc, it is difficult to debug this.

That’s useful, thanks. I’ll start over and build it up step by step and see at what point it falls over.

Thanks so much.

I have taken it back to basics and built it up bit by bit again this morning, and I can't actually find a state that would trigger the error popup at all, and as the success popup works fine, I am going to leave well alone at this point, as it seems to work as I need.

Thanks again for all the help.

Just a post script to this: I can now confirm that the error popup message is working correctly.

What did you change to make it work?

I have no idea. Something yesterday when I was working through this with you must have sorted it. I just know it's working today because I have been testing form processing settings and removing one triggered the error, so I was finally able to check it.

All''s well that ends well!

Another postscript to this: having uploaded the site to the IONOS server, with absolutely no changes other than the form submission settings, the form clearing on closing the success dialog has stopped working. I shall have to debug this again from the ground up now I have access to the IONOS server. I shall report back here if/when I get it working again.

One step forward and three back - it's always the way!

Resolved - there were two objects with the same ID causing a clash - now fixed.

Is there any way to control the size at which the dialog appears on a screen? I have set mine to scrollable, and the object on the page in WWB is plenty big enough for my short error and success messages, but online, even in a large browser viewport, the dialog is quite small. It seems to be of a fixed size. Is there a way to make that default size bigger, or is this standard browser behaviour?

Thanks.

The width is controlled by the width in the workspace. The height depends on the content.

You can force a minimum height by adding this code to Page HTML (between head tags). This depends on the type of dialog and other properties, so you may need to adjust this.

Thanks - I'll try this. But why, if the height is controlled by the content, is the height not adjusting to the content? I have two other dialogs (for Privacy Policy and T&Cs), and they do adapt because the content is in the doalog. In the case of the form popup, it's using the success and error pages.

This has resolved the issue - thanks.

Thanks - I'll try this. But why, if the height is controlled by the content, is the height not adjusting to the content?

Because there is no content when the page loads. And an inline frame cannot update its parent's height after it changes (for security reasons)