The branding process in Slate can be implemented so that your Slate public-facing pages closely resemble your institutional admissions web page.
Below are some popular topics related to Slate branding.
Side Navigation Bars
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.
Removal of Dynamic Features, Search, and Embedded Forms
Search boxes that use embedded forms can also be sources of conflict with Slate’s form functionality and should be removed from pages in the branding process.
Your institution 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 your Slate test environment before moving any code to the production environment.
For additional information, please see Test Environments.
Any custom scripts or other non-Slate code must be maintained by your institution, and we cannot guarantee support of the custom code if problems are encountered.
Editing branding files
In Slate, two files 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 thoroughly testing all edits in your Slate test environment before 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.
CSS file caching
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.
It is best practice for a Slate database to have one build.XSLT and one build.css file where the custom branding styles are stored. Conditional branding can be created within a database. This article on Conditional Branding may prove helpful with a general overview and a few examples.
Mobile Device Branding
The mobile view that is implemented is Slate's default mobile template. This template ensures that Slates content is rendered consistently across all mobile platforms.
We strongly recommend testing all Slate pages in your Slate test environment before enabling mobile branding in your production environment to ensure content is rendered as expected on all platforms. This will allow you to revert to Slate's default mobile template and ensure your users have uninterrupted access to your instance of Slate.
Override Slate’s default mobile view and utilize your institutional branding:
Analytics in Slate Pages
For additional information, please see the Embedded Google Analytics.
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 icon. You may be able to open an incognito window after the 15-minute mark to see the new icon.
Need a Favicon Image? A Favicon is a small 16x16 icon that displays next to the URL of your site in a browser's address bar. To get your school's favicon, use this link: http://www.google.com/s2/favicons?domain=www.example.org and replace www.example.org with your institution's site.