As expected, Torro Forms registers a post type called torro_form which represents forms. In addition, it registers a taxonomy called torro_form_category, an internal means to categorize forms. Those work just how you would expect it from WordPress. You can edit them in the backend, and since the post type is set to be public, you can also view forms on the frontend. However, Torro Forms includes many more content types than those two. In order to have a clean and organized database structure with something as complex as forms, it is just not viable to store everything that belongs to a form post as metadata. Therefore the plugin introduces its own database tables for the additional content types. Those tables are:
wp_torro_containers: Containers are the individual pages of a form. Most simple forms only have a single one, but more complex ones may need to split the form fields across multiple ones. A container always has a parent form it is associated with.wp_torro_elements: Elements are the actual form fields. Their most important properties are their type, which determines how they generally work, and their label. An element always has a parent container it is associated with.wp_torro_element_choices: Element choices are the choices to pick from in elements that require them, for example elements of typedropdown. An element choice always has a parent element it is associated with.wp_torro_element_settings: Element settings are simple key-value pairs which define the behavior of the element they belong to. The settings an element needs are mostly defined by that element’s type. An element setting always has a parent element it is associated with.wp_torro_submissions: Submissions are a set of user-submitted data for a form. They store user identification data, and they also support metadata through an extra table. A submission always has a parent form it is associated with.wp_torro_submission_values: Submission values are the individual values submitted by the user for a submission. While they could alternatively be stored as submission metadata, having them in their own table makes them more performant to query and keeps concerns separate.wp_torro_submissionmeta: This is not a content type, but simply the additional table that allows submissions to have arbitrary metadata stored.
Content Type Properties
Here you see a simplified UML diagram of all content types, their main properties and how they are hierarchically organized.
The class names used above are the actual classes used to represent the respective objects. They all have a common base class, making their technical usage coherent and easy to learn (read the “Working with the plugin’s object types” article to learn more). A few extra annotations:
- The
idattributes on all objects are read-only. They are automatically set when an object is persisted with the database for the first time. You can then use that ID to access the same object again later. - As mentioned before, forms do not use a custom database table, but are a regular post type. The
awsmug\Torro_Forms\DB_Objects\Forms\Formclass is however still abstracted away from that, exposing only the data relevant for the plugin. It is mapped internally to properties of the post object that is actually persisted with the database. Although there are no such plans at this point, this abstraction would allow to in the future move away from using a custom post type. - Form categories are excluded from the above diagram, although they also have a
awsmug\Torro_Forms\DB_Objects\Form_Categories\Form_Categoryclass. That is because they are really only used internally and don’t interact with the other objects in any way – except of course that they are associated with forms, just as known taxonomy behavior.