If we don't provide a context and settings variable for every attach function in the JavaScript files we have to use the Drupal.settings (7.x) / drupalSettings (8.x) object but it is easier and better if we just pass these two arguments and use the local settings object instead of accessing the mentioned one.

Comments

yannickoo’s picture

Status: Active » Needs review
StatusFileSize
new1.89 KB
hass’s picture

Status: Needs review » Needs work

We need to fix all occurences of Drupal.settings. Not only a few...

hass’s picture

Tried dpm($node); but cannot expand to all data. What exactly does this patch trying fix?

pcambra’s picture

Tried dpm($node); but cannot expand to all data. What exactly does this patch trying fix?

I don't think that the data is not expanding because of this, I think the issue is bigger: #1853112: Replacement for Krumo? meaning that non stdClass such as *everything* now in D8 is not expanded because the same reasons that metadata wrappers or other classes weren't in D7.

Closing #2112747: Dumping with krumo() no longer working? as dupe of this

pcambra’s picture

Issue summary: View changes

Updated issue summary.

pcambra’s picture

Some of the conversions happened in #2108403: Big menu sales! hook_menu needs routing now

aaronbauman’s picture

All Drupal.behaviors attach() functions get passed a "settings" parameter.
Isn't using that argument more appropriate than the global in those contexts?

aaronbauman’s picture

Issue summary: View changes
Status: Needs work » Needs review
StatusFileSize
new1.25 KB

Anyway, there are only 2 instances of this issue remaining.

pcambra’s picture

+++ b/js/devel_krumo_path.js
@@ -7,7 +7,7 @@ Drupal.behaviors.devel = {
+    $('.krumo-footnote .krumo-call').once().before('<img style="vertical-align: middle;" title="Click to expand. Double-click to show path." src="' + settings.basePath + 'core/misc/help.png"/>');

shouldn't this be drupalSettings?

aaronbauman’s picture

Well, that was my question in #6.
Is the settings argument to the attach() function not more appropriate in this context?

If not, I don't know what that argument is for.

edit: According to this document, the local settings argument is indeed more appropriate in this context.

pcambra’s picture

Status: Needs review » Reviewed & tested by the community

Setting as RTBC as for #2128675: JavaScript error on all pages

Yeah, seems is cheaper to use settings if we have it in the context

salvis’s picture

Looks ok to me.

salvis’s picture

Title: dpm() does not work because of the new global variable drupalSettings » Replace removed Drupal.settings in JS
yannickoo’s picture

I would pass context and settings in every attach function so we do not need drupalSettings and just use settings.

pcambra’s picture

Category: Bug report » Task
Status: Reviewed & tested by the community » Needs review

I think it's the way to go, but I'm getting back to NR as we need further testing with the new changes.

This could be backported to D7 too.

pcambra’s picture

Version: 8.x-1.x-dev » 7.x-1.x-dev
Component: krumo » devel
Status: Needs review » Patch (to be ported)

I'd say we can port some of these changes to D7 (proper settings handler instead of Drupal.settings)

pcambra’s picture

Issue tags: +Needs backport to 7.x
yannickoo’s picture

Title: Replace removed Drupal.settings in JS » Pass "context" and "settings" arguments for every JavaScript "attach" function
Issue summary: View changes
Status: Patch (to be ported) » Needs review
Issue tags: -Needs backport to 7.x
StatusFileSize
new3.61 KB
salvis’s picture

Thanks, yannickoo!

You missed two recursive calls to devel_node_access_user_ajax().

With that it's working fine. Wait for the testbot...

yannickoo’s picture

Oh sorry but thank you salvis! :)

salvis’s picture

Status: Needs review » Fixed

No problem, that's why we do reviews.

Pushed to D7.

pcambra’s picture

\o/ thanks @yannickoo @aaronbauman & @salvis =D

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.