error 500 codes maar geen errorlog
Dan zou ik eens kijken hoe dat zit, anders valt er niet zoveel te analyseren.
Een error_log houdt elke webserver wel bij. Of en hoe je erbij kan, hangt van het hostingplatform af. En anders kan je zit wel beïnvloeden met een simpele .htaccess of php.ini. Afhankelijk wat je webserver draait (zie daarvoor de output van phpinfo() en kijk naar de 'Server API' ).
https://perishablepress.com/ho…ror-logging-via-htaccess/
https://mediatemple.net/commun…error-logging-via-php.ini
Dat is wel een artikel uit 2008.
Wanneer PHP in CGI-modus draait dan resulteren het gebruik van php_flag en php_value blijkbaar in internal server errors.
Mogelijk kun je wel een php.ini instellen, of een .htaccess-bestand gebruiken, maar dan wel met het formaat <setting> = <waarde>.
Maar alle relevante directives (error_reporting, display_errors, display_startup_errors, error_log, meer?) zijn overal instelbaar (PHP_INI_ALL) dus je zou dit net zo goed in PHP zelf kunnen doen, bijvoorbeeld met een switch-statement op grond van $_SERVER['SERVER_NAME'], zodat je één configuratiebestand hebt voor alle omgevingen, in plaats van serverspecifieke .htaccess-bestanden die je wellicht per ongeluk overschrijft met alle gevolgen van dien.
Ook kan je dergelijke PHP-scripts overschrijven... 
Welke aanpak iemand kiest is net wat iemand fijner vindt. Blijkbaar kies jij voor het laatste. Maar ik vind dit meer een taak voor de webserver i.p.v. een eigen PHP-script. En helemaal als dit niet op userniveau wordt ingesteld.
Ook kan je dergelijke PHP-scripts overschrijven...
Yup. Maar een config.php overschrijven met een config.php waar de informatie van alle omgevingen in zit heeft geen effect. Een .htaccess die je van dev/test naar productie kopieert heeft meestal verstrekkendere gevolgen.
Bijkomend voordeel: deze config.php kun je zelfs versionen. Het .htaccess bestand niet, omdat die per omgeving verschillende inhoud heeft.
Dit is naast persoonlijke voorkeur dus ook een stuk minder foutgevoelige oplossing.
Taak voor de webserver? Dunno - dit zijn applicatie-instellingen. Die lijken mij thuishoren... in de applicatie.
Je kan ze ook apart loggen, en zelf bijvoorbeeld er een ErrorID aan hangen, zodat je fouten makkelijker kan terughalen, als iemand je de foutcode doorgeeft.
Maar persoonlijk vind ik het iets van de webserver die het hoort te loggen. Er kan immers ook wat aan die kant fout gaan wat gelogd dient te worden.
Maar ook hier verschillen de meningen en is er niet één beste en vaste oplossing.
Heb recentelijk nog een Mollie betalingsysteem opgezet. Als je de error hier neer zet kan ik je mogelijk helpen.
Bijkomend voordeel: deze config.php kun je zelfs versionen. Het .htaccess bestand niet, omdat die per omgeving verschillende inhoud heeft.
Ik ben het hier niet mee eens. Stel je werkt samen met meerdere partijen, die hebben dan gelijk al je gegevens als je je config meestuurt naar bijvoorbeeld git. Een .htaccess daarentegen kan standaard waarde bevatten voor zowel de live- als testomgeving.
Je kan ze ook apart loggen, en zelf bijvoorbeeld er een ErrorID aan hangen, zodat je fouten makkelijker kan terughalen, als iemand je de foutcode doorgeeft.
Maar persoonlijk vind ik het iets van de webserver die het hoort te loggen. Er kan immers ook wat aan die kant fout gaan wat gelogd dient te worden.
Zelf error id’s maken duurt alleen maar lang. Gewoon een foutmelding geven van dat het verkeerd is gegaan en eventueel het bericht weergeven van de exceptie.
Het lijkt mij niet logisch als je webserver echt alle errors logt. Het is juist handiger om die te loggen met behulp van php. Zo krijg je totale controle plus je kunt alles wegschrijven naar een log of een dienst zoals sentry.
Php heeft een standaard functie daarvoor: http://php.net/manual/en/function.set-error-handler.php. Als je een framework zoals symfony gebruikt zit dit er standaard al in.
Mollie zelf gooit ook excepties, die zou je nog kunnen afvangen en kijken wat daar in staat.
Stel je werkt samen met meerdere partijen, die hebben dan gelijk al je gegevens als je je config meestuurt naar bijvoorbeeld git. Een .htaccess daarentegen kan standaard waarde bevatten voor zowel de live- als testomgeving.
Sja, je kunt altijd uitzonderingen verzinnen.
Maar laten we dit eens verder analyseren. Wat zou hier dan op zijn minst instaan? Database credentials waarschijnlijk. Hoe erg is dat? Een lokale ontwikkelomgeving kom je niet bij, een test/acceptatie-omgeving: misschien? Als je externe connecties accepteert en/of phpMyAdmin (lol) hebt draaien ofzo kunnen ze bij de database. Wat voor baat zou een gelieerde partij hebben bij het ingooien van jullie gezamenlijke ruiten? En als blijkt dat je geen afspraken kunt maken met zo'n partij dan is het hek sowieso van de dam. De live omgeving? Daar kunnen jullie als het goed is allebei bij als je samen ontwikkelt.
Probleem?
Het lijkt mij niet logisch als je webserver echt alle errors logt.
Errors zijn er niet voor niets. Zolang je ze logt op de goede plek zie ik geen probleem. Servergerelateerde errors horen in een log thuis die zich bezighoudt met de gesteldheid van de server. Applicatiegerelateerde errors (en exceptions) horen thuis in logs die toegespitst zijn op het wel en wee van je applicatie. Zolang je zelf wat overzicht creëert kun je bijhouden wat je wilt zonder dat je door de bomen het bos niet meer ziet.
Natuurlijk kun je tunen wat je logt. Maar iets op voorhand onder het tapijt vegen lijkt mij geen goede strategie. Ik heb liever dat ik alle meldingen en waarschuwingen aan heb staan en dat ik geen meldigen krijg dan dat ik de helft uitzet en eigenlijk niet weet wat ik negeer.
Sja, je kunt altijd uitzonderingen verzinnen.
Maar laten we dit eens verder analyseren. Wat zou hier dan op zijn minst instaan? Database credentials waarschijnlijk. Hoe erg is dat? Een lokale ontwikkelomgeving kom je niet bij, een test/acceptatie-omgeving: misschien? Als je externe connecties accepteert en/of phpMyAdmin (lol) hebt draaien ofzo kunnen ze bij de database. Wat voor baat zou een gelieerde partij hebben bij het ingooien van jullie gezamenlijke ruiten? En als blijkt dat je geen afspraken kunt maken met zo'n partij dan is het hek sowieso van de dam. De live omgeving? Daar kunnen jullie als het goed is allebei bij als je samen ontwikkelt.
In mijn ogen heb je hier precies het probleem te pakken. Dus als jij met iemand samen werkt moet die persoon zich maar aanpassen aan jouw credentials. De hele database omgooien en dat soort zaken.
Je moet dit juist uit je git omgeving, of wat dan ook, houden. Zeker als je ook nog eens gebruik maakt van automatisch deployen. Dan staan je test credentials op de live server, of vise versa. Ideaal.......
Errors zijn er niet voor niets. Zolang je ze logt op de goede plek zie ik geen probleem. Servergerelateerde errors horen in een log thuis die zich bezighoudt met de gesteldheid van de server. Applicatiegerelateerde errors (en exceptions) horen thuis in logs die toegespitst zijn op het wel en wee van je applicatie.
Ja dan zeg je toch precies wat ik zeg? Met die PHP error handler kun je ze juist mooi opvangen en wegschrijven. De webserver laat namelijk niet altijd de PHP errors in de log zien of een ingekorte versie.
Een dienst als Sentry geeft juist extra input die altijd handig is. Zoals welke data was ingevuld bij een formulier wat er verkeerd ging. Maakt het fixen van je probleem wel een stuk gemakkelijker.
Hierbij doe je een aantal aannames die deze opzet ook min of meer onmogelijk maakt he:
- je werkt samen
- je maakt gebruik van git (of een soort van "gedeeld" versioning systeem)
- er is geen mechanisme om standaard configuratie te overrulen
Op die manier kan ik ook voorwaarden verzinnen die elke aanpak buiten spel zet. Als jij de enige partij bent die een applicatie ontwikkelt en beheert werkt dit prima. En uiteraard moet je jezelf niet vastprogrammeren zodat dingen niet meer flexibel zijn. Dat heb ik ook nooit voorgesteld.
Maar nogmaals, daar ging deze hele thread niet over. De topicstarter moet gewoon zorgen dat 'ie fouten kan opvangen, anders kun je niet eens beginnen met een analyse van het probleem.
Heb je nog geen account? Registreer je nu en word deel van onze community!
