* Update twig demo to use TwigProfileCollector
* Update documentation on twig bridge collector
* Deprecate TwigCollector
TraceableTwigEnvironment and TraceableTwigTemplate
fixes#386
i had the same issue, very annoying indeed. firefox doesn't crash. i tried to disable the hardware acceleration in chrome, seemed promising, but did't solve that.
i suppose this PR is not the quality for a permanent fix (sorry for that), but i hope someone more skilled can improve the PR.
* Prevent back reference issues in TracedStatement
* Prevent substring replacement
If a previously replaced value in the query string contains the placeholder
for a future replacement, the string inside was being replaced
Also, PHP allows the bindParameter syntax to omit the leading ':', so we
test to make sure it's there and add it if not
* Use Twig_Extension_Profiler as data-source
* Add documentation for TwigProfileCollector
* Add DebugBar\Bridge\Twig\TimeableTwigExtensionProfiler to measure rendering
* Fix & enable xdebug-link-generation in ExceptionsCollector
* Enable xdebug-link-generation to TwigProfileCollector
(An instance of the Twig_Environment or the Twig_Loader has to be passed to
the collector, to be able to resolve the templatename to the filename)
Add "ajax"-attribute to xdebug-links (IDEA / PhpStorm-Links should be opened by ajax)
Patch increases possible number of records stored and loaded from Redis DB by separating metadata and collector's data and storing them in different hashes.
Introduce a new HtmlVariableListWidget that is similar to
VariableListWidget but for variables with HTML contents.
Update the collectors that use the existing VariableListWidget to use
DebugBarVarDumper to dump the variables using the VarDumper HtmlDumper.
Because many debug bar users may not yet support inline static assets,
default to use the old VariableListWidget for now.
Updated collectors:
* ConfigCollector
* RequestDataCollector
Use the new DebugBarVarDumper class to support dumping variables in
interactive collapsible HTML; the new useHtmlVarDumper() function will
enable this.
Since this will require users to handle the new inline assets provided
by the JavascriptRenderer, make this dumping format optional and default
to the old behavior for now.
Implementers of RequestIdGeneratorInterface::generate() need to be sure
that each call to generate() will return a unique ID.
This could fail to happen in the existing implementation if microtime()
returns the same value on two successive generate() calls that come
within the same microsecond. For example, in a tight ID-generating
loop. It was unlikely, but now it is practically impossible.
Additionally, implementers should make sure that the return value is not
all-numeric to avoid any mixed data types when IDs are used as keys in
PHP arrays. (For example, numeric IDs could result in bugs when
array_merge is used.)
The memory_get_usage and memory_get_peak_usage functions have a
$real_usage parameter. Update the MemoryCollector and PDOCollector
collectors to use a value of false instead of true. For
MemoryCollector, we allow the user to choose which type of memory usage
to gather.
To recap, when $real_usage is set (and previously this was the
hard-coded default), PHP returns the amount of memory allocated from the
operating system by the PHP memory manager. This is typically done in
large chunks of memory and is not very granular.
When $real_usage is cleared, PHP returns the amount of memory the user’s
application has actually allocated from the PHP memory manager.
Clearing $real_usage has useful application especially for the
PDOCollector. As an example, a query that returns only a few rows will
often say that zero bytes were used when $real_usage is set. That’s
because PHP was able to satisfy the memory requests from memory it had
already allocated from the operating system. To contrast, the same
query will show an expected few kilobytes of memory usage when
$real_usage is set to false.
The find function for memcached storage is not very efficient when a
large number of debug bar frames have been stored over time. Improve
the performance by:
1. Retrieve no more items than absolutely necessary. (i.e. don’t
retrieve every last possible item and then slice the result array.)
2. Use bulk retrieval getMulti function with memcached.
The Symfony VarDumper component includes an HtmlDumper that dumps
variables in a rich HTML format that allows for expanding and collapsing
individual tree nodes in the dumped variable. This makes it much more
practical to navigate large/deep variables that have been dumped.
DebugBarVarDumper provides a Debug Bar-friendly wrapper around the
VarDumper component. It’s intended as a better alternative to
DataFormatter::formatVar. It provides for:
* Debug Bar-friendly styles for the VarDumper HTML.
* Implements AssetProvider for returning VarDumper static assets
(requires users of JavascriptRenderer to support inline assets).
* Simplifies VarCloner and HtmlDumper function calls for cloning and
dumping variables in a Debug Bar environment. VarDumper was
originally written/targeted to be a replacement for var_dump, so the
default behavior of HtmlDumper echoing static assets and variable
dumps directly to the page output isn’t really appropriate.
Furthermore, we must contend with several different Symfony versions
going back to v2.6.0. This class provides a friendly wrapper.
I have tested this with these Symfony versions:
* v2.6.0
* v2.7.0
* v2.8.0
* v3.0.0
* v3.1.0
* v3.2.0
* v3.3.0
All seem to work fine, with graceful degradation as needed.
Furthermore, the class is ready to take advantage of new features that I
added and are upcoming in Symfony v3.4:
* setMinDepth: https://github.com/symfony/symfony/pull/23515
This feature will be valuable for the upcoming BacktraceCollector.
Some existing user-provided stylesheets on the page might have a
different default color for code and pre elements; set it to black:
similar to what is already being done with the root div.phpdebugbar
style.
When showing backtraces, it’s useful to:
1. Show line numbers for each line of contextual code.
2. Highlight the line from the backtrace.
This commit adds the functionality to widgets.js/css for doing this.
Add new inline_css, inline_js, and inline_head keys on the
AssetProvider::getAssets() function. This allows us to support
collectors that require static assets that are not actually saved to a
file.
Then, update all the asset functions in JavascriptRenderer to support
these new keys.
An initial use case for this is supporting the HtmlDumper in Symfony’s
VarDumper. HtmlDumper only provides the styles and scripts in inline
HTML form. The static assets can be customized based on some
configuration properties available on the HtmlDumper class. One can
actually view the CSS/JS as a long PHP string/heredoc embedded in the
HtmlDumper.php source code. They are only accessible via the
getDumpHeader function, which returns the CSS/JS in a combined HTML
string.
If the URI ends with a trailing '/', then the existing code would just
show an empty string as the label, which isn't very useful if a page is
making lots of varied AJAX calls to URIs that end with trailing slashes.
Fix this by detecting if the URI ends with a trailing '/'. If it does,
then we also include the segment of the URI just prior to the
trailing '/'.
1. The list of messages was missing padding-bottom, causing the search
box to obscure the bottom message.
2. Explicitly declare styles for text input elements to avoid
interference from the containing page’s stylesheet. (On our site,
text input elements had 10px padding, causing the search box to be
much larger than the padding-bottom margin allowed for.)
* Support debug bar collection from command-line
It can be useful to use the PHP Debug Bar from the command line if a
storage layer is configured. In that scenario, a user would run a PHP
CLI application, then open a web page with the debug bar front-end and
use the open handler to locate the command-line invocation.
However, a problem is that the collect() function assumes that standard
HTTP variables are available - this assumption does not apply when
running from the CLI. Write a special branch of code for the CLI server
API so that reasonable metadata can be collected for the CLI case.
Without this patch, null method, URI, and IP are logged and it actually
becomes impossible to open the CLI invocation in the open handler - let
alone tell them apart.
* Fix gethostname call in DebugBar::collect
It might fail, and we need to be prepared for that.
