[buddypress-trac] [BuddyPress Trac] #5972: Password strength meter's JS re-uses theme compat. asset handle

buddypress-trac noreply at wordpress.org
Sun Feb 22 01:58:29 UTC 2015

#5972: Password strength meter's JS re-uses theme compat. asset handle
 Reporter:  DJPaul                       |       Owner:  DJPaul
     Type:  defect (bug)                 |      Status:  assigned
 Priority:  normal                       |   Milestone:  2.3
Component:  Appearance - Template Parts  |     Version:  2.1
 Severity:  major                        |  Resolution:
 Keywords:  has-patch                    |

Comment (by boonebgorges):

 > Sorry Boone, I don't understand. I am only suggesting we override the
 $handle for the wp_enqueue_script() call. I am not saying we should change
 in any way the existing process of locating where the file is actually on
 the hard drive, only its $handle.

 I'm not sure I totally understand either, but I think it's partially
 because the logic used for script naming here is a bit wonky. Check out
 /bp-legacy/buddypress-functions.php#L208. Our CSS and JS are enqueued
 according to the 'handle' returned by `locate_asset_in_stack()`. In each
 case, the `$location_type` of the located file is included in that handle
 /bp-legacy/buddypress-functions.php#L342. So we have `wp_enqueue_script(
 'bp-legacy-js' )`, `wp_enqueue_script( 'bp-parent-js' )`, or
 `wp_enqueue_script( 'bp-child-js' )`, based on where the JS file is found.

 I don't remember why I originally made these handles dynamic, but it's the
 root cause of what's happening in #5797. So maybe it is, in fact, better
 to have non-dynamic handles like you suggest in your patch for 'password-
 verify'. My only point is that it would be out of sync with the way
 enqueuing currently works in bp-legacy.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5972#comment:8>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list