CodeCanyon DHVC Form - WordPress Plugin

A Guide to Setting Up CodeCanyon DHVC Form and Building Forms in WordPress

CodeCanyon DHVC Form is a WordPress plugin that helps you build forms through the visual interface of WPBakery Page Builder. This guide does not repeat the product's short description. Instead, it walks through the real steps that matter after installation: field logic, notifications, spam protection, a service inquiry workflow, and how to verify the final result on your site.

The main goal of this guide is to show how to go from an installed ZIP archive to a working form that not only looks good on the page, but also submits data reliably, stores entries, and does not break because of the theme, caching, or an outdated PHP version. We will also look at when DHVC Form is a practical choice and when another form builder may be a better fit.

This guide is based on verified details from the product page, documentation, and support discussions. If exact behavior depends on the plugin version, WPBakery, the theme, or server settings, the wording is intentionally cautious: check first, change second, roll back if needed.

What problem the plugin solves and how it differs from a standard contact form

DHVC Form belongs to the form builder category, but its key strength is not a separate admin page for fields. Its real advantage is the way it works with WPBakery Page Builder. You build the form as part of the page itself: add form elements, configure them, and place them alongside text, buttons, columns, explanations, and other builder blocks. That makes the plugin especially useful on sites that already rely on WPBakery, where editors want to keep working in a familiar visual interface.

The product page confirms support for drag-and-drop form building, AJAX submission, entry saving, CSV export, notifications, multiple field types, conditional logic, multi-step forms, file uploads, Mailchimp and PayPal integration, plus login and registration elements. That does not mean every feature should be enabled at once. The practical approach is to start with a simple form and add only the mechanisms your use case actually needs.

The main difference for editors is that the form becomes part of the WPBakery layout. That works well when the inquiry form needs to be embedded into a landing page, service page, booking form, application form, or registration block. But if the site already runs on the WordPress block editor and does not use WPBakery, depending on a separate page builder can become an unnecessary extra layer.

For the site owner, form design is only part of the picture. Any form collects visitor data, triggers email, may save an entry to the database, and sometimes sends a subscriber to a third-party service or accepts a file. So after installation, you need to verify more than appearance. You need to test the full handling chain: required fields, spam protection, recipient address, email format, admin entry storage, post-submit behavior, and error flow.

When DHVC Form makes the most sense

The plugin is a strong fit for projects where WPBakery is already the main way pages are built. For example, a service site may already use builder sections and need a quote request form inserted directly into a specific part of the layout. Or an event page may need a multi-step application form: contact details first, then a date choice, then a comment and consent. In those cases, it is more convenient for the editor to stay inside the page builder instead of switching to a separate form builder.

A second good use case is a form where visual presentation matters as much as the fields themselves. WPBakery provides columns, rows, spacing, and styling controls, while DHVC Form adds the form elements. Together, that makes it easier to build more than a plain list of fields. You can create a clean inquiry block with an explanation in one column, the form in another, and benefits or a validation checklist below.

A third use case is a site where the editor needs more than basic email submission: conditional fields, submission records, CSV export, login forms, or registration forms. The main requirement is to confirm in advance that these features are supported by your current version and do not conflict with the rest of the plugin stack.

When this should not be your starting point

If WPBakery Page Builder is not installed or not used on the site, DHVC Form may not be the most straightforward choice. First, you would have to maintain the page builder itself, and only then the form. For a site built on the block editor, Elementor, or a lightweight theme without WPBakery, a modern form builder with no extra dependency will often be simpler.

Another reason to pause is advanced automation. If you need complex calculations, user dashboards, deep lead analytics, CRM-heavy integrations, payment workflows, or many editorial roles, compare DHVC Form with more specialized tools. It may handle a service inquiry form and some advanced scenarios, but it is not meant to replace a full CRM or a large business process builder.

Security and support also deserve attention. Independent vulnerability databases have documented a privilege escalation issue in older DHVC Form versions prior to 2.4.7. So before using it on a live site, make sure you are running a fixed release and that form editing is restricted to trusted roles only.

What to check before installation: WPBakery, plugin version, and editor role

Installation prep should not be treated as a formality. A form builder runs inside WordPress and depends on several layers: the CMS core, the theme, WPBakery, email delivery, caching, user permissions, and sometimes third-party services. A failure in any of those layers can look like "the form does not work," even when the form itself was built correctly.

The first thing to verify is WPBakery Page Builder. DHVC Form is positioned as a form solution for Visual Composer/WPBakery, so the site needs a working page builder. Check that WPBakery is active, that the editor opens on the correct content types, and that builder elements are available for the current user role. If the editor is hidden for an author or manager role, the form element may not appear in the add-element interface.

The second item is the DHVC Form version itself. Do not rely on an old archive sitting in a project folder. Check the changelog on the product page and make sure your version is not part of a known vulnerable range. If the site has already been running an older release, back up the database and files before updating, then test forms on a staging copy or in a safe environment.

The third item is PHP and server compatibility. Support discussions have referenced symptoms tied to outdated server environments and JavaScript conflicts. That does not mean the plugin always conflicts, but it does suggest the right sequence: update the foundation first, disable unnecessary optimization second, and test the form after that.

Quick pre-check map

If the site is already live and receiving inquiries, do not install a new form builder directly on a production page. Clone the page, restrict access, build the form, submit several tests, check the emails and entries, and only then replace the old form. It takes a few extra minutes, but it lowers the risk of losing real leads.

Practical pre-installation check: make sure you have a backup, administrator access, a working WPBakery setup, and the ability to send a test email from the site. Without those four conditions, troubleshooting will take longer than configuring the form itself.

Installation and the first check without overloading the settings

DHVC Form is installed like any premium WordPress plugin from a ZIP archive: in the admin panel, open Plugins, select Add New, then Upload Plugin, upload the archive, and click Activate. If WordPress says the archive does not contain a plugin, the usual reason is that you uploaded the full package with documentation and a nested plugin ZIP instead of the actual installable plugin file. In that case, extract the package locally and locate the plugin archive itself.

After activation, check whether the DHVC Form element appears in the WPBakery interface. The easiest test is to create a draft page, open the visual editor, and try adding a basic form with one text field, one email field, and a submit button. Do not add conditional logic, file uploads, or external services yet. At this stage, you only need to prove that the "editor - form - submission" chain works in its minimal form.

If the form was added successfully, publish the test page in a restricted mode or open its preview. Check three states: an empty form, a required-field error, and a successful submission. This matters because a form may display beautifully while failing to validate required fields, or validate fields correctly while failing to send the email.

Which settings not to touch on day one

New users often enable everything at once: reCAPTCHA, Mailchimp, PayPal, file uploads, multiple steps, hidden fields, and conditional branching. That makes troubleshooting harder. If the form stops submitting, you no longer know where to look: required field logic, API key, upload directory permissions, mail delivery, or a script conflict.

A better approach is incremental rollout. Start with a simple form and email. Then enable entry storage. Then spam protection. Then conditional logic. Then integrations. After each step, run a test submission and record what changed. Every new feature should have its own result check, otherwise the form turns into a black box.

Editor permissions and form access

If people other than administrators will manage forms, verify role permissions in both WPBakery and WordPress in advance. An editor may be allowed to modify the page but blocked from adding certain builder elements. It is also worth restricting access to settings that control email recipients, external services, file uploads, and user registration. That is not about distrust. It is basic protection for your lead handling flow.

For a small team, one simple rule is usually enough: one responsible administrator changes system-level form settings, the editor changes text and labels, and the manager only reviews entries. If that separation is not possible with the standard tools, it is better not to grant form access to every site author.

Post-install settings map: from fields to a verified result

Once DHVC Form is installed, it is tempting to jump straight into building a nice-looking form on the page. But a reliable form should be designed from the result backward, not from visual style forward. What data needs to reach the manager? What should the user see? Where should the entry be stored? What check confirms success? Once you start with that map, the settings become much easier to understand instead of turning into a random collection of enabled options.

A practical map has five layers. The first layer is the fields the visitor fills out. The second is validation rules: required status, email format, allowed values, file size. The third is the post-submit action: an AJAX message, a redirect, or another result confirmed by your version. The fourth is internal processing: email, entry storage, export. The fifth is external services: reCAPTCHA, Mailchimp, PayPal, and any additional handlers. You should not configure the fifth layer until the first four have been verified.

This order is especially useful on WPBakery-based sites. The visual editor makes it easy to assemble an attractive section, but the form inside that section is still a technical workflow. A field placed in a beautiful column still has to pass validation. A button that matches the theme design still has to submit the request correctly. A post-submit message that looks like a normal text block still has to appear at the right time.

Level 1. Fields and data names

Start by deciding what data you actually need. For each field, define a clear label, a field type, and its role in the email. If a field is labeled "Subject," the manager should know whether it means the inquiry topic, the requested service, or the email subject line. If a field is labeled "Company," decide whether it should be required for individual customers. If a field is hidden, it should carry real internal data, not serve as a placeholder for a future idea.

A good practice is to keep a short internal table next to the form definition: field name, purpose, who reads it, and where it appears. You do not have to publish this table. It helps preserve intent during future edits, especially if another editor will update the form a month later.

Level 2. Validation and required fields

At the second level, define what mistakes users might make and how the form should respond. An email without an @, an empty required field, a file that is too large, or an unchecked consent box all need to be tested manually. If the user only sees a generic "error" message, they have no idea what to fix.

DHVC Form offers a range of form elements, but the final behavior still depends on the specific build and page. So test every field type separately. For a date picker, check date selection, manual input, and mobile browser behavior. For a select field, make sure the placeholder option is not submitted as if it were a real choice. For a consent checkbox, confirm it is not preselected if that matters for your policy.

Level 3. Post-submit message

The user needs to understand that the inquiry was received. The post-submit message should be specific. "Thank you, your request has been sent. We will reply to the email you provided" is better than "Success." If the form is tied to a consultation request, explain what happens next. If the form includes a file upload, clarify that the file was received, but only if your verification confirms that behavior.

If you use a redirect instead of an inline message, make sure the thank-you page is not cached with another user's data and is not indexed as a generic landing page unless it has its own standalone value. For standard inquiry forms, an inline message below the form is usually enough because it keeps the user in context.

Level 4. Internal processing

This level is about what happens after the button is clicked. The email should arrive at the correct address, the entry should be saved, the export should open properly, and the manager should understand the meaning of every field. If the email only contains technical field names, the manager will make mistakes. If the stored entry misses the user's key selection, the form loses much of its value as a record.

Run at least three test submissions: one valid request, one with a long comment, and one where the user makes a mistake and then corrects it. The long comment helps you see whether the email breaks or truncates text. The corrected-error test shows whether the form preserves the data the user already entered.

Level 5. Integrations and external validation

Only connect external services after internal processing works correctly. reCAPTCHA should filter automated submissions without blocking real visitors. Mailchimp should receive a subscriber only when there is clear consent. A PayPal flow should be tested as its own chain, with a clear outcome for both the user and the administrator.

If the form breaks after you connect an external service, step back one level. Do not rebuild the entire form. Disable only the new service, rerun the test, then check keys, domain, API fields, and restrictions. That makes it much easier to locate the cause without chaotic edits.

Reusing forms in WPBakery without copying old mistakes

One of the strengths of DHVC Form combined with WPBakery is how quickly you can reuse a similar block on another page. But copying a form without reviewing it often carries old mistakes along with it: the wrong email subject, an unnecessary field, an incorrect lead source, an outdated message, or a condition that only fits the original page. Reuse should be deliberate, not automatic.

If you need the form on multiple service pages, do not create ten separate versions without a reason. First decide what actually changes. In most cases, only the lead source, the email subject, a hidden service label, and the supporting text next to the form need to change. Fields, spam protection, and core validation should stay consistent. That gives the manager a uniform lead format and keeps the editor from maintaining a cluster of almost identical forms.

When to copy the entire block

Copying the full WPBakery block is convenient when both the form and the page context are nearly identical. For example, a site may have several service pages that all need the same consultation request form. In that case, you can copy the row containing the explanation and the form, then change only the nearby text and the notification subject. After copying, always submit a test from the new page, because the lead source and email subject need to remain distinguishable.

If the form lives inside a saved WPBakery template or a library block, be careful. Changing the template may affect multiple pages. Before editing, confirm whether you are working with a local copy or a shared element. On a business-critical site, it is smart to keep a short list of pages that use the form so you can rerun tests quickly after an update.

When it is better to create a separate form

A separate form is the right choice when the logic changes. For example, a support page may ask for the site address and an issue description, while a pricing page may ask for budget and timeline. If you try to force both scenarios into one form with a large number of conditions, it becomes harder for users and harder to troubleshoot. Two simple forms are often more reliable than one universal one.

A separate form also makes sense when different recipients are involved. If job applications go to HR and support requests go to the technical team, do not mix them into a single notification with conditional addresses until every branch has been tested. A mistake in the conditions can route sensitive messages to the wrong person.

Text versioning and post-edit control

Forms rarely go through a review process as formal as code. But for important forms, one simple rule is worth adopting: any change to fields, notifications, reCAPTCHA, integrations, or conditional logic requires a test submission. If you only change explanatory text next to the form, a visual review is enough. CSS changes should be checked both at page width and in the error state.

If the team updates forms frequently, keep an internal note with the basics: what changed, on which page, who tested it, and which test email was used. That is not bureaucracy. It is how you avoid losing leads because of an invisible edit. With DHVC Form living inside a WPBakery visual layout, that discipline is especially helpful because an editor can accidentally change not just text but also form behavior.

Form fields: how to build a clear structure instead of a long questionnaire

Fields are not just technical elements. They define how well a visitor understands what you are asking for and how useful the submission will be to the manager. The DHVC Form product page confirms support for multiple field types, including text fields, email, textarea, checkbox, radio, select, date picker, file upload, and other elements. But form quality does not come from the number of fields. It comes from how well those fields match the task.

For a simple inquiry form, a name, email or phone number, an inquiry topic, and a comment are usually enough. For a service-matching form, you can add a select field for the type of request and a textarea for details. A registration form needs account fields, a password or confirmation field, and a clear post-submit message. A form with attachments must explain what files can be sent and must be tested against the server's file size limits.

Validation means checking data before the form is processed. It is not just for email fields. If a field is required, the user should see a clear message next to it. If a field accepts a date, the expected format should be obvious. If a field accepts a file, the visitor should not be left guessing why the upload failed.

How to choose required fields

A required field should be genuinely necessary for the first response. If the manager can contact the person by email, the phone field is usually better left optional. If the inquiry requires the user to choose a service, a select field can be required, but the option list should stay short. Too many required fields reduce submission rates and increase the number of unreliable answers.

Test every required field with one question: "What can we not do without this value?" If the answer is unclear, the field should probably be removed or made optional. That matters even more in DHVC Form because the visual builder makes it very easy to keep adding elements until the form grows out of control.

Hints, placeholders, and error messages

An in-field hint only helps until the user starts typing. So important instructions are better placed next to the field or in a short description before the group. A placeholder can be used to show the format, for example: This email address is being protected from spambots. You need JavaScript enabled to view it., +1 555 0100, I need a project cost estimate. But do not use a placeholder as the only field label.

Error messages should tell the user what to do next. "Invalid" is a poor choice. "Enter an email in the format This email address is being protected from spambots. You need JavaScript enabled to view it." is much better. If your plugin settings allow custom error messages, replace abstract wording with text users can actually act on. If the current version does not expose a specific field for changing the message, do not edit the plugin files. It is safer to improve the field label or add a short explanation above the form.

File uploads without unnecessary risk

A file upload form is useful for design requests, support tickets, resumes, renovation estimates, document translation, or technical diagnostics. But it requires discipline. Allow only the file extensions you actually need, limit file size, do not ask for sensitive documents without a clear reason, and verify where files are stored.

If emails with attachments do not arrive, do not assume DHVC Form is the only problem. Many servers limit email size or block attachments. In that case, it is safer to store the uploaded file on the site and send the manager a notification with a link or a notice about the new submission, if that mode is available in your settings. If your version does not confirm that behavior, stick to small attachments and verify delivery through an SMTP plugin.

Notifications, entries, and the admin email

A form is only truly working when the data reaches the place where people will act on it. In DHVC Form, two channels matter most: the email notification sent to the administrator and the submission entries stored in the admin area. The product page confirms support for saving entries and exporting CSV, which means you do not have to rely on the inbox alone.

Email is useful for fast reaction: the manager gets a notification and replies to the visitor. Entries are useful for control: even if the email lands in spam, the submission can still be found in WordPress. CSV export is helpful when inquiries need to be moved into a spreadsheet, CRM, or report. Do not disable entry storage until you are sure email delivery is consistently reliable.

Recipient address and the "from" field

A common mistake is putting the visitor's address in the email sender field. On modern mail servers, that can break delivery because the site is effectively sending mail from someone else's domain, which looks suspicious. A safer setup is to use a sender on your own domain, such as This email address is being protected from spambots. You need JavaScript enabled to view it., and place the visitor's email in the reply-to field or in the message body.

Test the notification setup like this: submit the form using an external email address, inspect the message headers, and click "Reply." If the reply goes to the visitor and the email stays out of spam, the setup is correct. If messages do not arrive, the first thing to check is not the form but WordPress's ability to send mail at all.

Email template and useful submission data

The email should be short, but complete enough to work with. Include the name, contact details, selected service, message text, submission date, the page the request came from, and technical details only when they are genuinely needed. Do not overload the email with every hidden field if the manager never uses them.

If the form appears on multiple pages, it is helpful to add a hidden field or internal source marker if your version supports it. That way, the manager can see which service page generated the request. If the plugin does not provide that option in your setup, use separate forms for important pages and distinguish them through the email subject line.

CSV export and lead quality control

CSV export is useful for more than reporting. It helps you spot which fields users fill incorrectly, where they often leave empty comments, which services are selected most often, and which messages repeat again and again. After a few dozen submissions, export the data and see whether there is a field that almost everyone skips or fills with the same low-value answer.

If a field does not help the manager make a decision, remove it. If users keep typing the same information into comments, turn that information into a select or radio field. That kind of improvement cycle does more for the form than generic advice about "higher conversion."

Conditional logic and multi-step forms: when complexity is justified

Conditional logic is useful when the form needs to react to the user's answer. For example, if someone selects "Website Support," the form can reveal a site URL field. If they choose "New Project," it can show a budget or timeline field. The product page lists conditional logic support, and that is one of the features that can make DHVC Form more useful than a very basic form plugin.

A multi-step form is useful when there are too many questions to show comfortably in one long list. But it should not be used to hide poor structure. If the form has ten fields, sometimes the better solution is to cut it down to five instead of splitting it into three steps. Multi-step design makes sense when the stages are clear: contact details, project parameters, confirmation.

How to design conditional logic

Start with a question map on paper or in a document. List which fields each type of user should see. Then build the form without conditions and make sure every field works. Only after that should you add display rules. That makes it much easier to tell whether the problem is in the field itself or in the condition.

Conditions should stay simple. One selection field should control one group of extra fields. If multiple conditions overlap, you risk hiding a required field that is still needed for submission. That kind of failure often shows up as a form that cannot be submitted for no obvious reason.

Example of safe logic

For a service request form, you can create a field called "Request Type" with options such as "Consultation," "Website Support," and "Cost Estimate." If the user selects "Website Support," a "Website Address" field appears. If they select "Cost Estimate," a "Project Description" field appears. These conditions are clear to both the user and the manager. If they choose "Consultation," no extra technical fields are shown.

The check is simple: submit the form once for each option and make sure the email contains only relevant data. If a hidden field shows up in the email with an empty value, adjust the email template or the form structure. The user should never see the internal mechanics of the conditions.

Multi-step forms without losing submissions

A multi-step form should stay short. The first step should ask for the easiest action, such as choosing a goal or leaving a contact detail. The second step can ask for specifics. The final step should show the submit button and briefly explain what happens next. If the first step demands too much writing, some visitors will leave before they understand the benefit.

After building a multi-step form, test browser behavior carefully: can the user go back, do entered values persist between steps, does the selection reset after an error, and are required fields validated on the correct step? Those details matter more than decorative progress bar styling.

Spam protection and careful use of external services

A form that is clearly visible on a site will almost inevitably attract automated submissions. DHVC Form lists support for reCAPTCHA, as well as Mailchimp and PayPal integration. Each of those features can be useful, but each one also requires its own validation. Spam protection affects submission flow, mailing list signup touches personal data, and payment logic needs especially careful testing.

For a standard contact form, start with basic anti-spam protection. If you use reCAPTCHA, generate keys for the correct domain, place them in the settings, and test the form in a normal browser window, not just while logged into the admin area. If the validation does not appear or the form stops submitting, temporarily disable JavaScript optimization and inspect the browser console.

reCAPTCHA: what to check first

reCAPTCHA has a client-side part on the page and a server-side validation step. If the keys do not match the domain or the script does not load, the form may show a validation error. If the server cannot verify the response, submission may also be rejected. So your test must cover not only the widget display, but an actual successful submission.

Do not enable reCAPTCHA together with aggressive script minification unless you test the result. An optimizer may move or merge JavaScript in a way that breaks the validation flow. The safe sequence is: enable reCAPTCHA, submit a test, then enable optimization, then submit another test. If the form breaks after optimization, add the form scripts and reCAPTCHA scripts to the optimizer's exclusion list, if your cache plugin supports that.

Mailchimp and subscription consent

Mailchimp integration is useful when the inquiry form also adds the user to a mailing list. But subscription should never be hidden. Add a separate checkbox with clear consent wording, and do not make it required if the subscription is not necessary to process the request itself. That keeps the inquiry separate from marketing communication.

Verify field mapping carefully: email should go to the email field, name to the name field, and extra data only to fields that truly exist in the Mailchimp audience. If the subscriber does not appear, first check the API key, the audience, and the merge field mapping. Do not change the form blindly.

PayPal and payment forms

If you use a PayPal scenario, treat the form as part of a payment workflow. It is not enough to confirm that the button appears. You need to submit a test form in a safe mode, make sure the user understands what they are paying for, see what happens after submission, and verify what email the administrator receives.

Do not use the form as a replacement for a full store if you need order management, inventory, taxes, shipping, and refunds. For those cases, WooCommerce or another commerce platform is usually the better fit. DHVC Form may work for a simple payment, deposit, or paid inquiry flow, but it should not replace a complete order system.

Login and registration forms: useful feature, higher requirements

The product page lists login and register elements. That gives DHVC Form a broader scope than a typical contact form: it can build forms tied to WordPress user accounts. But those forms demand stricter setup because a mistake affects user access, roles, security, and visitor expectations.

If you need a registration form for a restricted area, first define what should happen after submission. Should the user be logged in immediately, wait for confirmation, receive an email, or go through manual approval? Do not start with the form design. Start by deciding which process is safe for your site.

What should never be granted to a random user

User registration should never grant elevated permissions. New accounts should receive the lowest role appropriate for reading or basic participation. If the site uses WooCommerce roles, membership plugins, or restricted content, verify those access boundaries separately. The registration form itself should never open the door to administrative capabilities.

Messages also need attention. If registration is disabled in WordPress or restricted by another plugin, the visitor should see a clear explanation, not a blank error. If registration is enabled, test both the confirmation email and the page shown after submission.

Safe testing for a registration form

Create a test user with a separate email address, submit the form from a logged-out window, and verify four results: the account is created, the role is correct, the email arrives, and the user does not gain access to areas they should not see. Then remove the test account. If even one of those checks fails, the form should not remain on a public page.

If you suspect a conflict, disable third-party login, registration, and membership plugins only in a test environment. On a live site, disabling them may affect real user access. If the conflict appears only with one specific plugin, record the exact combination in the project notes and continue troubleshooting through the documentation of both products.

Practical scenario: a service inquiry form with entry storage and email verification

Now let us build a practical example that fits most service-based sites: a "Get a Consultation" form on a service page. The goal is to collect a name, email, request type, and comment, send an email to the manager, save the entry in WordPress, and show the visitor a clear confirmation message after submission.

Preparation: WPBakery is active, DHVC Form is installed, a test page has been created, WordPress email has already been verified or an SMTP plugin is installed if server mail is unreliable. Work on a copy or a draft, not on the homepage, so visitors do not see the in-progress state.

Step 1. Create the page structure

Open the page in WPBakery and add a row with two columns. In the first column, place a short explanation: what the form is for, what happens after submission, and when the user can expect a reply. In the second column, add the DHVC Form block. This layout works better than a standalone form with no context because the visitor understands why they are being asked to leave their details.

Do not overload the opening section. If the page already contains a long service description, keep only a short note next to the fields. A page builder makes it easy to add blocks, but forms work best when the surrounding content stays clean and focused.

Step 2. Add fields and set required status

Add a name field, an email field, a Select field for "Request Type," and a Textarea field for "Comment." Make the email and request type required. The name field can also be required if managers genuinely use it in replies. A phone number is better left out of the first version if email contact is enough.

For the select field, use a short list: "Consultation," "Website Support," and "Cost Estimate." If you have more than five options, group them by meaning or rely on the comment field instead. A long dropdown is often less useful than an open-ended question.

Step 3. Configure the notification

In the notification settings, use the manager's address on the site domain or another working address that accepts mail from the site. Make the email subject easy to identify, for example "New inquiry from service page." In the email body, include all field values and a link to the page, if that variable is available. If your version does not confirm a page source variable, add the source manually in the form subject or use a separate form for that page.

Use a sender address from your own domain, and use the visitor's email for replies if the settings allow that. This lowers the risk of mail delivery problems. If you are unsure which field is correct, send a test and check where the reply goes.

Step 4. Enable entry storage and export

Entry storage should be enabled before the public launch. After a test submission, open the entries list and make sure the inquiry appears, the field values are intact, special characters display correctly, and any attachments are either absent or open correctly if you added them. Then run a CSV export and open the file in a spreadsheet application.

If the CSV opens with the wrong encoding, that is not necessarily a form error. Sometimes the spreadsheet tool misdetects file encoding. Try importing the file through the application's import menu with an explicit encoding choice. If the problem appears only in the plugin export, document it and rely on admin entries as the primary channel until you resolve it.

Step 5. Verify the visible result

Open the page as a normal visitor, not from inside the admin area. Submit the form once correctly, then again with errors: an empty email, an invalid email, and an empty required select field. Make sure the messages are clear, the button does not hang, the confirmation appears after success, the email arrives, and the entry is saved.

Quick takeaway from the scenario: the form is ready for publication only after all three channels are verified successfully: the on-page message, the admin email, and the stored admin entry.

Post-launch validation: do not stop at a single test

Once the form is published, run several checks under conditions that resemble real visitors. Open the page in another browser, use a phone only as an extra check, stay logged out, and keep site caching enabled. If the form only works for the administrator, that is a serious warning sign. Scripts or nonce validation may be behaving differently for guests.

Check page performance as well. Forms with several scripts, reCAPTCHA, a date picker, and external services can add overhead. You do not need to draw conclusions from a single speed score. What matters is whether the form blocks the first screen, delays submission, or produces JavaScript errors in the console.

Checklist for the live site

• The form is visible to guests and logged-in users, if that is intended.
• Required fields show a clear error, whether the form validates without reload or with a correct reload.
• A successful submission shows a clear message and does not leave the user uncertain.
• The email arrives at the correct address and does not look like it was sent from someone else's domain.
• The entry is saved in WordPress and can be found later.
• Cache, minification, and deferred loading do not break the submit button.
• If reCAPTCHA is enabled, it is validated for guests, not just administrators.
• If file upload is enabled, file type and size are limited reasonably.

Repeat this validation after updates to the theme, WPBakery, the cache plugin, and DHVC Form itself. The form sits at the intersection of several systems, so a failure may appear not on the day you build it, but after a neighboring layer is updated.

How to tell the problem is not the form itself

If data is saved in entries but the email never arrives, the form most likely submitted the data correctly and the issue is in mail delivery. If the email arrives but no entry is created, check entry-saving settings and permissions. If neither email nor entry appears, investigate submission errors, required field rules, reCAPTCHA, or JavaScript.

That kind of separation saves time. Instead of the vague statement "the form is broken," you get a precise question: is mail not working, are entries not being saved, is validation failing, is a script not loading, or is an external service blocking the request?

Safe visual improvements without editing plugin files

DHVC Form runs inside the page, so its appearance often depends on the theme, WPBakery, and the site's global CSS rules. If the form looks uneven, the button does not match the design, or the fields are too narrow, do not edit the plugin files. Any edit inside the plugin will be lost after an update and may also break other forms.

The safe route is to add a small CSS snippet through a child theme, the theme's additional CSS field, or a trusted code snippets plugin. The basis for that approach is standard WordPress practice: the look of a public-facing block should be adjusted through the theme layer, not through the plugin core. Before adding CSS, inspect the actual HTML classes of the specific form in the browser and scope your CSS to the page or form container so you do not affect unrelated elements.

Custom CSS adjustment for a cleaner form

The example below is a cautious customization. It is not an official DHVC Form API and does not guarantee identical classes across all versions. Use it as a pattern: replace the .service-request-form selector with the container class you personally added to the WPBakery row or the form block.

.service-request-form input,
.service-request-form textarea,
.service-request-form select {
  width: 100%;
  min-height: 44px;
  border: 1px solid #d7dbe3;
  border-radius: 6px;
  padding: 10px 12px;
}

.service-request-form textarea {
  min-height: 130px;
}

.service-request-form button,
.service-request-form input[type="submit"] {
  min-height: 46px;
  border-radius: 6px;
  padding: 0 22px;
}

The post-change check is simple: open the form on the page, confirm that fields stay inside the column, the button is visible, validation errors do not overlap the inputs, and the mobile layout remains intact. Rolling back is just as simple: remove this CSS snippet or disable the container class. Do not use global selectors like input without a container, or you may unintentionally change the site search, checkout, account pages, and other forms.

Compatibility with the theme, cache, and page builder

DHVC Form sits at the intersection of the visual editor, the form engine, and the public page. That means compatibility usually has to be checked as a chain of conditions rather than a single item. The theme controls styles, WPBakery renders the layout, the form plugin adds fields and scripts, the cache plugin may combine files, and the browser executes validation and AJAX submission.

If the form looks wrong, start with the theme. Temporarily switching to a default theme is acceptable only on a staging copy of the site. On a live site, it is better to create a blank test page with a minimal layout and compare the form inside a plain WPBakery row without complex sections, animations, or nested blocks. If the form works on the simple page, the problem is most likely in the layout or styling of the specific page.

Cache and deferred script loading

AJAX submission and dynamic field validation depend on JavaScript. A cache plugin may combine, minify, or defer scripts. That is useful for speed, but it can also break load order. The symptoms are familiar: the button does nothing, the submit indicator spins forever, reCAPTCHA does not appear, the date picker does not open, or conditional fields do not switch correctly.

The right test is to disable only JavaScript optimization temporarily, not the entire site cache, and then submit the form. If the issue disappears, re-enable optimization and add exclusions for the form scripts, WPBakery, or reCAPTCHA one by one. Do not leave the entire cache system disabled if a targeted exclusion solves the problem.

WPBakery and editing elements

If the form element does not appear in the editor, check WPBakery settings for post types and roles. In some configurations, the builder is enabled only for pages and not for custom post types. In other cases, part of the element library may be hidden through the role manager. That is not a form bug. It is an interface restriction inside the builder.

If the form is present on the page but stops being editable after a WPBakery update, create a new test form element on a draft page first. If the new element works, the problem may be in the old saved page markup. Rebuild the settings manually in a new block and compare the result. Do not edit serialized page data directly in the database.

Troubleshooting common DHVC Form issues

Form issues rarely have one universal cause. With DHVC Form, it is especially important to separate the symptoms: the visual editor, the public page, submission flow, email, entry storage, spam protection, and external integrations. Below is a practical troubleshooting guide based on symptoms that are common for this class of form plugins and supported by discussions around the product, WPBakery, and WordPress mail delivery.

The form says submission was successful, but no email arrives

Symptom: the visitor sees a success message, but the administrator never receives the email. Possible causes include WordPress mail delivery, an incorrect sender address, spam filtering, domain policy, or a mistake in the recipient address.

What to check: whether an admin entry was saved, whether the recipient email is correct, whether the visitor's address is being used as the sender, and whether other WordPress emails are arriving. If entries are being saved, the form is passing data correctly and the focus should shift to mail delivery.

How to fix it: configure SMTP delivery, use a sender on your site domain, check the domain's SPF/DKIM records, and repeat the test with an external email. If the email starts arriving after SMTP is enabled, do not change the form structure without a reason.

The submit button does not respond or spins forever

Symptom: the user clicks the button and nothing happens, or the submission indicator never finishes. Possible causes include a JavaScript error, a minification conflict, a reCAPTCHA script that did not load, or a conflict with the theme or WPBakery.

What to check: the browser console, form submission with JavaScript optimization disabled, and form behavior on a simple test page. If everything works on a simple page, look for a conflict in the specific layout. If it fails everywhere, inspect the scripts and optimization plugins.

How to fix it: exclude the form scripts, WPBakery scripts, and reCAPTCHA from script merging or deferred loading, then re-enable optimization one setting at a time. To roll back, restore the previous cache settings and keep the form working.

reCAPTCHA does not appear or blocks submission

Symptom: the widget never shows up, the form displays a validation error, or submission only works when anti-spam is disabled. The cause may be the wrong key type, domain mismatch, an external script being blocked, a cache conflict, or incorrect script load order.

What to check: the reCAPTCHA keys, the domain, the browser console, guest mode, and the effect of caching. Do not test only as an administrator. A logged-in user may get different scripts and caching behavior.

How to fix it: regenerate keys for the correct domain, disable optimization for the validation script, clear the cache, and submit the form again. If reCAPTCHA remains problematic, disable it temporarily and use other restrictions until you find the exact cause.

The form element does not appear in WPBakery

Symptom: the plugin is active, but the editor does not show the required element. Possible causes include WPBakery not being enabled for that page type, the element being hidden for the current role, an incompatible builder version, or incomplete plugin activation.

What to check: whether WPBakery is available on pages, role permissions, the list of active plugins, and whether a new test page can be created. If the element is visible for an administrator but not for an editor, the issue is almost certainly role permissions or builder settings.

How to fix it: enable the required post type in WPBakery, review the role manager, update the WPBakery and DHVC Form combination, and then create a new test block. Do not edit saved markup by hand.

Conditional fields hide incorrectly

Symptom: the required field does not appear after a selection, a hidden required field blocks submission, or empty values are sent in the email. The cause is usually overlapping conditions, overly complex logic, or a required field that is sometimes hidden.

What to check: each selection option separately, the required status of hidden fields, the email template, and a test submission for every branch. Simplify the form to one condition and see whether the problem disappears.

How to fix it: split one complex condition into two groups, remove required status from a field that may be hidden, or create separate forms for separate scenarios. Rolling back means disabling the condition and returning to a flat form if the logic is not essential.

A security issue appears after an update or a scanner warning

Symptom: a security scanner reports a DHVC Form issue, or the administrator sees a recommendation to update the plugin. Independent databases documented a privilege escalation vulnerability in older releases before the fixed version.

What to check: the actual plugin version, the changelog, the availability of a fixed release, and which user roles can edit forms. If the version falls within the vulnerable range, do not delay the update.

How to fix it: create a backup, update the plugin to the fixed release, test the forms on a staging page, and then review user roles. If the update breaks an older form, restore the backup in a test environment and rebuild the form manually in the new structure, but do not stay on a vulnerable version without temporary access restrictions.

Video walkthrough of the DHVC Form interface

The product page includes a demo video for DHVC Form. It is most useful not as a replacement for a written guide, but as visual confirmation of how the builder works: adding elements, working inside the visual editor, and moving from form setup to the final result. If your release looks different, follow the general principle and verify the exact tabs against your current plugin version.

After watching, do not try to repeat the entire video start to finish. Revisit only the part you actually need: building a basic form, adding fields, configuring submission, and checking the result. The video is especially helpful for people using CodeCanyon DHVC Form inside WPBakery for the first time.

When CodeCanyon DHVC Form is a strong choice

CodeCanyon DHVC Form is worth using when the site already runs on WPBakery Page Builder, the editor needs a visual way to assemble a form directly inside the page layout, and the workflow fits inquiry forms, applications, subscriptions, multi-step forms, conditional fields, entry storage, and clear notifications. In that context, the plugin helps keep the process in one place instead of splitting it between a separate form builder and the visual page layout.

Before launch, do not skip the practical checks: plugin version, editor permissions, basic submission, email delivery, entry storage, reCAPTCHA, caching, and guest behavior. If all of those pass, you can move forward with publication and then download CodeCanyon DHVC Form or update the archive for test deployment on your own site.

If the site does not depend on WPBakery, or if the form is becoming a core business system with calculations, complex automation, and many integrations, compare alternatives first. The right form solution is not the one with the longest feature list. It is the one your team can configure safely, verify reliably, maintain confidently, and troubleshoot quickly when something breaks.