PHP gibt keine Fehler mehr aus
Mief
- php
Hallo Leute,
auch nach googlen und ausprobieren gab es keine Erfolge:
PHP gibt keine Fehlermeldungen mehr aus. Und das ist für einen Web-Entwickler ziemlich Sch****.
Hier mal der entsprechende Teil aus der PHP.ini:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error handling and logging ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; This directive informs PHP of which errors, warnings and notices you would like
; it to take action for. The recommended way of setting values for this
; directive is through the use of the error level constants and bitwise
; operators. The error level constants are below here for convenience as well as
; some common settings and their meanings.
; By default, PHP is set to take action on all errors, notices and warnings EXCEPT
; those related to E_NOTICE and E_STRICT, which together cover best practices and
; recommended coding standards in PHP. For performance reasons, this is the
; recommend error reporting setting. Your production server shouldn't be wasting
; resources complaining about best practices and coding standards. That's what
; development servers and development settings are for.
; Note: The php.ini-development file has this setting as E_ALL | E_STRICT. This
; means it pretty much reports everything which is exactly what you want during
; development and early testing.
;
; Error Level Constants:
; E_ALL - All errors and warnings (includes E_STRICT as of PHP 6.0.0)
; E_ERROR - fatal run-time errors
; E_RECOVERABLE_ERROR - almost fatal run-time errors
; E_WARNING - run-time warnings (non-fatal errors)
; E_PARSE - compile-time parse errors
; E_NOTICE - run-time notices (these are warnings which often result
; from a bug in your code, but it's possible that it was
; intentional (e.g., using an uninitialized variable and
; relying on the fact it's automatically initialized to an
; empty string)
; E_STRICT - run-time notices, enable to have PHP suggest changes
; to your code which will ensure the best interoperability
; and forward compatibility of your code
; E_CORE_ERROR - fatal errors that occur during PHP's initial startup
; E_CORE_WARNING - warnings (non-fatal errors) that occur during PHP's
; initial startup
; E_COMPILE_ERROR - fatal compile-time errors
; E_COMPILE_WARNING - compile-time warnings (non-fatal errors)
; E_USER_ERROR - user-generated error message
; E_USER_WARNING - user-generated warning message
; E_USER_NOTICE - user-generated notice message
; E_DEPRECATED - warn about code that will not work in future versions
; of PHP
; E_USER_DEPRECATED - user-generated deprecation warnings
;
; Common Values:
; E_ALL & ~E_NOTICE (Show all errors, except for notices and coding standards warnings.)
; E_ALL & ~E_NOTICE | E_STRICT (Show all errors, except for notices)
; E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR (Show only errors)
; E_ALL | E_STRICT (Show all errors, warnings and notices including coding standards.)
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
; http://php.net/error-reporting
error_reporting = E_ALL | E_STRICT
; This directive controls whether or not and where PHP will output errors,
; notices and warnings too. Error output is very useful during development, but
; it could be very dangerous in production environments. Depending on the code
; which is triggering the error, sensitive information could potentially leak
; out of your application such as database usernames and passwords or worse.
; It's recommended that errors be logged on production servers rather than
; having the errors sent to STDOUT.
; Possible Values:
; Off = Do not display any errors
; stderr = Display errors to STDERR (affects only CGI/CLI binaries!)
; On or stdout = Display errors to STDOUT
; Default Value: On
; Development Value: On
; Production Value: Off
; http://php.net/display-errors
display_errors = On
; The display of errors which occur during PHP's startup sequence are handled
; separately from display_errors. PHP's default behavior is to suppress those
; errors from clients. Turning the display of startup errors on can be useful in
; debugging configuration problems. But, it's strongly recommended that you
; leave this setting off on production servers.
; Default Value: Off
; Development Value: On
; Production Value: Off
; http://php.net/display-startup-errors
display_startup_errors = On
; Besides displaying errors, PHP can also log errors to locations such as a
; server-specific log, STDERR, or a location specified by the error_log
; directive found below. While errors should not be displayed on productions
; servers they should still be monitored and logging is a great way to do that.
; Default Value: Off
; Development Value: On
; Production Value: On
; http://php.net/log-errors
log_errors = On
; Set maximum length of log_errors. In error_log information about the source is
; added. The default is 1024 and 0 allows to not apply any maximum length at all.
; http://php.net/log-errors-max-len
log_errors_max_len = 1024
; Do not log repeated messages. Repeated errors must occur in same file on same
; line unless ignore_repeated_source is set true.
; http://php.net/ignore-repeated-errors
ignore_repeated_errors = Off
; Ignore source of message when ignoring repeated messages. When this setting
; is On you will not log errors with repeated messages from different files or
; source lines.
; http://php.net/ignore-repeated-source
ignore_repeated_source = Off
; If this parameter is set to Off, then memory leaks will not be shown (on
; stdout or in the log). This has only effect in a debug compile, and if
; error reporting includes E_WARNING in the allowed list
; http://php.net/report-memleaks
report_memleaks = On
; This setting is on by default.
;report_zend_debug = 0
; Store the last error/warning message in $php_errormsg (boolean). Setting this value
; to On can assist in debugging and is appropriate for development servers. It should
; however be disabled on production servers.
; Default Value: Off
; Development Value: On
; Production Value: Off
; http://php.net/track-errors
track_errors = Off
; Turn off normal error reporting and emit XML-RPC error XML
; http://php.net/xmlrpc-errors
;xmlrpc_errors = 0
; An XML-RPC faultCode
;xmlrpc_error_number = 0
; When PHP displays or logs an error, it has the capability of inserting html
; links to documentation related to that error. This directive controls whether
; those HTML links appear in error messages or not. For performance and security
; reasons, it's recommended you disable this on production servers.
; Note: This directive is hardcoded to Off for the CLI SAPI
; Default Value: On
; Development Value: On
; Production value: Off
; http://php.net/html-errors
html_errors = Off
; If html_errors is set On PHP produces clickable error messages that direct
; to a page describing the error or function causing the error in detail.
; You can download a copy of the PHP manual from http://php.net/docs
; and change docref_root to the base URL of your local copy including the
; leading '/'. You must also specify the file extension being used including
; the dot. PHP's default behavior is to leave these settings empty.
; Note: Never use this feature for production boxes.
; http://php.net/docref-root
; Examples
;docref_root = "/phpmanual/"
; http://php.net/docref-ext
;docref_ext = .html
; String to output before an error message. PHP's default behavior is to leave
; this setting blank.
; http://php.net/error-prepend-string
; Example:
;error_prepend_string = "<span style='color: #ff0000'>"
; String to output after an error message. PHP's default behavior is to leave
; this setting blank.
; http://php.net/error-append-string
; Example:
;error_append_string = "</span>"
; Log errors to specified file. PHP's default behavior is to leave this value
; empty.
; http://php.net/error-log
; Example:
;error_log = php_errors.log
; Log errors to syslog (Event Log on NT, not valid in Windows 95).
;error_log = syslog
;windows.show_crt_warning
; Default value: 0
; Development value: 0
; Production value: 0
Hier mal der entsprechende Teil aus der PHP.ini:
vergleiche erst mal, ob das überhaupt die wirksame PHP.ini ist.
<?php phpinfo(); ?>
hilft Dir dabei.
vergleiche erst mal, ob das überhaupt die wirksame PHP.ini ist.
<?php phpinfo(); ?>
hilft Dir dabei.
Danke, hab die richtige PHP.ini gefunden, aktualisiert, Apache neugestartet und jetzt gibt der auch wieder Fehler aus.
(Warum hat PHP auch mehrere ini's?)
(Warum hat PHP auch mehrere ini's?)
Ganz einfach! Wenn man PHP in einer Shell ausführt sind in der Regel ganz andere Einstellungen nötig als wenn es der Webserver macht. Bei dem wieder muss man unterscheiden zwischen PHP als Modul, PHP als (F)CGI. Dazu kommt noch die Möglichkeit eine PHP.ini im DOCUMENT_ROOT abzulegen.
Wenn man es so will kann man außerdem die PHP.ini in übersichtliche Abschnitte zerlegen. Beispiel hierfür ist der Apache, dessen monolithische Konfigurationsdatei (nach der Installation) zuletzt so groß war (über 5000 Zeilen), dass die Administratoren, um das Ding noch händelbar zu halten, mit etwas wie einem einem
cp http.conf http.original && grep -v '^#' http.original > http.conf
auf ca. 200 Zeilen "eindampften". Wodurch natürlich die Kommentare weg waren.
Statt dessen gibts beim Apache jetzt bequeme Abschnittsdateien.
Hallo,
Wenn man es so will kann man außerdem die PHP.ini in übersichtliche Abschnitte zerlegen. Beispiel hierfür ist der Apache, dessen monolithische Konfigurationsdatei (nach der Installation) zuletzt so groß war (über 5000 Zeilen), dass die Administratoren, um das Ding noch händelbar zu halten, mit etwas wie einem einem
cp http.conf http.original && grep -v '^#' http.original > http.conf
auf ca. 200 Zeilen "eindampften". Wodurch natürlich die Kommentare weg waren.
naja, wenn man einen Apachen einrichtet(e), hat man doch in der Regel sowieso große Teile der mitgelieferten httpd.conf gelöscht, weil sie für die individuelle Konfiguration nicht zutrafen, und ebenso einen großen Teil der Kommentarzeilen. Ich habe jedenfalls die im Originalpaket enthaltene httpd.conf (zumindest in Apache 2.0, als sie "am Stück" war) immer nur als Referenz genommen, um daraus meine persönliche Config zu extrahieren.
Statt dessen gibts beim Apache jetzt bequeme Abschnittsdateien.
Ob das bequem ist, darüber kann man streiten. Ich finde es praktischer und übersichtlicher, wenn ich nur *eine* Config-Datei habe, auch wenn die dann etwas größer wird. Durch das Zerlegen in mehrere Teildateien wird es IMO sehr viel umständlicher.
Auch wenn ich inzwischen ungefähr weiß, in welcher der zahlreichen Einzeldateien ich eine bestimmte Direktive suchen muss, komme ich doch jedes Mal wieder in Versuchung, die Einzeldateien auf meinem Testserver wieder zu *einer* zentralen Config-Datei zusammenzufassen.
Ciao,
Martin
Statt dessen gibts beim Apache jetzt bequeme Abschnittsdateien.
Ob das bequem ist, darüber kann man streiten.
Anfangs war ich auch "eher so mittelmäßig" begeistert.
Jörg Reinholz