I am unable to replicate this at all.

Tested with output_buffering on/off/4096

Tested with PHP 7.4.22 & 8.09

Even with firefox 91, although the browser is irrelevant for this kind of issue.

Also see #34568

Also see #34568

Strange, but cant fix what I cannot replicate

@PhilETaylor :
I can give you the backend credentials of my joomla 4.0 installation,
so you can replicate it by yourself
(you can not damage anything because it's just a test installation of Joomla 4.x)

I'm almost sure that it has to do with this kind of shared hosting ...

I don't think it's related, but who knows, so it's worth a try.

@BlackBrix Do you use the htaccess.txt file shipped with Joomla 4? With "use" i mean having copied it to ".htaccess".

If this is the case, edit .htaccess and go to the end. There is following section:

## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
##     directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this, and you see
##     ERR_CONTENT_DECODING_FAILED in your browser console network tab,
##     then your server is already gzipping css and js files and you don't need this
##     block enabled in your .htaccess
<IfModule mod_headers.c>
	# Serve gzip compressed CSS files if they exist
	# and the client accepts gzip.
	RewriteCond "%{HTTP:Accept-encoding}" "gzip"
	RewriteCond "%{REQUEST_FILENAME}\.gz" -s
	RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

	# Serve gzip compressed JS files if they exist
	# and the client accepts gzip.
	RewriteCond "%{HTTP:Accept-encoding}" "gzip"
	RewriteCond "%{REQUEST_FILENAME}\.gz" -s
	RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

	# Serve correct content types, and prevent mod_deflate double gzip.
	RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
	RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]

	<FilesMatch "(\.js\.gz|\.css\.gz)$">
		# Serve correct encoding type.
		Header append Content-Encoding gzip

		# Force proxies to cache gzipped &
		# non-gzipped css/js files separately.
		Header append Vary Accept-Encoding
	</FilesMatch>
</IfModule>

Can you remove that and check if it works after that?

As said, I don't really think it is related, but I'm not 100% sure.

@BlackBrix I can't reproduce it on my system if you send me credentials @ harald.leithner@community.joomla.org I can have a look. thx

@richard67 :

"Do you use the htaccess.txt file shipped with Joomla 4?"

no, it's not "in use" = (it's not renamed to ".htaccess")

@HLeithner :
yes, I will send an E-Mail.

I forgot to mention,
that the error appears only, if you are NOT logged in (as an admin) to the front-end.
If I am logged in to the front-end as a superuser I can see all menu items
so please visit the front-end as a guest to see this error

I think I broke the page... it happens after the cache has been created, when joomla want's to load the cache. Initial it didn't wrote into the /cache directory. I set the cache directly and it got filled but error still exists. Could you check the file permission and maybe setup a new joomla installation :-(

@HLeithner : I set up a new joomla installation -> same credentials

I've got the same issue. It needs 2 page refreshes for the menu to disappear. Then after couple minutes it came back again.
j4.tlwebdesign.nl

Server: nginx

Are you using Plesk ?

Please upload your system information file downloadable from https://j4.tlwebdesign.nl/administrator/index.php?option=com_admin&view=sysinfo

No it's a directadmin server.

systeminfo-2021-08-17T20_35_25+02_00.txt

I don't think it's related, but who knows, so it's worth a try.

@BlackBrix Do you use the htaccess.txt file shipped with Joomla 4? With "use" i mean having copied it to ".htaccess".

If this is the case, edit .htaccess and go to the end. There is following section:

## These directives are only enabled if the Apache mod_headers module is enabled.
## This section will check if a .gz file exists and if so will stream it
##     directly or fallback to gzip any asset on the fly
## If your site starts to look strange after enabling this, and you see
##     ERR_CONTENT_DECODING_FAILED in your browser console network tab,
##     then your server is already gzipping css and js files and you don't need this
##     block enabled in your .htaccess
<IfModule mod_headers.c>
	# Serve gzip compressed CSS files if they exist
	# and the client accepts gzip.
	RewriteCond "%{HTTP:Accept-encoding}" "gzip"
	RewriteCond "%{REQUEST_FILENAME}\.gz" -s
	RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

	# Serve gzip compressed JS files if they exist
	# and the client accepts gzip.
	RewriteCond "%{HTTP:Accept-encoding}" "gzip"
	RewriteCond "%{REQUEST_FILENAME}\.gz" -s
	RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

	# Serve correct content types, and prevent mod_deflate double gzip.
	RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]
	RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]

	<FilesMatch "(\.js\.gz|\.css\.gz)$">
		# Serve correct encoding type.
		Header append Content-Encoding gzip

		# Force proxies to cache gzipped &
		# non-gzipped css/js files separately.
		Header append Vary Accept-Encoding
	</FilesMatch>
</IfModule>

Can you remove that and check if it works after that?

As said, I don't really think it is related, but I'm not 100% sure.

I tried this and it didn't do anything. Same behaviour still.

Well the only way we are going to get to the bottom of this is for someone to debug it live on a server that exhibits and can replicate the issue over and over again. I cannot replicate it on any PHP version or dev or cPanel servers with either apache or nginx...

The common bits so far are

phpversion: 7.4.22 or 7.3.28
server: Apache
sapi_name: cgi-fcgi

If anyone is willing to provide a test site then Please send me your complete site details, including FTP, using the form at https://fix.mySites.guru/now and I'll take a look for FREE so that we can identify the root cause and fix it.

Will do Phil.

Ik have this issue also.
The testwebsite is running on DirectAdmin.
In FireFox and Chrome

etting Value
PHP Version 7.4.22
Web Server Apache/2
WebServer to PHP Interface fpm-fcgi
Joomla! Version Joomla! 4.0.0 Stable [ Furaha ] 17-August-2021 12:30 GMT
User Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.131 Safari/537.36

When I disable the Conservative caching, the problem is gone.
When I enable the Conservative caching, the problem is back, after 1 of 2 times refreshing

I can reproduce the issue. Both in Firefox and Chrome.

This will not be a browser issue.

I can now replicate "something" - one moment

If anyone is willing to provide a test site then Please send me your complete site details, including FTP, using the form at https://fix.mySites.guru/now and I'll take a look for FREE so that we can identify the root cause and fix it.

You should've received an e-mail. I run my own webserver so we can try out a lot of stuff.

Well I can replicate it and i can see it and I know its because somewhere deep in rendering the modules it loses the $attribs for "style" => "card" but I cannot find the exact needle in the haystack with the current level of caffine in my blood system

@wilsonge This needs a Release Blocker label please :)

I'm almost sure that this happened to me too while testing previous RCs. I've noticed modules randomly disappear on the frontend, i've not digged too much but i was under the impression that the issue was related to a self modification of records in the database. Indeed restoring the database from an original backup had the effect to recover all visible modules.

@PhilETaylor did you actually find the reason? I only checked the admin interface but it was a bit hard without file access to find the real reason...

Sorry no, I got lost in all the render methods...got sleepy and gave up after a 2 hours trying to understand it.

I do not understand the various layers of rendering modules and got lost, but its quite easy to replicate and there is a hard coded "style" => "raw" in one of the render methods (but thats not the root reason)

The issue is deep in Joomla PHP rendering modules code, having admin interface access only is not going to help you find it sorry.

@HLeithner
You have File Access cause I gave you an extra FTP Login,
didn't that Work ?

Its also something you dont want to be debugging on a live site ;-)

@HLeithner
You have File Access cause I gave you an extra FTP Login,
didn't that Work ?

Yes wouldhelp.

@PhilETaylor can you replicate it locally?

I can replicate it on 4.0 branch,

The menu does not disappears, it just rendered without correct chrome style.

But other menus rendered correctly.

Yes I can replicate it every time locally - yes it just loses its style/chrome it doesn't completely disappear but the surrounding "card" html is lost

oh on my updated site it didn't happens but with the sample data it did, ok so I can replicate it too.

That makes it easier...

and I found ,
cache ID does not count [style => raw] attribute, so on second call it rendered without chrome

if try to make cache ID like

$module->id . $view_levels . $app->input->getInt('Itemid', null) . md5(serialize($cacheparams->methodparams)),

it works again.

hmhm, but this not a right fix

I think changing this

to something like:

if (isset($attribs['style']) && $attribs['style'] === 'raw')
{
	$cachemode = 'static';
}

// Default to itemid creating method and workarounds on
$cacheparams = new \stdClass;
$cacheparams->cachemode = $cachemode;
$cacheparams->class = ModuleHelper::class;
$cacheparams->method = 'renderModule';
$cacheparams->methodparams = array($module, $attribs);

$result = ModuleHelper::moduleCache($module, $params, $cacheparams);

if (isset($attribs['style']) && $attribs['style'] === 'raw')
{
	$module->content = $result;
	$module->contentRendered = true;
}

return $result;

Should be good.

I will do PR tomorrow, if no one will find something better

please test #35225