There are several ways to collect, store, and use data in a WordPress website. In this article, I’ll discuss and compare three of them: Forms, Custom Post Types (CPTs) and custom database tables.
My definition of “data” for this discussion is:
Multiple occurrences within a collection of identically-formatted information. Each occurrence is unique within the set. But the collection as a whole has its own identity and requirements for how the information is to be used.
An example of a simple Form is the ubiquitous Contact Form seen on almost every website. It collects a subject line, a message, and some way (name, email address, phone number) to reply to message. It sends the message to the site owner, and then is probably never needed again.
Custom Post Type
A CPT leverages the standard WordPress features for adding and publishing Posts, but with the ability to identify this set of posts separately. A CPT may also define custom fields (post metadata) to be entered along with the usual title, content, featured image, etc. A theme template can be associated with the CPT to allow all posts of this type to be displayed with the same styling, including the display of the custom fields in a specific manner.
Custom Database Table
Custom tables allow a WordPress plugin developer to store data outside of the standard structure, in normal SQL tables. The tables can be defined with complex relationships, and the data can be presented in many ways: listed, summarized, charted, etc. This is the most flexible way to store information, at the cost of needing full custom programming and being unable to use most of the WordPress default features.
When to use Form vs. CPT vs. Table?
There is overlap between these three tools. The major Forms plugins provide conditional logic, built-in functions, and hooks to add custom code. CPTs, also, can be manipulated programmatically, often using functions that WordPress provides for that purpose. Custom tables still need an HTML form involved somewhere, in order to provide a way for user to input their data.
However, each tool has a “sweet spot” where it provides the functionality needed for the purpose without either overkill or painful restrictions. Using custom tables is probably not necessary for a contact form! Conversely, a Form plugin probably will not be sufficient to write an online Payroll application.
I haven’t gone to these extremes, but I have done variations of this kind of poor fit between the tool and the task.
- I have made the mistake of thinking some new data-collection need was for “just a form”. I found later that the data from the form entry was part of a far larger business process; the form itself was only the tip of the iceberg.
- I’ve made a similar mistake with a CPT, collecting information that started as only a few simple fields but that would grow to almost 100,000 entries. For those entries, everything was in custom metadata; the task had no use for the post content or featured image, and the post title needed to be a unique identifying key.
I have also had some successes.
- I’ve done a fair-sized multi-user application whose core is one large multi-page Formidable Form, plus many of its built-in functions and some custom code.
- I’ve been very happy with CPT’s to help clients enter repetitive articles about the same topic on their websites without having to worry about creating and styling new pages. This is especially helpful if there are custom fields that should be required for each article.
- I’ve done applications as plugins with full custom database and my own HTML forms. I discovered advantages like being able to search-and-replace to propagate changes throughout the code (difficult in drag-and-drop editors) and ability to track the changes using version-control repositories like Github.
From those experiences, here are some guidelines that I can suggest as you make your own tool/task decisions:
If the data to be collected is …
- Straightforward fields without complex relationships
- Input from the front-end by the site visitor (rather than from the dashboard by a site editor)
- Used once and then has served its purpose (not constantly referenced later)
…it is a good candidate for a Form.
If the data is …
- Heavy on text paragraphs about a subject (think “blog post”)
- Entered by an editor via the WordPress dashboard
- Needs to be presented on the site in a particular format or style distinct from normal posts
…it is likely to be a best as a Custom Post Type.
If the data …
- Has complex relationships or logic required
- Needs to be manipulated programmatically (summarized, reported, graphed)
- Has a lot of volume (hundreds or thousands of occurrences)
…it probably needs one or more Custom Database Tables.
Forms or CPTs or Custom Tables, which to choose? Each can be excellent, depending on your needs. I hope this discussion helps you to find the right fit, and I wish you success with your next project.