biberkopf

Same problem her. The two reply mails both seems to strip any attempt to add a linefeed if you tick off “HTML”. Also if you use “<br>”. I haven’t tested with block elements like <div> og <p>.

I had to rewrite and reformat all my contact forms to plain text. So now I’m prepared for the next bug. ??

(BTW: Plain text mails used to honour <b> and <i> which was really handy. What happened to that?)

Hope we will soon be back in business with this wonderful plugin.

I had a hard time understanding this problem. But in my case the doublets happened when the user was double clicking the submit button in the form. This is a common behaviour with some users.

I solved it by adding the plugin “Redirection for contact form 7”. This will replace the form with a confirmation text so the user has nothing to click on.

Hope this can help you too.

Correction: The wp-config.php fix seems to work for me anyway. Sorry for the confusion.

But it works only for the rendering of the form in the frontend which was never a problem in my case.

My issue is with the rendering of a html formatted email.

Which I have explained in detail here:

https://www.ads-software.com/support/topic/ver-5-7-1-hasnt-fixed-styling-issue/#post-16300946

First I didn’t notice any change, but then realized I had forgot to remove the disabling of autop in the wp-config.php ?? .

The fix in 5.7.1 seems to work fine in the rendered frontend, but not in the content of the email itself.

Here is what happens in my case. I’ll show what is defined in the my backend form and what comes out in the email content field in the receiving end.

My form is defined like this:

<table>
<tr><td>Navn</td><td>[Navn]</td></tr>
</table>

In version 5.6.4 the output in the email came out like this:

<table>
<tr>
<td>Navn</td>
<td>TEST Navn test 5.6.4</td>
</tr>
</table>

<table>
	<tr>
		<td>
			
Navn
			
		</td>
		<td>
			
TEST Navn test 5.7.1
			
		</td>
	</tr>
</table>

So extra p-tags, line feeds and indention spacing is still being added to the mail-content, because it consists of html code.

This is a problem because the forms are being processed by a fairly rigid conversion script in the receiving end. And I can’t edit that particular conversion script. Even the whitespace can present a problem in that process.

To declare all details: I have ticked off the “Use HTML content type” in the email definition in the backend.

I am aware that if I disable this function the autop is not happening. But it is not currently possible to do this as it will change a number of other things (multipart for one) in the email construct which will cause the conversion in the receiving end to break.

So I hope the changed behaviour in the email content can be avoided like it seems to have been avoided in the html frontend presentation of the form.

(Thanx for a tremendous form plugin!)

• This reply was modified 2 years, 2 months ago by biberkopf.

+1

@frafor Neither of your solutions seems to work on my site.
I’m running on Genesis and I have activated the checkbox for using HTML-content in the the form.

Thanx for the tip. ??

The update seems to have solved my problem. Thanx a lot. ??

• This reply was modified 4 years, 2 months ago by biberkopf.

Hi Scott and Bernard:
I feel very confident with you on the case.
Thanx for your thoroughness and dedication!
And a happy new year to you.
??
/j

Similar experience on relational data. I have a customer working on a site with several CPTs with quite a few fields in each CPT. He reported that fields were missing here and there in the frontend. This has happend within the last few weeks without any of us having edited the pages. So I suspect some update in December has changed something fundamental.
I’m using BB Pro + BB Theme + Themer + Pods Beaver Themer Add on.
I haven’t dug into all of the cases, but let me focus on one that is different from the above, since it is involving fields from a relationship CPT:

On one CPT “Regent” I have a Pods relationship to “Books”.
I’m presenting a list of related books on the single record of a particular Egyptian king/regent.

<div class="uabb-blog-post-section">
[wpbb post:pods_display field='ophav']
([wpbb post:custom_field key='aarstal'])
[wpbb post:custom_field key='titel_kilde']
[wpbb post:custom_field key='udgiver']</div>

The shortcode [wpbb post:pods_display field=’ophav’] fails to show up.
If I change it to [wpbb post:custom_field key=’ophav’] it works fine.

I’m using UUABs Advanced Posts module presenting the related records with “Grid”, but I have just reproduced the issue with BBs own posts module. Same situation.

• This reply was modified 4 years, 2 months ago by biberkopf.
• This reply was modified 4 years, 2 months ago by biberkopf.
• This reply was modified 4 years, 2 months ago by biberkopf.

We are seing the same issue on the page:
https://forum.astronomisk.dk/forums/reply/316881/
Exactly the same problem.
Trying to load this URL:
https://i2.wp.com/forum.astronomisk.dk/wp-content/uploads/2018/03/tube2_surface.jpg?ssl=1
results in this error:
“We cannot complete this request, remote server returned an unexpected status code (400)”
(I’m also seeing this error: “Error 0005. The type of image you are trying to process is not allowed.”)
If you remove the “ssl=1” parameter the original cached image will load:
https://i2.wp.com/forum.astronomisk.dk/wp-content/uploads/2018/03/tube2_surface.jpg
So it seems there must be something fishy going on on the image caching server.
I reoploaded the same image again without any problems.

FWIW: I don’t know how the software (formerly known as Photon) does its trick on its own server, but we have had SG Cache activated on this server at the time when the upload took place. Also the page in question had 4 big images (about 1MB each) uploaded at once, so perhaps there has been some timeout going on in the webserver-to-photon-server-process that could have interfered with the preparation work of the SG Cache?! Maybe something that led to an timeout or some unexpected behaviour like the original webserver image being altered in the middle of the photon-caching process? Obviously, I’m just guessing.

But please be aware that the original version still seems to be available from:
https://i2.wp.com/forum.astronomisk.dk/wp-content/uploads/2018/03/tube2_surface.jpg

@marcus I feel so stupid. Not used to such an advanced interface. ?? You are absolutely correct. I didn’t notice that the top filter was set to future events. Not using it myself on a daily basis. I’ll dig myself a big hole. Sorry to bother you all.

It really looks like the backend event list is now only showing current and future events. I managed to edit a hidden event (changed the id in the edit-url) and changed the event dates to a current one, which brought it back on the administration list.
I wonder if this is a bug or a feature?! But it’s confusing and not really what you would expect from a regular wp-interface. (Maybe somebody forgot an ‘!admin’ statement somewhere.) ??

@mapl I couldn’t replicate that on my installation. I went back to php 5.6 and 5.5 and neither solved the problem.

+1
We have just discovered the same problem. I smells a bit like a bug in the v 5.9.5.
Here’s a screenshot of the our events list in the backend:
https://snag.gy/POYwkj.jpg
The only two records shown out of the total of 46 have been created since the problem occured. I have not been able to find any anomalities in the wp_post database table when looking through post_type=event.
I have also tried to compare a handful of the events post_meta-data in the database without finding any explanation to this error. I have activated the debugging in the plugins debug.php and checked php and wp debugging without any luck.
In the frontend, the hidden events seem to be visible in the grid calendar with a functional link to the single event page. So this seems to work as intended.