Reference library

Sitekit CMS Help» Reference library» Building and developing» Managing Scripts
Article number: 303784

Script Manager

The script manager, introduced in Sitekit CMS 10.2, provides an area in admin where you can order edit and apply your scripts and their associated CSS to your site. As third party scripts are increasingly used in modern sites to provide content editors, slide-shows, interface effects and analytics there is a requirement to prevent script interference and duplication, reduce page size and so to increase page speed. It allows you to do the following:

  • Add edit and delete scripts both as references to files and as code blocks.
  • Manage dependencies between scripts.
  • Specify where on a page each script should be placed.
  • Group resources needed for specific functionality into script groups.
  • Avoid duplication of script calls in pages.

In this page we'll go over the admin interface for the script manager accessed under 'Build > Scripts'. When you first enter this section it will already be populated with any scripts and CSS blocks your site currently uses for specific Sitekit functionality (related to forums, and forms etc) however it is a good idea to see if your site needs more specific scripts added to the manager to prevent conflicts, this example shows you how. It also includes the site wide welcomestyle.aspx CSS reference (10.4)

Script commandments

The following are the cardinal rules of script management usage and need to be applied to get the maximum advantage from it. Existing sites are likely to need conversion to the new method if script clashes occur.

  1. Each included framework, script or plug-in requires its own script group.
  2. The script group should include all JS and CSS files that constitute that plugin BUT NOT scripts that belong to other plugins/frameworks.
  3. Dependencies should be added to show which other script groups a group requires. e.g. JQuery-UI consists of a script file and a CSS, so they go in the JQuery-UI group; JQuery-UI needs JQuery, so it has a dependency on JQuery.
  4. Pre-defined script groups are automatically included on pages where the Sitekit front-end needs them, e.g. for the doc-finder, location picker and date-picker. These are handled automatically and you don't need to consider them.
  5. When a script group is included in a page, all script groups it depends on are also automatically included.
  6. The script manager ensures that no script is ever included twice.
  7. Script groups can be manually included using the magic word syntax : :::include-script-group-name::: [where script-group-name = name of script group].
  8. It doesn't matter how many include statements appear on a page, the script will only ever be inserted once, so you should always precede each use of a script with an include.
  9. You do not need to manually include every dependent script, they will be included automatically, e.g.:::include-jquery-ui::: will automatically include JQuery.
  10. The Script Manager provides precise control of the ordering that script will be included on the front-end and allows management of scripts, groups and dependencies.
  11. You can change the paths of any scripts or delete them, so if you want to move JQuery onto a CDN, you simply change the path in the script manager. You can replace scripts with your own custom ones in the same way or you can simply remove them, in which case they won't be included front-end.

From now on, all script includes for a site should be done by putting the above magic word or its variant into HeadSectionHTML Variable-Block, rather than referencing the script directly unless a script has limited scope. If an included script is only needed in a very small scope then the include statement can be placed immediately before it is used. e.g. say in a body block on one specific page, you wish to use a bit of JQuery script then you can do the following in that body block:

<script type="text/javascript"> $(document).ready(function(){alert('Hello World');}); </script>

The Registered scripts table

The table has five columns and allows you to Add (at the bottom) Edit, Delete and View all the scripts in use in your site. It also allows you to drag and drop the scripts, changing their order of execution on the page. This is important because web pages parse from top to bottom so some scripts need to be executed in the correct order.

Script manager table

Each of the table entries can be edited or new ones added at the bottom and then dragged to the correct location. As you can see the 'position' column reflects a typical top to bottom page render. When you edit an existing script you see the following.

ScriptManager4

Going through each of these in turn:

  • on - allows scripts to be switched on/off, so that they can be removed from the front-end without having to delete them from the script manager (added in 10.3)
  • Group name - each script or css section needs to belong to a group. You should group things together that belong to the same plugin.
  • Path or block - the registered script table allows you to enter the path to previously uploaded files or paste the content in directly. 
  • Type - there's five options
    • CSS file - the path to an already uploaded css file in the asset tree or an absolute address to an externally hosted file
    • CSS block - insert a syntactically complete block of css
    • JS file- the path to an already uploaded js file in the asset tree or an absolute address to an externally hosted file
    • JS block -  insert a syntactically complete block of js, or minimised js
    • No script block -  insert a syntactically complete block of html for users that don't run script
  • Position - The script will be put in one of these locations on the page:
    • Head - just before the closing </head> tag.
    • Bodystart - just after the opening <body> tag.
    • Bodyend - just before the closing </body> tag.
    • Inline* - at the position of the 'include' magic word (added in v12).
  • async - HTML 5 script loading/execution attributes and are only relevant to JS files. A warning message will be shown if the user tries to switch them on for other types of script. (added in 10.3)
  • defer - HTML 5 script loading/execution attributes and are only relevant to JS files. A warning message will be shown if the user tries to switch them on for other types of script. (added in 10.3)
  • SRI - subresource integrity makes script more secure When a script has an integrity value specified then it will automatically be included in the script reference in the front-end markup with cross-domain set to anonymous.Browsers will block the execution of scripts whose integrity is compromised and show a message in the console.(added in 11.1)
  • Edit, delete, view - these are self evident, view pops up the file in a new window.
  • SRI for invoking SRI, it calculates the integrity hash for a script file and automatically insert it into the SRI column above

*When a script is 'inline', the script will be inserted wherever the 'include' magic word appears in the page. It will be inserted without wrapping '<script>' or '<style>' tags, so these must be included within the script itself if required. (added in v12)

Script groups

This allows you to create or delete existing groups, you should group things together that belong to the same plugin but not scripts that belong to other plugins.

ScriptManager2

Dependencies

If a plugin or framework makes a reference to a script belonging to other plugins then this should not be added to the group but instead added as a dependency. The most common one of these for most plugins is the main JQuery library as shown below.

ScriptManager3

 

 

Related questions