David Botibol
Forum Replies Created
-
Hi Ralden Souza (@rsouzaam),
Thank you very much for picking this up, and for your suggestions. I need to clarify what is going right and what is going wrong.
We are not having email delivery issues when using the Plain Text template. Emails using that template are delivered correctly to the destination inbox.
The bouncing of WPForms notification emails occurs when using one of the html templates, if the destination emails address forwards to a btinternet email address.
Your advice regarding SMTP plugin is good. We use WP Mail SMTP plugin. The header of a bounced email shows that it had passed authentication. So the problem in this case is not lack of authentication.
In order to reproduce the issue using your test site you would need to bring up the Email tab of WPForms Settings and select an html template such as Classic, and Save Settings. You would need submit a form where a notification is sent to an email address that forwards to a btinternet email address. One such email address I’ve set up is [email protected] which you may use.
Best wishes,
David
Hi Ralden,
I updated another website to Version 1.9.1.3 on Oct 8, 2024, 5:01 PM BST. For this website there remains in place the following code snippet to disable the weekly summary processes.
add_filter( ‘wpforms_emails_summaries_is_disabled’, ‘__return_true’ );
add_filter( ‘wpforms_dash_widget_allow_entries_count_lite’, ‘__return_false’ );So far the error log has not been added to by this plugin. However there are weekly processes involved; so I shall look again over the next week or so.
Thanks for your help.
Best wishes,
David
- This reply was modified 1 year, 4 months ago by David Botibol.
Hi Kenneth,
Thank you for this update.
I have updated one website to the latest release 1.9.1.3.
The ‘Disable Email Summaries weekly delivery’ switch stays on.Good week,
David
Hi Kenneth,
The fault occurs on two totally separate and different websites.
On both sites the wpforms Scheduled Actions tab shows scheduled tasks and many completed tasks but no recent failed tasks. I think these are WP-Cron rather than Cron tasks. I don’t think we have non-WordPress cron jobs set up. Also, on one of the sites I installed Cron Logger plugin which shows lots of wp-cron.php runs.
Can you tell me which files in the plugin zip relate to the process that would trigger these entries in the error log? It could be worth searching what changes in them occurred between 1.8.9.1 and 1.8.9.4. Unfortunately WPForms Lite 1.8.9.3 appears to be missing from https://wordpress.org/plugins/wpforms-lite/advanced/, so I couldn’t check that one.
The Weekly WPForms Summary process having failed, is there a way to trigger it, rather than waiting till the following week?
Best wishes,
David
Hi Kenneth,
After updating to WPForms Lite 1.8.9.4 the fault returned. I have reverted to WPForms Lite 1.8.9.1. Did the correction in 1.8.9.1 get accidentally downdated? I see there are recent releases 1.8.9.5 and 1.8.9.6. From which release is the correction re-applied, please?
Thanks for keeping a watch on this plugin.
David
Hi Kenneth,
Investigating this issue further, I discovered that with WPForms Lite 1.8.8 versions the weekly email was being sent, but incorrectly showing zero totals.
Looking at the site where I updated to WPForms 1.8.9.1, the following scheduled actions subsequently completed:
wpforms_process_forms_locator_scan
wpforms_process_forms_locator_save
wpforms_admin_notifications_update
wpforms_email_summaries_fetch_info_blocksHowever wpforms_builder_help_cache_update action failed via Admin List Table: Scheduled action for wpforms_builder_help_cache_update will not be executed as no callbacks are registered.
There are no new entries in the error_log. The weekly email turned up on 17 June 2024 at 17:44. The weekly email shows Entries This Week whereas for WPForms Lite whereas previous releases showed the total number of submissions for each form, as documented at https://wpforms.com/docs/how-to-use-email-summaries/ .
Thank you very much for your help with this.
Good wishes,
David
Hi Kenneth,
Thanks for picking this up.
On one website the last SA last failed action in Scheduled Actions was wpforms_admin_addons_cache_update on 2024-03-23 23:32:18 +0000, whereas the first wpforms_weekly_entries_count error was 02-Jun-2024 23:00:19 UTC, following update of WPForms Lite. I think the failed actions are unrelated to the wpforms_weekly_entries_count error.
Looking at WPForms 1.8.9.1, the file of interest, \wpforms-lite\src\Lite\Emails\Summaries.php has a fresh date. but unchanged contents. So if the error was in the old version of that file, it is still in the new one. The changelog does not assert any adjustment of wpforms_weekly_entries_count processing.
The problem manifests with PHP7 as well as PHP8.
I propose to try WPForms 1.8.9.1 as you ask.
Good weekend,
David
Hi Paul,
Release 15.0.6 was out earlier this week. I have installed it and thereby resolved the issue. Review is at https://wordpress.org/support/topic/responsive-support-52/ . Thanks for your help.
Good weekend,
David
Hi Paul,
I see that this thread is marked as resolved. I appreciate that you found the source of this issue; however from a user perspective the matter will not be resolved until we have been able to install a software release that is free of this bug.
I had in mind to do the review after having implemented the patch release. However April came and went with no updates from Shield. Looking at the changelog, that is an unusually long hiatus. When is the correction due for release, please?
Best wishes,
David
Thank you, Paul. That was impressively fast. Respect from an old programmer. I look forward to the patch release.
Yes. Username = David Botibol
Bad link is
Hi Cory,
I can understand that there would not have been other requests for this. The decision to omit error_log and rename .htaccess is not mentioned in https://snapcreek.com/duplicator/docs/changelog-legacy/. People would not be aware of it. People would assume that Duplicator backs up all the files as named, as it formerly did. People will not be motivated to raise the issue unless they need to extract one of those files from backup and suffer the distress of not finding the copy that they relied upon being there.
Thanks for taking note.
Best wishes,
David
Hi Cory
Thank you for the reply. Working from what you say, it seems that the root directory .htaccess file is renamed to htaccess.orig in the archive. If there is an existing htaccess.orig in the root directory, it is omitted from the archive.
Apart from migration, Duplicator also serves as a simple backup utility. (See https://en-gb.wordpress.org/plugins/duplicator/). It is in this backup use case that all files may be needed. One example is malicious damage to a website. Forensic investigation may wish to compare current files with previously backed up versions. The old error_log could be of interest.
I accept that some users would wish to exclude large error logs from the archive, but this exclusion was formerly available at the user’s choice via File Filters. Would you like to reinstate that choice?
Best wishes,
David