yiisoft / yii-debug Goto Github PK

• Make https://github.com/yiisoft/yii-debug/blob/master/src/Storage/FileStorage.php concrete using PHP's FS functions.
• Remove dependency on yiisoft/yii-filesystem, kill the package.

Seems, Yii Cache don't use in this package.

I have a simple app without the db module for example.

Currently it seems impossible to disable the DB panel from configuration.

What steps will reproduce the problem?

1. Clone and run https://github.com/machour/yii-bootstrap4-ks as described in the readme.
2. Remove the debug db panel from config/web.php and run composer du

What's expected?

The app to run normally.

What do you get instead?

Fatal error: Uncaught yii\exceptions\InvalidConfigException: Unknown component ID: db

When its set in config '__class' => yii\debug\Module::class, - then

Exception (Invalid Configuration) 'yii\base\InvalidConfigException' with message 'Object configuration must be an array containing a "class" element.'

I think the ability to store output data would be killer-feature for yii-debug.

Things which we can log:

• Page output
• CSS filles
• JS files
• Images
• Fonts
• Screenshot of page

It very useful for ajax or api requests.

One way it to handle all cURL requests inside third-party libraries is to proxy all of them through internal wrapper with global stream/curl context.
See:

Here's debugger design we've planned together with @xepozz.

General idea is to separate data collection and data display. In Yii 2 it was not
split so design was not convenient for both APIs and displaying data from
multiple servers.

Collection goes to yiisoft/yii-debug,
API goes to yiisoft/yii-debug-api,
displaying goes to yiisoft/yii-debug-viewer.

Modules

Debugger is extendable via modules. Each module provides:

• One of multiple data collectors
• Debug viewer panel
• Debug toolbar panel (optionally)

Modules are distributed as packages named as yii-debug-<name>.

Data collector

Collecting data

Debug data collector is modular and is using multiple application requests:
ApplicationStartup, ApplicationShutdown, BeforeRequest and AfterRequest.

On ApplicationStartup each module may register its own listener for events
containing data it needs. When such event occurs, data is being collected.
On AfterRequest and ApplicationShutdown data is flushed and persisted.

As an alternative, on ApplicationStartup any initialization could be done and at ApplicationShutdown data could be collected directly from service without using events.

An interface for collector:

interface DebugDataCollectorInterface
{
    public function startup(): void;
    public function shutdown(): void;
    public function flush(): array;
}

As an extra idea we may implement a decorator for DI container that would return service proxies that may record data.

Data collected

Besides module-specific data, all modules write common information about the data
collected:

1. Date and time of occurence.
2. A set of tags such as "application ID" or "server".

The following collectors are planned:

• EventsCollector
• ReqeustCollector
• ResponseCollector
• LogCollector
• ViewsCollector
• RoutesCollector
• FrameworkInfoCollector
• ComposerCollector
• DIContainerCollector

Storing data

Data persistence happens via an interface. Default implementation wites to files.
For the case of multiple servers storage should be switched to a shared one.

interface DebugDataStoreInterface
{
    public function persist(DebugDataInterface $data): void;
    public function list();
    public function read(): DebugDataInterface;
}

interface DebugDataInterface
{
    public function get(string $key);
}

Displaying data

Data collected during current request is displayed in a debug toolbar in form
of a very short summary. Previously collected data along with details could
be viewed via debug viewer.

Debug toolbar is implemented as middleware that adds extra HTML / JS code to
each page. For what to append it is querying all modules for an instance of
DebugToolbarPanelInterface:

interface DebugToolbarPanelInterface
{
    public function render(): string;
}

Debug viewer panel is implemented as another interface:

interface DebugViewerPanelInterface
{
    public static function name(): string;
    public function render(): string;
}

When debug viewer is getting a list of panels, it is querying name() from each
module. When rendering a panel, render() method is used.

There should be a view when all data collected is listed. There we should be able to filter by data tag.

Implementation plan

• Get feedback
• Fix interfaces
• Implement two collectors from the list
• Implement file storage
• Implement debug panel
• Implement debug viewer
• Get feedback
• Fix whatever is not correct
• Implement the rest of collectors

References

• #28 - Multi server support for debug panel
• #27 - Export/Import results
• #26 - Separate debugging and showing results
• #25 - Standalone debug application
• #24 - Allow debugging console application

What steps will reproduce the problem?

What is the expected result?

What do you get instead?

Additional info

Just a thought, when in 'debug' mode, It would be great if we had some sense of how long we're spending trying to match a route. For large applications, optimizing the router can be a huge undertaking and it would be excellent to have while organizing the rules.

This would be excellent to see as part of the toolbar and/or the route page.

What steps will reproduce the problem?

Process connect to several cache systems. For performance purposes programmers need to know how effectively use cache.

What is the expected result?

In debug panel: performance, time to do query.

What do you get instead?

Nothing in debug panel if I use memcache.

Additional info

So main message in a subject.
Console application must be abble to debugging, profiling and monitoring.

What steps will reproduce the problem?

composer update

What's expected?

Successful packages update

What do you get instead?

• Installation request for yiisoft/yii-debug dev-master -> satisfiable by yiisoft/yii-debug[dev-master].
  - yiisoft/yii-debug dev-master requires yiisoft/yii-bootstrap-implementation ^3.0@dev -> no matching package found.

Additional info

yii-base-web composer.json :

 "require-dev": {
        "yiisoft/yii-debug": "dev-master",
        "yiisoft/yii-gii": "dev-master",
        "phpunit/phpunit": "^7.0"
    }, 

What is the idea of yiisoft/yii-bootstrap-implementation?

Debug tool application must read an individual files which contains information about debug process.
Each result of request analyse can be exported or imported. This application must manage it.

Thereby analysis data collected at production can be read in development enviroment, data can be stored for a long time (ex. we can store only important results to fix them later) etc.

P.S. After #26 it must definitely be.

The following console command to debug should be present:

• Router
  • Dump router settings
  • Dump all routes
  • Dump specific routes group
  • Test an URL to match a route
• Container
  • Dump definition
  • Test container if it has specific service
  • Dump web / cli entries
• Config
  • Dump config files and their content
• Config Params
  • Dump config params
  • Test if specific parameter exist
• Translations
  • Dump all translations
  • Dump specific languages
  • Translate a string from CLI

All of these commands should be present, but I think it's better to place them into respective packages

What steps will reproduce the problem?

Clean install of yiisoft/yii-demo or yiisoft/app-api and enable debug in params

What is the expected result?

Actual memory usage to be recorded

What do you get instead?

Always the same memory amount is recorded

Additional info

@samdark commented on Jun 22, 2017, 11:17 PM UTC:

In 2.1 we plan making core jQuery-free and it would be cool if extensions would follow the same path.

This issue was moved by samdark from yiisoft/yii2-debug#246.

Since Yii 2.1 adopted PSR Log, usage of the Monolog instead of standard Yii logger is very likely.
Thus it should be support for extracting information for debug toolbar from Monolog.
This could be achived creating our own log handler for the Monolog logger and attaching it in the same way as current LogTarget.

See:
https://github.com/Seldaek/monolog/blob/master/src/Monolog/Handler/AbstractProcessingHandler.php

What steps will reproduce the problem?

http=>https

What steps will reproduce the problem?

Yii2 store debug data into files, this solution is not suitable for multi-server environments. The problem is similar to https://github.com/yiisoft/view/issues/51.

What is the expected result?

Support cloud platforms with LB.

What do you get instead?

Yii2 does not support it due to file storage.

Suggests

Storage interface should be defined, which already allows to using eg. redis, mysql.

This happens when shell autocomplete is used.

Web applications have page for reading information about debug process. Console application don't have that page.

After #24 should be possible to read information about debugged process.

Standalone debug reader application can be run in container and be available as one instance on debug.mysite.ru or mysite.ru/debug instead of admin.mysite.ru/debug/default, mysite.ru/debug/default, api.mysite.ru/debug/default and etc.mysite.ru/debug/default.

P.S. Application can be run as extention (like yii2-debug) and will be available on mysite.ru/debug/default or mysite.ru/my-debug-page, as standalone service and will be available on debug.mysite.ru or mysite.ru/dbg (like a phpmyadmin or others) and as container and will be available on mysite.ru:8081

For real projects it would be nice to have debugging in producation.
Thus it should be two independent processes: writing and reading.

Now we're ready to enable debug for few time on production server to collect information (ex. when server have peak load or just regulary statistics)

@samdark commented on Mar 8, 2017, 10:51 AM UTC:

See yiisoft/yii2#13706 (comment)

This issue was moved by samdark from yiisoft/yii2-debug#217.

Timeline collector should know about all applications' collectors. Like xhprof that shows all every collector call during the application run.

For instance, application collect 5 collectors' calls.
Schematically it may look like the following:

|
| log('app start')  router('matched route')  log('app end')   
-----12:00--------------12:01----------------12:02------------> time

Timeline collector may reference to each collector's entry and have it's own interpretation of the entry to render and reference it.

By default, it can be just $collectorShortName ($time) with or without an icon. Also it should know the id of the entry.
So each collector should have marked theirs entries with a unique id and time. Making this process easy we can add a helper to wrap a raw data with id and timestamp.

After it implemented yiisoft/yii-dev-panel#50 should also be made

See yiisoft/yii2-debug#317

If i run some console command and for some reason it cannot be initialized, then the debugger will push out 4 errors to the output with stacktraces

PHP Notice:  Undefined index: Symfony\Component\Console\Event\ConsoleCommandEvent in vendor\yiisoft\yii-debug\src\Collector\CommandCollector.php on line 56
...
PHP Notice:  Trying to access array offset on value of type null in vendor\yiisoft\yii-debug\src\Collector\CommandCollector.php on line 58
...
PHP Notice:  Trying to access array offset on value of type null in vendor\yiisoft\yii-debug\src\Collector\CommandCollector.php on line 59
...
PHP Fatal error:  Uncaught TypeError: get_class() expects parameter 1 to be object, null given in vendor\yiisoft\yii-debug\src\Collector\CommandCollector.php:59