|
; Turn off HTML tags in error messages. The new format for HTML errors produces |
|
; clickable messages that direct the user to a page describing the error or |
|
; function in causing the error. These references are affected by docref_root |
|
; and docref_ext. |
|
html_errors=On |
|
|
|
[xdebug] |
|
|
|
; You must uncomment one (and only one) line from the following to load |
|
; the xdebug extension. |
|
zend_extension="xdebug.so" |
|
;zend_extension_ts="/usr/lib/php4/xdebug.so" |
|
;zend_extension_ts="c:\php4\xdebug.dll" |
|
;zend_extension="c:\php4\xdebug.dll" |
|
|
|
; When this setting is set to on, the tracing of function calls will be enabled |
|
; just before the script is run. This makes it possible to trace code in the |
|
; auto_prepend_file. |
|
xdebug.auto_trace=Off |
|
|
|
; If this setting is 1, Xdebug will color var_dumps and stack traces output when |
|
; in CLI mode and when the output is a tty. On Windows, the ANSICON tool needs |
|
; to be installed. If the setting is 2, then Xdebug will always color var_dumps |
|
; and stack trace, no matter whether it's connected to a tty or whether ANSICON |
|
; is installed. In this case, you might end up seeing escape codes. |
|
xdebug.cli_color=1 |
|
|
|
; This setting, defaulting to 0, controls whether Xdebug should add variable |
|
; assignments to function traces. |
|
xdebug.collect_assignments=0 |
|
|
|
; This setting, defaulting to 1, controls whether Xdebug should write the |
|
; filename used in include(), include_once(), require() or require_once() |
|
; to the trace files. |
|
xdebug.collect_includes=1 |
|
|
|
; This setting, defaulting to 0, controls whether Xdebug should collect the |
|
; parameters passed to functions when a function call is recorded in either the |
|
; function trace or the stack trace. |
|
; The setting defaults to Off because for very large scripts it may use huge |
|
; amounts of memory and therefore make it impossible for the huge script to run. |
|
; You can most safely turn this setting on, but you can expect some problems in |
|
; scripts with a lot of function calls and/or huge data structures as parameters. |
|
; Xdebug 2 will not have this problem with increased memory usage, as it will |
|
; never store this information in memory. Instead it will only be written to disk. |
|
; This means that you need to have a look at the disk usage though. |
|
; This setting can have four different values. For each of the values a different |
|
; amount of information is shown. Below you will see what information each of the |
|
; values provides. See also the introduction of the feature Stack Traces for a |
|
; few screenshots. |
|
; Value Argument Information Shown |
|
; 0 None. |
|
; 1 Type and number of elements (f.e. string(6), array(8)). |
|
; 2 Type and number of elements, with a tool tip for the full information. |
|
; 3 Full variable contents (with the limits respected as set by |
|
; xdebug.var_display_max_children, xdebug.var_display_max_data and |
|
; xdebug.var_display_max_depth. |
|
; 4 Full variable contents and variable name. |
|
; 5 PHP serialized variable contents, without the name. |
|
xdebug.collect_params=0 |
|
|
|
; This setting, defaulting to Off, controls whether Xdebug should write the |
|
; return value of function calls to the trace files. |
|
xdebug.collect_return=On |
|
|
|
; This setting tells Xdebug to gather information about which variables are |
|
; used in a certain scope. This analysis can be quite slow as Xdebug has to |
|
; reverse engineer PHP's opcode arrays. This setting will not record which |
|
; values the different variables have, for that use xdebug.collect_params. |
|
; This setting needs to be enabled only if you wish to use |
|
; xdebug_get_declared_vars(). |
|
xdebug.collect_vars=Off |
|
|
|
; If this setting is set to 0, then Xdebug will not set-up internal structures |
|
; to allow code coverage. This speeds up Xdebug quite a bit, but of course, |
|
; Code Coverage Analysis won't work. |
|
xdebug.coverage_enable=1 |
|
|
|
; If this setting is On then stacktraces will be shown by default on an error |
|
; event. You can disable showing stacktraces from your code with xdebug_disable(). |
|
; As this is one of the basic functions of Xdebug, it is advisable to leave this |
|
; setting set to 'On'. |
|
xdebug.default_enable=On |
|
|
|
; These seven settings control which data from the superglobals is shown when an |
|
; error situation occurs. Each php.ini setting can consist of a comma seperated |
|
; list of variables from this superglobal to dump, but make sure you do not add |
|
; spaces in this setting. In order to dump the REMOTE_ADDR and the REQUEST_METHOD |
|
; when an error occurs, add this setting: xdebug.dump.SERVER = REMOTE_ADDR,REQUEST_METHOD |
|
xdebug.dump.COOKIE= |
|
xdebug.dump.FILES= |
|
xdebug.dump.GET= |
|
xdebug.dump.POST= |
|
xdebug.dump.REQUEST= |
|
xdebug.dump.SERVER= |
|
xdebug.dump.SESSION= |
|
|
|
; Controls whether the values of the superglobals as defined by the xdebug.dump.* |
|
; settings whould be shown or not. |
|
xdebug.dump_globals=On |
|
|
|
; Controls whether the values of the superglobals should be dumped on all error |
|
; situations (set to Off) or only on the first (set to On). |
|
xdebug.dump_once=On |
|
|
|
; If you want to dump undefined values from the superglobals you should set this |
|
; setting to On, otherwise leave it set to Off. |
|
xdebug.dump_undefined=Off |
|
|
|
; Controls whether Xdebug should enforce 'extended_info' mode for the PHP parser; |
|
; this allows Xdebug to do file/line breakpoints with the remote debugger. When |
|
; tracing or profiling scripts you generally want to turn off this option as PHP's |
|
; generated oparrays will increase with about a third of the size slowing down |
|
; your scripts. This setting can not be set in your scripts with ini_set(), but |
|
; only in php.ini. |
|
xdebug.extended_info=1 |
|
|
|
; Introduced in Xdebug 2.1 |
|
; This setting determines the format of the links that are made in the display |
|
; of stack traces where file names are used. This allows IDEs to set up a |
|
; link-protocol that makes it possible to go directly to a line and file by |
|
; clicking on the filenames that Xdebug shows in stack traces. An example format |
|
; might look like: myide://%f@%l |
|
; The possible format specifiers are: |
|
; %f the filename |
|
; %l the line number |
|
xdebug.file_link_format= |
|
|
|
; If this setting is set to 1 then errors will always be displayed, no matter what |
|
; the setting of PHP's display_errors is. |
|
xdebug.force_display_errors=0 |
|
|
|
; This setting is a bitmask, like error_reporting. This bitmask will be logically |
|
; ORed with the bitmask represented by error_reporting to dermine which errors |
|
; should be displayed. This setting can only be made in php.ini and allows you |
|
; to force certain errors from being shown no matter what an application does |
|
; with ini_set(). |
|
xdebug.force_error_reporting=0 |
|
|
|
; This setting allows you to configure a mask that determines whether, and which, |
|
; notices and/or warnings get converted to errors. You can configure notices and |
|
; warnings that are generated by PHP, and notices and warnings that you generate |
|
; yourself (by means of trigger_error()). |
|
; For example, to convert the warning of strlen() (without arguments) to an |
|
; error, you would do: |
|
; ini_set('xdebug.halt_level', E_WARNING); |
|
; echo "Hi!\n"; |
|
; Which will then result in the showing of the error message, and the abortion |
|
; of the script. echo "Hi!\n"; will not be executed. |
|
; The setting is a bit mask, so to convert all notices and warnings into errors |
|
; for all applications, you can set this in php.ini: |
|
; xdebug.halt_level=E_WARNING|E_NOTICE|E_USER_WARNING|E_USER_NOTICE |
|
; The bitmask only supports the four level that are mentioned above. |
|
xdebug.halt_level=0 |
|
|
|
; Controls which IDE Key Xdebug should pass on to the DBGp debugger handler. |
|
; The default is based on environment settings. First the environment setting |
|
; DBGP_IDEKEY is consulted, then USER and as last USERNAME. The default is set |
|
; to the first environment variable that is found. If none could be found the |
|
; setting has as default ''. |
|
xdebug.idekey="vagrant" |
|
|
|
; This is the base url for the links from the function traces and error message |
|
; to the manual pages of the function from the message. It is advisable to set |
|
; this setting to use the closest mirror. |
|
xdebug.manual_url=http://www.php.net |
|
|
|
; Controls the protection mechanism for infinite recursion protection. The value |
|
; of this setting is the maximum level of nested functions that are allowed before |
|
; the script will be aborted. |
|
xdebug.max_nesting_level=100 |
|
|
|
; By default Xdebug overloads var_dump() with its own improved version for displaying |
|
; variables when the html_errors php.ini setting is set to 1. In case you do not |
|
; want that, you can set this setting to 0, but check first if it's not smarter |
|
; to turn off html_errors. |
|
; You can also use 2 as value for this setting. Besides formatting the var_dump() |
|
; output nicely, it will also add filename and line number to the output. |
|
; The xdebug.file_link_format setting is also respected. |
|
xdebug.overload_var_dump=2 |
|
|
|
; When this setting is set to 1, profiler files will not be overwritten when a |
|
; new request would map to the same file (depnding on the xdebug.profiler_output_name setting. |
|
; Instead the file will be appended to with the new profile. |
|
xdebug.profiler_append=0 |
|
|
|
; Enables Xdebug's profiler which creates files in the profile output directory. |
|
; Those files can be read by KCacheGrind to visualize your data. This setting |
|
; can not be set in your script with ini_set(). |
|
xdebug.profiler_enable=0 |
|
|
|
; When this setting is set to 1, you can trigger the generation of profiler |
|
; files by using the XDEBUG_PROFILE GET/POST parameter. This will then write |
|
; the profiler data to defined directory. |
|
xdebug.profiler_enable_trigger=1 |
|
|
|
; The directory where the profiler output will be written to, make sure that the |
|
; user who the PHP will be running as has write permissions to that directory. |
|
; This setting can not be set in your script with ini_set(). |
|
xdebug.profiler_output_dir=/tmp/xdebug-profiler |
|
|
|
; This setting determines the name of the file that is used to dump traces into. |
|
; The setting specifies the format with format specifiers, very similar to sprintf() |
|
; and strftime(). There are several format specifiers that can be used to format |
|
; the file name. |
|
; See the xdebug.trace_output_name documentation for the supported specifiers. |
|
xdebug.profiler_output_name=cachegrind.%R%s |
|
|
|
; Normally you need to use a specific HTTP GET/POST variable to start remote debugging. |
|
; When this setting is set to 'On' Xdebug will always attempt to start a remote |
|
; debugging session and try to connect to a client, even if the GET/POST/COOKIE |
|
; variable was not present. |
|
xdebug.remote_autostart=Off |
|
|
|
; If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to |
|
; connect to the client that made the HTTP request. |
|
; It checks the $_SERVER['REMOTE_ADDR'] variable to find out which IP address to use. |
|
xdebug.remote_connect_back=On |
|
|
|
; This setting can be used to increase (or decrease) the time that the remote |
|
; debugging session stays alive via the session cookie. |
|
xdebug.remote_cookie_expire_time=3600 |
|
|
|
; This switch controls whether Xdebug should try to contact a debug client which |
|
; is listening on the host and port as set with the settings xdebug.remote_host |
|
; and xdebug.remote_port. If a connection can not be established the script will |
|
; just continue as if this setting was Off. |
|
xdebug.remote_enable=On |
|
|
|
; Can be either 'php3' which selects the old PHP 3 style debugger output, 'gdb' |
|
; which enables the GDB like debugger interface or 'dbgp' - the brand new debugger |
|
; protocol. The DBGp protocol is more widely supported by clients. See more |
|
; information in the introduction for Remote Debugging. |
|
xdebug.remote_handler=dbgp |
|
|
|
; Selects the host where the debug client is running, you can either use a host |
|
; name or an IP address. |
|
xdebug.remote_host=localhost |
|
|
|
; If set to a value, it is used as filename to a file to which all remote debugger |
|
; communications are logged. The file is always opened in append-mode, and will |
|
; therefore not be overwritten by default. There is no concurrency protection |
|
; available. |
|
xdebug.remote_log="/tmp/xdebug.log" |
|
|
|
; Selects when a debug connection is initiated. This setting can have two different values: |
|
; req Xdebug will try to connect to the debug client as soon as the script starts. |
|
; hit Xdebug will only try to connect to the debug client as soon as an error condition occurs. |
|
xdebug.remote_mode=req |
|
|
|
; The port to which Xdebug tries to connect on the remote host. Port 9000 is the |
|
; default for both the client and the bundled debugclient. As many clients use |
|
; this port number, it is best to leave this setting unchanged. |
|
xdebug.remote_port=9000 |
|
|
|
; If this setting is 1, then Xdebug will disable the @ (shut-up) operator so |
|
; that notices, warnings and errors are no longer hidden. |
|
xdebug.scream=1 |
|
|
|
; When this setting is set to 1, Xdebug will show a stack trace whenever an |
|
; exception is raised - even if this exception is actually caught. |
|
xdebug.show_exception_trace=0 |
|
|
|
; When this setting is set to something != 0 Xdebug's generated stack dumps in |
|
; error situations will also show all variables in the top-most scope. Beware |
|
; that this might generate a lot of information, and is therefore turned off by default. |
|
xdebug.show_local_vars=0 |
|
|
|
; When this setting is set to something != 0 Xdebug's human-readable generated |
|
; trace files will show the difference in memory usage between function calls. |
|
; If Xdebug is configured to generate computer-readable trace files then they |
|
; will always show this information. |
|
xdebug.show_mem_delta=0 |
|
|
|
; When this setting is set to 1, you can trigger the generation of trace files by using |
|
; the XDEBUG_TRACE GET/POST parameter, or set a cookie with the name XDEBUG_TRACE. |
|
; This will then write the trace data to defined directory. In order to prevent Xdebug |
|
; to generate trace files for each request, you need to set xdebug.auto_trace to 0. |
|
xdebug.trace_enable_trigger=On |
|
|
|
; The format of the trace file. |
|
; 0 shows a human readable indented trace file with: time index, memory usage, |
|
; memory delta (if the setting xdebug.show_mem_delta is enabled), level, |
|
; function name, function parameters (if the setting xdebug.collect_params |
|
; is enabled, filename and line number. |
|
; 1 writes a computer readable format which has two different records. There |
|
; are different records for entering a stack frame, and leaving a stack frame. |
|
; The table below lists the fields in each type of record. Fields are tab separated. |
|
; 2 writes a trace formatted in (simple) HTML. |
|
xdebug.trace_format=0 |
|
|
|
; When set to '1' the trace files will be appended to, instead of being overwritten |
|
; in subsequent requests. |
|
xdebug.trace_options=1 |
|
|
|
; The directory where the tracing files will be written to, make sure that the |
|
; user who the PHP will be running as has write permissions to that directory. |
|
xdebug.trace_output_dir=/tmp/xdebug-trace |
|
|
|
; This setting determines the name of the file that is used to dump traces into. |
|
; The setting specifies the format with format specifiers, very similar to |
|
; sprintf() and strftime(). There are several format specifiers that can be used |
|
; to format the file name. The '.xt' extension is always added automatically. |
|
; The possible format specifiers are: |
|
; %c crc32 of the current working directory trace.%c trace.1258863198.xt |
|
; %p pid trace.%p trace.5174.xt |
|
; %r random number trace.%r trace.072db0.xt |
|
; %s script name cachegrind.out.%s cachegrind.out._home_httpd_html_test_xdebug_test_php |
|
; %t timestamp (seconds) trace.%t trace.1179434742.xt |
|
; %u timestamp (microseconds) trace.%u trace.1179434749_642382.xt |
|
; %H $_SERVER['HTTP_HOST'] trace.%H trace.kossu.xt |
|
; %R $_SERVER['REQUEST_URI'] trace.%R trace._test_xdebug_test_php_var=1_var2=2.xt |
|
; %U $_SERVER['UNIQUE_ID'] trace.%U trace.TRX4n38AAAEAAB9gBFkAAAAB.xt |
|
; %S session_id (from $_COOKIE if set) trace.%S trace.c70c1ec2375af58f74b390bbdd2a679d.xt |
|
; %% literal % trace.%% trace.%%.xt |
|
xdebug.trace_output_name=trace.%c |
|
|
|
; Controls the amount of array children and object's properties are shown when |
|
; variables are displayed with either xdebug_var_dump(), xdebug.show_local_vars |
|
; or through Function Traces. This setting does not have any influence on the |
|
; number of children that is send to the client through the Remote Debugging feature. |
|
xdebug.var_display_max_children=256 |
|
|
|
; Controls the maximum string length that is shown when variables are displayed |
|
; with either xdebug_var_dump(), xdebug.show_local_vars or through Function Traces. |
|
; This setting does not have any influence on the amount of data that is send to |
|
; the client through the Remote Debugging feature. |
|
xdebug.var_display_max_data=1024 |
|
|
|
; Controls how many nested levels of array elements and object properties are |
|
; when variables are displayed with either xdebug_var_dump(), |
|
; xdebug.show_local_vars or through Function Traces. This setting does not have |
|
; any influence on the depth of children that is send to the client through the |
|
; Remote Debugging feature. |
|
xdebug.var_display_max_depth=5 |