Saving uploaded file to the 'file' column

This should just work by default.

When you do a form submission, does CF7 send you the uploaded file as an attachment in email? If not, do you have defined in your php.ini file “upload_max_filesize” or “post_max_size”

Thanks for the reply, Michael!

It looks like they do have it set up to send the uploaded file as an attachment in an email. Would that stop it from getting uploaded to the database?

Also, I don’t believe it’s an issue with max file size as I’ve tried uploading an 18kb file that didn’t get put into the database

No that won’t stop it. But if you are failing to get it in the email, then we know that Contact Form 7 is not getting the file thus CFDB cannot get it downstream. In such as case, the problem may have to do with the ability to upload the file and not directly with the plugin(s). I’m just trying to see if that is the case. Once possible cause is if the file is too big for what is the server is configured to allow to be uploaded (those setting in php.ini).

But if you are getting the file in email, then the problem is likely related to the plugin.

I just asked the client, and they said that they have been getting the resume files as attachments in the emails that are sent out, so it doesn’t seem to be an issue of actually uploading the file.

After some investigating, it seems like several of the older submissions have the data in place, but most of the newer submissions don’t.

I did a query on the table and found that around 1857 out of 2408 entries have the file data in the database, but the rest are null including most of the recent submissions. The closest submission that actually has a file uploaded into the database was on 4/10/2013 1:24:52 PM. So it looks like a good bit of the older ones have the data, but most of the recent submissions don’t.

In fact, from January 17th, 2013 and back, it seems like it was working fine. From then until now, only 4 of several hundred submissions has actually stored the file in the database.

I talked with the client, and on January 17th, they actually updated the WordPress core when it started having these issues. He said they didn’t update the plugin though, so maybe WordPress 3.5 has issues with their version of the plugin.

We’re able to get to the files using the following URL:

https://www.OurWordPressDomain.com/wp-admin/admin-ajax.php?action=cfdb-file&s=TIMESTAMP&form=Career+Inquiry&field=resume

where TIMESTAMP is the Unix time code for that entry. So we know the data is there somewhere, but I just can’t seem to get it from the database after this update to the plugin happened.

Do you know where the data is stored that this URL pulls from?

If it helps, here are the versions of the plugins we have:

Contact Form 7 version 3.0.1
Contact Form 7 Modules: Hidden Fields version 1.2.1
Contact Form 7 Modules: Send All Fields version 1.2.1
Contact Form to DB Extension version 2.2.4

Do your have an “error_log” file defined in your php.ini? If so, there may be exceptions written there. If you don’t have this set, I suggest defining an “error_log” file and doing a test submission.

Also: I want to see if somehow we have duplicate entries for the file but some with and without the actual file data. If you take that example where you have the unix timestamp, run the following query filling in the correct values for <stuff in brackets>

SELECT length(file) AS file_size
FROM wp_cf7dbplugin_submits
WHERE form_name = '<your form name>'
AND submit_time = <your unix timpstatmp>
AND field_name = '<the field name of the upload file>'

if you get more than one row back, then we may need to clean up the data. The returned values is the file size, so >0 means there is data there.

Thanks for your responses Michael! We’ve donated to the project and really appreciate your help on this.

I set the error_log file, but nothing is going into it even after submitting the form. I may have missed a setting, so I’ll go back and check on that to be sure.

I ran the query, and I’m only getting one result for the files. I did notice something, however. The link is allowing us to download the file, but the files are all empty after they are downloaded. The result for your query on one of those files is NULL for the file length. I think I got excited that a file was being downloaded, but didn’t check to see if it actually had any data.

OK, so we are back to the files just not getting saved in the DB. Double check your error_log. Looking at the plugin code, if the file fails to get saved in the DB, there should be an error message “CFDB Error: could not save uploaded file” or “CFDB Error” with some other text.

PS. looking at the versions you list, CF7 is really out of date. And the current version of CF7 requires WP 3.5. It sounds like the site upgraded its WP version but did not upgrade plugins with likely have needed changes. You should just upgrade all the plugins.

Hey Michael, I actually had the client upgrade all of the plugins last night to see if that fixed the issue, and it did! There’s still a few months of empty file data, but at least now any new applicants will have their file data stored in the database. Thanks for all of your help with this!