Skip to:
Content
Pages
Categories
Search
Top
Bottom

Trouble with $topic_id = bbp_get_reply_topic_id( $reply_id );


  • antipole
    Participant

    @antipole

    Various email notification functions work when a topic or reply is submitted or edited from the frontend but not from the backend. I have code which is hooked on to transition_post_status to take over notification functions when a topic or reply is published from the front or backend. It works great for topics, but I am having trouble with replies.

    I have the following code fragment fired on publication of a reply:

    $reply_id = bbp_get_topic_id( $post->ID );
    $topic_id = bbp_get_reply_topic_id( $reply_id );
    $forum_id = bbp_get_topic_forum_id( $topic_id );
    $reply_author_id = bbp_get_reply_author_id($reply_id);
    error_log("Trace point reply to be published topic_id:". strval($topic_id) . " reply_id: " . strval($reply_id) . " forum_id: " .  strval($forum_id). " author_id: " . strval($reply_author_id));

    In all cases, $reply_id and $reply_author_id are found correctly.
    When invoked from the frontend, $forum_id is found correctly, but not from the backend.
    $topic_id is shown as zero whether from front or backend.
    So bbp_get_reply_topic_id($reply_id) is not functioning as I anticipate. I have tried bbp_get_reply_topic_id( $$post->ID ) with the same result.

    How do I get the topic_id from the reply_id? Can SKS please help here?

Viewing 14 replies - 1 through 14 (of 14 total)

  • Robin W
    Moderator

    @robin-w

    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


    Robin W
    Moderator

    @robin-w

    there is also

    do_action( 'bbp_topic_attributes_metabox_save', $topic_id, $forum_id );

    for topics


    antipole
    Participant

    @antipole

    @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?


    antipole
    Participant

    @antipole

    Stack Trace

    #5 /home/…/public_ in /home/…/public_html/ovni-owners-test-site/wp-content/plugins/ovni-submission-notifications/pending-submission-notifications.php on line 98
    1.
    test_reply_call(9705)
    /home/…/public_html/ovni-owners-test-site/wp-includes/class-wp-hook.php:288
    2.
    WP_Hook->apply_filters(”, Array)
    /home/…/public_html/ovni-owners-test-site/wp-includes/class-wp-hook.php:310
    3.
    WP_Hook->do_action(Array)
    /home/…/public_html/ovni-owners-test-site/wp-includes/plugin.php:453
    4.
    do_action(‘bbp_reply_attri…’, 9705, 9605, 1882, 0)
    /home/…/public_html/ovni-owners-test-site/wp-content/plugins/bbpress/includes/admin/replies.php:315
    5.
    BBP_Replies_Admin->attributes_metabox_save(9705)
    /home/…/public_html/ovni-owners-test-site/wp-includes/class-wp-hook.php:288


    Barry
    Participant

    @barryhughes-1

    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).


    Robin W
    Moderator

    @robin-w

    @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


    antipole
    Participant

    @antipole

    @Barry – thanks for your interest.

    Standard WP and bbPress email notifications fall short because

    1. When a WP post is held for moderation, admin/moderators do not get any notification.
    2. When a WP post or comment is held for moderation and subsequently approved, subscribers are not notified
    3. When bbPress topics or replies are held for moderation and subsequently approved, subscribers are not notified.
    4. 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:

    1. 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.
    2. Publishing a topic from the backend fails to notify subscribers. bbPress_notify_forum_subscribers presumably fails to workout the forum-id behind the scenes.
    3. 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.


    antipole
    Participant

    @antipole

    @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.


    Robin W
    Moderator

    @robin-w

    no idea why wordpress requires the number of arguments, just the way it works 🙂


    Barry
    Participant

    @barryhughes-1

    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 🙂


    antipole
    Participant

    @antipole

    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.


    Robin W
    Moderator

    @robin-w

    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


    antipole
    Participant

    @antipole

    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


    Robin W
    Moderator

    @robin-w

    @antipole thanks for posting the solution and link to the code 🙂

Viewing 14 replies - 1 through 14 (of 14 total)
  • You must be logged in to reply to this topic.
Skip to toolbar