you could hook your code to this action
do_action( 'bbp_reply_attributes_metabox_save', $reply_id, $topic_id, $forum_id, $reply_to );
which fires when a reply post is saved in admin and that gives you all the items you want
there is also
do_action( 'bbp_topic_attributes_metabox_save', $topic_id, $forum_id );
for topics
@robin-w thanks. I am experimenting with your suggestion. I have
function test_reply_call($reply_id, $topic_id, $forum_id, $reply_to){
error_log("Trace rest reply: $reply_id: ". strval($reply_id) . "; $topic_id: " . strval($topic_id) . "; $forum_id: " . strval($forum_id) . "; $reply_to: " . strval($reply_to));
}
add_action('bbp_reply_attributes_metabox_save', 'test_reply_call');
This is fired when I post a reply in the backend, but I get
Fatal error: Uncaught ArgumentCountError: Too few arguments to function test_reply_call(), 1 passed in /home/…/wp-includes/class-wp-hook.php on line 288 and exactly 4 expected in /home/…/wp-content/plugins/ovni-submission-notifications/pending-submission-notifications.php
The do_action in bbp_reply_attributes_metabox_save does use 4 arguments. What am I doing wrong please?
Hi @antipole,
Looking back at your original strategy, you only shared a fragment of your code – so it’s hard to be sure of this – but I’m wondering if the problem are the assumptions you are making about the type of $post your callback is receiving.
https://gist.github.com/barryhughes/30bacb98b716ecaa864f0b6eaa7c051c
Does a revised approach like the one I shared above work for you? It should give you the author ID (whether that is the author of the reply or the topic) and the forum ID. If you need to, you could add an extra test to confirm the status change reflects publication (vs a topic being set back to draft by an admin).
@antipole
you need to specify the number of arguments in the call so..
function test_reply_call($reply_id, $topic_id, $forum_id, $reply_to){
error_log("Trace rest reply: $reply_id: ". strval($reply_id) . "; $topic_id: " . strval($topic_id) . "; $forum_id: " . strval($forum_id) . "; $reply_to: " . strval($reply_to));
}
add_action('bbp_reply_attributes_metabox_save', 'test_reply_call', 10 , 4);
the ’10’ is the priority – 10 is the standard, the higher the number the higher the priority so the order in which any other links to this hook are run, and the ‘4’ the numbers of arguments you are calling through
@Barry – thanks for your interest.
Standard WP and bbPress email notifications fall short because
- When a WP post is held for moderation, admin/moderators do not get any notification.
- When a WP post or comment is held for moderation and subsequently approved, subscribers are not notified
- When bbPress topics or replies are held for moderation and subsequently approved, subscribers are not notified.
- Sometimes it is best for admin or moderator to create or moderate topics or replies in the backend. Standard bbPress does not send subscriber notifications when they are published from the backend.
I am working on a plugin which uses the transition_post_status hook to look for publications of the above and make notifications. I show the full plugin as of now here.
The section above line 76 deals with WP posts held for moderation and subsequently approval. It is basically cloned from another plugin as acknowledged.
From line 72 is my work. It looks for a topic or reply status changing to ‘publish’.
It works when a topic or reply is published from the frontend but not from the backend. The relevant bit of code gets executed correctly, but the relevant variables are not set up correctly. I suspect that some of the functions I am calling rely on globals that are set up by the bbPress frontend but these are not in place for backend actions.
My trace statements reveal that:
- Publishing a topic from the frontend works fine – BUT trace shows that $forum_id is set to zero. So the bbPress_notify_forum_subscribers call works without the $forum_id parameter being set. It must work it out otherwise.
- Publishing a topic from the backend fails to notify subscribers. bbPress_notify_forum_subscribers presumably fails to workout the forum-id behind the scenes.
- On reply publication, the code gets the $reply_id OK but the notifications do not get sent, so it must fail to work out the missing information.
I think my basic approach of using the transition_post_status hook is good as it allows me to act when a post changes to publish from draft/pending etc. whether from the front or backends. But the calls to collect the required ids are not all they seem and rely on behind the scenes poking around in stuff that is not in place when invoked from the backend.
@robin-w Ahh yes! Thanks for putting me right on the number of args.
If I follow your route, I will have work to do to work out when a topic/reply is changing to ‘publish’ as in my code.
no idea why wordpress requires the number of arguments, just the way it works 🙂
Publishing a topic from the frontend works fine – BUT trace shows that $forum_id is set to zero.
Ah yes, you’re right. That’s because “transition_post_status” fires before bbPress generates the meta data linking the topic (or reply) with its parent forum.
So, during your callback, the information isn’t available (actually it is, you could grab the post parent value from the post object, but that’s not “the way”).
Maybe try following Robin’s strategy 🙂
So using Robin’s strategy, when I publish a topic/reply from the backend, but not from the frontend, I can get the details I need. Actually, it is called twice on a publish – probably once when a draft is created and again once it becomes ‘publish’.
I would need to know when a topic/reply changes to ‘published’ from ‘not published’ to avoid sending notifications on edits or for pending versions, etc. This my original approach does nicely (if it worked as hoped). I don’t know how I could determine this via the bbp_topic_attributes_metabox_save approach without getting into complicated stuff about saving and storing previous metadata states.
I am beginning to despair of finding a solution.
in your original code, try
$reply_id = bbp_get_topic_id( $post->ID );
$topic_id = $_POST['parent_id'] ;
$forum_id = bbp_get_topic_forum_id( $topic_id );
$reply_author_id = bbp_get_reply_author_id($reply_id);
I think that $_POST[‘parent_id’] should be available at the point the transition_post_status runs
you might also find that $post->parent_id is there as well
It turns out to be horribly messy in my original approach. I had to poke around to pick up stuff in different places depending on whether it was invoked from the font or backend. As an example:
$forum_id = bbp_get_topic_forum_id($topic_id); // This often does not work here
if (!$forum_id){ // need to find it elsewhere, which is different for front and backend submissions
$forum_id = $_POST['bbp_forum_id'] ? $_POST['bbp_forum_id'] : $_POST['parent_id'];
}
Note for frontend it is to be found in $_POST[‘bbp_forum_id’] and for backend submissions $_POST[‘parent_id’]
In the end I adopted Robin’s suggestion for hooking onto bbp_topic_attributes_metabox_save for backend and onto bap_new_topic and bap_new_reply for frontend.
So I now have a much simpler plugin which is sending notifications when topics or replies are actually published (even after moderation) and which works with publication from front or back ends and for moderation approval in front or backends.
Subscription choices are lost during moderation and not available in the backend. So I force-subscribe users to their own topics and to topics they reply to on publication. (They can unsubscribe later if they wish.)
Thank you very much to those who contributed to me getting there.
Code is to be found here
@antipole thanks for posting the solution and link to the code 🙂
Don’t know how this happened, but I have found the actual bbp_notify_forum/topic_subscribers calls were missing from the code I posted. Now fixed and updated – added lines 75-84.
