AllAnnouncementsApps & WidgetsCMSDesign & ThemesDocumentationEmployee CenterNow ExperienceTips & TricksTutorialsUncategorizedVideos

Bootstrap Dropdowns in Fuji

I've been getting a lot of email lately about Bootstrap dropdowns no longer working in Fuji. Even some of the old JavaScript solutions that seemed to resolve the conflicts between Prototype.js and Bootstrap.js no longer seem to be working in Fuji. The issue is being worked on and hopefully should be resolved in an upcoming patch, however until then I offer this simple, hacky but working solution: [crayon-6623879c4e04f728626936/] In the few cases where I have tested this, it seems to resolve the problem and dropdowns go back to working as usual.

ServiceNow CMS issues in Fuji

If you have upgraded to Fuji you might have discovered that it caused some issues with your CMS portal. The main issues being: A modified version of Twitter Bootstrap is already included Not all UI scripts execute The version of bootstrap that is included has some changes to it (such as modified media queries) that can cause some negative side effects to your site. The good news is that it can be disabled by creating a system property called "glide.ui.heisenberg.exclude" and setting it to "view_content". Once set, you will need to include your own version of Bootstrap if needed. The issue with UI scripts will be fixed in Fuji Patch 2, however the work around is to include empty script tags (<script></script>) in front of all your existing <script> tags. The issue is that it is skipping every odd numbered script tag. Example: [crayon-6623879c4f77a958153308/] Only alert 2 and 4 would be executed. So until you are able to upgrade to Fuji Patch 2, the solution is to include the extra script tags.

Custom Content Block Types

This is one of those secrets I wish I would have discovered years ago because it really opens a world of possibilities within the CMS. This method was revealed to me by Brian Alson. There's a few other ways of creating custom blocks types like this, but this one is by far the easiest. If you're creating a block that will contain "child" records, such as a slideshow, then I would suggest extending the child table from "content_link" table and either create a M2M table or a parent reference field back to the content block. I would love to hear your comments or feedback if you guys find this useful.

CMS Dynamic Edit Page Button

Jumping between the page preview and the page editor is always a pain. Even with multiple tabs I always seem to loose the edit page screen, so I've created this UI Macro which puts a "Edit Page" button on every page. When editing a page it changes to "View Page". Hope you enjoy and let me know if you find this useful. Create a UI Macro with: Name: "render_cms_edit_button" XML: [crayon-6623879c50382638656326/] Insert the content block in to your site layouts at very bottom using [crayon-6623879c50389918551899/]

Modifying UI Pages & Macros without affecting upgrades

In the Wiki you will find solutions that include updating OOB Macros or UI Pages, however this will obviously cause those files to be skipped during the next upgrade. So how do you go about updating UI Pages and Macros (or other records) without future upgrades being impacted? The answer is actually quite simple. I discover this little nugget in the Wiki: By default, the Active field on a tracked table is treated as update_exempt even if the attribute is not present (starting with the Calgary release) This means that if we clone the original record, set the original record to "active=false", then we can continue to make changes to the copy record without affecting the upgrade process. The only thing to note is after an upgrade you will want to check the difference between the files so in the event there was a change, you can manually upgrade your updated record.

UI Pages without all the extra platform HTML

If you create a empty UI pages you will notice that without anything on the page, the platform has already loaded in a ton of platform code including JavaScript (js_includes), CSS (css_includes), as well as quite a bit of HTML. If you are looking to build a page that includes jQuery, Angular, Bootstrap, or other JavaScript or CSS library, chances are you will run into a conflict. The following trick was originally brought to my attention by Will Leingang, who recently wrote a blog post about it. However because I think this is a very important trick to know, I am going to post it as well. The solution is to append "?sysparm_direct=true" to the end of the URL (after .do). Before: After: This method technically also works for CMS pages, however because CMS pages also load some additional javascript files to the page, if you remove the framework template you will get several JavaScript errors. There are some ways around this as well but require overloading some platform files, so that will be beyond the scope of this blog post.

Using UI Pages in a CMS Site without iFrames

This may not seem so exciting at first, but once you realize the potential of this technique the results can be pretty powerful. It's no secret that a lot of content in ServiceNow's ESS Portal lives inside iframes. I don't want to get into why iframes suck or why having UI Pages and forms from the main interface showing in CMS is not ideal... so I'll just assume you've used it enough to understand why it's a problem. This is far from a complete solution, but it highlights one technique that could be used to get rid of those pesky iframes as it pertains to UI Pages. One of the challenges is that UI Pages usually need to live in both the CMS and the main interface. So the trick is to figure out how to distinguish between the two. The answer to that is in the URL that is used. If you visit: [instance]/kb_home.do it's loading the UI page as normal. However if you insert "ess/" in front of the ui page name ([instance]/ess/kb_home.do), it will also load in the style sheets from that CMS site. The "ess" refers to the "url_suffix" field on the site. It will also populate a new variable called $[current_site], which really is the GlideRecord of the site record based on the url_suffix. What this allows us to do is distinguish between different sites and the main UI. Consider the following code: [crayon-6623879c52020583690793/] In this example, if we had a header defined in a UI Macro included on our site, we could now also include that header (or footer, or custom markup) on any UI page when used with our site. This essentially removes the need for using iframes. Now it also opens up another can of worms, such as: instance upgrades, and modifying OOB records. However in my personal experimenting I have been able to use this method to bring the full service catalog and knowledge base into a CMS site, without using any iframes, and without causing upgrade issues. It does take some tinkering, but it's doable with a little bit of work. To start I would definitely suggest cloning the UI pages and experimenting with the copy. With this method we're really just styling UI pages to look like a CMS site, there are many other ways of doing it and I've experimented with several with great results. However this method is fairly quick to get you started. I'd love to hear your feedback, and let me know if you have any questions.

Building a Responsive ServiceNow ESS Portal with Twitter Bootstrap – Part 1

When I first started building portals on top of ServiceNow, one of my first goals was to try to make a responsive site using Twitter Bootstrap. After several attempts I realized it's not quite as simple as it sounds. In the next series of blog posts I will cover some simple steps to help get you started. In this post I assume you are at least familiar with Twitter Bootstrap and the ServiceNow CMS. Some of the challenges with the content management system (CMS): The out-of-box (OOB) ESS portal is full of tables, iframes, and inline styles. Bootstrap uses jQuery and ServiceNow uses Prototype and the two don't always play nicely together. The HTML markup cannot be changed for many of the content blocks. The site header/footer and layout is defined on the page itself, not the site Because ServiceNow is a platform, most issues can be solved with a little bit of coding. However for the sake of simplicity, I am going to use just the OOB CMS functionality. For part 1 of this series, I am going to cover replacing the header of the ESS portal. I will use some of the sample templates provided by Bootstrap (http://getbootstrap.com/examples/jumbotron/). Let's get started: Navigate to "Content Management > Dynamic" and create a new block. Copy paste the below html into the content block (within the <jelly> tags): [crayon-6623879c531c4402830811/] Save it, and grab the sys_id Now lets go into the site and create a new layout using the following html (within the <jelly> tags): [crayon-6623879c531cc417272151/] Next we will need to create a new page to try out the Bootstrap layout. Fill out the basic information and select the newly created layout from the layout field. From the page, create a new "Content Theme" In the "Style Sheet" related list, click new. Select "Link to External Style Sheet" from the drop down and paste this URL into the URL field: "//maxcdn.bootstrapcdn.com/bootstrap/3.3.2/css/bootstrap.min.css" and then submit. From the related list also bring in "Gray CSS - Menu". Go back to the page and click on "Edit Page" and then "Add content", now place two content blocks on to the page, I used "Portal - Block Menu" and "KB Top Five". If you did it all correct you should have a page that looks like: This is just a starting point, and we still don't have JavaScript and the portal is still using ServiceNow's table based blocks. But these will be covered in our next blog post. Hope you have enjoyed this tutorial and if you have any questions please, don't hesitate to post a comment.