Skip to:
Content

BuddyPress.org

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#6043 closed defect (bug) (fixed)

Persistent "repair" message in admin for people allowing registration

Reported by: imath Owned by: boonebgorges
Milestone: 2.2 Priority: normal
Severity: normal Version:
Component: Core Keywords: has-patch
Cc:

Description

Since r9177 even if we define the pages for registration and activation, the message inviting us to repair the page association keeps on showing.

That's because these two pages are not components and the following check is not taking this fact in account :

if ( ! bp_is_active( $component_name ) || 'trash' == get_post_status( $page_id ) ) {
	unset( $page_ids[ $component_name ] );
}

Attachments (1)

6043.patch (1.1 KB) - added by imath 5 years ago.

Download all attachments as: .zip

Change History (8)

@imath
5 years ago

#1 @boonebgorges
5 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 9180:

Don't remove Register and Activate pages from bp_core_get_directory_page_ids().

These two pages do not correspond to components, so they should be excluded
from bp_is_active() checks.

Props imath.
Fixes #6043.

#2 @imath
5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

I'm sorry, but r9180 is not fixing the issue on my config (WP & BP Trunk Multisite). My original patch does, but i have no idea why your commit is not fixing it :( Very strange.

#3 @imath
5 years ago

I think my patch is working because it's the wrong way to solve the issue, the correct check should be ! empty() in my case, and then it fails. Your commit is the good way, but it looks like the function is running twice.

the first time bp_get_signup_allowed() is false and the second time it's true.

Last edited 5 years ago by imath (previous) (diff)

#4 @boonebgorges
5 years ago

Thanks, imath. The problem is that the admin notice is being built before $bp->site_options is being populated. The result is that the 'registration' value is not yet loaded, which causes bp_get_signup_allowed() to return false.

I'm going to put in a band-aid fix for the time being, just to get this to work properly. I'll open a ticket for a broader fix.

#5 @boonebgorges
5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 9189:

Ensure site_options have been loaded in bp_get_signup_allowed().

This function is sometimes run before $bp->site_options has been populated,
resulting in incorrect 'registration' values.

Fixes #6043.

#6 @imath
5 years ago

Thanks a lot boonebgorges :)

#7 @boonebgorges
5 years ago

#6045 is the new ticket.

Thanks for your help, imath.

Note: See TracTickets for help on using tickets.