< base > seems entirely wrong here to me. The error template should explicitly use absolute paths for its own assets (it mostly already does via jdoc:include), and if users put relative paths in custom modules, that's a documentation/editor issue — not something to fix by globally rebasing all URLs on the error page.

@Bodge-IT sorry massively disagree with you on that based on real world experience

@Bodge-IT try using the custom-404 module position and you will see why not having a base is an issue. (Not commenting if this is the correct fix)

@Bodge-IT try using the custom-404 module position and you will see why not having a base is an issue. (Not commenting if this is the correct fix)

Yep. just been digging into the issue further and concluded my earlier comment was wrong for the error page.

I have tested this item ✅ successfully on 652f4f8

Hi @krishnagandhicode, did you check multi-lingual sites? and multi-lingual sites that are running from a sub-domain?

I ask because while I do confirm the BEFORE and AFTER condition for:
The image fails to load and then The image loads correctly,

for the Home button, I can't seem to see any difference... (it could be simply that the Joomla router is handling things correctly...

Before I pass or fail this, I wanted to check with you.

Hi @krishnagandhicode, did you check multi-lingual sites? and multi-lingual sites that are running from a sub-domain?

I ask because while I do confirm the BEFORE and AFTER condition for: The image fails to load and then The image loads correctly,

for the Home button, I can't seem to see any difference... (it could be simply that the Joomla router is handling things correctly...

Before I pass or fail this, I wanted to check with you.

Yes Uri::base() automatically grabs the right physical root URL, also for sub-domains as well.
router handles multilingual sites as well.

You are right about the home button, The original issue (# 46610) mentioned about this ("Back to home page") and I also tested using laragon with joomla in a subfolder so the button actually did break for me, I believe you tested using a hosted site - so it works fine for you.

if the main issue - relative image path is fixed with the patch - then the fix works :)

I have tested this item ✅ successfully on 652f4f8

I have tested this successfully. I was indeed using a hosted site. Thanks @krishnagandhicode!

RTC

Maintainer decisions:

• PR can be merged if everything works
• One tested all 4 cases, they all work. But they think the base path should be moved one line down, after the metas, because the UTF-8 charset should be always the first element in the head. Not sure if it is relevant today, but in the past this was some kind of security thing to never have wrong charset definition.

@krishnagandhicode Could you please check and adopt if you agree?

Maintainer decisions:

• PR can be merged if everything works
• One tested all 4 cases, they all work. But they think the base path should be moved one line down, after the metas, because the UTF-8 charset should be always the first element in the head. Not sure if it is relevant today, but in the past this was some kind of security thing to never have wrong charset definition.

@krishnagandhicode Could you please check and adopt if you agree?

AGREED - DONE
Thanks Heiko.

@Bodge-IT and @exlemor could I ask you to test again?

Sorry, this is incorrect.

1. It bypasses Document API.
2. The <base> may be added by document renderer

   joomla-cms/libraries/src/Document/Renderer/Html/MetasRenderer.php

   Lines 105 to 109 in 9890bce

   	$base = $this->_doc->getBase();
   	if (!empty($base)) {
   	$buffer .= $tab . '<base href="' . $base . '">' . $lnEnd;
   	}

Usually we do not enforce this tag.
If I right remember it only added for "subfolder installation". Maybe we have to look on it current behavior and make a proper fix for all installation.

no r2c

Other way to fix the issue is to look why plugin "System - SEF" does not replace the image path as it does for regular pages. That how images in other content is working.

Other way to fix the issue is to look why plugin "System - SEF" does not replace the image path as it does for regular pages. That how images in other content is working.

When a 404 exception is thrown , the exception skips the normal this->render() call and jumps to the catch block. the exception handler's render method takes over , but it never fires the onAfterRender event.

maybe thats why Sef plugin neven gets a chance to rewrite the those relative paths ?

I am not sure but can we trigger onAfterRender inside the exception handler's render method or there some other way ?

I have tested this item ✅ successfully on 53e07f6

I am not sure but can we trigger onAfterRender inside the exception handler's render method or there some other way ?

Sorry I forgot to write a response.

It is possible but it definitely will have a side effect. Also will be incomplete because should work together with before/after event and the extension may not expect it during error.
And in general new event dispatching should not be in path release. It will be new feature not a bug fix.

What you could try is to add onBeforeRespond listener to SEF plugin, and check for
if ($app->getDocument() instanceof \Joomla\CMS\Document\ErrorDocument){ ... }.

An existing onAfterRender code will be need to move in to dedicated protected method.
Potentially with internal flag to make sure it is called only once.
This will be called then from onAfterRender and onBeforeRespond.

Other ways is

1. Add onAfterError event additionally to existing onError event inside Application try/catch block.
2. Or onBefore/AfterRender in to ErrorHandler (it is still questionable).
3. Or both

But all these will be new feature.
And need to be discussed if we really want these events there.

What you could try is to add onBeforeRespond listener to SEF plugin, and check for if ($app->getDocument() instanceof \Joomla\CMS\Document\ErrorDocument){ ... }.

An existing onAfterRender code will be need to move in to dedicated protected method. Potentially with internal flag to make sure it is called only once. This will be called then from onAfterRender and onBeforeRespond.

Thanks @Fedik I will refactor the SEF plugin now to use a protected method for onAfterRender and an internal flag to make sure it runs once per req.

What you could try is to add onBeforeRespond listener to SEF plugin, and check for if ($app->getDocument() instanceof \Joomla\CMS\Document\ErrorDocument){ ... }.
An existing onAfterRender code will be need to move in to dedicated protected method. Potentially with internal flag to make sure it is called only once. This will be called then from onAfterRender and onBeforeRespond.

Thanks @Fedik I will refactor the SEF plugin now to use a protected method for onAfterRender and an internal flag to make sure it runs once per req.

@Fedik Would that mean it is a new feature? If so, the PR has to be made for the 6.2-dev branch.

I mean, if we use onBeforeRespond listener we can take it as bug fix, there will be just code moving around SEF plugin.
But of course, RM still free to decide if they want it or it need to wait 6.1 bugfix or in 6.2.

And when we take another path and decide to add a new event dispatching, then it definitely a new feature.

I mean, if we use onBeforeRespond listener we can take it as bug fix, there will be just code moving around SEF plugin. But of course, RM still free to decide if they want it or it need to wait 6.1 bugfix or in 6.2.

And when we take another path and decide to add a new event dispatching, then it definitely a new feature.

Since you suggested it's okay as a bug fix, I've prepared the patch. It works and keeps everything contained within the SEF plugin.

Should I update the PR ?

Should I update the PR ?

Yes you can update. Then RM will see the changes and can make a decision.

Should I update the PR ?

Yes you can update. Then RM will see the changes and can make a decision.

If it is really just a bug fix, 5.4-dev is ok as target branch.

Looks good now. Thanks!

@brianteeman, @Bodge-IT and/or @exlemor could I ask you to test again?

The code works

Do all these new functions need to have @ since etc

I have tested this item ✅ successfully on 5c19cf7

I have tested this item ✅ successfully on 5c19cf7

Hi @krishnagandhicode, thank you for the fix ;) works successfully!

RTC

✅ Final test before merge with JBT

• Moved file htaccess.txt to .htaccess
• Seen missing image on category/bla before PR
• Applied PR with Patch Tester
  • Relative image is shown on category/bla
  • Installed languages de-DE and es-ES and multilingual sample data
  • Relative image is shown in language e.g. de/bla
  • Turned off Search Engine Friendly URLs
    • Relative image is shown in e.g. index.php?option=com_content&view=article&id=4711
  • Enabled 'Search Engine Friendly URLs' and 'Use URL Rewriting'
    • Relative image is shown e.g. de/bla or de/allcategories-de-de/uncategorised/bla
  • Deleted .htaccess and disabled 'Search Engine Friendly URLs' and 'Use URL Rewriting'
    • Relative image is shown e.g. index.php?option=com_content&view=category&id=4711
• Reinstalled with PRs full package to test w/o multilingual and w/o custom 404 error page it generally works
  • w/o .htaccess
    • Enabled 'Search Engine Friendly URLs'
      • 404 is working on e.g. index.php?view=article&id=4711
    • Disabled 'Search Engine Friendly URLs'
      • 404 is working on e.g. index.php?option=com_content&view=article&id=4711
  • Enabled 'Search Engine Friendly URLs' + 'Use URL Rewriting' + .htaccess
    • 404 is working on e.g. view=article&id=4711

Thank you @krishnagandhicode for your contribution. Thank you @Fedik and @richard67 for your support. Thank you @brianteeman, @Bodge-IT and @exlemor for testing.