jcornell

Thanks. Your suggestion worked. I was trying to use Regex with the full URL. I suggest you make this clearer in your plugin, possibly with an example.

I see the inclusion/exclusion rules are now available, but I’ve been unsuccessful at all trying to set up rules that will do what I want to accomplish. Is this something you can help me with?

Specifically, on our test site https://blog.thewellingtonatsevenhills.com/, I want to redirect all URLs to https://engage.goenumerate.com/s/wellingtonhomeowners, except for WordPress admin pages and except for https://blog.thewellingtonatsevenhills.com/fake-electronic-phonebook/ (and all variations such as without trailing slash and/or without leading https://).

Do you have an estimated time frame on a solution? We’re trying to plan our activities that will need some kind of redirect. Thanks.

I just installed the latest version and this problem is resolved. Thanks.

I deleted/dropped the 3 tables you mentioned. I then got an error trying to add the redirect rule again. I resolved this by deactivating and re-activating the plugin. After re-entering the rule to redirect All URLs (which is what I want), and clearing the browser cache again, the redirect behaved the same as before, still allowing me to get to the wp-login.php page but then redirecting me to the external website after login.

I confirmed that without this redirect rule, the wp-admin page is displayed after login.

For your debugging purposes, following is the csv-formatted data from the wp_irrp_redirectionmeta table:

meta_id,redirect_id,meta_key,meta_value
1,1,ignore_trailing_slashes,
11,1,ignore_parameters,
21,1,ignore_case,
31,1,pass_on_parameters,
41,1,redirect_code,301
51,1,inclusion_exclusion_rules,
61,1,redirect_options,are_case
71,1,redirection_http_headers,
81,1,rules_group1,”a:2:{s:7:””enabled””;s:1:””0″”;s:10:””login_info””;s:0:””””;}”
91,1,rules_group2,”a:3:{s:7:””enabled””;s:1:””0″”;s:4:””role””;s:0:””””;s:9:””role_name””;s:0:””””;}”
101,1,rules_group3,”a:3:{s:7:””enabled””;s:1:””0″”;s:8:””referrer””;s:0:””””;s:14:””referrer_value””;s:0:””””;}”
111,1,rules_group4,”a:4:{s:7:””enabled””;s:1:””0″”;s:5:””agent””;s:0:””””;s:11:””agent_value””;s:0:””””;s:11:””agent_regex””;s:1:””0″”;}”
121,1,rules_group5,”a:5:{s:7:””enabled””;s:1:””0″”;s:6:””cookie””;s:0:””””;s:11:””cookie_name””;s:0:””””;s:12:””cookie_value””;s:0:””””;s:12:””cookie_regex””;s:1:””0″”;}”
131,1,rules_group6,”a:3:{s:7:””enabled””;s:1:””0″”;s:2:””ip””;s:0:””””;s:8:””ip_value””;s:0:””””;}”
141,1,rules_group7,”a:3:{s:7:””enabled””;s:1:””0″”;s:6:””server””;s:0:””””;s:12:””server_value””;s:0:””””;}”
151,1,rules_group8,”a:3:{s:7:””enabled””;s:1:””0″”;s:8:””language””;s:0:””””;s:14:””language_value””;s:0:””””;}”
161,1,criterias,”a:1:{i:0;a:2:{s:8:””criteria””;s:8:””all-urls””;s:5:””value””;s:8:””all-urls””;}}”
171,1,action,”a:2:{s:4:””name””;s:14:””a-specific-url””;s:5:””value””;s:53:””https://engage.goenumerate.com/s/wellingtonhomeowners””;}”

And here is the csv-formatted data from the wp_irrp_redirection_logs table:

“1”,”1″,”https://blog.wellingtonhomeowners.com%2Fwp-admin%2Findex.php/”,”https://engage.goenumerate.com/s/wellingtonhomeowners”,”2023-12-01 21:53:29″,”1701467609″,”200″,”301″,”is_not_404_redirect”,
“11”,”1″,”https://blog.wellingtonhomeowners.com%2Fwp-admin%2F/”,”https://engage.goenumerate.com/s/wellingtonhomeowners”,”2023-12-01 21:55:24″,”1701467724″,”200″,”301″,”is_not_404_redirect”,
“21”,”1″,”https://blog.wellingtonhomeowners.com/robots.txt/”,”https://engage.goenumerate.com/s/wellingtonhomeowners”,”2023-12-01 22:10:13″,”1701468613″,”200″,”301″,”is_not_404_redirect”,

MixHa – I was able to delete the plugin files using your instructions and then login successfully. I then reinstalled and activated your plugin again, deactivated all the other plugins, cleared the browser cache, and tried again. Guess what? The same problem is still happening. Any other suggestions before I give up?

I’ve manually deleted older rows from wp_mail_catcher_logs table gradually over the last few days. The oldest row now is from 7/21/2021 which means all of the rows there now were created after I first reported this problem and after I updated to version 1.5.3 on 6/28/2021. And I have the setting to delete everything older than 1 week and still nothing is getting deleted. So it seems that the data in the table is probably not the problem.

I also compared the table structure to the one in our test environment where the email log deletions work successfully. They appears the same.

Do you have any other suggestions?

There were no emails logged in this test environment so that explains why there were none to delete.

I created two emails there which were logged by your plug-in. I then waited two weeks, changed the setting to delete logs over 1 week old, and re-ran the cron event. The two emails logged were deleted as they should have been.

Back to the problem environment in which it is not working, with now 2204 emails logged over the last seven months. I hesitate to turn on debug in this environment because our users access it at all hours and I don’t want to disrupt them. Is there another way to see what might be happening to prevent the deletions?

I ran the wp-cron task for this in one of test sites with DEBUG on and got the following log message:

[07-Jul-2021 18:49:36 UTC] WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘)’ at line 2 for query DELETE FROM wp_mail_catcher_logs
WHERE id IN() made by do_action_ref_array(‘wp-mail-catcher_0’), WP_Hook->do_action, WP_Hook->apply_filters, WpMailCatcher\ExpiredLogManager::removeExpiredLogs, WpMailCatcher\Models\Logs::delete

I changed the plugin settings as you suggested. I also triggered the cron task manually using the WP Crontrol plugin. The problem remains.

I don’t know where to look at error logs to see if any relevant messages are there.

@wardee I installed v1.5.3 on Monday morning and now 48 hours later, the logs still date back 6 months instead of 4 weeks as desired.

Thanks. Looks good now.

Thanks for the quick fix. I installed it today. The date now looks correct but the time is a little bit off in most cases. It seems to be that the minutes are missing from the export or are replaced with the seconds. Examples with the last several logged as of now:
Plugin: 19:14:31 Export: 19:31
Plugin: 19:14:03 Export: 19:03
Plugin: 19:13:21 Export: 19:21
Plugin: 19:13:13 Export: 19:13
Plugin: 16:21:48 Export: 16:48

Thank you. Excellent turn around time on this update!

Please ignore my last response. I wasn’t looking at the right page. It is working now.