Custom Lookup
Recently a client of ours needed to filter the options on a lookup in a way that wasn’t possible with out-of-the-box features. So, we needed to write some JavaScript to meet their requirements.
The desired interface was to replace the existing lookup control with a drop down interface that also included searching capabilities. Rather than reinvent the wheel, we decided to use a jQuery plugin that Power Pages already leverages: Select2. All we needed to get where we wanted to go was some custom JavaScript, along with a bit of Liquid and FetchXML to generate the list of options we wanted to present.
With development done, off it went for testing. At first, all was well. Then we started to get spotty reports of it not working for some testers. We confirmed that yes, it wasn’t loading properly for some people, but for most of the testers, it worked perfectly fine. For those that it wasn’t working for, client-side console errors complained about the Select2 plugin not being loaded properly.
Why would the plugin load fine for some users, but not others? We eliminated obvious things like browser differences or network problems. Since the error messages were related to Select2 not being loaded properly, we even tried including the library manually in the head of the page. Still no luck for those certain people.
This was the point where the issue got to my desk. I wanted to see the issue for myself, so we jumped on a call with one of the people who was experiencing the issue, and after a few minutes of screen sharing, we stumbled upon the difference between the people it worked for, and the people it didn’t: the Administrators Web Role.
Why Being an Administrator Matters
Why would the Administrators web role matter in this situation? Because, as I mentioned before, Power Pages uses the Select2 jQuery plugin, but only in the legacy front-side editor. Anyone logged in as an administrator had the Select2 plugin loaded properly by Power Pages, and those who did not, were missing it.
But, I did say that we suspected that might be an issue, so we included a reference to the plugin ourselves in the head of the page. Why didn’t that work? Because as a jQuery plugin, Select2 must be added to the page after jQuery itself is included. jQuery isn’t included until lower down in the page.
Where Is jQuery Exactly?
If you look at the source of the page, you won’t find a direct reference to jQuery. This is because jQuery is included in a bundle of JavaScript.
Look for a file with a name like preform.moment_X_XX_X.bundle-XXXXXXXXXX.js. As of the writing of this post, the filename look something like preform.moment_2_29_4.bundle-4fdd3f639b.js.
This bundle is included in the page below the Header Web Template, but above the main content of the page. As I mentioned in my blog post five years ago, this means that jQuery doesn’t exist until after both the <head> element of the page (where we tried to put it), and the Header web template. So if you need to include a reference to JavaScript that depends on jQuery, you need to do it after that.
So what options does that leave us with? The two most common options I see are:
- In the content (HTML) of the web page or a Web Template used in a Page Template – this is useful if you only need the code on specific pages
- You can use the Tracking Code Content Snippet, which is included near the closing </body> tag – this is useful if you want it included on every page
So, in addition to now knowing where jQuery is included automatically in Power Pages, hopefully you’ve also learned the lesson about making sure to test without being logged in as an administrator (even though as Power Pages developers we want this role so we can refresh the cache)!