Gravity SMTP 2.3.3 fixes a MySQL error that could occur on first installation. A failed activation can leave tables, options, scheduled actions, connector state, or a schema version partially written. Deleting everything immediately can remove useful evidence or collide with a production email queue.
Use this for new Gravity SMTP installations, multisite activation, cloned staging sites, custom table prefixes, restricted database users, interrupted deployments, and hosts that separate schema and runtime privileges.
Quick answer
Before another activation, capture the exact database error, SQL statement, table prefix, database version, charset, collation, user grants, plugin version, multisite context, existing tables, schema options, and scheduled actions. Back up the database. Update the plugin files to 2.3.3, then retry on staging with the same prefix and permissions. Compare created tables and indexes against a clean reference install. Preserve existing email logs and queues unless the vendor schema proves they are disposable test data.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Clean install | Empty schema | All expected tables |
| Partial table | Interrupted activation | Idempotent repair |
| Missing privilege | Restricted schema user | Actionable error |
| Multisite | Network activation | Correct prefix and scope |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Freeze the first SQL evidence | Record WordPress, Gravity SMTP, PHP, MySQL or MariaDB versions, database host, prefix, charset, collation, user grants, multisite mode, activation scope, and UTC failure time. | Expected Gravity SMTP tables, columns, indexes, options, and version markers match the reference schema. |
| Back up the current schema | Capture the first SQL error and list matching tables, indexes, options, cron events, Action Scheduler jobs, connector rows, email logs, and migration locks before cleanup. | Activation and page loads add no new MySQL, PHP, or migration-lock errors. |
| Compare with a clean 2.3.3 install | Compare a clean 2.3.3 install using the same database engine and prefix, including column types, defaults, indexes, auto-increment behavior, and schema version markers. | A marked email moves through the connector, log, provider, and inbox once. |
| Repair only the proven mismatch | Test missing CREATE, ALTER, INDEX, and temporary privilege scenarios without granting the runtime account broad global permissions. | Multisite and custom-prefix environments create records only in their intended scope. |
What to check first
- Record WordPress, Gravity SMTP, PHP, MySQL or MariaDB versions, database host, prefix, charset, collation, user grants, multisite mode, activation scope, and UTC failure time.
- Capture the first SQL error and list matching tables, indexes, options, cron events, Action Scheduler jobs, connector rows, email logs, and migration locks before cleanup.
- Compare a clean 2.3.3 install using the same database engine and prefix, including column types, defaults, indexes, auto-increment behavior, and schema version markers.
- Test missing CREATE, ALTER, INDEX, and temporary privilege scenarios without granting the runtime account broad global permissions.
- Retry activation once after the files and database state are understood, then send a marked test message and confirm logs, queue processing, provider delivery, and uninstall policy.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp plugin get gravity-smtp --field=version
wp db query "SHOW TABLES LIKE '%gravity%';"
wp option list --search='gravitysmtp' --format=table
wp cron event list | grep -i gravity
# Back up before repair or activation retry.
Why this usually happens
- An installation routine is interrupted after some tables exist but before the schema version is saved.
- The database user can read and write rows but cannot create or alter indexes.
- A custom or multisite prefix differs from an assumption in a migration query.
- Two activation requests run close together and compete for the same table or lock.
Decision rule
Retry installation only after the partial schema and privileges are understood. Repair the smallest proven mismatch, preserve real logs and queues, and require a clean message lifecycle after activation.
Production verification checklist
- Expected Gravity SMTP tables, columns, indexes, options, and version markers match the reference schema.
- Activation and page loads add no new MySQL, PHP, or migration-lock errors.
- A marked email moves through the connector, log, provider, and inbox once.
- Multisite and custom-prefix environments create records only in their intended scope.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze the first SQL evidence
- Back up the current schema
- Compare with a clean 2.3.3 install
- Repair only the proven mismatch
- Retry once and send a marked message
Mistakes to avoid
- Changing production before recording exact versions, UTC time, the affected fixture, current behavior, and a tested rollback point.
- Accepting one successful admin screen while the public page, stored record, API response, accessibility tree, queue, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving broad credentials, debug logs, temporary filters, synthetic records, or recovery code active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, cache, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I rule out a cache artifact?
Record the origin response, purge only affected paths, and repeat in private and normal sessions. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When is the test complete?
Close it when the main path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP repair a WordPress database install.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references