Custom Field Validation - Plover CRM Documentation

PloverCRM validates all custom field data to ensure quality, prevent errors, and maintain database integrity.

[Screenshot: Form showing validation errors with clear messages]

Overview #

Validation occurs at every entry point (UI, API, forms, imports) and provides:

Data Integrity: Only valid data enters database
Type Safety: Enforces field type constraints
Security: Sanitizes input to prevent XSS/SQL injection
Consistency: Standardizes data formats
User Feedback: Clear error messages

Validation Layers:

Client-side (browser, immediate feedback)
Server-side (authoritative, cannot be bypassed)
Type-specific rules
Sanitization
Format normalization

[Screenshot: Validation flow diagram]

How Validation Works #

Process:

Field definition lookup → Skip if doesn’t exist
Type-based validation → Skip if fails
Value sanitization → Remove dangerous content
Format normalization → Standardize format
Database storage → Save validated value

Validation vs Sanitization:

Validation: Checks if data meets requirements, rejects invalid
Sanitization: Cleans data to make it safe, always applied

Both are essential for data quality and security.

Validation Rules by Type #

Text Field #

Validation: Accepts any string, max 255 chars Cleaning: Removes HTML tags, line breaks, and extra whitespace Example: " John<script>alert('xss')</script>Doe " becomes "JohnDoe"

[Screenshot: Text field validation example]

Textarea Field #

Validation: Accepts any string, max 65,535 chars Cleaning: Removes HTML tags, preserves line breaks Example: "Line 1<br>Line 2" becomes "Line 1Line 2" (preserves \n, removes
)

Email Field #

Validation: Must be valid email format ([email protected]) Cleaning: Converts to lowercase, removes whitespace Example: "[email protected]" becomes "[email protected]"

URL Field #

Validation: Must include protocol (http:// or https://), valid domain Cleaning: Encodes special characters, removes dangerous protocols Example: "https://example.com/path with spaces" becomes "https://example.com/path%20with%20spaces"

Number Field #

Validation: Must be numeric (integer or decimal), accepts negative Cleaning: Converts to numeric format Example: "123.45" becomes 123.45, "$123" is rejected

Select/Radio Field #

Validation: Value must match defined options (case-sensitive) Cleaning: Removes HTML and special characters Example: Options: [“Technology”, “Healthcare”] – “technology” is rejected (case mismatch)

Checkbox Field #

Single: Accepts boolean (true/false) or “1”/”0″ Multiple: Accepts array, each value must be in options Example: ["Option A", "Option B"] → valid if both in options

Date Field #

Validation: Must be valid date, accepts 20+ formats Normalization: Always stored as YYYY-MM-DD Example: "06/02/2026", "Feb 06, 2026" both become "2026-02-06"

Date Time Field #

Validation: Must be valid date and time, accepts 20+ formats Normalization: Always stored as YYYY-MM-DD HH:MM:SS Example: "06/02/2026 02:30 PM" becomes "2026-02-06 14:30:00"

[Screenshot: Validation rules quick reference table]

Validation Contexts #

UI Validation #

Layers: HTML5 → JavaScript → Server-side Experience: Immediate feedback on blur, visual indicators, error messages below fields Behavior: Form submission blocked until errors fixed

[Screenshot: UI validation with red highlights and error messages]

API Validation #

Response: HTTP 400 with detailed errors

{
  <span class="hljs-attr">"code"</span>: <span class="hljs-string">"rest_invalid_param"</span>,
  <span class="hljs-attr">"data"</span>: {
    <span class="hljs-attr">"params"</span>: {
      <span class="hljs-attr">"custom_fields.email"</span>: <span class="hljs-string">"Invalid email format"</span>,
      <span class="hljs-attr">"custom_fields.annual_revenue"</span>: <span class="hljs-string">"Must be a number"</span>
    }
  }
}

Behavior: All or nothing – entire request fails if any field invalid

Form Integration Validation #

Process: Form plugin validates → PloverCRM validates → Contact created Behavior: Invalid fields skipped with warning logged, contact created with valid fields Example: Invalid email skipped, contact created without email field

[Screenshot: Form integration validation flow]

CSV Import Validation #

Process: Row-by-row validation, valid rows imported, invalid rows skipped Output: Detailed error report

Row 3: Failed
-<span class="ruby"> <span class="hljs-symbol">Email:</span> <span class="hljs-string">"invalid-email"</span> - Invalid email format
</span>-<span class="ruby"> Annual <span class="hljs-symbol">Revenue:</span> <span class="hljs-string">"abc"</span> - Must be a number
</span>
Summary: 2 successful, 1 failed

[Screenshot: CSV import error report]

Error Messages #

Good Messages:

✅ “Email must be in format: [email protected]”
✅ “Please select from: Technology, Healthcare, Finance”
✅ “Date must be in format: YYYY-MM-DD (e.g., 2026-02-06)”

Bad Messages:

❌ “Invalid input”
❌ “Validation failed: FILTER_VALIDATE_EMAIL returned false”
❌ “Error”

Writing Effective Messages:

State the problem
Provide the solution
Give an example
Be polite and specific

[Screenshot: Good vs bad error message examples]

Validation Logging #

What Gets Logged:

[WARNING] Invalid value for custom field, skipping
-<span class="ruby"> <span class="hljs-symbol">Field:</span> annual_revenue
</span>-<span class="ruby"> <span class="hljs-symbol">Type:</span> number
</span>-<span class="ruby"> <span class="hljs-symbol">Value:</span> <span class="hljs-string">"abc"</span>
</span>-<span class="ruby"> <span class="hljs-symbol">Contact:</span> <span class="hljs-number">12345</span>
</span>-<span class="ruby"> <span class="hljs-symbol">Source:</span> API</span>

Access Logs:

WordPress debug log: wp-content/debug.log
PloverCRM logs: PloverCRM → Settings → System Logs

Best Practices #

Field Design:

Use specific types (Email for emails, not Text)
Provide clear help text with examples
Use consistent formats across organization
Limit select/radio options (5-20 ideal)

Data Entry:

Validate early (catch errors before submission)
Provide examples in placeholders
Handle errors gracefully (preserve input, show clear message)
Test thoroughly (valid, invalid, edge cases)

Integration:

Map form fields to correct types
Validate client-side before API calls
Validate CSV data before importing
Monitor integration logs

Performance:

Keep validation simple and fast
Validate in batches for bulk operations
Use async validation for expensive checks

[Screenshot: Validation best practices checklist]

Troubleshooting #

Valid Data Rejected #

Causes: Case sensitivity, whitespace, format mismatch, type mismatch Solutions:

Select/radio: Use exact case (“Technology” not “technology”)
Trim whitespace before validation
Use YYYY-MM-DD for dates
Send numbers as numeric type, not string

Validation Not Working #

Causes: Field not defined, wrong slug, Super Admin (bypasses validation) Solutions:

Verify field exists and is active
Check field type is correct
Verify field slug matches exactly
Check user role

Errors Not Showing #

Causes: JavaScript error, CSS hiding message, missing error handler Solutions:

Check browser console for errors
Inspect element to see if message hidden
Check network tab for API error details
Review validation logs

Date/DateTime Issues #

Causes: Format not recognized, invalid date, timezone confusion Solutions:

Use ISO 8601 format (YYYY-MM-DD)
Verify date is valid (check days in month)
Check WordPress timezone settings

Select/Radio Issues #

Causes: Case mismatch, whitespace, options not saved, cache Solutions:

Use exact case and no extra spaces
Save field definition and clear cache
Verify options in field definition

Number Issues #

Causes: String format, comma separators, currency symbols Solutions:

Remove commas: “1,000” → “1000”
Remove symbols: “$123” → “123”
Send as number type in API

[Screenshot: Troubleshooting decision tree]

Security #

PloverCRM automatically protects your data by:

XSS Prevention: Removes HTML/JavaScript from input, escapes output
SQL Injection Prevention: Uses secure database queries
Validation as Security: Prevents malformed data and injection attacks

Best Practices:

Never trust user input
Always validate on the server
Use specific field types
Limit input length
Review validation logs regularly

Advanced Topics #

Validation Process:

Field definition lookup
Type-based validation
Value cleaning
Format normalization
Database storage

Performance: Text/email/number fields validate quickly, date/datetime fields take slightly longer.

[Screenshot: Validation pipeline diagram]

Last Updated: February 3, 2026