Technolutions uses a branding tool that takes an existing site's URL and copies the site's images and styles into files that are saved to your Slate instance to create your Slate branding. By maintaining separate branding files that are not linked to files on your site, it ensure that changes to your institutional website will not cause unplanned changes to the Slate branding.

For more information, review Branding Bookmarklet.

Right and left hand side navigation elements are not supported in Slate branding.  Slate's content size will vary depending on which Slate page users are viewing and this content will not be able to fit on a page with sidebars. 

Any features that depend on JavaScript, such as menu pop-ups, often conflict with Slate's programming and are removed in the branding process. If an institution has a web development resource that can provide a template that uses CSS to replace this functionality, or otherwise does not use a JavaScript framework like jQuery, we will update the branding using the non-JavaScript template. 

Search boxes which use embedded forms can also be sources of conflict with Slate’s form functionality and are removed from pages in the branding process.

You can edit the Slate branding as desired.  If you choose to implement custom code within your Slate branding, please note that we cannot predict how your custom code will interact with Slate's code. ALL Slate pages should be tested thoroughly in the Slate test environment prior to moving any code to the production environment. Any custom scripts or other non-Slate code must be maintained by you and we cannot guarantee support of the custom code if problems are encountered.  

For additional information, please see Test Environments.

In Slate, there are two files that govern how your public-facing pages appear - build.xslt, which lays out the structure of the page and build.css, which holds the styles that will be applied to the build.xslt.  We strongly recommend testing all edits thoroughly in the Slate test environment prior to moving any code to the production environment as errors in these files may cause your external pages to become unavailable. 

To view and edit these files, navigate to the Database page in your Slate instance and click File Editor under the Configurations section.   

The css files are cached on the server and therefore changes made to build.css will not be immediately visible. To force an update to the file cache, edit the build.xslt file and update the version parameter in the reference link to the build.css file:

<link href="/shared/build.css?v=20151203192252" rel="stylesheet" />

Update the timestamp which will trigger a change to the file version.   Please note that you need to allow up to 15 minutes for the file to propagate across all production nodes, and you may need to wait a bit longer (up to 24 hours, possibly) for your browser to expire the cached files.

Every Slate instance has one build.xslt and one build.css file where the custom branding styles are stored. Embedded forms can be used to customize different registration pages.

Using an embedded form enables you to insert a form into an institutional web page.  The styling of the form will match the page it is embedded into.  The forms will not produce any style of their own when using this method.

When using Slate’s "Embed Form" code from the Edit Form page, Slate uses the