Form submission broken after 3.5.1 update

[LukeDouglas]

Has anyone else experienced online form submissions not being submitted after upgrading to 3.5.1? I can confirm that this issue has to be due to the Joomla 3.5.1 update. I have tested three sites with three different form applications and all three break on submissions after the update to 3.5.1. After restoring the sites back to 3.5.0, the online form submissions work fine. Hopefully, the Joomla development team will get this resolved quickly.

[Chamira Athauda]

What form extension are you using?

What happens when the 'Submit' button is clicked?

Are you using ReCaptcha 2.0?

[LukeDouglas]

Chamira Athauda,

I have tested this with JSN UniForm, Breezing Forms and FlexiContact. All three have the same issues under Joomla 3.5.1. Once they are restored back to Joomla 3.5.0, all is well.

When the submit button is clicked on all three, the page refreshes with no data inputted and does not redirect to the URL on a successful submission of a form.

ReCaptcha is set to version 1.0 but this is not the issue. I tested this with ReCaptcha 'disabled' and got the same results.

[Mjusick]

I have the same Problem with BreezingForms and J 3.5.1. No Mails are send. I have many sites using BreezingForms which I updated tu 3.5.1 . I get the Error "0 - Invalid address" after submitting Forms. Any suggestions about a solution?

[TheMuffinMan]

Hi,

these errors happen across extensions because something important has been refactored/corrected in the Joomla Email API.

However, as for BreezingForms full and lite, there are updates available since yesterday.

I am sure most of the other major extensions already provide updates or will do so in the next few days.

Regards,
Markus

[Mjusick]

Thanks for the quick response!

[khoward66]

I use flexicontact and had the same issue after the upgrade, I have found the issue is with the "From Name" field on the form and the update to the AddReplyTo function in Joomla!'s JMail class.
https://api.joomla.org/cms-3/classes/JMail.html

The class now accepts the $replyto variable as a mixed array of email addresses and the $name variable as a separate mixed array. Flexicontact was passing the "From Name" and "From Email" field data in one array to the AddReplyTo function so it was attempting to validate both the person's name and email as email addresses.

The flexicontact file that was causing the issue is components/com_flexicontactplus/models/email.php under the sendEmail function. Searching "AddReplyTo" in this file also works.

[deleted user]

Because this misnomer has been going around since the changes in core were made, addReplyTo hasn't accepted an array with an email address AND the user's name as the first parameter since 3.0.0. Joomla core was even doing this incorrectly, see https://github.com/joomla/joomla-cms/pull/9577

I dug into it a little bit yesterday and I found that the JMail::add() method (which the various addXXX methods proxy to) never handled an error state (that is when PHPMailer's methods for adding an address to a message would return a boolean false meaning an error had happened, the error was silently discarded and things just kept running in the background). The change to have PHPMailer throw exceptions caused Joomla to not be able to just silently ignore these errors.

So, the old way would appear to work because the error condition was never handled and now it looks like it's broken because the error isn't ignored. It looks like addReplyTo in Joomla 2.5 may have worked this way but since 3.0.0 that type of parameter stopped working.

[TheMuffinMan]

Hi,

do you know if accepting the "config." prefix for the joomla config getter also got removed?
Before 3.5.1 e.g. "config.mailfrom" used to work, now it only returns the values w/o the prefix.

Regards,
Markus

[TheMuffinMan]

...by the way, setSender() still accepts only one parameter with an email, fromname pair.
I think that's why I assumed it would be the same for addReplyTo().

However, many extensions seem to assumed the same, at least things are clear now. Thanks.

[deleted user]

IMO the problem with JMail's extended methods from PHPMailer is that they're adding non-standard behavior as per their documented API. For example addReplyTo only accepts string values for its parameters and returns a boolean value indicating success or fail (or throws a phpmailerException if configured to do so), whereas JMail's overrides that and allows arrays or strings and returns $this object for chaining. So while these shortcuts are definitely convenient, IMO they've been implemented poorly by ignoring errors from the PHPMailer API before 3.5.1 and they deviate from the documented API which causes confusion.

It's one of those "you have to read the code to fully understand what it's doing" situations sadly. The documentation's just not that clear.

[hobra]

@mbabker
100% agreed, the Joomla 3.5.1 change to enable exception handling by default brings pain.
But that pain has to be felt as it exposes the real issues at hand that were not detected in all that years. I am guilty myself.

For anyone interested, I am doing this in my extensions now:

Code: Select all

try {
	  if(version_compare(JVERSION, '3.0', 'ge')) {
	   	   $mailer->addReplyTo($replyTo, $replyToName);
	   } else {
  	   	   $mailer->addReplyTo(array($replyTo, $replyToName));
	   }
} catch (Exception $e) {
      // do exception handling and logging here
}

[Webdongle]

Since 3.5.1 I have tested on my site php 7.04

• Contact form with recaptcha2, send copy to yourself
  • With contact email manually added in the component contact
  • With a user in Registered User Group selected in the component contact and their email automatically added
• User registration with recaptcha2, Administrator verify selected
  • With SU verifying
  • With user in a User Group that has Receive system mails Yes
  • With user in a User Group that has Receive system mails Yes ...Administrator login, User component Permissions Create and Access Administrator Interface 'Allowed'
    (needed if registration menu item set to guest)

Full Success
From, Reply To and To fields all populate correctly. The fix applied to the Joomla 3.5.1 full package works as expected. System emails also arrive correctly. Great job mbabker et. al.

[Scott235]

Hi,

these errors happen across extensions because something important has been refactored/corrected in the Joomla Email API.

However, as for BreezingForms full and lite, there are updates available since yesterday.

I am sure most of the other major extensions already provide updates or will do so in the next few days.

Regards,
Markus

I'm having the same issue but the version of Breezing Forms I'm using is BreezingForms 1.8.7 Stable (build 880)

I don't see any updates to BF beyond this.

BF is a component, not an Extension.

[Scott235]

@mbabker
100% agreed, the Joomla 3.5.1 change to enable exception handling by default brings pain.
But that pain has to be felt as it exposes the real issues at hand that were not detected in all that years. I am guilty myself.

For anyone interested, I am doing this in my extensions now:

Code: Select all

try {
	  if(version_compare(JVERSION, '3.0', 'ge')) {
	   	   $mailer->addReplyTo($replyTo, $replyToName);
	   } else {
  	   	   $mailer->addReplyTo(array($replyTo, $replyToName));
	   }
} catch (Exception $e) {
      // do exception handling and logging here
}

Where do you add this? What file? Where is the file? Will it eliminate the error of Invalid Address?

[elanimal]

Where do you add this? What file? Where is the file? Will it eliminate the error of Invalid Address?

[LukeDouglas]

elanimal and Scott235,

That code is for developers of 3rd party add-on's.

[elanimal]

Ok, TKS

[elanimal]

And if i have RSForm 1.51.1 where i use this code?

[Chamira Athauda]

@elanimal

RSForm!pro was updated a day or so ago, it is now v1.51.13

If you have an active subscription you should update it first and check.

[elanimal]

aha

[Scott235]

elanimal and Scott235,

That code is for developers of 3rd party add-on's.

[hoekbrwr]

I am desparately in need for this update Build 885. Will this solve this error definitely?

I must ask somebody else to install this build however.

[Scott235]

I am desparately in need for this update Build 885. Will this solve this error definitely?

I must ask somebody else to install this build however.

I just ran the update on our site we have on our Dev server version and it worked. We're now at BreezingForms 1.8.7 Stable (build 885) instead of BreezingForms 1.8.7 Stable (build 880) I filled out one of our forms and no Invalid Address error. I then ran the BF update on our real site and its good there too.

So you logged into the CrossTec.org site to get the new version so you have the zip file?

[TheMuffinMan]

Hi,

BreezingForms Full Build 885 works (Lite Build 913, too). But it was not just the addReplyTo() issue that caused trouble, it was just the most likely to happen after the change of behaviour in Joomla! 3.5.1.

Before, Joomla! allowed previous transactions, such as form submissions, to pass and displayed notification messages at the top of the page about email issues that happened.

Now, Joomla! will throw a hard error (500) and thus stop the current transaction. This requires all extension developers to handle the thrown error, for example using a try / catch block and enqueuing the error message in the catch-block to restore the old behaviour (displaying a notification at the top of the page).

That's what we did for BreezingForms, so if any email issue occurs, it won't halt the entire form submission any longer.

Regards,
Markus

[Scott235]

Its interesting that when there's any kind of update to any application and or the core CMS something is going to happen. Its never fool proof.

Hi,

BreezingForms Full Build 885 works (Lite Build 913, too). But it was not just the addReplyTo() issue that caused trouble, it was just the most likely to happen after the change of behaviour in Joomla! 3.5.1.

Before, Joomla! allowed previous transactions, such as form submissions, to pass and displayed notification messages at the top of the page about email issues that happened.

Now, Joomla! will throw a hard error (500) and thus stop the current transaction. This requires all extension developers to handle the thrown error, for example using a try / catch block and enqueuing the error message in the catch-block to restore the old behaviour (displaying a notification at the top of the page).

That's what we did for BreezingForms, so if any email issue occurs, it won't halt the entire form submission any longer.

Regards,
Markus

[LukeDouglas]

Well Joomla did warn that we should ensure our 3rd party add-on's were compatible but the issue with that is you really wouldn't know unless you checked with all 3rd party add-on's websites to see if they had encountered problems with the Joomla update as well as had an update to fix the problem BEFORE you update the Joomla install. Sure, it's a lot of work but that is the way it 'should' be done but I suspect a lot of website developers just update their sites and then FIND out there is an issue. Lesson learned here. I'm not updating anymore of my clients websites until I have ensured to the best of my abilities that the 3rd party add'on's won't crash.

[Scott235]

Well Joomla did warn that we should ensure our 3rd party add-on's were compatible but the issue with that is you really wouldn't know unless you checked with all 3rd party add-on's websites to see if they had encountered problems with the Joomla update as well as had an update to fix the problem BEFORE you update the Joomla install. Sure, it's a lot of work but that is the way it 'should' be done but I suspect a lot of website developers just update their sites and then FIND out there is an issue. Lesson learned here. I'm not updating anymore of my clients websites until I have ensured to the best of my abilities that the 3rd party add'on's won't crash.

I hear ya. Updating and upgrading to newer versions of whatever is always a risk unless you have a duplicate of the site(s) elsewhere to test on before doing the actual one.

[LukeDouglas]

Scott235,

I have really reduced the large number of add-on's, especially with galleries, slideshows, forms and shopping carts, by standardizing on just one for each type. So my life is a bit easier than others that have dozens of different add-on's.

[Scott235]

Scott235,

I have really reduced the large number of add-on's, especially with galleries, slideshows, forms and shopping carts, by standardizing on just one for each type. So my life is a bit easier than others that have dozens of different add-on's.

Guess it depends on what the client's needs are for their site. I have a duplicate of their site on a Dev server and that's where I do upgrades first then to the prod site but even that's not foolproof.

I have a few client sites that are using Word Press and there's always updates to plugins and to WP itself here and there. I have duplicates of them too. Just last week I made of copy of each site and the DB to keep just in case.