* 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.
