Closed (fixed)
Project:
Panelizer (obsolete)
Version:
8.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
17 Mar 2016 at 09:43 UTC
Updated:
4 Jul 2016 at 04:00 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
swentel commentedComment #3
swentel commentedHmm, I don't have it on a regular ipe page, so this might be a panelizer problem, let me double check.
Comment #4
swentel commentedConfirmed, only happens on panelizer - moving to different queue.
Comment #5
swentel commentedComment #6
swentel commentedmeh, wrong path
Comment #8
dsnopekGood catch!
However, I think this should be inside of the existing
if() { ... }statement just before the$build['#attached']['library'][] = 'panelizer/panels_ipe';(I think it's that line that's causing the Panels IPE Javascript to be added, since it depends on it).And, maybe rather than checking for the permission, we could check something on the
$buildarray that would let us know if the IPE added itself? Otherwise, we could be getting the permissions wrong if/when this issue is committed: #2667754: Allow other modules to disable the IPE based on custom logic. Maybe it could look in$build['#attached']['library']and if it finds the IPE Javascript, it could figure it's safe to add the Panelizer Javascript?Comment #9
wiifmJust came across this as well - #2717561: JavaScript should only be rendering on the page if the user has access to use panels_ipe. Closed that as a duplicate.
Comment #10
hampercm commentedWorking on a new patch for this, based on the suggestions from #8
Comment #11
hampercm commentedNew patch based on the suggestions from #8. This will disable the attachment of the Panelizer library any time the panels_ipe/panels_ipe library isn't already attached.
I've tested it for Anonymous and Authenticated users without sufficient privileges to use the IPE, and verified no IPE-related JS files were linked.
Comment #13
dsnopekThanks! Committed. :-)
Comment #15
Gravypower commentedIt seems that this change has started to cause some notices and warnings to show for me.
I believe that the issue has some roots in the fact I am using workbench moderation so am not 100% sure which module is causing this issue. However I was wondering if there was any reason why a test to see it the '#attached' key exists before accessing the 'library' key.
something along the lines of
thoughs?
Aaron
Comment #16
Gravypower commentedHere is a patch with my idea.
Comment #17
dsnopekThanks!
A couple things:
isset()is easier to read and fits in with other Drupal code better thanin_array(), for example:isset($build['#attached'])I'm looking forward to the new issue and patch ;-)
Comment #18
Gravypower commentedI have created a new issue (2760051) as per direction of @dsnopek and posted new patch there. Thanks for your reply.
Comment #19
Gravypower commented