• This is a really great plugin. I have just one minor issue. It’s not sending any emails

    The Subscription Options were set to All Email. I posted an activity update in the group. The other group members did not receive any email. There are no entries in the email log on the server.

    I tested with WordPress 6.4.2 and BuddyPress 11.4.0, the default WordPress theme and no other plugins were enabled. Email works as WordPress can send emails.

    I started to debug a little. As far as I can see your ass_send_email function never executes.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Author Boone Gorges

    (@boonebgorges)

    Sorry to hear you’re having problems.

    I started to debug a little. As far as I can see your ass_send_email function never executes.

    This is a helpful starting point, as it suggests that it’s not a problem with your outgoing mail tools. See https://github.com/boonebgorges/buddypress-group-email-subscription/wiki/How-to-troubleshoot-missing-emails

    My guess is that subscriptions are not properly set up, perhaps because the database tables are not created. Look for wp_bpges_queued_items and wp_bpges_subscriptions.

    Another possibility is that items are being queued (see the queued_items table referenced above) but that the email queue is never being triggered. This can happen if for some reason your server doesn’t allow for “self-pings”.

    By identifying whether the DB tables exist and are populated, it can help to narrow things down a bit.

    Thread Starter Michael

    (@michael8888)

    Thanks for the fast reply.

    There are many entries in wp_bpges_queued_items. What exactly do you mean by self-ping here? Do you mean internal HTTP requests? This works.

    Plugin Author Boone Gorges

    (@boonebgorges)

    If there are many ‘immediate’ items in wp_bpges_queued_items, then it narrows down the issue even more. It means that items are being logged in the queue, but the queue is never being triggered.

    By “self-ping” I mean: WP needs to be able to send a server-side request to https://example.com/wp-admin/admin-ajax.php?action=wp_bpges_send_queue where example.com is the URL of your site. See https://github.com/boonebgorges/buddypress-group-email-subscription/blob/1971a19d9efb4097d5ace1952c630f38abc58c7d/lib/wp-background-processing/classes/wp-async-request.php#L87 Occasionally servers are configured to reject this sort of request, perhaps because they expect admin-ajax.php requests to come from the client. Check your access log for requests of this sort, and see whether they’re returning 200 or 50x.

    If the requests are going through, then something in the send queue mechanism must not be working properly. The main logic here is in https://github.com/boonebgorges/buddypress-group-email-subscription/blob/master/classes/class-bpges-async-request-send-queue.php

    Thread Starter Michael

    (@michael8888)

    We have no particular WordPress configuration that would disallow server-side requests to admin-ajax.php. Disabling security plugins did not resolve the issue. It is also not a web server configuration since I can I access the file with wget on a server terminal. So I don’t know what is causing this issue.

    Why do you need AJAX requests to send emails from a mail queue? Why not use a cron job for asynchronous sends?

    We downgraded now to 4.0. It seems it doesn’t have this issue.

    Plugin Author Boone Gorges

    (@boonebgorges)

    Why do you need AJAX requests to send emails from a mail queue? Why not use a cron job for asynchronous sends?

    We use a library called wp-background-processing for the asynchronous process, and this library uses admin-ajax.php. It’d probably be possible to switch to a cron job, but this would come with its own challenges.

    Sorry you were unable to identify the underlying issue. If you find yourself able to do further investigation in the future, including looking at some of the logs referenced above, feel free to circle back to this thread.

    Thread Starter Michael

    (@michael8888)

    I checked the access logs. It is all 200 for admin-ajax.php. So I guess it is a different issue.

    Thread Starter Michael

    (@michael8888)

    I am curious what’s the purpose of ass_generate_notification. I don’t see any calls for this function.

    Plugin Author Boone Gorges

    (@boonebgorges)

    ass_generate_notification() is the older version of bpges_generate_notification(). I left the legacy version in there in case any third party was using it.

    If you’re seeing 200 notices, it does help to eliminate at least some possible issues. As a next step, you might consider enabling BPGES_DEBUG to see if any information can be gleaned from that log.

    Thread Starter Michael

    (@michael8888)

    Turns out that not even BPGES_DEBUG is working. I tested without plugins with a WordPress theme. The corresponding function is never executed.

    With Xdebug I see that bpges_send_queue is executed when I post in a group, but then the plugin does all kinds of things that are not related to sending emails. The emails are never sent.

    Plugin Author Boone Gorges

    (@boonebgorges)

    Turns out that not even BPGES_DEBUG is working. I tested without plugins with a WordPress theme. The corresponding function is never executed.

    BPGES_DEBUG is not a function. It’s a constant that causes certain messages to be logged to BPGES_DEBUG_LOG_PATH, which by default is wp-content/uploads/bpges-debug.log. See eg https://github.com/boonebgorges/buddypress-group-email-subscription/blob/1971a19d9efb4097d5ace1952c630f38abc58c7d/classes/class-bpges-async-request-send-queue.php#L94

    With Xdebug I see that bpges_send_queue is executed when I post in a group, but then the plugin does all kinds of things that are not related to sending emails.

    I’d be happy to think some more about it if you had more details about what you mean by “all kinds of things that are not related to sending emails”.

    Thread Starter Michael

    (@michael8888)

    Of course, I know it is a constant. What I am saying is that the bpges_log function is never executed. It’s weird that not even this works without any other plugins enabled. The only thing that really works is changing the settings.

    The plugin never gets beyond autload_real.php when I post and activity update.

    We have about 50 plugins that work fine, which means that your plugin must be doing something unusual.

    Did you test with the latest WordPress and BuddyPress versions with PHP 8.x?

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘All Email not woring with WordPress 6.4.2 and BuddyPress 11.4.0’ is closed to new replies.