-1 for me. We had a long discussion about this at the time of implementation. This was the solution rather than forcing users to accept. I'm strongly against going even further backwards on this

I still don't get why the project feels like the stats collection notice should be in your face everywhere while the 2.5 EOL message and now our PHP EOL message get locked to the control panel only; those are more urgent things to be communicating to users.

We are throwing it in their face and forcing them to make a choice, that's the issue. Having this on the dashboard is one thing, having it on the article editing screen and every other screen is a whole other thing. It's too aggressive.

I have tested this item ✅ successfully on fc717c7

Here is a video of my test and I think it perfectly demonstrates the issue. I started with a fresh install and had to install and verify the patch tester without clicking the prompt. It's a huge distraction having the message pop up every single time on every single screen when you're trying to do something. I can't believe for a second that any Joomla user is okay with this the way it is. Let's fix this now.

Agree with Babker, so I'd personally suggest moving this to a post installation message (as that's pretty much what it is)

@c-lodder i have tryed this and this resulted into a not translated message :(

I personally dont care. The reason it is not a postinstall is because we asuming that sending is allowed after a few time (i cant remember the actual time we wait) This is also the reason we need to force the user to take a chooice. ;)

On the other hand, just press one of the buttons and it will never show up again.
I always do that directly after installation since it annoys me to much (which it does by design)

Put yourself in the shoes of a person who has never used Joomla before. You install for the first time, this message is the first you see when you login, then it follows you everywhere until you choose. What message are we sending to new users?

We need to think about that more. We're all used to this, but from an onboarding perspective it's a nightmare. This does not deliver a pleasant first user experience, and first impressions count for a lot. That's where my head is at.

Show on Control Panel is enough. After next Update the Message come again, User knows more about Reasons why its helping to click "Always send".

Decision of Production Department?

I have tested this item ✅ successfully on fc717c7

Moving to Needs Review on request by @yvesh

RTC

Please note per a discussion with Tobias that apparently moving the load language call after the cpanel check causes the messages to not translate. Let's move forward with this as is and we can address that issue separate.

This PR is wrong.. As with this PR we just include the js in com_cpanel and if we do so there come no updates to the stats server (you need to be on the cpanel that the code is triggerd). I'm working on a fix.

I need some more input :(

The plugin is trigger twice.. the first time with com_cpanel as option and the seccond time with com_ajax.
This means if we add any check like above we add the js only on com_cpanel to the actual site, wich is wrong i think as this way the stats sending is not triggerd anywhere else than com_cpanel.

Or do we get the decision that it is ok that we are only sending the stats if we are on the cpanel?

If we have that decision i can also fix the languages part by moving that code to the onAjaxSendStats method.

In order to fix this: #14615 we can move that the code to onGetIcons event (wich is only triggerd in com_cpanel too)..

IIRC the design was so that the collection could happen regardless of who is logged into the site or where (same way the update notification email plugin triggers independently of an admin logging into the site). So we shouldn't limit that part to someone logging into the site and hitting the control panel.

Use the plugin's isAjaxRequest method if you need to do something conditional based on full page request or AJAX.

IIRC the design was so that the collection could happen regardless of who is logged into the site or where (same way the update notification email plugin triggers independently of an admin logging into the site). So we shouldn't limit that part to someone logging into the site and hitting the control panel.

That is also broken by this line: https://github.com/joomla/joomla-cms/blob/staging/plugins/system/stats/stats.php#L79

I give up. Ping me if the server side breaks 🤣

I give up. Ping me if the server side breaks

hehe 😄 Thanks anyway. Your reply means we need to find a fix for that.

You have to add the original option from which com_ajax is called in the JavaScript :-) Than you can decide there if you render or not..

Why did you close it?

It did never worked correctly. If you have a solution you can do a new PR :)