Steps to replicate the issue (include links if applicable):

• On a wiki with HeaderFooter installed, create MediaWiki:Hf-nsfooter- (or any hf-header / hf-footer / hf-nsheader / hf-nsfooter message) whose body uses {{PAGENAME}}, e.g. Page being viewed: {{PAGENAME}}.
• View any article in the main namespace (e.g. Main_Page) with $egHeaderFooterEnableAsyncFooter = false (the default).
• Inspect the rendered footer.

What happens?:
{{PAGENAME}} inside the message resolves to the message's own title (Hf-nsfooter-) instead of the article being viewed (Main_Page). Any parser function that depends on the page context — including {{NAMESPACE}}, {{FULLPAGENAME}}, and SMW {{#show:{{PAGENAME}}|?Some_Property}} — sees the message page, not the article.
In our case the message is:

{{#if:{{#show:{{PAGENAME}}|?Ontologie_classe_nom}}|<div>…{{Sections_sémantiques/{{#show:{{PAGENAME}}|?Ontologie_classe_nom}}}}</div>}}

The #show returns empty (because the message page has no Ontologie_classe_nom property), #if collapses to nothing, and the user sees an empty <div class="hf-nsfooter" id="hf-nsfooter-"></div>.

What should have happened instead?:
{{PAGENAME}} should resolve to the article being viewed, matching the behavior of the asynchronous path (ApiGetHeaderFooter::execute), which binds both the Message and the Parser to $contextTitle:

                                                                                                                                
$messageText = $this->msg( $messageId )->page( $contextTitle )->text();
…
MediaWikiServices::getInstance()->getParser()->parse( $messageText, $contextTitle, … );

The synchronous path in AddHeaderFooter::generateHeaderFooter is missing this binding:

                                                                                                                                
$msg = wfMessage( $msgId );                                                                                                     
…
return $div . $msg->parse() . '</div>';

It should be:

$msg = wfMessage( $msgId )->page( $title );

(passing in the $title that onContentAlterParserOutput already receives). This restores parity with the API path and with the historical behavior — older MediaWiki message parsing inherited the surrounding parser's title, so {{PAGENAME}} worked without an explicit binding; modern Message::parse() requires it.

Workaround until fixed: set $egHeaderFooterEnableAsyncFooter = true; (and/or …AsyncHeader), which routes rendering through the API path that already passes the page context.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

• MediaWiki 1.45.3
• HeaderFooter 4.0.0
• SemanticMediaWiki (for the #show-based reproducer; the bug also reproduces with plain {{PAGENAME}} and no SMW)

Other information (browser name/version, screenshots, etc.):

• Bug source: extensions/HeaderFooter/src/HookHandler/AddHeaderFooter.php, generateHeaderFooter() — line calling $msg->parse() without ->page( $title ).
• Browser-independent (server-side rendering bug).