File Attachment Error

We are having some issues with our site that is hosted with WordPress VIP, where every form we have with Contact Form 7 that has a file attachment on it doesn’t work on submit.

I reached out to VIP support, where they essentially told us that we could look at doing some manual updates to the plugin, however these would end up getting rewritten/scrapped everytime we updated the plugin, which is not ideal.

Here was what support said:

——————————–

We’ve tracked the issue you raised to incompatibilities with the VIP File System.

The problem, from a high level (i.e., the line of code that breaks things), is that the wpcf7_maybe_add_random_dir function attempts to create a directory, but the function behaves in a way that’s unexpected (on VIP’s platform) due to code that the function runs (more on this below). 

Theoretically, a workaround for that is to simply comment out this line utilizing the function.

However, it’s difficult to say whether that is a reliable fix, whether it will introduce other problems, or whether it’s even a useful solution, as plugin updates will typically overwrite modifications to the plugin code. 

Previously, we’ve addressed issues with the directory structure so that the CF7 plugin functions in a way that’s compatible with our platform, but our ability to do so relied on a filter that existed within the plugin already.

For this specific problem, there’s no filter that we can leverage that would allow us to apply a fix. 

However, one potential path forward might be for the plugin developer to add a filter here, which could open up reliable options for a fix to this specific problem on our platform, but again, it may introduce others, and whether adding a filter is an option is something that their developers would more readily know than anyone from our side would.

To elaborate more on the specific code within the wpcf7_maybe_add_random_dir function that’s problematic, the issue stems from the use of file_exists. 

The reason that’s problematic is a result of what’s mentioned in our documentation here – i.e., if file_exists() is used in code to check if a directory exists, it will always return true for paths within /wp-content/uploads/.

Because the use of file_exists always returns true, its implementation within the function (where it tries to create a random directory) causes an infinite loop, and ultimately leads to the continuous spinner with no successful submission that you pointed out when opening the ticket.

Similar to the potential workaround of simply commenting out the line that breaks things, there might be some way to modify the function’s use of file_exists, but at best, that’s a short-term potential solution that’s overridden each time the plugin is updated.

So, to summarize, it’s likely there are custom solutions that modify some aspect of the plugin’s code in a way that works on our platform and addresses your issue, but we don’t typically recommend that sort of approach, given it’s less of a solution and more of a temporary workaround, in which there are other new problems that could arise.

With all of the above points in mind, there’s no apparent resolution that’s viable or ideal, leaving only a couple of avenues that might act as a long-term solution:

• With the examples of incompatibilities between plugins and our file system in mind, find another plugin that satisfies the functionality your site needs
• Work with the CF7 plugin team to implement a change that allows more flexibility to customize plugin behavior, especially as it pertains to the uploads directory
  • As mentioned above, one thought that comes to mind might be to add a filter here

——————————–

The page I need help with: [log in to see the link]