v2.4.0

Full Changelog: v2.3.1...v2.4.0

v2.3.1

Full Changelog: v2.3.0...v2.3.1

v2.3.0

Full Changelog: v2.2.1...v2.3.0

CF7 to API v2.2.1

Fixed

• Release Build: Fixed missing assets from Composer packages in release ZIP
  • Settings Hub CSS (settings-hub.css) now included in build
  • GitHub Updater JS (check-updates.js) now included in build
  • Updated build script to preserve assets/ directories in SilverAssist packages

CF7 to API v2.2.0

Changed

• Admin Dashboard UI Redesign: Aligned settings page with card-based design system
  • Expanded CSS with full card design system and CSS variables
  • Added version badge, status-indicator, and feature-status styles
  • Simplified Plugin Information section
  • Removed obsolete update check script for cleaner admin experience

Maintenance

• GitHub Actions Dependencies: Updated CI/CD workflow dependencies
  • Bumped actions/upload-artifact from v6.0.0 to v7.0.0
  • Bumped actions/download-artifact from v7.0.0 to v8.0.0
• Code Cleanup: Removed redundant CSS properties from resolved status indicator

CF7 to API v2.1.0

Added

• Granular Alert Preferences: Per-submission failure alerts with granular control

  • New alert_types setting structure with threshold and individual options
  • maybe_send_individual_alert() triggers when a submission permanently fails after all retries
  • Individual alerts are event-driven (no cooldown) vs rate-limited threshold alerts
  • Privacy-first design: alert emails contain only error metadata (form name, endpoint, timestamp, response code, error message) - never user-submitted form data
  • Spam prevention: transient flag per log_id prevents duplicate alerts on retry
  • UI: "Alert Types" section with nested checkboxes for threshold and individual alerts
  • Threshold settings reorganized under clear subheading
  • Backward compatible: threshold alerts enabled by default, individual disabled
  • Integrated in LogsController::handle_retry_action() for retry exhaustion and max limit scenarios

• Response Action Hook (cf7_api_after_response): New filter hook for extending plugin functionality

  • Fires after each API response is received (success or failure)
  • Provides complete response data (status code, headers, body, parsed JSON, duration)
  • Includes submission context (log ID, form ID, form title, form data, endpoint, retry info)
  • Enables developers to:
    • Store CRM lead IDs returned by APIs
    • Trigger notifications based on response content
    • Log to external monitoring services (Sentry, Bugsnag, etc.)
    • Send data to secondary endpoints (multi-endpoint support)
  • Hook only fires for HTTP responses (not WP_Error cases)
  • Minimal overhead when no callbacks are registered
  • See docs/API_REFERENCE.md for complete documentation and examples

• Form Filter Dropdown: Visible dropdown selector to filter logs by Contact Form 7 form

  • Dropdown appears in filter controls between Status and Date filters
  • Lists all forms that have at least one log entry
  • Shows "All Forms" default option to display logs from all forms
  • Gracefully handles deleted forms (displays as "Form #123")
  • Auto-submits on selection for immediate filtering (no button click needed)
  • Active filter tag shows selected form with individual remove capability
  • Filter persists across pagination and combines with status/date filters
  • Alphabetically ordered by form title for easy navigation
  • New LogReader::get_forms_with_logs() method retrieves distinct forms with logs
  • Comprehensive unit test coverage (6 tests for all scenarios)

CF7 to API v2.0.0

Added

• MVC Architecture: Complete restructuring following Model-View-Controller principles
  • Model Layer: Type-safe domain models (LogEntry, FormSettings, ApiResponse, Statistics)
  • Repository Layer: Data access interfaces (LogRepositoryInterface, SettingsRepositoryInterface)
  • Controller Layer: Request routing and hook management
    • Controller/Admin/LogsController: Admin logs page routing
    • Controller/ContactForm/SubmissionController: Form submission handling
  • Service Layer: Business logic separated from controllers
    • Service/Logging/: LogWriter, LogReader, LogStatistics, RetryManager
    • Service/Security/: EncryptionService, SensitiveDataPatterns
    • Service/ContactForm/SubmissionProcessor: API communication logic
  • View Layer: Reusable partials for maintainability
    • View/Admin/Logs/Partials/: StatisticsPartial, DateFilterPartial, ExportButtonsPartial
    • View/Admin/Settings/Partials/GlobalSettingsPartial
  • Config Layer: Centralized configuration (Config/Settings)
• Unresolved Errors Filter: New filter to show only errors that haven't been successfully retried
  • "Unresolved" tab in logs table shows errors pending resolution
  • "All Errors" renamed to distinguish from unresolved filter
  • Error resolution counts displayed in filter badges
• Search by Sender Name/Lastname: Extended search functionality to filter logs by sender name
  • Search now includes name and lastname fields from form submissions
  • Respects anonymization rules: fields marked as sensitive via settings are excluded from search
  • Maintains existing SQL-based search for endpoint and error_message (full dataset)
  • PHP-based filtering for name/lastname applied to the first 5,000 logs in the current sort order; on sites with more than 5,000 logs, name/lastname searches may not include older matches

Changed

• Visual Resolved Indicator: Errors with successful retries now show a "Resolved" badge
  • Green badge appears next to error status when retry was successful
  • Tooltip explains the error was resolved via manual retry
  • Makes it easy to identify resolved errors at a glance

Developer

• New Service Classes: Specialized services following Single Responsibility Principle
  • Service\Logging\LogWriter: Log creation, updates, deletion with encryption
  • Service\Logging\LogReader: Log retrieval with decryption
  • Service\Logging\LogStatistics: Statistics and metrics calculations
  • Service\Logging\RetryManager: Retry management and error resolution tracking
  • Service\ContactForm\SubmissionProcessor: Form submission business logic
• New Model Classes: Type-safe domain models with full PHPStan Level 8 compliance
  • Model\LogEntry: API request log representation
  • Model\FormSettings: Form configuration
  • Model\ApiResponse: API response data
  • Model\Statistics: Aggregated statistics
• Exception Classes: Custom exceptions for better error handling
  • Exception\ApiException: API-related errors
  • Exception\ValidationException: Validation errors with detailed tracking
• PSR-4 Namespace Organization: Proper directory structure
  • Service\Security\*: Security-related services
  • Config\Settings: Configuration management
• Architecture Documentation: See docs/ARCHITECTURE.md for complete structure
• Migration Guide: See docs/UPGRADE.md for 2.0.0 migration instructions

Notes

• Quality Gates: PHPCS WordPress-Extra (0 errors) and PHPStan Level 8 (0 errors) compliance
• All logging functionality migrated to dedicated services in Service\Logging\
• See docs/UPGRADE.md for migration guidance

CF7 to API v1.3.13

Added

• New "From" Column in Logs Table (#54): Quick sender identification without opening log details
  • Displays sender name and masked email (e.g., John Doe <jo***@example.com>)
  • Extracts data from common form fields (name, firstname, your-name, email, your-email, etc.)
  • Email masking preserves privacy while allowing identification
  • Shows "Unknown" when sender info cannot be extracted

Changed

• Renamed "Form" Column to "Channel" (#54): Better reflects the source/channel of submission
• Improved Endpoint Column (#54): Fixed width with CSS text-overflow ellipsis
  • Full URL visible on hover via title attribute
  • Cleaner table layout without PHP-based truncation

Fixed

• Empty Status Filter Bug (#54): Fixed table showing no results when URL has empty status parameter
  • Added ! empty() check to prevent filtering with empty string
  • URLs like ?status&date_filter now work correctly
• Status Filter Auto-Submit (#54): Status dropdown now submits form automatically on change
• "All Time" Date Filter Auto-Submit (#54): Previously only non-empty filter values triggered auto-submit

CF7 to API v1.3.11

Fixed

• Log Filters UI (#50, #48): Fixed broken filters after refactor
  • Filters now use the WordPress .filtered-by pattern
  • Active filters are shown as removable tags
  • "Clear all" link added, duplicate "Clear Filters" button removed
  • Unified into a single filter bar with native admin styles

CF7 to API v1.3.10

Added

• Status Filter Dropdown (#47): New status filter UI control on logs page
  • Dropdown with "All", "Success", and "Error" options
  • Appears alongside date filter for consistent UI
  • Preserves form_id and search parameters when filtering
  • Combined active filters badge shows both status and date filters
  • Already integrated with pagination, sorting, and export URLs
• Date-Aware Statistics Grid (#47): Stats now reflect active date filters
  • Stats grid displays date context label (e.g., "Total Requests (Yesterday)")
  • All statistics (total, successful, failed, avg time) respect date filters
  • Date context shown as "(All Time)", "(Today)", "(Last 7 Days)", etc.

Changed

• Dashboard Widget Recent Errors (#47): Now limited to last 24 hours
  • get_recent_errors() accepts optional $hours parameter
  • Dashboard widget passes 24-hour filter to match other statistics
  • More relevant error display focusing on recent issues
• Failed Requests Count (#47): Excludes successfully retried errors
  • get_statistics() uses subquery to exclude errors with successful retries
  • Matches logic from get_count_last_hours() for consistency
  • Shows only unresolved failures in stats grid

Enhanced

• RequestLogger::get_statistics() (#47):
  • Now accepts optional date parameters: get_statistics(?int $form_id, ?string $date_start = null, ?string $date_end = null)
  • Returns statistics filtered by date range when parameters provided
  • Failed requests count excludes successfully retried errors
  • Backward compatible (date parameters optional)
• RequestLogger::get_recent_errors() (#47):
  • Now accepts optional hours parameter: get_recent_errors(int $limit = 5, ?int $hours = null)
  • Filters errors by time window when hours specified
  • Backward compatible (hours parameter optional)

Documentation

• USER_GUIDE.md (#47):
  • Added dedicated "Status Filter" section
  • Updated filtering examples with combined filter use cases
  • Updated "Clearing Filters" to reference both status and date filters
• API_REFERENCE.md (#47):
  • Updated get_statistics() method documentation with new parameters
  • Updated get_recent_errors() method documentation with new parameters
  • Added examples for date-filtered statistics queries