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.
The default behavior of Drupal.attachBehaviors gets in the way of debugging, this patch is here to let behaviors crash for easier debugging.
Comment | File | Size | Author |
---|---|---|---|
#3 | devel-1891496-3.patch | 1.92 KB | tim.plunkett |
#3 | interdiff.txt | 1.04 KB | tim.plunkett |
devel-remove-behaviors-guard.patch | 1.81 KB | nod_ | |
Comments
Comment #1
Wim LeersEDIT: Incorrect pedantry was here. Ignore this.
Code looks good :)
Comment #2
pcambraIs this a feature you'd want to enable/disable on purpose?
Comment #3
tim.plunkettLooks great, and works great if we use the right hook :)
Comment #4
nod_haha! too much work on D7 :)
(I think you got your interdiff mixed up).
Comment #5
tim.plunkettThat interdiff is from another issue :)
The only change was from devel_library_alter to devel_library_info_alter.
Comment #6
Wim LeersSensible :)
Comment #7
pcambraThanks for the update, my question in #2 remains, though.
As far as I've understood this, the patch overrides how the behaviors are attached to allow debugging, maybe this something that should be on a setting somewhere to enable/disable this feature.
Comment #8
jessebeach CreditAttribution: jessebeach commentedTested and working as expected.
@pcambra, I would just as soon leave this the default behavior when devel is enabled. It doesn't change the behavior of the code that's run, just the behavior of the error reporting in the browser. Rather than have an error reported in the attach function call from drupal.js, the error will be reported on the line where it occurred. There's no reason you wouldn't want this behavior if you're building or debugging a site. On the other hand, there's no reason to not have the error shielding on a prod site.
I make this change manually any time I start an issue that deals with JS. Let's please get this in so practice and code line up again.
thanks tim.plunkett and nod_!
Comment #9
pcambraAdding Moshe for a final call
Comment #10
moshe weitzman CreditAttribution: moshe weitzman commentedDevel is designed to be run on production sites, and to be uninvasive at initial install time. So, I'm not sure I agree that our errors should get louder just be enabling devel.
Comment #11
cweagansWhat? That actually happens?
Comment #12
nod_Umm I've had to audit a site that had a real bad security leak because of devel running in production, I always though this module should never be on a prod site.
I just checked, not running devel is a security check on insight.
Comment #13
moshe weitzman CreditAttribution: moshe weitzman commentedI designed devel, and I designed it to be safe to run on Prod (with default configuration). This is documented in the README.txt.
Each site owner and service can then decide if their security requirements want devel to be disabled.
Comment #14
tim.plunkettThey're not getting louder, they're just staying as loud as they were in D7. At a useful level of loudness.
Comment #16
corbacho CreditAttribution: corbacho commentedI would appreciate feedback on this patch, does it solve the problem for you? So there is no need to patch Devel
https://drupal.org/node/1639012#comment-8743641
Comment #17
willzyx CreditAttribution: willzyx commentedClosing this issue since #1639012: Guard against broken behaviors was committed long time ago in core. Thanks to all!