Transforming UB’s digital communications.
If your site uses custom HTML, CSS, or JavaScript, the NextGen template rebuild affects how that code behaves. This page explains what changed, where your code might be living, and how to get it organized during your conversion.
NextGen is a complete rebuild of UBCMS templates. The underlying HTML structure, CSS selectors, and layout system are all updated — which means code written against the old templates may not work as expected after conversion.
The most common issues are CSS rules that target selectors that no longer exist or have been renamed. JavaScript that relies on specific DOM structure may also break if that structure changed. The Selector Change Log documents the specific changes.
For most sites, the impact is cosmetic — layout adjustments, spacing, visual styling. Functional breakage (forms, interactive elements, JavaScript-driven behavior) is less common but worth checking carefully.
Custom code in UBCMS can end up in several places. Before you start fixing anything, it helps to know where to look.
The design area is the cleanest home for site-wide CSS and JavaScript. UBCMS automatically includes main.css and main.js from this location on every site page. Any additional files you've added here need to be explicitly imported or called — either via a reference in main.css or main.js, or directly on the pages that need them.
HTML Snippet components can hold custom code on individual pages, or they can be stored in the Shared Content area and referenced across multiple pages via a Shared Content Reference component. A snippet in Shared Content that's referenced on 200 pages only needs to be updated once — a snippet copied individually to 200 pages needs to be updated 200 times.
Page Properties includes an Advanced tab with a Head Content field. Code placed here is injected into the <head> of that specific page. It's easy to lose track of, since there's no central view of which pages have Head Content populated.
Your site report's Fix Outdated Code tab is your starting point. It flags any code referencing outdated selectors and shows you exactly where that code lives — whether it's in an HTML Snippet, Head Content, or the Site Design area (/etc/design/). That's your working list for Step 2.
The Review HTMLSnippets tab gives you a broader picture — it lists every page with an HTML Snippet component, not just ones with outdated code. That's useful if you want a full inventory of where snippets exist across your site, beyond what's flagged as outdated.
While you're updating your code in Step 2, it's worth thinking about where that code ends up — not just whether it works. If your code is currently scattered across individual pages in Head Content fields or copied snippets, consider consolidating it as part of this process rather than making the same fix in dozens of places.
The goal is code that lives in /etc/design/ for site-wide styles and scripts, with HTML Snippets in Shared Content for anything that needs to be referenced across pages. When everything is centralized, you're making one update that cascades across many pages, rather than updating many pages.
You don't need to achieve this perfectly during conversion. But plan to clean out any old scattered code after your site goes live — leaving duplicate or outdated code behind will create maintenance problems down the road.
The help desk doesn't provide custom code support. Your customizations are yours to maintain. The Selector Change Log, CSS/JS Migration Tips, and Testing Custom Code pages are there to help — but implementation is the responsibility of the site team.
If something isn't working and you're confident it's not your custom code, report it using the feedback form.