why is this a new fieldset? Surely it belongs with logging?

I think we should separate this from logging.
I believe that 'file' is just the first option and others will follow with
additional settings. So the tab will get some more content...

Brian Teeman notifications@github.com schrieb am Sa., 15. Sep. 2018,
03:54:

why is this a new fieldset? Surely it belongs with logging?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#22188 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACEuuBKhUbLNKbPsEG7LPOWGtKNxcu0ks5ubMBQgaJpZM4WqMqR
.

Correct.
But I think the sentence is not quite right - the "where" doesn't sound
correct. @brianteeman ?

Quy notifications@github.com schrieb am Sa., 15. Sep. 2018, 22:36:

@Quy commented on this pull request.

In plugins/system/debug/debug.php
#22188 (comment):

@@ -600,4 +601,26 @@ private function collectLogs(): self

  return $this;

}
+

• /**
• • Setup the storage method where debug information will be store (or not).

Change to stored

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#22188 (review),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACEukdee0T712o4gDBYzg8TUIMpMCZrks5ubcdEgaJpZM4WqMqR
.

Storage only refers to logging so it should be in the logging tab

It also makes no sense at all what the "storage" is referring to when it is on its own tab.

It needs to be on the logging tab AND only shown when logging is actually enabled

Back on my keyboard...
So, what I am trying to say is that

• Logging refers basically to "Messages" that are generated by the system during execution, deprecated messages or messages by 3PD extensions.
  I believe activating this should not imply that those messages are going to be written to text files.
• Storage refers to the way the whole "debug bar" data (like system info, session and request data, database queries and, well, the log messages) are handled.
    Current options include:
  • File
  • None
    Other possible options would be
  • Redis
  • PDO
  • A custom handler

So, in my humble opinion, this deserves two separated tabs.

On the other hand, if that doesn't make any sense to you, I would be willing, and able, to perform the required changes to get this merged so I can use my keyboard for writing code instead of comments ?

please make the requested changes - if the other stuff is ever written then the decision can always be reviewed at that time

Done .

Partially reverted...
If you think that the storage option doesn't deserve its own tab it should go to the general "Plugin" tab, because it has absolutely no connection to the log tab for the reasons stated above.

I stick by my original comment

This isn't a logging configuration in the sense of dealing with log files, so IMO it's right that it does not go onto the logging tab.

what is it then? Maybe i have completely misunderstood it but from what I understand its purpose is to decide if log files are created

It's to configure whether the temporary files for a debugged request's data is stored basically, used in conjunction with the debug bar's Open Handler feature. It basically gives you the ability to review data for previous requests.

Well, when this option is fully integrated it wouldn't be "just" whether the data is stored but what backend storage is used (as hinted at earlier in this thread and in another issue).

Then the word storage is definitely misleading to me although now I see exactly what it is I see it is called storage in the code http://phpdebugbar.com/docs/storage.html

So if the field was called something like "storing collected data" or "collecting data storage" that would be less confusing perhaps?

"Collected Data Storage" should work.

Thank you very much.
Let's blame Mrs. Hamilton, my English teacher at school...
I also could have posted the link to the docs about storage, not sure why I omitted that - My fault.

Mrs Hamilton did a good job

OK since now we all know what we are talking about... I'd like to pollute my own PR with something a little OT..

I just tried to implement the open handler.
The following code:

# /components/com_content/Controller/DisplayController.php

public function xxx()
{
	$debugBar = new DebugBar();
	$debugBar->setStorage(new FileStorage($this->app->get('tmp_path')));

	$handler = new OpenHandler($debugBar);
	$handler->handle();
}

and

# /plugins/system/debug/debug.php:293

$debugBarRenderer
  ->setOpenHandlerUrl(JUri::root(true) . '/index.php?option=com_content&task=xxx&format=raw');

will enable the browsing of previous requests inside the debug bar which, IMHO, is a killer feature since it will enable the average developer for the first time to examine what happens during a redirect without the requirement for a single step debugger.

Now as you might have noticed the code is "hacked" into com_content which is obviously not the right place.
On the other hand I think that adding a new component (com_debug) to add this functionality would be an overkill...

Suggestions?

Add a view to com_admin.

And for the front end?
A simple controller task that returns a JSON response would be enough.
Or do we need some overriding strategy here?

Michael Babker notifications@github.com schrieb am Di., 18. Sep. 2018,
10:32:

Add a view to com_admin.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#22188 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACEuvWGLdtBcXNrlqPddXMoMKFJlZRNks5ucRIQgaJpZM4WqMqR
.

Add a view to com_admin.

I tried hard but I could not find a way to display anything from com_admin in frontend :(
Any hint how to accomplish this would be very much appreciated.

Not sure if we want to explore how to disable this great feature or are we good with the security enhancement that will be introduced by #22327 (which also includes the answer to my OT question here)?
So this could be closed.

Set to "closed" on behalf of @franz-wohlkoenig by The JTracker Application at issues.joomla.org/joomla-cms/22188

Closed as stated above.