• Resolved majecdad

    (@majecdad)


    I might have gone about this wrong, so I’m looking for guidance. A while back, I inquired about having ‘unapproved’ users NOT show up in the activity stream. In looking at github, I thought I saw your update addressing that matter (#89) which is slated to run with 4.3 (ETA unknown?).

    It also stated that the issue was “Fixed in 583edab” July 19, 2015 – “We prevent the notice upon activation of the user account, and add the notice upon approval. We don’t want to deny the new user notice overall, just hold off until approval.”

    I grabbed the code from 583edab and added it to /includes/core.php.

    However, this did not seem to resolve the issue of the display of unapproved users.

    Will this code from 583edab added to includes/core.php not work at all until after the release of 4.3?

    This issue is such an important part of new user moderation, I’m hopeful that it will be addressed soon.

    Thanks for your efforts here.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Michael Beckwith

    (@tw2113)

    The BenchPresser

    Simply put, if it’s not working in it’s current form, then it needs more testing. I have to believe I did do testing of it at the time, but perhaps not extensively enough or with the right conditions.

    To highlight the code in question for BP Core, the following is most significant:

    		do_action_ref_array( 'bp_activity_before_save', array( &$this ) );
    
    		if ( 'wp_error' === $this->error_type && $this->errors->get_error_code() ) {
    			return $this->errors;
    		}
    
    		if ( empty( $this->component ) || empty( $this->type ) ) {
    			if ( 'bool' === $this->error_type ) {
    				return false;
    			} else {
    				if ( empty( $this->component ) ) {
    					$this->errors->add( 'bp_activity_missing_component' );
    				} else {
    					$this->errors->add( 'bp_activity_missing_type' );
    				}
    
    				return $this->errors;
    			}
    		}
    

    Unless I’m mistaken, it should get to the $this->errors->add( 'bp_activity_missing_type' ); line and then return some errors 2 below it.

    https://github.com/WebDevStudios/BuddyPress-Registration-Options/commit/583edabc712cd863505801945f42230dad336d13

    This is the commit in question, and we should be getting the type parameter set to an empty string, which would evaluate to true for an empty() check.

    Perhaps part of if ( true === bp_registration_get_moderation_status( $args->user_id ) && 'new_member' == $args->type ) isn’t evaluating to true in your case, and it’s never executing anything. Given that it was the summer of 2015 when that commit was made, there’s a year of chance that something has changed since. Still not sure when 4.3.0 will be considered ready, and I don’t always have a long window period open.

    Michael Beckwith

    (@tw2113)

    The BenchPresser

    As a followup, all I’m essentially doing at times is finding the appropriate filters in BuddyPress and amending things. If you or someone else you know find a way to successfully block/hide things, have at it. If you’re willing to contribute those back to us, we appreciate and give credit as appropriate. Definitely wouldn’t call us perfect, but we do what we can, even if it’s very slowly at times.

    Thread Starter majecdad

    (@majecdad)

    Yeah, I would trust your code and testing a lot more than I would mine. ??

    Whether something has changed from the commit in summer ’15, or whether I have something else creating an issue here, I don’t know. I had just found a need to return to this issue, and had hoped stumbling across this commit might resolve the problem.

    While I hope you all can get to 4.3 at some point, I understand the timeframes on these updates, and how other work takes precedent. I’ll continue to follow these threads and github and test more on my side.

    Thanks again for your work here.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Git update on user moderation/display’ is closed to new replies.