Tag Archives: Developer Toolbar

Embedding your JavaScript into a SharePoint page

A very typical approach for client side development in SharePoint is to throw the code onto the page where you need it. You can alternatively put into the master page, but generally speaking, most code doesn’t need to run on each and every page. The following describes my preferred, tried and true, method of handling this.

Upload the Assets

Say you have some great JavaScript code provided by a developer or blogger, and you want to now use it on your page. First things first, get the JavaScript into your SharePoint site!

Upload the JS file into a library. I generally use SiteAssets, with a small folder structure for organization, like SiteAssets\js, or if there is more, sometimes like SiteAssets\webparts\mywebpartname.

Once the JS is uploaded, we now need a HTML file to reference it. This can be pretty simple HTML file. You can create it on your desktop (create a new text file, and rename the extension to .html) or using SharePoint Designer, you can create it directly in SharePoint. Throw it in the same place as your JS file, or however you have your assets structured.

As an example, we’ll take a block of code from one of my blog posts, we’re going to throw the necessary HTML and JS into the HTML file you created, something like:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js" type="text/javascript"></script>
<script src="/SiteAssets/Lozzi.Fields.js" type="text/javascript"></script>

<script type="text/javascript">
Lozzi.Fields.disableWithAllowance("Start Date", ["Project Managers"]);
Lozzi.Fields.disable("Task Status");
Lozzi.Fields.hide("% Complete");

This is all the HTML and code needed to run the JS I’m working with. Notice Line 2, the second <script tag. This is the path to the JS file you uploaded into SharePoint. Make sure the path is correct. This block of code above will differ for each and every JS example you work with.

Once the HTML file is saved, navigate to it through your browser and copy the link to the HTML file. You can do this simply by clicking on the file’s ellipses, the …, and copy the URL from there

copy file link

Embed in SharePoint

Ok, now that we have the JS file uploaded, and a HTML file created, let’s embed it in SharePoint! This is the easy part.

Navigate to the page you want to use this code on. Just use your browser and click to go to the page, pretty simple so far right?

Now edit the page: click the cog in the top right and select Edit Page

edit page

Once the page is in edit mode, click Add a Web Part button at the top of a zone, it doesn’t matter too much where. If you don’t have an Add a Web Part button, you’re probably using a wiki page, so click anywhere in the content area where you want add a web part, then click Insert Web Part.

add content editor web part

In the Add web part ribbon, select Media and Content on the left, and then select Content Editor. Click Add to add to your page. You should have something like:

added content editor web part

Notice the Content Editor web part added. Now click the web part, in the top right, and edit the web part.edit web part

In the tool pane on the right, paste in the URL to the HTML file. Click OK.

past html link in content editor

Afterwards, your content editor web part may look empty, or you may see some of your HTML, it depends on what you’re working with. My example, I’m just using JavaScript to hide fields on my page.

save content editor

Save the page and you should be good to go! Your code should fire off and you should see things happening. If not, if you question what’s going on, try using the developer tool bar in your browser, more on how here.

A couple of notes:

  • You may want to modify the Content Editor Web Part’s Chrome Type setting to hide the title from view
  • If you receive the error “Cannot retrieve the URL specified in the Content Link property. For more assistance, contact your site administrator.”, check the URL you’re pasting in. SharePoint can’t find it, make sure it’s valid. Paste it into a new browser window and see if downloads the file.
  • Make sure to structure your JS and HTML files well, you never know who’s going to look at it next.
  • Consider using the URL to the HTML file as a relative URL instead of a absolute URL. How? Consider the following URL is an absolute URL: https://sharepoint/sites/sitename/siteassets/myfile.js. Make it relative by dropping the first part: /sites/sitename/siteassets/myfile.js. This will keep it a wee bit more flexible and migrations in the future should be a little easier.

‘Til next time, Happy SharePointing!


Before you make SharePoint Public – 2 more times

I wanted to quickly share on two more options for you to listen in on my session Before you make SharePoint Public.

SP24 is reairing all of their sessions, this Wednesday and Thursday, May 14th – 15th. My session will be run Wednesday night, at 9pm EST. I hope you can make it. Check out the wrap up from my first session here.

I am also presenting this session live at the Connecticut SharePoint User Group on May 15th. CTSPUG is hosted at 100 Pearl Street in Hartford, CT, check out their site for more details, www.ctspug.org

I hope to see you there!

We all know what IsDlg does… wait, what the…??

Here’s a little nugget I came across, on SharePoint 2010 and 2013 (including O365), and was exceptionally frustrated with. There’s a difference between IsDlg and isdlg. See it? Case sensitivity. Come to find out that means the world to SharePoint.

I was tasked to setup a basic Page Viewer web part to consume a page from another web. Simple enough. I threw the URL into the web part, including IsDlg=1, and blamo, I got my page. However, I couldn’t scroll the web part. The page I was using was longer than the web part, which would normally cause the page to scroll, but alas, not in this web part.

Enter the IsDlg parameter. Don’t know what IsDlg is? It’s a little query string parameter that SharePoint uses to hide elements on your page using CSS. Have you noticed that if you enable the dialog on a list, and the forms then appear in the dialog window, that the header is missing? The left nav too?

Dialog Window in Use

It’s the same page as if you didn’t use the dialog setting, Microsoft isn’t crazy enough to have two versions of a page that does the same thing. Instead when the IsDlg parameter is sent to the page as a parameter in the query string, it hides everything on the page with a CSS class of s4-notdlg.

Here’s what the URL may look like:


Note the IsDlg=1 at the end. I’m a big fan in questioning everything, so let’s try it out for ourselves.

Go to a display form of a list item, which is not in a dialog.

A Normal Display Form

and add &IsDlg=1 (case sensitive) to the end of the URL, hit enter.

Display Form with IsDlg=1

See how we lost the top header and left nav? Looks like the dialog up above, right? Pretty cool eh? So, as you may be thinking, “this is awesome, I can use this in the page viewer web part too”. You would be correct in your thinking! Here’s where things get a little fishy.

When you use IsDlg (again case sensitive), SharePoint does NOT scroll the window if the window requires it. Again, give it a whirl. Take your window you used above, and resize it so it’s nice and small, put the Close button below the bottom of the window.

IsDlg missing scroll bars

See? The close button is below the window, but there’s no scroll bars. If you change the IsDlg to isdlg, then you get a happier page.

Scroll bars come with isdlg

Whew, there’s our trusty little scroll bar, now I can press Close.

Let’s dig deeper: core.js

Why is this happening? Well I dove into the JavaScript that handles it, in the core.js file, there are several lines of code which look similar to:

isdlg = (ajaxNavigate.get_search()).match(new RegExp("[?&]IsDlg=1"));

JavaScript is very case sensitive, so it’s actually, and quite specifically, looking for IsDlg, not isdlg. Weird right? So if you send the page IsDlg, SharePoint forces the size of the window and disables the scrolling. If you send isdlg, SharePoint does nothing with it except for hiding the CSS elements (as we discussed earlier). Your browser’s native capabilities kick in and scrolling occurs.

This is great for the dialog interface SharePoint is use to as they will size with the page. Now the user is scrolling the entire page and not just the page within the dialog. This is annoying for us if we want to use IsDlg feature elsewhere and we want to scroll just inside the web part. We have to use the isdlg option instead.

Oh yeah, I confirmed this occurs in Internet Explorer, FireFox and Chrome too ;)

‘Til next time, Happy SharePointing!

A Non-Developer’s Intro to the Developer Toolbar: Other Cool Stuff

This is part four of my mini-series, part one covered element inspectionpart two covers scripting and part three covered performance.

In this, my final post, I will cover some of the other neat things the developer toolbar does for us. I may get a little deeper than a non-developers point of view. All of the items below live in the menu of the toolbar


Link Report

Click the View menu, then Link report.

Link Report

This neat little report tells you all of the links on the current page, and how they’re accessed.

Image Report

Click the Images menu, then image report.

Image Report

This report includes all of the images on the page, along with loads of data about the image, including sizes.


Pronounced cash, but has nothing to do with money. Cache is a local temporary storage location for assets like images and scripts, and allows your computer to use the local version instead of the server version, which is faster. However, cache is also a frequent headache dealing with web pages. Hopefully your developers and support teams never said “you need to clear your cache”. If they do, you can do this from this menu. Select Clear browser cache… from the Cache menu.

Resize your Browser

You can resize your browser to some of the standard dimensions. Click the Tools menu, then click Resize and select your size. Why would you want to do this? One, you can see what the page looks like for users with a lower resolution than yours. Two, basically an extension of one, is if you’re dealing with responsive web design, you can see what your tablet would see when the browser is reduced to the tablet size.


Click Tools menu, then Show Ruler.

rulerA neat little tool to size up anything on the page. Not sure what a non-developer would use this for, but hey, it’s cool anyway.

Don’t be afraid to explore

I think that should do it! The developer toolbar, though named and targeted to developers, has some nice resources for non-developers. Don’t be afraid to explore and try out some other stuff. Have fun and harass your developers, they’ll love it.

A Non-Developer’s Intro to the Developer Toolbar: Performance

Sorry for the delay in getting this last post in, it completely skipped my mind. This is part three of my mini-series, part one covered element inspection and part two covers scripting.

In this post, we will look into some of the performance tools available to the developer toolbar in Internet Explorer. This will allow you to assess your SharePoint site, and see where some of the slow points are.

Let’s get the developer toolbar open, press F12.


Profiler assess the scripts and functions running on the page. Out of the box, there’s a ton running, and there’s little we can do about it, it’s all SharePoint. If you have some custom pieces in your site, especially those using client side development, then this tool may be of use.

Click the Profiler tab, then click Start profiling button. This may hang for a little, just give it a little time. When it’s ready, the button will change to Stop profiling. Reload the page now. Once the page has fully reloaded, click Stop profiling. You’ll then see your results.

Developer Toolbar Profiler

The results will show you which functions in the client code are taking the longest. Sadly, a lot of them are SharePoint’s, and we can’t do much about it. You’ll see a lot of functions that may be confusing in name, like ‘Anonymous function’.

  • If you sort by the Function column, you can find your functions a little easier.
  • Sort by Inclusive Time to find the functions that took the most time, including child functions. Exclusive Time is the time it took for that one function.
  • Doubleclick a function and it should send you to the Script tab, if it can find the function for you.


This is the real fun one, and gives us more direction on what’s going on. Click the Network tab, then click Start capturing. Reload the page and you’ll see results immediately.

Developer Toolbar Network

This tells us what took so long to download, from scripts to CSS files to images. You can sort by the Taken (time it took to download) or Received (amount of data) columns to see which items on the page took the most time. Normally, the page itself, in my case home.aspx, took the longest. This is because this page contains all of the HTML markup you see. Rarely is there something that can be done about this size, other than if there are custom web parts spilling out extraneous markup.

This tool will tell you if there is a large image or script/CSS file that’s taking long to download. You can take this data back to your developers and complain about the long times. They may have a shocked look on their face when you report this to them. Have fun with that ;). Large assets like images and script files can be optimized and minified to improve download speeds.

My next post will be on some of the other neat tools and advantages in the Developer Toolbar.

Til then, Happy SharePointing!