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.
I have accepted an offer to come back to ServiceNow and join the UI team, focusing specifically on CMS. I'm very excited and humbled by this incredible opportunity. Now this is where I could really use your help. Below are 3 questions regarding your experience with CMS, if you could take a moment to provide some feedback I would really appreciate it. You will help in shaping the future of the ServiceNow content management system. With the existing CMS, what are some of the biggest pain points and frustrations? If ServiceNow were to build a new CMS, what would that look like and what features would you like to see? How important would a mobile portal be for your organization and users?
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-5d0bc22886b1f818894819/] Insert the content block in to your site layouts at very bottom using [crayon-5d0bc22886b3b692102243/]
This is Part 2 of my ServiceNow CMS + Twitter Bootstrap series. Below are the code examples you will need as explained in the video: cms_menu: [crayon-5d0bc22889454446401293/] cms_menu_bootstrap_nav [crayon-5d0bc2288946a258179184/] Layout Includes: [crayon-5d0bc2288947d765138093/] jQueryFix: [crayon-5d0bc22889489678651848/]
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.
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-5d0bc2288c3a4926726797/] 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.
The "content_page" object is a scriptable java object called 'GlideContentPage'. In a script you can simply do: [crayon-5d0bc22891575172443139/] Which will get you access to the following functions: getSiteID getID getURLSuffix getParentPage getName getDescription getMeta getTheme isValid getTitle getModelTable getModelID getDefaultLayout cloneable isFrameBuster