How will you make sure you don't accidentally clear a message/warning the user should actually see?

Personally I think the _messageQueue property was made private for a reason. Maybe so it's no longer possible to clear the list? I don't really know, just a guess.

Like with everything, it should only be used when you need to and with care.

This is like the proposed parameter to enable plugins on install. They are tools for developers and in both cases developers are already using them (in this case in 2.5). We cannot expect that our extension developers are stupids and/or malicious.

So here

I was struggling with the same thing 4 months back. Thanks for implementing this.

Thanks.

Would be helpful (in light of the acceptance for J3.3) if you guys can test it and report back (if successful) on http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33270

Would it be an idea to only clear the message queue if debug is disabled?

Good idea. I added the code to make it return (do nothing) in debug mode.

Really Helpful, However is it possible to filter specific message rather than message type?

@nonumber Just wondering since I recently saw some error messages while updating an extension from you (I think it was Sliders?). Is this the reason you want to empty the message queue, to remove those messages? Apparently they are useless since everything updated fine and I could see the use for it here.
However in this case I updated several extensions at the same time. Wouldn't there be a "danger" that if you empty the queue here that you also empty messages from other extension installers? As far as I know there is no way to track which extension raised the message and you can't only clear the "own" messages.
There could also be plugins creating messages which could be present already when you're going to clear the message queue.

Like with everything, it should only be used when you need to and with care.

In this case I just think a developer can't know for sure that he is only clearing his own messages. And clearing messages from other extensions is probably never intended. Or how would you make sure that you don't accidentally clear something else?

Is this the reason you want to empty the message queue, to remove those messages?

Yes, one of the reasons

In this case I just think a developer can't know for sure that he is only clearing his own messages. And clearing messages from other extensions is probably never intended.

The idea is not to only clear your own messages. That would be a bit beside the point, as you could solve that within your own extension/code.
The idea is to be able to remove messages placed by other code/extensions.

I agree with @Bakual here. We should not clear messages from other extensions.

Ok, 2 months old now. Not worth my time anymore.

Hi, please please implement that feature.

I copied the code and put in production in many sites, it's extremely useful to suppress unuseful messages that customers ASK to suppress (so it's a developer utility method, very nice)

The security issue "we should not allow third party extensions to clear the message queue" isn't a valid reason to not implement this, simply because it's very very easy using php reflection in an extension to change a private property to public access and put it null... so malicious can do the malicuous if this is the issue, also now. Anyway adding this method instead can be very useful and if you really want to care security, you can add a logger call each time is called to dump the stack trace and erased messages for sysadmins, and also a global system flag to prevent it's execution if admin wants (or default prevented).

You may blame the J!Tracker Application for transmitting this comment.

Hello all,

Just another 2 cents. I too think this should be implemented because there are definitely use-cases for this feature. In my case I have used the ability to empty the message queue too. In my case in a JSON view.

We talk about other extensions messages that we shouldn't touch and to some degree I agree with this but there are other cases where extensions mess with the workflow. So if extension developers want to mess things up they can.

The responsibility lies with the developer, I believe we should give them tools to work with. Emptying the message queue is just one of those tools.

Having a specific method for emptying the queue is better than each developer messing with the message queue.

We should leave the responsibility to the developer and not baby-sit them.

My 2cents upon some thinking is that this shouldn't be implemented for the reason @Bakual mentioned.

One of the reasons given for this was error messages on install when there are no errors. However that means you've now just suppressed error messages from say my extension as well (because you can install multiple extensions at once) - that's just made my life 20 times harder to debug because as far as any client is concerned something has broken on their server without any error messages at all.

If you could do this for a given extension only (leaving it in the hands of the developer of the extension to be responsible) - then I'd be much more sympathetic to it. However just the way error messages are queued up means that this just isn't possible at the moment and therefore one extension developer makes another's life a pain in the ass for their convenience. So I'm against this.

I agree with George. Since this is not restricted to the extension emptying
the queue, there is too much risk in supressing helpful error messages.

Matt Thomas
203.632.9322
http://betweenbrain.com/

Sent from mobile. Please pardon any typos or brevity.
On May 18, 2014 6:08 AM, "George Wilson" notifications@github.com wrote:

My 2cents upon some thinking is that this shouldn't be implemented for the
reason @Bakual https://github.com/Bakual mentioned.

One of the reasons given for this was error messages on install when there
are no errors. However that means you've now just suppressed error messages
from say my extension as well (because you can install multiple extensions
at once) - that's just made my life 20 times harder to debug because as far
as any client is concerned something has broken on their server without any
error messages at all.

If you could do this for a given extension only (leaving it in the hands
of the developer of the extension to be responsible) - then I'd be much
more sympathetic to it. However just the way error messages are queued up
means that this just isn't possible at the moment and therefore one
extension developer makes another's life a pain in the ass for their
convenience. So I'm against this.

—
Reply to this email directly or view it on GitHub#3098 (comment)
.

Was this ever an issue in Joomla 2.5 then?
There it is possible to simply empty the queue.

Just my opinion, but the right question should be "why are there unwanted message, and how can i avoid them?" instead of "how can i suppress messages?" ...
If we want to implement such feature we need namespaces for messages first.

Was this ever an issue in Joomla 2.5 then?
There it is possible to simply empty the queue.

You mean like this:

JFactory::getApplication()->set('_messageQueue', '');

To me this feels wrong by simply looking at it, even if it "works".

That's a very good question Nils. That seems like the better thing to focus
on in my opinion.

Matt Thomas
203.632.9322
http://betweenbrain.com/

Sent from mobile. Please pardon any typos or brevity.
On May 18, 2014 10:10 AM, "Nils Rückmann" notifications@github.com wrote:

Just my opinion, but the right question should be "why are there unwanted
message, and how can i avoid them?" instead of "how can i suppress
messages?" ...
If we want to implement such feature we need namespaces for messages first.

—
Reply to this email directly or view it on GitHub#3098 (comment)
.

I fully agree with Nils. I'd rather make sure the messages aren't added than trying to remove them afterwards.
What are the use cases where you would need to empty the messages? Where are they coming from? Maybe we can improve the code at the source.

if someone need clear messageQueue because of their extension, then they always can use Reflection ... or better check the extension logic, because definitely something wrong there, if it requires such hack

mee to see no reason why it should be in CMS, the messages API made for notify user, and if some message already in queue then there a reason for it - Joomla! does not generate a random messages

For an application specific implementation, what we offer is quite fine
IMO. We already know you can use Reflection to do as you please with the
container, so folks who want the means of controlling the message queue
already have it. At the framework level, I agree 100% that this type of
control should be in the API. For our CMS, I just don't think it's a good
decision.

On Sunday, May 18, 2014, Fedik notifications@github.com wrote:

if someone need clear messageQueue because of their extension, then they
always can use Reflection ... or better check the extension logic,
because definitely something wrong there, if it requires such hack

mee to see no reason why it should be in CMS, the messages API made for
notify user, and if some message already in queue then there a reason for
it - Joomla! never does not generate a random messages [image: ]

—
Reply to this email directly or view it on GitHub#3098 (comment)
.

i am so disapointed this was not accepted into joomla 3. i am also an extension developer and i need to suppress messages which come from 3rd party extensions and are for no use for the visitor.

example:

• a 3rd party extension shows an error that a value for a field is missing
• my exntesion handles the logic and shows the field where the 3rd party ext does not expect it, but the 3rd party class still triggers the error (otherwise i'd have to copy whole 3rd party application into my application)

joomla is my prefered and recommended system because it is easily extensible. breaking this feature (and many others influeced by ->set() ) will cause further problems for application compatibility and may cause audience to shift to a CMS that does not change it's core that often in such markant way.

i really hope that this gets included in LTS 3.5.

stan

This comment was created with the J!Tracker Application at http://issues.joomla.org/.

I'd like to see this as well.
Here's an example of where I need it.
Fabrik has its own password field, these fields are extended from JFormField, but I do want to use the JRulePassword class to validate it against the new com_user password options. The JRule class enqueue their message in the application. However, Fabrik works by inserting errors inline, next to their corresponding field. This gives the form better affordance than simply displayed at the top of the page.
However now the form shows messages both at the top of the page and next to the field. :(

I don't buy the theory that its an issue - you could take that argument to the extreme and say that we shouldn't provide db access to developers in case they drop tables. However, what might be good would be to add a new property to the message array to state the provenance of the message e.g. 'com_user', 'lib_cms' etc. And ass creativeprogramming states you can get round this by using a reflexion class anyway. All we really want to do is provide a simple interface for developer to access rather than hacking a less than optimal solution.

for what its worth here's a slightly modified version of the function to kill a message type: taken from https://groups.google.com/forum/#!topic/joomla-dev-general/TRFT0gtNIio

function _killMessage($app, $type)
    {
        $appReflection = new ReflectionClass(get_class($app));
        $_messageQueue = $appReflection->getProperty('_messageQueue');
        $_messageQueue->setAccessible(true);
        $messages = $_messageQueue->getValue($app);

        foreach ($messages as $key => $message)
        {
            if ($message['type'] == $type)
            {
                unset($messages[$key]);
            }
        }

        $_messageQueue->setValue($app, $messages);
    }
```<hr /><sub>This comment was created with the <a href="https://github.com/joomla/jissues">J!Tracker Application</a> at <a href="http://issues.joomla.org/tracker/joomla-cms/3098">issues.joomla.org/joomla-cms/3098</a>.</sub>

thanks Pollen, it is a must 4m to be able to override a message, there is always a Use Case that wants you to do just that.

Speed of development is important too.

Sorry, but this code scares the hell out of me. Reflection does have some benefits, but it should surely not used to alter core classes at runtime.

Here's a case - http://issues.joomla.org/tracker/joomla-cms/6993