Download the PHP package dogma/dogma-debug without Composer

On this page you can find all versions of the php package dogma/dogma-debug. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

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 PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • 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.
Please rate this library. Is it a good library?

Informations about the package dogma-debug

Dogma - Debug

Remote console debugger

includes:

requirements:

installation:

Run composer create-project dogma/dogma-debug.

usage:

WARNING: Dogma - Debug is for development use only.

It does pretty nasty things in the background (like rewriting source code) to accomplish what it does, which you should never do in a production environment with live data.

It is not a production debugging logger like Tracy/Symfony/Laravel error loggers, and it does not aim to replace them.

1) Run php server.php in some local console for displaying outputs (starts a socket server on port 1729). 2) Include shortcuts.php or client.php in your code or use it in auto_prepend_file directive in your php.ini. 3) You can create debug-config.php in the same directory as client to configure it.

Dumper

Dumper has a lot of features and configuration options to make dump outputs more compact, readable and usable - for example:

function shortcuts:

other:

configuration:

common:

traces:

formatters:

output:

ErrorHandler

prints formatted errors/warnings/notices with call stack and error statistics when request is finished

activate by calling ErrorHandler::enable($types)

configuration:

ExceptionHandler

prints formatted unhandled exceptions with call stack

activate by calling ExceptionHandler::enable()

activate inspecting caught exceptions by calling ExceptionHandler::inspectThrownExceptions(...)

configuration:

OutputHandler

reports output operations (echo) and output start

activate by calling OutputHandler::enable()

configuration:

RedisHandler:

reports communication with Redis server

for now only Predis connected via io streams is supported

activate by calling RedisHandler::enableForPredis()

configuration:

RequestHandler

reports request inputs and outputs

no activation needed. this handler only holds configuration for debugger headers and footer

configuration:

ShutdownHandler

reports process signals like SIGTERM etc. on Linux/Unix and Ctrl-C signal on Windows. together with ResourcesHandler and Debugger tries to determine what caused termination of the process

activate by calling ShutdownHandler::enable()

SqlHandler

reports SQL database queries and events

for now only Dibi abstraction layer is supported directly, but you can register your own logging function

activate by registering a callback to SqlHandler::log() in your DB layer

configuration:

Stream wrappers

wrapper report io operations on PHP streams (fopen(), fwrite() etc.) by registering stream handlers on them

also enables interceptors to do their thing by rewriting source code of included files and "decorating" native PHP functions and constructs

wrappers:

activate by calling e.g. FileStreamWrapper::enable()

configuration:

(similarly for all other stream handlers)

Interceptors

by using source code rewriting witchcraft implemented in stream wrappers, we can track or even disable usage of system functions and constructs (exit and die)

implemented interceptors for now:

see Intercept.php for more complete list of intercepted native functions

with these handlers you can investigate what and when exactly any foreign library or your code is doing, without the need for some logging support in that library and without having to use stepping debugger like XDebug

it is pretty simple to write other handlers like this to track any native php functions that are not covered yet

you can activate interception for groups of functions by calling *Interceptor::intercept...() methods

you might want to clear opcode caches when changing interception configuration, because PHP code is rewritten on-the-fly and PHP does not know which files should be reloaded (with new changes). you can run e.g. service apache2 restart to do this when using apache

Author:

Vlasta Neubauer, https://twitter.com/paranoiq

All versions of dogma-debug with dependencies

PHP Build Version
Package Version
Requires php Version ^7.1|^8.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package dogma/dogma-debug contains the following files

Loading the files please wait ....