Custom Field Validation

Custom Field Validation #

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

Overview #

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

• Data Integrity: Only valid data enters the 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:

1. Client-side (browser, immediate feedback)
2. Server-side (authoritative, cannot be bypassed)
3. Type-specific rules
4. Sanitization
5. Format normalization

How Validation Works #

Process:

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

Validation vs Sanitization:

• Validation: Checks if data meets requirements; rejects invalid data
• 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 characters
Cleaning: Removes HTML tags, line breaks, and extra whitespace
Example: " JohnDoe " → "JohnDoe"

Textarea Field #

Validation: Accepts any string, max 65,535 characters
Cleaning: Removes HTML tags, preserves line breaks
Example: "Line 1 Line 2" → "Line 1\nLine 2" (preserves \n, removes )

Email Field #

Validation: Must be valid email format ([email protected])
Cleaning: Converts to lowercase, removes whitespace
Example: "[email protected]" → "[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" → "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" → 123.45; "$123" is rejected

Select/Radio Field #

Validation: Value must match a defined option (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 are defined options

Date Field #

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

Date Time Field #

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

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 all errors are fixed

API Validation #

Response: HTTP 400 with detailed errors

{
"code": "rest_invalid_param",
"data": {
"params": {
"custom_fields.email": "Invalid email format",
"custom_fields.annual_revenue": "Must be a number"
}
}
}

Behavior: All or nothing — the entire request fails if any field is invalid.

Form Integration Validation #

Process: Form plugin validates → PloverCRM validates → Contact created
Behavior: Invalid fields are skipped with a warning logged; contact is created with valid fields only
Example: Invalid email skipped, contact created without the email field

CSV Import Validation #

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

Row 3: Failed
- Email: "invalid-email" - Invalid email format
- Annual Revenue: "abc" - Must be a number

Summary: 2 successful, 1 failed

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:

1. State the problem
2. Provide the solution
3. Give an example
4. Be polite and specific

Validation Logging #

What Gets Logged:

[WARNING] Invalid value for custom field, skipping
- Field: annual_revenue
- Type: number
- Value: "abc"
- Contact: 12345
- Source: API

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 the 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, and 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

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 is 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

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:

1. Field definition lookup
2. Type-based validation
3. Value cleaning
4. Format normalization
5. Database storage

Performance: Text, email, and number fields validate quickly. Date and datetime fields take slightly longer.

Last Updated: February 3, 2026