WeePee

I can confirm the issue. I have the same errors when caching is enabled (using “Hyper Cache”). After clearing the cache and disabling caching, the form is working again. I’ve been using this setup successfully for years and there has been no update to Hyper Cache for a long time, so it’s very likely a bug in CF7…

I get the same error when trying to restore a backup with Updraft Plus while this plugin is active. It causes the backup verification process to hang infinitely, making it impossible to restore a backup! This really needs to be fixed…

Hi!

I’m the one he’s talking about ?? I actually have a backup of the database after the attack (created by UdraftPlus). I’ve searched the DB dump for the “Vuln XXX” string above but couldn’t find anything. Also, the post with ID 1195 has not been modified. Everything looked like before the attack. I restored the website to a clean state, just to make sure… The attack repeated a day later and since then I’m blocking the IP range it came from.

Is it possible that Sucuri sents these “Post Update” warnings when someone *tries* to update a post but actually fails to do so? That would at least make sense in this case…

Here’s an example of a page where the attack succeeded: https://www.evesca.com/x-htm/

Thanks for your fast response! However, I don’t think the problem is related to the plugins or theme, as I didn’t change them for a long time. I only switched the PHP version.

I tried to switch back to PHP 7.0 and the error was gone. It also seems to work with PHP 7.1. Also, the development version of the site (which uses the same plugins) works fine with PHP7.0 on Ubuntu 16.04.

I will stay with PHP 7.1 for now, as it’s supported until end of 2019…

Thanks for your fast respone! I’m using the function to change the slug and it seems to work.

Personally, I don’t care about a translation, as long as I can define all user visible text. This is already possible for form fields, buttons and error messages, but not for the slug.

If you’d make the slug configurable in the plugin settings that would be great for all of us who use testimonials for SEO ?? It’s also more flexible than using a static translation for the slug…

• This reply was modified 6 years, 2 months ago by WeePee. Reason: marked as resolved

Cool ??

Hi! Thank you for your response!

I can’t confirm that behavior. I’ve tested the patched contact form on my website (see link above) with the latest Chrome on Win7, Linux and Android and it works as expected. It also works correctly with Firefox and IE 11.

You can test by yourself by comparing my patched version against the original one on fastsecurcontactform.com. The difference is even more obvious on mobile devices, where autofill kicks in before you even start typing (you just need to activate the input-field, see screenshot).

At least, the HTML standard is pretty clear about this issue:

The “off” keyword indicates either that the control’s input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for them.

Imho, a captcha cleary is “a value that will never be reused”. And even if Google should decide to deliberately break user experience in their browser, that would be no valid reason to also break user experience on the remaining browsers…

Thank you! I’ve already tried to contact the developer, but did not get a response yet. So I decided to post a patch here in order to make the fix easily available.

Btw, I really miss a preview function in this forum, expecially when posting code… I can only hope it will be properly formatted ??

--- ./includes/class-fscf-display.php.old       2016-03-08 19:43:55.941589399 +0100
+++ ./includes/class-fscf-display.php   2016-03-08 19:45:42.157357679 +0100
@@ -2030,7 +2030,7 @@
 <div ' . self::get_this_css('field_div_style') . '>'
                                        . self::echo_if_error( 'captcha' )
                                        . "\n     <input " . self::get_this_css('captcha_input_style')
-                                       . ' type="text" value="" id="fscf_captcha_code' . self::$form_id_num . '" name="captcha_code" ' . self::$aria_required . ' />';
+                                       . ' type="text" value="" autocomplete="off" id="fscf_captcha_code' . self::$form_id_num . '" name="captcha_code" ' . self::$aria_required . ' />';
                        $string .= "\n</div>";
                } else {
                        $string .= $captchaRequiresError;

I’ve done some more debugging and it seems that the current behaviour is because of a missing HTML attribute. All browsers I’ve tested do enable autocompletion for all fields of type “input” (but not “textarea”, as it seems). So, if you like to disable autocompletion for some specific fields, you have to set autocomplete=”off”. Some plugins I use (e. g. UpdraftPlus) are already doing this for some of their input fields (mostly user credentials).

I’ve added the missing attribute to the captcha input field and it works like expected (i. e. no more suggestions or autocompletion by the browsers). Finally, the captcha can be entered without problems on mobile phones, while autocompletion still works for the other fields (except for “textarea”).

Changes I made:
in “./includes/class-fscf-display.php” on line 2033, I added autocomplete=”off” after value=””. I can also provide a patch.

Note that I didn’t yet change the code on the productive website (i. e. the link above)! However, I will do that soon but also hope for a new (fixed) version of the plugin… What’s the best way to contact the developer and submit my patch?

That’s strange. Maybe you have disabled autocompletion in your browser? Or you were browsing in private mode? Of course you have to fill out the captcha field multiple times in order to reproduce the issue…

Here’s the website if you’d like to test one more time:
https://www.coaching-grunwald.de

I am using “fast secure contact form” (version 4.0.41), so this seems to be the correct forum. I’ve been using “contact form 7” before, but switched to “fast secure contact form” a few weeks ago…

Here’s a screenshot (yes, there’s a captcha image somewhere below that popup):

https://i.imgur.com/6LRUAxb.png

When I activate the captcha input field, a popup appears right above the field containing all old captchas ever entered before. This popup covers the captcha image which makes it impossible to read. This means that, if a user gets the captcha wrong once or twice, it’s even harder for him to fill it in correctly.

While these autofill suggestions make sense for fields like name and email, they are totally useless for captcha input. I’ve also noticed that autofill is disabled for the message field (I don’t get any popups when activating the message field) but for some strange reason it’s active for the captcha input field (in both FF and Chrome)…

I can confirm this bug. The default image I added previously was lost after updating to version 1.5.5 and when trying to add a new one it just disappeared. I checked the generated HTML and the “og:image” entry is indeed missing!

I reverted the plugin to version 1.5.4.2 and now the “og:image” entry is generated correctly. I’m glad that I had a backup ??

For me, the opposite is the case: I try to disable auto updating, but after saving changes it is always (re)enabled. Looking at wp-config makes it clear that nothing has changed. In this state, the plugin is useless ??