You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is where the issue begins. In the method declaration for post_credly_user_badge, the order of parameters is as follows:
public function post_credly_user_badge( $user_id = 0, $badge_id = 0 )
The very first thing we do is check the badge_id for validity
// Bail if the badge isn't in Credly
if ( ! credly_is_achievement_giveable( $badge_id ) )
return false;
However due to the order of parameters, and only passing in 1 parameter. $badge_id is instantly 0, thus we exit right away with a return of false.
If we got that far, we'd eventually set the $user_id variable to the correct value, but we never do. It remains the achievement ID value until we've exited.
Just tested with reversed parameters, and got a green success message. I don't see it in my credly profile, but I'm not sure my settings are all correct for that anyway. I assume our users have a better grasp of that part.
The text was updated successfully, but these errors were encountered:
Due to a lot of complaints on the forums about this one, I felt need to investigate further.
In the badgeos_send_to_credly_handler callback handler, we call the following, with $_REQUEST['ID'] being the post/achievement ID.
This is where the issue begins. In the method declaration for post_credly_user_badge, the order of parameters is as follows:
The very first thing we do is check the badge_id for validity
However due to the order of parameters, and only passing in 1 parameter. $badge_id is instantly 0, thus we exit right away with a return of false.
If we got that far, we'd eventually set the
$user_id
variable to the correct value, but we never do. It remains the achievement ID value until we've exited.Just tested with reversed parameters, and got a green success message. I don't see it in my credly profile, but I'm not sure my settings are all correct for that anyway. I assume our users have a better grasp of that part.
The text was updated successfully, but these errors were encountered: