WordPress – Contact Form 7 Better Database Plugin

The Contact Form 7 Better Database Plugin is a lightweight plugin that adds database support to CF7 so submitted form data will be stored in the database and accessible via the Administrator panel of WordPress.
One of the main goals is to keep the code minimal and utilise built-in WordPress functions/hooks/filters to make it well integrated and add minimal changes to WordPress including using existing WordPress database tables for storing the data.

Isn’t there already a plugin that does this?

Sorta. There’s the Contact Form 7 to Database Extension plugin that offers lots of features and even supports the Fast Secure Contact Form plugin all within the same plugin.
But after I ran into issues with it crashing my site to only discover it was because the plugin was storing uploaded files in binary form in the database instead of copying the files and referencing them via a link, I had to find something different.
When looking into solving this issue with that plugin, I found it had over 50 files to go through and decided not to spend any more time going through them to correct the issue. After all, we’re only talking about grabbing the submitted form data and storing it while allowing it to be viewed/moderated from the admin panel … surely we can do this in less than 50+ files.

Thus … this project was born.

Project Goals

• Use WordPress’ built-in features.
  • Use custom post type for form data.
  • Use post_meta for storing the flexible fields data, this way when the post is retrieved/deleted, WordPress does all of the querying to combine the data and saves us a lot of unnecessary query syntax/functions.
  • Use Media Library for attachments – WordPress already uses this for post attachments and since file uploads are form attachments, let’s use it too! I’d like to separate them if possible from the regular attachments as long as it’s not overly complicated.

• Minimal plugin size – It’s not a complicated plugin since CF7 is already doing the majority of the work, so the number of files/lines of code shouldn’t be excessive.
• WordPress best practices – I continue to strive to learn and use the correct ways/techniques of integrating plugins with WordPress and this one is no exception. Development should be done with WP_DEBUG set to true and all NOTICE level errors should be fixed. This is a huge pet-peeve of mine with many themes and plugins.
• Documented code – Code should be documented so the next guy doesn’t have to learn some sort of Da Vinci Code just to figure out what the heck is going on in the plugin. My desire is always for future development and improvements and that shouldn’t be made any more difficult for someone than it has to be.