Rick Curran

Thanks for looking at this further. I do agree that all the signs point to it being something within my theme, however I just can’t get to the bottom of what could be the cause.

Today I did some further tests which have made it even more confusing, I have taken a further look at it and I purposely disabled some other JavaScript and PHP includes on the site that relate to forms to see if they were causing an issue. I then went through the form, selected a file with the file select and I got no JavaScript error, I then re-enabled all of the other JS and PHP includes and tried it again and now there is still no error(!).

So unfortunately it really doesn’t make sense, the issue has disappeared but not in a way that I can pin down to any specific behaviour or repeatable action. I have on occasion had this issue before and it did seem to clear up by simply re-uploading the JavaScript file to the server, but on this occasion it has been a much bigger problem. Additionally I still do not encounter this issue on the Live version of the site which adds to the weirdness of this issue.

Interestingly both SWV schemas now show identical when I compare the Staging and Live versions, so the stray additional “required” file field is no longer appearing in the Schema. Can you clarify how the SWV schema is updated? Is it modified whenever a Contact Form entry is updated in the system or does the Schema generate when the Contact Form is loaded in the page of the site? I’m just trying to gain a better understanding of processes are happening here, whilst this bug has gone for now I do think there is some underlying situation that is causing this to be a weird “heisenbug” type of issue.

Yes, if I switch to the default theme the redundant required rule does not appear in the schema.

@takayukister The multi-step form functionality is my own code, it is basically some JavaScript code that handles the steps and does some of its own validation on the fields at each step by checking which fields are set as “required”. Generally I don’t rely on the default CF7 validation for these forms as the aim is to ensure everything is valid before the user proceeds to the next step and then to ultimately submit the form. In this case however it does seem to be the CF7 validation that is being triggered when the required file field is used. I am definitely happy to find an issue in my code which is causing or contributing to this error but so far I have not been able to. It’s the difference in behaviour between the Staging and Live versions of these sites / forms which is the key issue.

Sorry, one thing I should have included before is a link to the Live version of this same form which doesn’t trigger the error so that you can compare. This is the most confusing aspect of this issue, why the error occurs on the Staging site but not on Live. Here is a link to the Live version (Note, please don’t submit the form on the Live version as this an active form, the key point to note is when you actually select a file with the file selector, on Staging you should see the JS error, on Live you should not):

https://qreate.co.uk/cf7form-issue-live

Can you comment on the differences in the SWV schemas that I highlighted in my original post, this does seem to be an important difference between the two forms. I have a few questions about the schema:

• Does the SWV schema get updated when a form is saved?
• And does this schema get affected by updates to the CF7 plugin itself?
• Is the 4th ruleset I show in my original post an expected rule that should exist for forms with a “required” file field?
• The contact form entry on the Live site has not been updated / saved recently, so if the SWV schema is affected by updates and saving I am wondering then will this SWV schema change to match what is happening on the Staging site?

The last question above has been my main concern, at the moment the issue is only happening on Staging, but the form continues to work on the Live site. So I am concerned that updating / saving the form post on Live is going to introduce the same error.

• This reply was modified 6 months, 1 week ago by Rick Curran. Reason: Fixed typos, grammatical changes

If you step through that form you should see an error in the console when you select a file, if you go to the last step of the form, check the tick box and try to submit it will then come up with the “One or more fields have an error” message.

Hi Andrew, I have contacted via the Help centre now.

Hi Andrew, thanks for your reply. I’m not sure I understand the context of your reference to “Translate Post Tags only on the %sTags%s page“, I haven’t done any specific coding to implement this plugin, the process has been to install the plugin. The error causes a fatal error on both the frontend and backend admin, so I had to connect to the site via SFTP and remove the plugin from the plugins folder to be able to get in and log in to the site. As soon as I re-activated the plugin it cause the error again.

However, I’ve managed to do a bit more debugging which may shed a bit more light. The site is using English and Ukrainian and I think the error is occurring when the site is switched to Ukrainian.

I was able to determine this by rolling back to version 1.4.8 of the plugin which did not have the error occurring, with that version activated the site was running without error. I could see that the language switcher was set to Ukrainian (and could also confirm this as I the Multilanguage plugin settings in the WP Admin were also in Ukrainian). With version 1.4.8 activated I switched the language back to English and then updated the plugin to version 1.4.9 again, when running in English the site works fine but when I change to Ukrainian the error occurs and the site is down again.

So it seems to be something about the Ukrainian translation that is triggering the error, and it is something that changed in version 1.4.9 that is causing this as with 1.4.8 it works without error.

Let me know if there is anything else you need to know.

Thanks again for your help!