Not a good fix. The Document instance in the factory is going to be a different document instance than the one being rendered at that point.

The template files (index.php, error.php, etc.) should NEVER be operating with JFactory::getDocument(), they should ONLY be operating with $this because they are in scope of the Document instance.

These types of conditionals would have to go into the module, not the template.

i think it is the same document, it must be the same,
unless someone outside the class code is setting the property ???

	public static function getDocument()
	{
		if (!self::$document)
		{
			self::$document = self::createDocument();
		}

		return self::$document;
	}

but even if it is a different document instance,
the check is still valid, because it is the document instance that will cause the error of
right ??

Call to undefined method Joomla\CMS\Document\RawDocument::addHeadLink(): View not found [name,type,prefix]: article, txt, contentView

The template files (index.php, error.php, etc.) should NEVER be operating with JFactory::getDocument(), they should ONLY be operating with $this because they are in scope of the Document instance.

i agree with you

but when we are calling code to create modules, then we are doing exactly it because the modules are not forbidden from calling it or using code that results in calling it, an example of the fact that it is used is the error that we patch now

About

These types of conditionals would have to go into the module, not the template.

this is understandable, i am already doing similar checks myself in plugins,
(just it is annoying to patch all modules that can be called, at least in this case it is only 1)

i will close this as soon as someone makes the new PR,
or should i close it now ?

i think it is the same document, it must be the same,
unless someone outside the class code is setting the property ???

When the error handler gets triggered it never overloads what's in the factory. So you will have an ErrorDocument instance being rendered while the factory will either not yet be initialized (depending on where in the request things fail) or it'll be a document for the request format (generally the HTMLDocument).

this is not understandable, i am already doing similar checks myself in plugins,

I meant to say that your argument is 'understanable',
but i see that i wrote a 'not understandable' in my answer, i corrected and removed the not

@mbabker

I have replaced check on JFactory::getDocument() with a check on format request variable
added check to also protostar's error.php

I have modified this PR
I have replaced check on JFactory::getDocument() with a check on format request variable

 $layout   = $app->input->getCmd('layout', '');
 $task     = $app->input->getCmd('task', '');
 $itemid   = $app->input->getCmd('Itemid', '');
+$format   = $app->input->getCmd('format', 'html');
 $sitename = $app->get('sitename');

because the error.php is already using other request variables like layout and task, i assume there is no issue with using format request variable

Hei I want use your solution

as I understand I must modify the file, but witch one file ?

@zyzak

Yes, you can apply same check in your template (as the check of this PR)

but since in your case you have have attempt to call a different method

JDocumentNNN::addFavicon() 

your issue for addFavicon() is here
#20004

someone will need to find where this is done by your template (probably the execution path that calls the above starts somewhere inside error.php of your Joomla template)

and after finding then put similar check

Please post in Joomla forums and link to this PR and to this comment andf mention your template author
or ask for support a Joomla expert and link to this PR and to this comment, and they will know what to patch

Please dont ask for support in this PR

• the best choice is to report to the template author and link here, and it should be easy for them to fix it

Please resolve the conflict.

Conflicts resolved

I have tested this item ✅ successfully on 70222c1

I have tested this item ✅ successfully on 70222c1

I have tested this item ✅ successfully on 70222c1

RTC

I still don't like this but at this point we're never going to get the right fixes in the core architecture, so here it goes.