Detect and store CF7 mail failed and spam submissions

[chrisblakley]

I've already worked through most of this, but recapping notes here for documentation/historical reference.

When users attempt to submit a form but the mail fails or is determined to be spam, they will be presented with an error message on the front-end of the website. In certain occasions, the form data will be successfully stored, but the administrators will not receive a message. This can cause user frustration and confusion. Additionally, troubleshooting these situations is challenging because there is no form submission data for context clues.

Now, Nebula will designate any submissions where the wpcf7_mail_failed error occurred with a "(Mail Failed)" in the title and a warning in the submission details explaining what the user/admins saw or didn't see.

For submissions that are designated as spam (by CF7), Nebula will store those but separate as a "spam" status. These can be found in a new dropdown to keep them separated from the actual submissions.

Spam submissions will sometimes contain valid data and other times data that cannot be decoded. Even the data that is valid may be incomplete! The method of capturing this data is much different than with actual submissions because CF7 aborts the process once spam is detected. For example, it is not possible (as far as I can tell) to determine what page the spam form was submitted from.

Each day, a cron job runs and will delete spam messages that are either older than 30 days or if there are more than 50 messages currently stored.

Next steps can include things like:

• [x] Move (or somehow "mark") submissions as "not spam"
• [ ] How do we handle (if at all) multiple/duplicate submission attempts?
• [x] Preserve spam submissions for longer than the expiration date
• [x] Try to get more information about the spam submissions (like the spam notes from CF7)

[chrisblakley]

Expanding this to capture invalid form submissions as well.

This still removes old spam/invalid submissions and keeps only 50 when the cron checks each day, but could still also consider debouncing/limiting the invalid storage in case users submit many invalid attempts in a row...

[chrisblakley]

Closing this now as it has been fully implemented. Additional ideas/features can use their own issues.