Online wallet Mollie Ideal script

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • FangorN wrote:

      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.

      AarClay wrote:

      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: 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.
    • sjaakmans wrote:

      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?

      sjaakmans wrote:

      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.

      The post was edited 4 times, last by FangorN ().

    • FangorN wrote:

      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.......


      FangorN wrote:

      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.