KB article breadcrumbs show "%short_descr" instead of article short description
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
I am encountering a weird issue with breadcrumbs in KB article. It shows as below :
Home > Category > Knowledge Base name > %short_descr
It should be ideally showing the KB article short description at the end.
This issue occurs only for one of our custom portal with custom theme and it works as expected in other custom / OOB portals. There aren't any modifications done to the OOB Widget and the root cause of the issue is that the dynamic page title adds the value "%short_descr" as a placeholder and it never changes.
In console, when I checked the "document.title" it reflects the correct value. Now i feel like it might be a timing issue of some sort.
I also checked removing the dynamic page title from kb_article_view widget (OOB) and its not changing anything on this custom portal but affects other portals (last part of the breadcrumbs is empty).
Appreciate any insights to the issue. TIA.
Ashwin
- Labels:
-
Tokyo
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
41m ago
Breadcrumb widget is capturing document.title before the kb_article_view widget's server script resolves and replaces the %short_descr token. The fact that document.title eventually shows the correct value in the console confirms it — by the time you check manually, the async resolution has completed, but the breadcrumb already rendered with the stale placeholder.
Here's why it only hits your custom portal:
Root Cause: Custom Theme Rendering Order
The theme controls the shell HTML and Angular bootstrap sequence. Your custom theme is likely causing the breadcrumb widget to initialize and read the page title before the kb_article_view widget completes its server-side data fetch. OOB themes and your other portals happen to have a widget rendering order where the article widget resolves first.
Things to investigate:
The page layout and widget instance order on the kb_article page for that specific portal matters. Widgets in earlier containers/rows generally render before later ones. If your breadcrumb widget sits in a container that renders before the article body, it grabs the unresolved token.
Check your custom theme's JS includes and Angular run/config blocks. Any additional scripts, custom Angular directives, or $rootScope watchers in the theme could delay the article widget's digest cycle relative to the breadcrumb.
Recommended fixes (least invasive first):
- Clone the breadcrumb widget for this portal and add a
$rootScope.$watchon the page title so it re-evaluates after the token resolves:
// Client script of cloned breadcrumb widget
$rootScope.$watch(function() {
return document.title;
}, function(newVal) {
if (newVal && newVal.indexOf('%') === -1) {
// rebuild the last breadcrumb segment
c.lastCrumb = newVal;
}
});
-
Use
$timeoutin the breadcrumb client script to defer readingdocument.titleby one or two digest cycles — even$timeout(fn, 0)may be enough to let the article widget's server response land first. -
Check the
sp_pagerecord for thekb_articlepage tied to this portal. Verify the dynamic page title field value is identical to the one used by your working portals. Sometimes a subtle difference in the token syntax or extra whitespace causes resolution failure. -
Look at the theme's
<sp-page />directive placement in the theme's HTML. If there are wrapper directives orng-ifconditions around it in your custom theme that aren't in others, those can shift the Angular compile and link phase timing for child widgets. -
As a longer-term fix, emit a custom event from the
kb_article_viewwidget's client script after the title resolves ($rootScope.$emit('article.title.ready', title)) and listen for it in the breadcrumb widget. This decouples the two from relying ondocument.titletiming entirely.
The most common culprit I'd check first is the widget instance ordering on that portal's kb_article page — simply reordering so the article widget is in an earlier container than the breadcrumb can sometimes resolve it without any code changes.
