Currently, email notifications are automatically sent to the admin_email with the subject line "{Form Name} Response". The configuration for this should be adjustable both at a global level and on a per-form basis.

Develop additional form types that provide diverse approaches to handling submitted data. This may include options such as not storing the submitted data as a standard "response," sending customized email notifications, seamless integration with other plugins and services, and directing users to specific destinations based on their inputs.

Before splitting the fields into separate blocks for field, label, and input, I had actually implemented hidden fields as a variation of an input field (ref: df776ec). A new block should be created that encompasses the original functionality.

Road to a stable release 🚀

This issue outlines the work needed to finish before tagging a stable release.

Blocks

Form

This block mimics the functionality of reusable blocks or template parts by using a CPT to store and retrieve the form. The block is used to insert/edit a form in any post or page and renders the <form> element.

• omniform/form

Field

This block renders a complete form field with a label and input. It also provides variations for the most common field types.

• omniform/field

Label

This block renders the <label> element for a form field.

• omniform/label

Button

This block mimics the functionality of the core/button but renders a <button> element to perform form actions like submit and reset.

• omniform/button

Variations

• omniform/button-submit
• omniform/button-reset

Input Field

This block renders the <input> element with a default type of "text" while providing variations for other available types.

• omniform/input

Variations

• omniform/input-email
• omniform/input-url
• omniform/input-number
• omniform/input-checkbox
• omniform/input-radio
• omniform/input-date
• omniform/input-datetime-local
• omniform/input-month
• omniform/input-tel
• omniform/input-time
• omniform/input-week

Select Field

This block renders the <select> element. It also provides a variation for rendering a multi-select element with the multiple attribute applied.

• omniform/select

Variations

• omniform/select-single
• omniform/select-multiple

Option

This block renders the <option> element used within an omniform/select or omniform/fieldset block.

• omniform/select-option

Option Group

This block renders the <optgroup> element used within an omniform/select block.

• omniform/select-group

Textarea Field

This block renders the <textarea> element.

• omniform/textarea

Fieldset

This block renders the <fieldset> element.

• omniform/fieldset

CAPTCHA

This block renders a CAPTCHA that must pass validation in order for the user response to be saved. Akismet integration is possible in the future with an ability to assign specific fields to the name, email, and message structure that the service expects for spam protection. I'm not a huge fan of the honeypot method at this point but I'm not opposed to adding it if there are enough requests for it.

Google's reCaptcha service seems to be pretty standard but I wanted to present hCaptcha as a privacy-first alternative. Both of these services have an almost identical API and implementing all three was simple and obvious. Friendly Captcha looks like another good alternative that could be implemented at a later date.

• omniform/captcha

Variations

• omniform/captcha-recaptchav2 reCaptcha v2
• omniform/captcha-recaptchav3 reCaptcha v3
• omniform/captcha-hcaptcha hCaptcha

Custom Post Types

This custom post type is for storing all information related to a single form's configuration.

• omniform

This custom post type is for storing all response data for a single form submission.

• omniform_response

Hooks

• on impression (omniform_form_render)
• after response is saved (omniform_response_created)

Documentation

• Build out section on site for documentation.
• Document omniform/button
• Document omniform/field
• Document omniform/fieldset
• Document omniform/form
• Document omniform/input
• Document omniform/label
• Document omniform/select
• Document omniform/textarea

Implement two distinct blocks, one for success messages and another for errors, allowing users to freely position and style their messages.

The "required" rule is the only optional validation rule applied to form fields. Appropriate validation rules should be applied to each field on the PHP side, such as requiring an email value for email fields, a URL for URL fields, and so on.

Hello JR!

First of all congratulations on OmniForm landing on the WordPress Plugin Directory!

I went to check it right away as I'd like to translate the plugin into Italian. However, I didn't see any language/translation option. Are you planning to eventually release language packs, so that we can localize the plugin?

Thanks again for your awesome work! :)

For the initial release, the process of viewing an individual response entry is kept deliberately simple. But there's ample opportunity to enhance its visual appeal and create room for future functionalities. Ideally, leveraging React would be a great choice to accomplish this.