com_connect - form and contact mailer

Gallex · 2023-04-10 11:31:30

Gallex wrote #335239:

to from field started additionally to appear “charset=“UTF-8”

com_connect 4.7
Textpattern version: 4.8.8
PHP version: 8.1.16

it adds at the end of from field charset=“UTF-8” (behind 1 more). take a look

EDIT: just saw, Kjeld has same problem

Last edited by Gallex (2023-04-10 11:44:09)

Bloke · 2023-04-10 16:26:17

I have absolutely no idea why this happens, sorry. It’s very strange. The latest version includes the patch that uses proper \r\n and \n instead of (the erroneous) PHP_EOL as separator. All values are passed as discrete entries in the $headers array and every header is constructed into a proper email header stream with a separator between them. So I can’t fathom why it would combine any of them.

The only thing I can think of is that it’s completely ignoring the separator in PHP 8 or it somehow treats newlines differently. But I can’t find anything in the changelogs that might indicate this is happening. And it seems to work fine using the 4.9.0 code on PHP 8, as far as I can tell.

I can’t reproduce these issues, either in localhost (Mac) or online (Ubuntu). Long shot: is this something to do with Windows servers? Anyone who is hitting this issue, what server environments are you running? Consult Admin->Diagnostics to find out.

Gallex · 2023-04-11 12:01:40

Bloke wrote #335286:

I have absolutely no idea why this happens, sorry. It’s very strange. The latest version includes the patch that uses proper \r\n and \n instead of (the erroneous) PHP_EOL as separator. All values are passed as discrete entries in the $headers array and every header is constructed into a proper email header stream with a separator between them. So I can’t fathom why it would combine any of them.

The only thing I can think of is that it’s completely ignoring the separator in PHP 8 or it somehow treats newlines differently. But I can’t find anything in the changelogs that might indicate this is happening. And it seems to work fine using the 4.9.0 code on PHP 8, as far as I can tell.

I can’t reproduce these issues, either in localhost (Mac) or online (Ubuntu). Long shot: is this something to do with Windows servers? Anyone who is hitting this issue, what server environments are you running? Consult Admin->Diagnostics to find out.

mine

PHP version: 8.1.16
GD Graphics Library: bundled (2.1.0 compatible); Supported formats: GIF, JPEG, PNG, WebP.
Intl extension: 8.1.16
Multibyte String extension: 8.1.16
Server time zone: Europe/Tallinn
Server local time: 2023-04-11 14:58:41
Daylight Saving Time enabled?: 1
Automatically adjust Daylight Saving Time setting?: 1
Time zone (GMT offset in seconds): Europe/Tallinn (7200)
MySQL: 10.5.19-MariaDB-cll-lve (MariaDB Server) 
Database server time: 2023-04-11 14:58:41
Database server time offset: 0 s
Database server time zone: SYSTEM
Database session time zone: SYSTEM
Locale: en_GB.UTF-8
Site / Admin language: en-gb / en-gb
Web server: Apache
PHP server API: litespeed
PHP SSL version: OpenSSL 1.1.1t  7 Feb 2023
RFC 2616 headers: 
Server OS: Linux 3.10.0-962.3.2.lve1.5.79.el7.x86_64 #1 SMP Wed Mar 15 09:10:44 UTC 2023 x86_64
Admin-side theme: hive 4.8.8
Active plugins: 
	com_connect-4.7.0
	pap_comconnect-0.1.2
	rah_metas-1.5 (modified)

Gallex · 2023-04-11 12:38:32

tested another server. no problem! :)

txp 4.8.8
com_connect 4.7

PHP version: 8.1.17
GD Graphics Library: 2.3.3; Supported formats: GIF, JPEG, PNG, WebP, AVIF.
Intl extension: 8.1.17
Multibyte String extension: 8.1.17
Server time zone: Europe/Tallinn
Server local time: 2023-04-11 15:34:22
Daylight Saving Time enabled?: 1
Automatically adjust Daylight Saving Time setting?: 1
Time zone (GMT offset in seconds): Europe/Tallinn (7200)
MySQL: 10.6.12-MariaDB-log (FreeBSD Ports) 
Database server time: 2023-04-11 15:34:22
Database server time offset: 0 s
Database server time zone: SYSTEM
Database session time zone: SYSTEM
Locale: en_GB.UTF-8
Site / Admin language: en-gb / en-gb
Web server: Apache
PHP server API: fpm-fcgi
PHP SSL version: OpenSSL 1.1.1t  7 Feb 2023
RFC 2616 headers: 0
Server OS: FreeBSD 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64
Admin-side theme: hive 4.8.8
Active plugins: 
	adi_notes-1.3.1
	com_connect-4.7.0
	pap_comconnect-0.1.2
	rah_comments-0.4 (modified)
	rah_metas-1.5 (modified)
	rah_sitemap-1.2

Bloke · 2023-04-11 13:43:54

Intriguing. Thank you for the info. So both flavours of Linux, one FreeBSD, the other not. The only major difference I can see that might have a bearing, beyond slightly newer PHP/MySQL environments, is the curious entry for RFC 2616 headers. The manual there states it should be set to 0 unless you know what you’re doing. In your non-working server case, it’s empty.

Whether this has a bearing on anything, I’m not sure. It’d be interesting to see if anybody else who has this issue also has that flag set to something other than 0. The RFC doc itself is largely impenetrable, but it does include this statement:

When in canonical form, media subtypes of the “text” type use CRLF as the text line break. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body; a bare CR or LF MUST NOT be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).

That last sentence might be the key. We’re only using LF in non-Windows environments. So maybe if that flag is not 0 it’s less forgiving and won’t interpret headers properly.

We could test this fairly simply. Edit the plugin and locate the two lines that mention IS_WIN and change them both from:

IS_WIN ? "\r\n" : "\n"

to:

IS_WIN ? "\r\n" : "\r\n"

If the server behaves itself, then we’ll need to be more clever about how we determine line endings and perhaps take the RFC 2616 status into account too.

Gallex · 2023-04-12 11:29:22

Bloke wrote #335289:

That last sentence might be the key. We’re only using LF in non-Windows environments. So maybe if that flag is not 0 it’s less forgiving and won’t interpret headers properly.

We could test this fairly simply. Edit the plugin and locate the two lines that mention IS_WIN and change them both from:

IS_WIN ? "\r\n" : "\n"...

to:

IS_WIN ? "\r\n" : "\r\n"...

If the server behaves itself, then we’ll need to be more clever about how we determine line endings and perhaps take the RFC 2616 status into account too.

BINGO! genius! :)

Bloke · 2023-04-12 12:13:54

Wow. Really? Okay. Thank you for testing. If this works for other people with the same issue, we should patch the plugin.

Leave it with me and I’ll see what I can do.

Kjeld · 2023-06-05 05:45:03

Bloke wrote #335293:

Wow. Really? Okay. Thank you for testing. If this works for other people with the same issue, we should patch the plugin.

Leave it with me and I’ll see what I can do.

This solution worked for me, too! Thanks.

Bloke · 2023-06-05 09:23:00

Thank you for testing, Kjeld. I’ll get a fix prepared for the next release.

Kjeld · 2023-06-05 09:48:59

Bloke wrote #335471:

Thank you for testing, Kjeld. I’ll get a fix prepared for the next release.

Great. Thanks for the fix, Bloke!

colak · 2023-10-17 15:03:02

I have the form below but it does not work. Any ideas?

<txp:com_connect to="who@domain.tld" label="" thanks_form="eu_stats" subject="Sea Blindness stats.">
<txp:com_connect_text name="Name" label="Your Name:" required="1" /><br>
<txp:com_connect_text name="Surname" label="Your Surname:" required="1" /><br>
<txp:com_connect_email name="Email" label="Your Email:" required="1" /><br>
<txp:com_connect_text name="Website" label="Your website (optional):" required="0" /><br>
<txp:com_connect_textarea label="Your comments about the event (optional):" required="0" /><br>
<txp:com_connect_select label="" options="{Gender},Male,Female,Non binary" required="1" /><br><br>
<txp:com_connect_select label="" options="{Residence},Cyprus,Elsewhere" required="1" /><br><br>
<txp:com_connect_checkbox label="Check this box if you wish to receive infrequent emails about our events." required="0" /><br><br>
<txp:com_connect_submit label="Submit" />
</txp:com_connect>

Bloke · 2023-10-17 15:21:09

colak wrote #335794:

I have the form below but it does not work. Any ideas?

You can’t have two select tags without labels (or with the same label). The plugin differentiates/validates the expected values by using the label attribute, so the second one will be overwriting the first and causing validation errors on submission.

If you’re not using the label to display a visual label, then you’ll need to specify a unique name attribute for each instead.

<txp:com_connect_select label="" name="Gender" options="{Gender},Male,Female,Non binary" required="1" /><br><br>
<txp:com_connect_select label="" name="Residence" options="{Residence},Cyprus,Elsewhere" required="1" /><br><br>

Last edited by Bloke (2023-10-17 15:22:22)

Textpattern CMS

Textpattern CMS support forum

#409 2023-04-10 11:31:30

Re: com_connect - form and contact mailer

Gallex wrote #335239:

#410 2023-04-10 16:26:17

Re: com_connect - form and contact mailer

#411 2023-04-11 12:01:40

Re: com_connect - form and contact mailer

Bloke wrote #335286:

#412 2023-04-11 12:38:32

Re: com_connect - form and contact mailer

#413 2023-04-11 13:43:54

Re: com_connect - form and contact mailer

#414 2023-04-12 11:29:22

Re: com_connect - form and contact mailer

Bloke wrote #335289:

#415 2023-04-12 12:13:54

Re: com_connect - form and contact mailer

#416 2023-06-05 05:45:03

Re: com_connect - form and contact mailer

Bloke wrote #335293:

#417 2023-06-05 09:23:00

Re: com_connect - form and contact mailer

#418 2023-06-05 09:48:59

Re: com_connect - form and contact mailer

Bloke wrote #335471:

#419 2023-10-17 15:03:02

Re: com_connect - form and contact mailer

#420 2023-10-17 15:21:09

Re: com_connect - form and contact mailer

colak wrote #335794:

Board footer