antipole (@antipole)

Forum Replies Created

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

  • antipole
    Participant

    @antipole

    Yes AsynCRONousbbPress Subscriptions works out of-the-tin as described. But it turns a single email with 123 Bcc addressees into 123 single addressee emails, which breaks my ISP’s limit of 100 emails/hour. Sigh!

    I have finally achieved my own plugin which hooks onto wp_mail() and which chops up outgoing emails into multiple emails with a configured maximum Bcc addressee limit. So with my ISP’s limit of 10 addressees, my 123 notifications get sent in 12 emails each with 10 addressees plus 1 with the last 3.

    It works with all outgoing emails that supply the Bcc addresses in an array (as does bbPress) or a flat list (as does Subscribe2 for WP post notifications).

    Code here.


    antipole
    Participant

    @antipole

    My site has been suspended by my ISP twice in the last couple of days for ‘malicious activity’, which turns out to be breaching their new limit of 10 addressees per email. (Most of my forums currently have 123 subscribers.)

    I have had to disable the sending emails for new topics entirely, until I have a solution.

    Breaking up these emails is pretty essential as most ISPs are now imposing some limit on the number of addressees, although my ISPs limit of 10 must one of the lowest.

    I have no indication that bbPress is going to address this, so I may have to develop something myself. In this thread a couple of approaches are mentioned. But before I start digging in to bbPress core, does anyone have any suggestions/pointers?

    PS I am using GD bbpress Toolbox to format the emails and do not want interfere with that function.


    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


    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.


    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.


    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

    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


    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?

    In reply to: bbp_new_forum hook

    antipole
    Participant

    @antipole

    Thanks – yes – stupid error. It is always amazing what a fresh eye brings.
    Things started working then and I checked all my numerous trace actions and it is now working well. Here is the final version for your interest.

    thanks a million, Tony

    // (2)	When a new forum is created, all current users are automatically subscribed to it
    
    //	Note status of forum entry at start of any update
    function ovni_pre_post_update_status($forum_id){
    	if (bbp_is_forum($forum_id)) {
    		global $ovni_forum_old_status;
    		$ovni_forum_old_status = bbp_get_forum_visibility($forum_id);
    		}
    	}
    add_action('pre_post_update', 'ovni_pre_post_update_status');
    
    function ovni_subscribe_users_to_new_forum($forum_id){  // subscribe all users to a new forum unless it is a group forum
    	if (bbp_is_forum($forum_id)){
    		if (bbp_get_forum_parent_id( $forum_id ) == 969) return;  // if this is group forum, do nothing
    		global $ovni_forum_old_status;
    		if (in_array($ovni_forum_old_status, array(NULL, 'auto-draft', 'draft'))){
    			// forum has just been published
    			$all_user_ids = get_users();
    			foreach ($all_user_ids as $this_user){
    				bbp_add_user_forum_subscription($this_user->id, $forum_id);
    				}
    			}
    		}
    	}
    add_action('bbp_forum_attributes_metabox_save', 'ovni_subscribe_users_to_new_forum');
    
    In reply to: bbp_new_forum hook

    antipole
    Participant

    @antipole

    Thanks @fterra for your suggestions.
    I cannot see that my action on pre_post_update is firing at all, even if I edit an existing forum. I have trace actions in and neither user 33 or 32 are getting subscribed.
    Puzzled.

    function ovni_pre_post_update_status($forum_id){
    	bbp_add_user_forum_subscription(33, $forum_id);	// debug **********
    	if (bbp_is_forum($forum_id)) {
    		global $ovni_forum_old_status;
    			bbp_add_user_forum_subscription(31, $forum_id);	// debug **********
    		$ovni_forum_old_status = bbp_get_forum_visibility($forum_id);
    		}
    	}
    add_action('pre_post_update', 'ovni_pre-post_update_status');
    In reply to: bbp_new_forum hook

    antipole
    Participant

    @antipole

    @fterra – thanks for your suggestions.

    I have it working using ‘bbp_forum_attributes_metabox_save’ as you suggested but have found, perhaps not surprisingly, my function is fired on an update to the meta date. So with the code below I create a new forum and all users are subscribe; some choose to unsubscribe; I update something in the meta data and everyone is subscribed again – not good. Any idea how I can determine whether this is a first time save or an update?
    Also I do not want to auto subscribe to group forums. I have fixed this by hard-coding in the group forum’s id, but maybe there is a better way of testing whether a forum_id is a group forum?

    Any ideas welcome thanks.

    function ovni_subscribe_users_to_new_forum($forum_id){  // subscribe all users to a new forum unless it is a group forum
    	if (bbp_get_forum_parent_id( $forum_id ) == 969) return;  // if this is group forum, do nothing
    	$all_user_ids = get_users();
    	foreach ($all_user_ids as $this_user){
    		bbp_add_user_forum_subscription($this_user->id, $forum_id);
    		}
    	}
    add_action('bbp_forum_attributes_metabox_save', 'ovni_subscribe_users_to_new_forum');
    In reply to: bbp_new_forum hook

    antipole
    Participant

    @antipole

    Robin.. thanks for pointing to topic-subscribe.

    It works for me mostly. In testing, I found that when a new topic is held for moderation (I have things set for user’s first topic to be moderated), then once the topic is approved all other users get subscribed to the topic except the submitter, who is left unsubscribed. I guess the approval process is unsubscribing.

    However, I modified your plugin to hook it on last in the actions:

    add_action (‘bbp_new_topic_post_extras’, ‘rw_topic_subscribe’, 1, 99) ;

    and now it seems to work even for moderated topics.

    I also have bbPress auto subscribe for new topics and replies installed and moderated topics are not getting subscribed despite this plugin ticking the box. {I tested your plugin with this other plugin deactivated. This is probably the same issue although the solution may not be so simple – I have raised it on its support forum.

    This may be a bit off-topic as it is not about new forums but I see no better place.

    Tony

    In reply to: bbp_new_forum hook

    antipole
    Participant

    @antipole

    @fterra – thanks for the suggestion. I gave it a go but I don’t see it working for me.

    You say this is your “bet”. Have you actually got something working on this hook?

    In reply to: bbp_new_forum hook

    antipole
    Participant

    @antipole

    I am still looking for a solution to this – I want to subscribe users to a new forum when it is created.

    The code above fires when you open the New forum admin page. I guess a new post is created at that time so an object ID is allocated. If you don’t go through and publish, the entry must then get deleted. Anyhow, if you do create the forum by publishing it, the subscriptions do not get created. My guess is that it is too soon in the process of creating a forum to add subscriptions to it.

    I have tried hooking onto the publish action but not got it to fire there. I really need to find a hook much later in the process. As stated above, the bbb_new_forum hook only fires from the front end and that limits it to creating group forums, as far as I can see.

    Any pointers gratefully received. Meanwhile I am having to manually activate some code and run it once after creating a new forum and then deactivate it – very error prone and easily forgotten.

    In reply to: bbp_new_forum hook

    antipole
    Participant

    @antipole

    Hi… I am trying this. I want to auto-subscribe all users to new forums and I have tried the following:

    function ovni_subscribe_all_users_to_new_forum($forum_id){  // subscribe all users to a new forum
    	echo 'ovni_subscribe_all_users_to_new_forum fired';
    	// this function will fire on all wp-insert_posts - only act if is for a new forum
    	if ((get_post($forum_id)->post_type == bbp_get_forum_post_type()) && !wp_is_post_revision( $forum_id )){
    		// have just posted a new forum
    		$all_user_ids = get_users();
    		foreach ($all_user_ids as $user){
    			bbp_add_user_forum_subscription($user_id, $forum_id);
    			}
    		}
    	}
     add_action(save_post, ovni_subscribe_all_users_to_new_forum, 90,1);
    

    When I load the New Forum admin page, the echo trace statement appears at the top of the New Forum page, before it has been submitted.

    Can SKS help here please?


    antipole
    Participant

    @antipole

    I am trying your bbl-style-pack plugin, as that would be easier for others to maintain should that situation arise.

    The Remove Private option removes both occurrences of the PRIVATE: prefix. It also removes private forums entirely from the (bbPress) Forums List widget display when on an ordinary page (not just the prefix PRIVATE:) – but not when displaying a forum list. I suspect that this is not what was intended.

    [Incidentally, the bbpStyle pack Forum Display tab has a minor typo in section 4. The tick box reads Move subscribe to rightRemove private prefix rather than Remove private prefix

    What I want to achieve is to remove one occurrence of the duplicate wording in the forum display heading PRIVATE: PRIVATE: forum name. Are you able to suggest a solution for this?

    Regarding the Oh bother! No topics were found here!, yes creating a topic would remove this, but I have created empty forums to guide users as to which forum to use for their potential topic. It would be nice to lose that message when you are next in that code.

    thanks again


    antipole
    Participant

    @antipole

    Robin… before I got your suggestion regarding rewrite rules, I had begun to suspect corruption of permissions in my forum database entires. I created a new test forum and it worked OK.

    So, for each empty forum I deleted it and created a new one. For each forum with topics, I created a new one, i.e. Forum A new, reassigned the topics from Forum A to Forum A new, deleted Forum A and then renamed Formum A new to Forum A.

    This has cleared my problem and I can now view the forum topics as Testuser2.

    How the problem arose, I do not know. There have been WordPress or bbPress updates recently and possibly something did not upgrade properly.

    There remain two issues:
    The keyword PRIVATE: is shown twice in the display of the forum contents.
    If the forum is empty, a blue box correctly says This forum is empty but then a yellow box says Oh bother! No topics were found here!

    In the latter case, I suspect a coding error whereby the empty forum is spotted but the code still tries to display the topics.

    Do I still need to reset my permalink as you suggest?

    Meanwhile I shall start re-instating my plugins etc.

    thanks for your support.


    antipole
    Participant

    @antipole

    Firstly, thank you for responding.

    I have disabled all plugins except BuddyPress and bbPress.
    I have switched to the theme Twentyfourteen.

    I still have a problem. Since simplifying as above, I have, signed in with admin rights, created a new topic in an otherwise empty private forum called ‘Domestic Water’. As that user I can read it etc.

    I then log out and back in as Testuser2 who has site role of Author and Forum Role of Participant. When I select the forum ‘Domestic Water’ from the list in the side bar I get a screen as shown here.

    Note that Private is repeated twice. The blue box is correct, saying there is one topic in the forum.
    But I then get a yellow box “Oh bother! No topics were found here!”

    Your further advice will be very much appreciated.

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