run composer install after switching to this branch
I have not included any vendor files or modified composer files here to make reviewing easier. Is that correct?

@elkuku please include the composer files in your commit and place them in the vendor folder. As we are shipping the vendor files with the CMS ;)

@zero-24 that would be over 2.000 files, making it almost impossible for reviewing. Please reconsider..

BTW...

place them in the vendor folder.

I believe you mean /libraries/vendor?

Yes that folder. Hmm can you .gitignore files out that are not needed?

As without shipping than with the cms we cant use that lib in the current architecture.

Run "Composer install", "Composer update package", "Composer install --no-dev" and you'll be good.

@zero-24 I understand that vendor files have to be included in the final package, I just thought it would be easier to review...

@mbabker Of course your're right (as usual), most of the files are dev dependencies...

Anyway, I created a new branch, you may review the diff here, and if you find it reviewable, I'll merge it in here...

The needed dependencies should be "reviewed" as well anyway. Not exactly codewise but personally I want to see what you're going to pull in.
For example If it needs 5000 lines of code in various dependencies to replace the 2000 lines in our debug plugin, then we at least should question it. ?

Files not lines

The 2000 files are with dev stuff which we don't need. So the actual file count is lower. I just did a guess with the 5000 lines. Looking at the other branch, it's actually 20'000 lines we add. So imho there has to be a very good reason to add all those dependencies just for a debug plugin.
But that is my personal opinion.

Can we use the namespacing convention listed at https://volunteers.joomla.org/teams/joomla-4-architecture/reports/115-joomla-4-architecture-sprint-odense-dk please. So Joomla\Plugin\System\Debug please :)

I like this concept overall :)

@Bakual and @brianteeman

The needed dependencies should be "reviewed" as well anyway. Not exactly codewise but personally I want to see what you're going to pull in.

I thought the change in composer.json might be enough, but you are right. So here are some more infos on files and lines ?

php-debugbar

• https://github.com/maximebf/php-debugbar
• http://phpdebugbar.com/

~/r/joomla-cms (debug-bar) $ phploc libraries/vendor/maximebf/
phploc 3.0.1 by Sebastian Bergmann.

Directories                                          7
Files                                               45

Size
  Lines of Code (LOC)                             6328
  Comment Lines of Code (CLOC)                    2123 (33.55%)
  Non-Comment Lines of Code (NCLOC)               4205 (66.45%)
  Logical Lines of Code (LLOC)                    1179 (18.63%)

The library has one dependency:

symfony vardumper

• https://github.com/symfony/var-dumper
• http://symfony.com/doc/current/components/var_dumper.html

~/r/joomla-cms (debug-bar) $ phploc libraries/vendor/symfony/var-dumper/
phploc 3.0.1 by Sebastian Bergmann.

Directories                                         10
Files                                               56

Size
  Lines of Code (LOC)                             7620
  Comment Lines of Code (CLOC)                    1074 (14.09%)
  Non-Comment Lines of Code (NCLOC)               6546 (85.91%)
  Logical Lines of Code (LLOC)                    1708 (22.41%)

This is a pretty cool replacement for var_dump() and can be used also by 3PDs.

@wilsonge

I like this concept overall :)

Big Thanks for this ?

Now on the namespacing thing.. I'd love to follow any conventions but I wasn't aware of the existence..
Could you give me some advice on how to accomplish this?
I mean I would have to create the folder(s) JROOT/plugins/system/debug/Joomla/Plugin/System/Debug and register the plugin root as the namespace root?
That seems odd :(

No there is going to be a PSR-4 map of Joomla/Plugin/System/Debug to JROOT/plugins/system/debug :) (see #15226)

@elkuku Please just do the PR with all the code that will be included with your PR. There is no point merging a PR when we have to manually run composer afterwards to get it working. It has to work right away. It's both easier to test and maintain and less failure will happen.

Expecial as currently travis is failing because of the missing code ;)

.....S...PHP Fatal error:  Class 'DebugBar\DebugBar' not found in /home/travis/build/joomla/joomla-cms/plugins/system/debug/debug.php on line 202
Fatal error: Class 'DebugBar\DebugBar' not found in /home/travis/build/joomla/joomla-cms/plugins/system/debug/debug.php on line 202

https://travis-ci.org/joomla/joomla-cms/jobs/224803602

All vendor files are commited, unit- and system tests run fine both locally and online and all CI tools are "happy" ?
I wonder why the debug plugin is even executed in CI tests but there may be reasons...

@wilsonge I am following the other PR and hope that it will be merged in a timely manner... But until than how would I setup the namespace outlined in the doc you mentioned?
I would be happy to change it to anything that works, since the namepace I picked here is an ugly band aid until you guys decide about a "proper" way ?

@wilsonge OK I found it finally ;)

Hmmm Mrs. joomla-cms-bot changed the labels here on JIssues...
External Library JavaScript Front End Plugins ⇒ External Library Libraries

Call the devs!! ?

I think this is going to break once I merge 3.7 stable into 4.0. One of the changes has been to via htaccess block direct access to libraries/vendor (exactly like Drupal do https://github.com/drupal/drupal/blob/8.4.x/core/lib/Drupal/Core/Composer/Composer.php#L106-L137). However this is going to have the effect here of blocking access to the js and css files required for this to work

Cool. I would have actually preferred moving those library files out of the web root completely but yeah...

OK, so I added a line to Gruntfile.js to copy all the relevant files (more or less) to media/vendor.
Now I suppose that I should also commit those files? Oo

In the meantime I commit the Grutfile. @wilsonge Could you check if the changes are appropriate, please?

Not sure why the drone test is failing with

27 04 2017 05:28:09.226:ERROR [Firefox 50.0.0 (Ubuntu 0.0.0)
 | Validate, validate method on #validate-numeric-nan | encountered a declaration exception]: 
TypeError: Joomla.optionsStorage is null in 
http://localhost:9876/base/media/system/js/core.js?0fd424e7fb8213be9940ef87c205dba3db7df6d0 (line 9)

THB I have no idea why this might fail and I suspect that it's not related to the changes I made.
Advise please.

@elkuku it's not your code, it's validator that blindly asks for a string and it throws if it's not declared. I'll fix that later on...

@dgt41 Thanks, good to know ?

guys what need to do to get this accepted?
it seems a great improvement

Personally I would go with: https://underground.works/clockwork/
https://github.com/itsgoingd/clockwork

I would go with: https://underground.works/clockwork/

only drawback, it forces me to install the browser extension ?

or use the web UI http://your.app/__clockwork

They need to add a LICENSE file to that repo. The note of the license in the Composer manifest isn't enough.

or use the web UI http://your.app/__clockwork

did not seen this part :)

@mbabker I wondered about that

It does state MIT in the composer file

sooo, I have tested both Debug bar and Clockwork

In 2 words, for Joomla! I would choose "Debug bar".

Here is some notes/comparison:

Debug bar

pros:

• client side rendering (based on own renderer)
• possible to view debug history (not implemented in current pull)
• possible to create a custom data handlers
• possible to create a custom client side widgets
• not bad documentation

cons:

• I didn't found anything critical

Clockwork

pros:

• client side rendering (based on AgularJS 1.5)
• possible to view debug history
• possible to create a custom data handlers

cons:

• client side depend from browser extension or need to adapt /Clockwork/Web/public
• not possible to create a custom client side widgets, except we write custom client rendering
• documentation does not exist (I not found)

So I think Clockwork is a nice toy or when someone have a time to fork and adapt it,
for Joomla! I would choose Debug bar.

@elkuku I have fixed the conflicts https://github.com/Fedik/joomla-cms/tree/debug-bar

Now I think, it would be more easy to write new plugin than rewrite existing ?

I would welcome to have a more modern debug bar for Joomla. Can you bring that pr into a state for reevaluation please. Thanks!

There's no action happening here. i'd love to see something like this make it into 4.0 - but I guess it's not happening in this PR - so I'm going to close this for now. Of course if it's comes back in sync we can reopen and evaluate :)

This has been updated

Sorry but it seems that something got wrong with the last merge... I'd like to close and redo this PR but unfortunately I am unable to close it....