[D8] dBug [#2874030]

dBug for Drupal

Implementation of dBug for Drupal.

Features

PHP version of ColdFusion’s cfdump.
Outputs colored and structured tabular variable information.
Variable types supported are: Arrays, Classes/Objects, Database and XML Resources.
Ability to force certain types of output. Example: You can force an object variable to be outputted as an array type variable.
Stylesheet can be easily edited.
Table cells can be expanded and collapsed.

dBug

The main modification is to return a render array instead of echo.

dBug page: https://github.com/ospinto/dBug

Usage:

$dbug_variable = Dbug::debug($variable);
$output['#attached']['library'][] = 'dbug/dbug';
$output['variable'] = [
            '#type' => 'markup',
            '#markup' => $dbug_variable,
];

Change the $variable for the variable you want to show the debug information.

Project homepage

https://www.drupal.org/project/dbug

Git clone command

git clone --branch 8.x-1.x https://git.drupal.org/project/dbug.git
cd dbug

Manual reviews of other projects

My main project

Business Rules

Comments

Comment #1

29 April 2017 at 18:54

yuriseki created an issue. See original summary.

Comment #2

yseki CreditAttribution: yseki as a volunteer and commented 29 April 2017 at 18:55

Issue summary:

View changes

Comment #3

PA robot CreditAttribution: PA robot commented 29 April 2017 at 22:23

Multiple Applications

It appears that there have been multiple project applications opened under your username:

Project 1: https://www.drupal.org/node/2874030

Project 2: https://www.drupal.org/node/2869895

As successful completion of the project application process results in the applicant being granted the 'Create Full Projects' permission, there is no need to take multiple applications through the process. Once the first application has been successfully approved, then the applicant can promote other projects without review. Because of this, posting multiple applications is not necessary, and results in additional workload for reviewers ... which in turn results in longer wait times for everyone in the queue. With this in mind, your secondary applications have been marked as 'closed(duplicate)', with only one application left open (chosen at random).

If you prefer that we proceed through this review process with a different application than the one which was left open, then feel free to close the 'open' application as a duplicate, and re-open one of the project applications which had been closed.

I'm a robot and this is an automated message from Project Applications Scraper.

Comment #4

PA robot CreditAttribution: PA robot commented 29 April 2017 at 22:23

We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)

Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).

I'm a robot and this is an automated message from Project Applications Scraper.

Comment #5

yseki CreditAttribution: yseki as a volunteer and commented 30 April 2017 at 03:40

Issue summary:

View changes

Comment #6

erik.erskine CreditAttribution: erik.erskine commented 3 May 2017 at 10:02

Manual review:

The Dbug class, CSS and JS all looks like it's been copied from another library, albeit with some minor modifications as you describe:

The main modifications are the return as a render array instead of echo and the adequacy to Drupal standards.

Please try to avoid including the third party code if you can. Otherwise things are much harder to maintain - you need to keep your copy in sync with future upgrades to the upstream library going forward, plus it adds extra work for the security team. Have a read of the policy regarding 3rd party code on drupal.org for more information.

It should be possible to trap the output of echo and capture it into a variable like this:

ob_start();
new \dBug($variable);
$output = ob_get_clean();

This is what the kint() function does. I was able to do the above and show the output via dpm.

You can then include a composer.json file with a requirement of ospinto/dbug. The Drupal module will end up being tiny, but that's a good thing.

Comment #7

erik.erskine CreditAttribution: erik.erskine commented 3 May 2017 at 10:03

Status:

Needs review

» Needs work

Comment #8

yseki CreditAttribution: yseki as a volunteer and commented 4 May 2017 at 02:29

Status:

Needs work

» Needs review

Hi @erik.erskine,

Thanks for your review, to talk about this elegant way to use the external library and to present me the ob_start() function.

I've rewritten the module using this approach; the downside is that the original dBug class is pretty old, the last version was written back in 2007, and it uses too many deprecated codes. It's not comfortable to use it in PHP 7 without removing all errors display on php.ini. I understand that in the production environment the display_errors should be turned off, but it pretty much annoying keep seeing those errors in development. Another point is that some of this deprecated code will stop to work in the next PHP release such as the constructor using the class name instead of __construct().

For those reasons, I believe that it's better to keep the rewritten code.
Following the exceptions of 3rd party libraries and content on Drupal.org, this code do not seems to be maintained by the author and it has the GPL3 license

The JS and the CSS files are not from an external library, but the scripts to toggle the tables in the same way as ColdFusion's cfdump does and the stylesheet for the tables.

Althow the kint() does a similar job, the goals of the dBug module are to mimic the original dBug class (or cold function variable debug) allowing the developer to develop modules that need to display the variable content in a page without the necessity to keep the Devel module turned on in a production site, as it would be necessary unsing the kint().

You can see the usage of those debug variables blocks in my main module Business Rules.
Here is the guide that presents the debug block

Thanks,
Yuri