sj-xweb
Forum Replies Created
-
Hi,
Any updates on this?
I created a separate php file called events-test.php and loaded it in the browser after logging into an account with no group associations.
Are you having issues replicating the problem?
The issue should be pretty easy to track if you just look at the code. The $groups in bp-em-groups.php is populated by groups_get_user_groups() function (defined by buddypress plugin), and that function calls BP_Groups_Member::get_group_ids(). In that function, you can see that the code that returns the groups is: (buddypress/bp-grouops/classes/class-bp-groups-members.php, line 492)
return array( 'groups' => $groups, 'total' => (int) $total_groups );That means $groups variable your code is looking at will always have 2 elements, making your conditional on line 88 of bp-em-groups.php always true.
I disabled all the plugins except for Buddypress and EM, and wrote a php script with the following code:
<?php require( $_SERVER['DOCUMENT_ROOT'] . '/wp-load.php' ); $EM_Events = EM_Events::get(array('group' => 'my')); ?>Still get the sql error. The key to replicate the issue is to be logged in as a member that do not belong to any groups, and you should watch the error_log since the error may not being displayed in the browser.
WordPress: 4.2.2
Buddypress: 2.3.2.1
Event Manager: 5.5.7.1Forum: Plugins
In reply to: [BadgeOS] Issue with switch_to_blogAs far as I know, the $GLOBALS[‘_wp_switched_stack’] array is an internal WP variable that it uses to track all the blog switches done in a page lifecycle. You can see it being used in switch_to_blog() definition in ms-blogs.php.
So every time switch_to_blog() is called, the old blog ID is appended to $GLOBALS[‘_wp_switched_stack’].
Here’s a sequence of events of what happens:
– BadgeOS stores current blogID into $cached_id (1)
– Loop switch_to_blog() for all the blogs on the network
– For every itereation, $GLOBALS[‘_wp_switched_stack’] is appended with the previous blogID
– At the end of loop, last switch_to_blog() is called with $cached_id (1) as parameter. At this point, the last blogID (9) is appended to $GLOBALS[‘_wp_switched_stack’]
– Buddypress runs its process, and calls restore_current_blog(), which changes the current blog to the last blog id (9) in the $GLOBALS[‘_wp_switched_stack’] array.I hope that clears it up a bit more.
Forum: Plugins
In reply to: [BadgeOS] Issue with switch_to_blogHi Michael,
Just tried, and that didn’t fix it. Further debugging showed that $GLOBALS[‘_wp_switched_stack’] has the following value before restore_current_blog() is called:
Array ( [0] => 1 [1] => 1 [2] => 2 [3] => 1 [4] => 7 [5] => 1 [6] => 8 [7] => 1 [8] => 9 )restore_current_blog will then set the current blog to the blog ID in the last element.
Forum: Plugins
In reply to: [BadgeOS] Issue with switch_to_blogOr, to fix the issue, you can also just put the switch stack in a variable before polling, and then set it back afterwards, like how you’re doing with the blog id right now.
First, make sure you have a Private Group in BuddyPress, and a member belonging to the group.
Create a recurring event associated with the Private Group using the group member.
Open up an instance of the recurring event, and copy the url from the address bar.
Log out and log back in as another member who is NOT a member of the group. Paste the url in the address bar and load it.
Expected behavior should be either redirect away from the event page, or some sort of error. Instead I’m able to see the event detail. I checked the database, and it looks like the while the Recurring Event series is flagged as private, the individual events records aren’t.
Hope that helps.
Angelo,
Are you able to reproduce the issue? Are there any updates on this?
Thanks.
EM version is 5.5.3.1.
It is happening to all private groups.
Hey, not sure if you guys are still looking for info on this issue, but we recently experienced the problem of achievement tab not displaying on member profile.
After debugging the code a bit, I figured out that our problem was related to a mismatch of data.
Specifically, it was on line 170 of badgeos-community-add-on/includes/bp-members.php:
$post_id = isset( $arr_achievement_types[$achievement_type] ) ? $arr_achievement_types[$achievement_type] : 0;The short story is that $arr_achivement_types is populated with post_name as the array key, and $achievement_type is populated with post_type. Which worked, until someone updates the title of an Achievement Type (which was the case for us).
Apparently post_name doesn’t update when the title is changed, but any new achievements created using the new title will have the updated name as post_type. So from that point on, the code is trying use the new name to select from an array populated with old names
After I updated the post_name field, the problem went away, and the achievement tab showed up again.
I’m not sure if this is exactly the issue you’re trying to resolve, and I hope it makes sense. Hopefully it will helps you with debugging the problem.