For example, if a user visits a site and JBrowser cannot identify the browser type, it'll generate a notice containing

@bentasker IIRC this is disabled in the current code base since J3.3.4: #4015 / 75915b7

@zero-24 So it is, sorry that was a bad example to use!

It'd still be handy to have a means to prevent caching of pages containing a notice/warning though (as a better example, if a module displaying an RSS feed cannot load the remote feed, it may generate a warning)

Moving to Needs Review so a Maintainer can decide if this should included or not. Thanks.

Another bad example as I believe #6980 resolves that

Not sure I follow your logic here Brian. #6980 fixes an issue with feeds but has little bearing on this issue - it was also fixed months after the example was given.

Although examples have been given, the point is that if a site sits behind a caching tier it may be desirable to ensure that errors/warnings will never be shown on the front end - otherwise they will be cached and appear for other visitors.

Things like 'invalid password' generally won't be cached as they're the result of a POST (meaning the result should never be cached), but any error/warning displaying as the result of a GET should be suppressable - the easiest/most flexible way I can see to do this is a plugin event.

Adding an event would also allow for logging of some of the output (using the feeds as an example - how often are they failing to load the feed?).

Are you saying that some messages are being stored after they are no longer relevant and thus being displayed when others visit the site ?

Sort of. Assume site 'a' is using Cloudflare (to pick a common provider). If whilst rendering a page (for example the home page), Joomla does something which causes a notification to be included in the HTML, that notification will be in the cached copy that Clouflare creates.

For as long as that copy is considered valid (which will vary based on config), every visitor to that page will see that notification whether it's relevant or not.

It's not that Joomla isn't flushing the message internally, because it is. The problem is, there isn't currently a clean way for us to programatically identify whether a message has been queued.

If there were, we could amend the cache-control header so that downstream knows to revalidate on the next request (or if preffered, suppress the message entirely).

Even if the site operator hasn't opted to put a caching tier in front of the site, there's no way to know whether there may still be caches downstream - some ISPs put caches on the edge of their network, so a site may also appear to misbehave for their users.

So what are the options for triggering a message outside of the html of the requested page ? ... a redirect to an error page that pops up seperate to the requested html page ? a Javascript message ? What ?

IMO the best option is to move that into control of the site operator - if there's a plugin trigger within enqueuemessage (or perhaps later when those messages are retrieved?) then a plugin can be used to do any of the following (whichever suits the admin)

• Completely suppress the message
• Replace the message with an anchor to allow display another way (AJAX request maybe?)
• Change the cache-control headers so that downstream won't cache this time

At the moment, the CMS assumes that the developer (whether third party or not) knows better than the operator, and deployments differ. There are messages that you will always want to display (e.g. 'Invalid username/password') but there are also plenty that you either don't want to display, or want to ensure aren't cached (the now-fixed user-agent identification message I mentioned being a prime example).

Your question is about site operators,

but you said
"there isn't currently a clean way for us to programatically identify whether a message has been queued"

You mean that you tried to replace:

with:
// 1 Get messages
$messages = JFactory::getApplication()->getMessageQueue();

// 2. Examine (loop through) messages and decide according to

• message type,
• refer URL
• other logic and decide whether to display it,

// 3. output the accepted messages with proper HTML containers

// 4. if number of messages > 0 disable Joomla caching for current page and also set no-caching HTTP headers ?

and it did not work ?

As there has been no reply to the last question to the OP for nearly 6 months I am closing this issue. It can always be re-opened if further information, including how to replicate the issue with the current release, is provided.