Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
user_badges_get_badges('select') doesn't return anything because at some point in time when the cache was updated to use a $stringified_options key the 'select' logic wasn't updated to set its data properly. The fix is pretty simple (patch to follow), though perhaps this has been addressed in 7.x-3.x by splitting this overloaded function into separate functions?
Comment | File | Size | Author |
---|---|---|---|
#4 | user_badges-fix_user_badges_get_badges-2172787.patch | 779 bytes | shabana.navas |
Comments
Comment #1
rszrama CreditAttribution: rszrama commentedNever mind, it appears in the latest 7.x-2.x-dev that you've actually removed the $stringified_options bit. I didn't expect that given the latest release was January 10.
Comment #2
rszrama CreditAttribution: rszrama commentedActually, I'm not sure what's going on here. I don't see any recent commits to the 7.x-2.x branch, and the only issue I see referenced in the 7.x-2.1 release was for a commit to the 7.x-3.x branch. Are your releases out of sync here? Because right now in 7.x-2.1 this bug exists that I don't see in the 7.x-2.x branch even though there have been no commits to it since the 7.x-2.1 release.
Comment #3
shabana.navas CreditAttribution: shabana.navas commentedVersion 7.x-2.1 is based on the 7.x-3.x version. It was a misnomer. I should have tagged the production version as 7.x-3.0. Will be doing that. Sorry for the confusion. Let me know if you run into any problems after this.
Comment #4
shabana.navas CreditAttribution: shabana.navas commentedPlease try out this patch. If it works, I will go ahead and add it to the dev version, then, release a proper 7.x-3.0 production version.
Comment #5
shabana.navas CreditAttribution: shabana.navas commentedComment #6
rszrama CreditAttribution: rszrama commentedI already fixed it locally in the same fashion. I'd highly recommend you fix your releases to match the release numbers to the Git branches. You shouldn't be tagging releases as 2.x from the 3.x branch of your code - doubt I'm the only person confused here. There should be no problem with simply tagging those as 3.0, 3.1, etc., no?
Comment #7
shabana.navas CreditAttribution: shabana.navas commentedYeah, I've got to fix those. Rookie mistake. I think it is too late to change the git tags as I already released these. I think I can only resort to creating a proper new 7.x-3.2 production release with this error fixed, to clear any doubts. I have also added to the notes for each release that it is based on the 7.x-3.x-dev version.
Comment #8
rszrama CreditAttribution: rszrama commentedYeah, it's too late to change the existing tags, but no worries. Fixing it from here forward should do just fine. : )