Download the PHP package webandco/neos-dev-tools without Composer
On this page you can find all versions of the php package webandco/neos-dev-tools. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package neos-dev-tools
Neos Development Tools
The package provides tools for Neos development
Installation
Install the package with composer. It is recommended to use the package only in development environments.
Tools
nodePublished file tool
This tools create a file when something is published in Neos. The purpose for this, is to use the file eg in gulp watch for browser-sync and reload the frontend, when the file changes.
Configuration
Webandco.DevTools.nodePublished.use
true to enable writing nodePublished file, else false
Webandco.DevTools.nodePublished.file
path of the nodePublished file
FLOW commandline BASH autocomplete
To get autocomplete for the FLOW commandline you need to load the script
in BASH. This might be handy in a server environment like Beach or custom docker containers.
Stopwatch
Sometimes it's quite handy to determine how many milliseconds an operation took to determine performance issues. This package makes use of Symfony's Stopwatch for this purpose.
The Stopwatch class is extended to provide some more features.
Instantiation
There are two ways to instantiate a stopwatch. Either directly using new Stopwatch() or
via the provided StopwatchFactory.
The factory might be relevant if multiple stopwatches are needed in different code parts. Using the factory you could create some final log output for all used stopwatches.
Usage
The stopwatch can be used like (Symfony's Stopwatch)(https://symfony.com/doc/current/components/stopwatch.html).
Two additional features are available: Restart the stopwatch and estimations.
Restart
Given a stopwatch $s = new Stopwatch(); you can avoid consecutive calls to
->start('critical_section') and ->stop('critical_section') by using
ETA and format duration
Let's assume you process a bunch of nodes in a loop and you know this takes a while. To get an estimate of how long it takes you can use the following:
Stopwatch duration
The duration in milliseconds can be retrieved for the whole stopwatch
using $s->getDuration() or for a single event $s->getEvent('someeventname')->getDuration().
Stopwatch metadata
You can also add metadata to a stopwatch, which can be used later on.
Stopwatch signals
The Stopwatch emits signals upon start/stop/openSection/stopSection. These signals can be used to create a tree of the stopwatch calls.
StopwatchTree
A StopwatchTree is provided which receives the signals emited by a Stopwatch and creates a calltree like structure.
The tree gives insight on which parts are slow in a method or multiple stacked methods.
For example, in Neos 4.3, one of the initial requests the neos backend issues is
/neos/schema/node-type?version=....
This request depends on the number of nodetypes configured and
the runtime depends mainly on Neos.Neos/Classes/Service/NodeTypeSchemaBuilder.php::generateConstraints().
The StopwatchTree can be used to get a better view on the method:
The final wLog() logs the signal itself and the call tree:
Keep in mind, that such heavy use of Stopwatch and Signals triples the runtime.
The method getConstraints() took around 23 seconds, which splits in 14 seconds for
inner-nodeTypes and 8 seconds for inner-autocreatedChildNodes.
Without the Stopwatch this method took around 6 seconds in the tested project.
Performance
From a few tests it seems that excessive use of Stopwatch can double the original runtime without signals. Using signals seems to triple the original runtime compared to without a stopwatch.
Logging
This package also provides a quick and dirty way to log to the SystemLogger. Keep in mind that this should not be used in production!
The goal is to get a fast way to log to the system log and have some convenience alike
console.log known from browsers.
In Package.php a function wLog() is declared
in the global namespace.
This function makes use of the LogService.
After the package is loaded you can use the function wLog()
without the need to inject the systemLogger by simply writing
somewhere in your code, which creates an output like
You can also write multiple lines using the syntax
Configuration
See Configuration/Settings.yaml.
- enabled: To enable or disable logging to SystemLogger. The global method
wLog()is created always. - pretty: In case a complex object is given as an argument, the object is logged using
json_encode. Ifprettyistruethe optionJSON_PRETTY_PRINTis used for those arguments. - color: If set to
trueevery new log message is printed in a new color. Thus you get a rainbow colored system log and maybe some issues or patterns might be easier to spot. The color can also be fixed using any of the namesnone, bold, dark, italic, underline, blink, concealed, black, red, green, yellow, blue, magenta,cyan, white, bg_black, bg_red, bg_green, bg_yellow, bg_blue, bg_magenta, bg_cyan, bg_white. - level: The log level to use for logging. Can be any of
emergency, alert, critical, error, warning, notice, info, debug - renderer: For custom objects you can provide a custom renderer which implements the LogRendererInterface.php
- signal: If enabled the emitted signals and their corresponding slots are logged using the DevTools log facility (aka
wLog())
Overrule config
You can overrule the config using
Enable logging the call depth given by count(debug_backtrace(false)):
Colored log messages
The messages written to the systemlogger are wrapped by bash color formating. It is possible to log messages in bold, italic, blinking, underlined or with a background color.
Conditional logging
To reduce the amount of log messages a condition can be added
Timing
To determine how long a method is running and how often it is called
Example output
Hex dump
A modified version of https://stackoverflow.com/a/34279537 allows to log a string in hex dump like format
with an output like this
By default, binary is inverted in the console. In this example the fusion cache markers can be seen.
Hexdump has the following configuration options:
- highlightBinary: How to highlight binary. Default is to use the "color"
invert - lineSeparator: The lineseparator to use. Default "\n"
- bytesPerLine: How many bytes should be shown per line. Default 48
- paddingCharacter: The chatacter to use for binary. Default
.
Caller
By default the caller of wLog() is determined and written to the log
It takes around 0.2 ms to determine the caller. This can be disabled via Webandco.DevTools.log.caller.enable in Settings.yaml.
Custom Log Renderer
Complex objects are rendered using json_encode. Often this doesn't expose
the needed information, thus you can create a custom renderer to transform a complex
object to simpler log message parts.
For an example, have a look at ThrowableLogRenderer.php
and the Settings.yaml.
Eel Helper
An Eel Helper is added to make use of wLog via fusion. The helper provides two methods
wLog()which just forwards the arguments to the actualfunction wLog()rwLog()which uses the first argument as the return value. The other arguments are forwarded to the actualfunction wLog()again.
For example
will add the current date and time to the current fusion value and writes the fusion object in the log.
An AbstractFusionObjectRenderer is also provided to format the given AbstractFusionObjects.
Determine Caller
Since flow creates proxy classes it is more complicated to get the caller of a method from the backtrace.
The method BacktraceService::getCaller() returns caller file, line, class and method
for a given method and class and uses Neos\Flow\Error\Debugger.
Log format mixing in one line
It is possible to write log lines with changing format:
This line results in a single log line that looks like: This is bold This is italic
Force log message
By default the logs are written during __destruct() of the LogService.
If you inject the LogService you can call eol() to force writing the log message:
LogService injection
To avoid the global wLog() method you can also inject the LogService
The injected LogService can then be used to write log messages using the eol() method
Signal logging
For debugging certain requests or implementing a feature
it can be useful to know which signals are emitted
and who catches them.
This can be enabled in the Settings.yaml
via Webco.DevTools.log.signal.enabled. A regex can be specified to
only show matching signals matching, e.g. /.*nodePropertyChanged$/i.
Log to stdout in case of cli
In Settings.yaml you can set the configuration logger depending on the php sapi name:
In the above configuration, webcoDevStdoutLogger is used to log to stdout in case of CLI commands.
FusionRenderingAspect
Via the configuration
an aspect is enabled which collects stats about rendered fusion objects.
The result is written to the System log via wLog(). This can be handy in determining which
fusion prototypes should be cached. The list printed via wLog() is ordered by the least relevant
prototype to the most relevant which would benefit the most if it is cached.
