nicht angemeldet tk
Der Martin
Rolf B
Rolf B
Rolf B
Rolf B
Der Martin
Der Martin
Der Martin
Rolf B
Der Martin
Rolf B
Hallo,
ich habe ein seltsames Problem. In einer Stelle meines Scriptes (das ein PDF generiert und dieses versendet), komme ich an diese Stelle:
Gunnar Bittersmannheader("Location:pdfmail.php?ID=$link&h=2$mahnstatuslink&$kopie_von_x");
Ok, ich weiß, dass die Weiterleitung per header:Location ansich absolute Links erwartet, aber es hat so seit 10 jahren funktioniert, weshalb ich diese Baustelle gerade mal beiseite lassen möchte.
Ich habe nun zu versendende PDFs, eines ist ein einseitiges PDF, das andere 2-seitig. Das ist wichtig, denn das einseitige läuft sauber in den Mailversand, das 2-seitige produziert einen Fehler (der aber nicht zu finden ist im Errorlog). Mache ich im DB-Backend aus dem 2-seitigen PDF ein einseitiges (durch Verringern der reinen Textmenge), so läuft auch dieses Dokument sauber in den Mailversand.
Konkret:
Dok1 (das einseitige) kommt an obige Weiterleitung mit folgenden Parametern:
Location:pdfmail.php?ID=a3d9eb1030cbe9fdea7bc3c5ca3f3170&h=2&kopie_von_x[]=6
Dok2 (das zweiseitige) kommt an obige Weiterleitung mit folgenden Parametern:
Location:pdfmail.php?ID=c538cecb2d21be7d5e60753de9ca04af&h=2&kopie_von_x[]=5
Nun gehe ich ins Empfängerscript und beginne das Script wie folgt:
<?php
echo("<PRE>");
print_r($_REQUEST);
echo("</PRE>");
exit;
Dok1 erzeugt daraufhin:
Array
(
[ID] => a3d9eb1030cbe9fdea7bc3c5ca3f3170
[h] => 2
[kopie_von_x] => Array
(
[0] => 6
)
)
Bei Dok2 erscheint eine leere weiße Seite.
Wo setze ich da nun an bei der weiteren fehlersuche?
Jörg
Moin,
Ok, ich weiß, dass die Weiterleitung per header:Location ansich absolute Links erwartet, […]
Nein, das ist nicht mehr so, siehe https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location#examples.
Bei Dok2 erscheint eine leere weiße Seite.
Ich würde mal vermuten dass nicht die Weiterleitung das Problem ist sondern das Script pdfmail.php – das wirft bei Dok2 vermutlich einen Fehler und das Script bricht ab. Wie sind error_reporting, display_errors und ggf. error_log eingestellt? Vielleicht musst du einfach die Ausgabe der Fehlermeldung einschalten (oder du hast im falschen Errorlog nachgeschaut).
Gruß
Tobias
Hallo Tobias,
Ok, ich weiß, dass die Weiterleitung per header:Location ansich absolute Links erwartet, […]
Nein, das ist nicht mehr so, siehe https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Location#examples.
Ach, ok, danke für den Hinweis.
Bei Dok2 erscheint eine leere weiße Seite.
Ich würde mal vermuten dass nicht die Weiterleitung das Problem ist sondern das Script pdfmail.php – das wirft bei Dok2 vermutlich einen Fehler und das Script bricht ab. Wie sind error_reporting, display_errors und ggf. error_log eingestellt? Vielleicht musst du einfach die Ausgabe der Fehlermeldung einschalten (oder du hast im falschen Errorlog nachgeschaut).
Hört sich für mich erstmal schlüssig an. Aber beim 2. Nachdenken überlege ich, dass ein script entweder mal grundsätzlich fehlerhaft ist und deshalb abbricht oder es läuft grundsätzlich und bricht an einer bestimmten Scriptstelle ab.
Wäre es grundsätzlich fehlerhaft, würde Dok1 nicht durchlaufen.
Würde es an einer bestimmten Stelle abbrechen, müsste es wenigstens die erstemn 10 zeilen (bis zum exit;) durchlaufen. Macht es aber nicht.
Meine Error-Reporting-Einstellungen stehen auf E_all
error_reporting(E_ALL);
ini_set("display_errors", 1);
Jörg
Hallo,
Bei Dok2 erscheint eine leere weiße Seite.
Ich würde mal vermuten dass nicht die Weiterleitung das Problem ist sondern das Script pdfmail.php – das wirft bei Dok2 vermutlich einen Fehler und das Script bricht ab. Wie sind error_reporting, display_errors und ggf. error_log eingestellt? Vielleicht musst du einfach die Ausgabe der Fehlermeldung einschalten (oder du hast im falschen Errorlog nachgeschaut).
Hört sich für mich erstmal schlüssig an. Aber beim 2. Nachdenken überlege ich, dass ein script entweder mal grundsätzlich fehlerhaft ist und deshalb abbricht oder es läuft grundsätzlich und bricht an einer bestimmten Scriptstelle ab.
nein, so einfach ist das Lied nicht. 😉
Das Script bekommt ja Parameter und erzeugt abhängig von denen eine andere Ausgabe. Also kann auch das Auftreten von Fehlern von eben diesen Parametern (und sonstigen Eingabedaten) abhängig sein.
Würde es an einer bestimmten Stelle abbrechen, müsste es wenigstens die erstemn 10 zeilen (bis zum exit;) durchlaufen. Macht es aber nicht.
Wie stellst du das fest?
Einen schönen Tag noch
Martin
Hi Martin,
nein, so einfach ist das Lied nicht. 😉
Das Script bekommt ja Parameter und erzeugt abhängig von denen eine andere Ausgabe. Also kann auch das Auftreten von Fehlern von eben diesen Parametern (und sonstigen Eingabedaten) abhängig sein.
Wie geht denn der php-Interpreter vor? Guckt der, wie weit er (individuell) kommen muss oder guckt der, ob er auf seinem Pfad einen Fehler findet? Und wie soll ich debuggen, wenn er nichtmal Zeile 1 ausführt und stattdessen sofort abbricht, ich aber keine Fehlermeldung erruieren kann?
Würde es an einer bestimmten Stelle abbrechen, müsste es wenigstens die erstemn 10 zeilen (bis zum exit;) durchlaufen. Macht es aber nicht.
Wie stellst du das fest?
Na, schrieb ich ja. Ich schaue, was mir php ausgibt... und das ist im Fall des Dok2 mal eine ganz gepflegte leere Seite. 😟
Jörg
Hallo Jörg,
bestimmte Codefehler führen zum sofortigen Abbruch, aber dann bricht das Script immer ab, unabhängig von Parametern. Z.B. unpaarige geschweifte Klammern oder Anführungszeichen. Vergessene Semikolons auch. Bei solchen Fehlern hilft Dir auch kein error_reporting oder ini_set("display_errors"), weil er da gar nicht hinkommt.
Wenn Du an die PHP Settings nicht herankannst, könntest Du Dir so behelfen: Schreib ein "get_getmail.php" mit diesem Inhalt:
<?php
error_reporting(E_ALL);
ini_set("display_errors", 1);
echo "Lade getmail.php<br>";
include "getmail.php";
Und rufe die get_getmail.php Seite ab. Dann wird erstmal alles aufgedreht, und dann sollte man auch Compile-Fehler sehen.
Wenn Du auf deinem Server keinen Fehler findest, lass es bei Dir gegen das lokale PHP laufen (auf der Befehlszeile, mit php -l -f getmail.php). Der -l Parameter steht für "Lint" oder "nur Syntax-Check".
Eine PHP IDE mit Syntax-Check ist auch hilfreich. Z.B. VSCode, der kann das, wenn er richtig konfiguriert ist.
Sobald es anläuft, ist nur noch der Code-Teil bis zum exit relevant. Aber den müsste man dann genau anschauen.
Rolf
Hallo Jörg,
bestimmte Codefehler führen zum sofortigen Abbruch, aber dann bricht das Script immer ab, unabhängig von Parametern. Z.B. unpaarige geschweifte Klammern oder Anführungszeichen. Vergessene Semikolons auch. Bei solchen Fehlern hilft Dir auch kein error_reporting oder ini_set("display_errors"), weil er da gar nicht hinkommt.
Das würde mir php-Storm aber schon anzeigen.
Sobald es anläuft, ist nur noch der Code-Teil bis zum exit relevant. Aber den müsste man dann genau anschauen.
Den hatte ich ja gepostet.
Jörg
Hallo Jörg,
müsste es wenigstens die erstemn 10 zeilen (bis zum exit;) durchlaufen
Dann zeig die doch mal, alle.
Du hast nur 5 Zeilen gezeigt. Für die gezeigten 5 gilt deine Aussage: Entweder es läuft, oder es läuft nicht. Aber wenn es 10 sind...
Da dein print_r($_REQUEST); nur zu Debug-Zwecken drin ist, verkneife ich mir die htmlspecialchars-Predigt 😉
Was ist übrigens, wenn Du deine pdfmail.php Seite direkt abrufst statt über einen Redirect? Bei error_reporting(E_ALL); + ini_set("display_errors", 1); SOLLTEN eigentlich Fehler auffallen, es sei denn, da fliegt eine Exception und du catchst sie weg.
Rolf
Hallo Rolf,
müsste es wenigstens die erstemn 10 zeilen (bis zum exit;) durchlaufen
Dann zeig die doch mal, alle.
Du hast nur 5 Zeilen gezeigt. Für die gezeigten 5 gilt deine Aussage: Entweder es läuft, oder es läuft nicht. Aber wenn es 10 sind...
Sorry, ich habe die Zeilen nicht gezählt... 10 Zeilen war geschätzt.
Was ist übrigens, wenn Du deine pdfmail.php Seite direkt abrufst statt über einen Redirect? Bei error_reporting(E_ALL); + ini_set("display_errors", 1); SOLLTEN eigentlich Fehler auffallen, es sei denn, da fliegt eine Exception und du catchst sie weg.
Bei Dok1 läuft meine pdfmail.php ja wunderbar durch.
Und sie läuft ja selbst bei Dok2 durch, wenn ich im DB-Backend etwas Text aus einer Tabellenspalte nehme, sodass das Dok2 im Prozess des Generierens auf eine Seite reduziert wird (von zuvor 2 Seiten).
Also sollte das Script selber grundsätzlich stimmen.
Jörg
Hallo Jörg,
wenn Du aber an den Anfang die von Dir gezeigten 5 Zeilen stellst, und auch dann - je nach Parametern - eine weiße Seite bekommst, dann muss das Problem außerhalb deines Scripts liegen.
Unbeholfenes Rumraten ist da zumeist wenig ergiebig.
PHPStorm zeigt auch nicht alles. Ein gescheiterter Include oder Require beispielsweise fällt erst zur Laufzeit auf, und wenn dein Code auf die DB zugreift und je nach DB-Inhalten auf SQL Fehler stösst, die dein Script abbrechen lassen, merkt der das auch nicht. Ich meine mich zu erinnern, dass die SQL-haltigen Snippets, die Du uns früher mal gezeigt hast, Errorhandling vermissen ließen. Aber das kann auch ein Irrtum sein.
An der PDF Seitenzahl kann es nur dann liegen, wenn dein PDF-Generator beim Seitenumbruch abkackt. Hast Du da Callbacks oder so drin, die beim Umbruch aktiv werden?
Weitere Ansätze
-> https://www.php.net/manual/de/errorfunc.configuration.php#ini.log-errors
-> https://www.php.net/manual/de/errorfunc.configuration.php#ini.error-log
Mit dem Browser in den Sourcecode der weißen Seite geschaut? Stehen da versteckte Überreste drin?
Wenn Du PDFs erzeugst, müsstest Du ja auch einen Content-Type Header setzen. Ersetze das versuchsweise durch text/plain, und such dann in dem, was im Browser ankommt (ist hoffentlich etwas) nach Fehlern
Du könntest meine get_getmail.php Idee auch dahingehend erweitern, dass Du einen Error-Handler einrichtest und den Fehler, den Du damit möglicherweise fängst, in die Ausgabe schreibst. Zusätzlich könntest Du auch einen Exception-Handler für ungefangene Exceptions setzen.
Diese beiden Handler kannst Du auch zu Beginn deines regulären getmail.php installieren und immer mitlaufen lassen. Oder verwendest Du solche Handler schon? Dann bau da was ein, dass Errors an geeigneter Stelle protokolliert werden.
Rolf
Hallo Rolf,
bin leider grad auf dem Sprung, wollte Dir nur Rückmeldung geben, dass ich Deine Tips morgen ausprobieren werde und mich beschweren, denn...
Ich meine mich zu erinnern, dass die SQL-haltigen Snippets, die Du uns früher mal gezeigt hast, Errorhandling vermissen ließen. Aber das kann auch ein Irrtum sein.
... das ist definitiv ein Irrtum 🤭😉
Ich habe ein ganz gescheites SQL - Errorhandling eingebaut. M it Logs und allem "pi-pa-po" 😉
Bis später wieder...bin echt gespannt, woran es diesmal hakt.
Jörg
Hallo Jörg,
Ich habe ein ganz gescheites SQL - Errorhandling eingebaut. M it Logs und allem "pi-pa-po"
Dann ist ja gut. Dann muss dein Errorhandling jetzt nur noch PHP Errors entdecken und protokollieren 😝.
Rolf
Hi,
Ich habe ein ganz gescheites SQL - Errorhandling eingebaut.
und zwei Deppenleerzeichen. Merke: Ein Bindestrich ist niemals von Trennzeichen (Blanks) eingerahmt. Denn dann bindet er nicht, sondern trennt.
Dann muss dein Errorhandling jetzt nur noch PHP Errors entdecken und protokollieren 😝.
Am besten auch noch gleich korrigieren.
Einen schönen Tag noch
Martin
Hi,
Ich habe ein ganz gescheites SQL - Errorhandling eingebaut.
und zwei Deppenleerzeichen. Merke: Ein Bindestrich ist niemals von Trennzeichen (Blanks) eingerahmt. Denn dann bindet er nicht, sondern trennt.
Wie war das mit den Korinthen? 😉
Trotzdem schön, das einmal zu wissen.👍
Ist das tatsächlich "offiziell"?
Wobei, was heißt heutzutage in Zeiten dieses fürchterlich-ideologischen Genderwahns in der deutschen Sprache schon "offiziell"? 😕
Jörg
Hallo,
Merke: Ein Bindestrich ist niemals von Trennzeichen (Blanks) eingerahmt. Denn dann bindet er nicht, sondern trennt.
Wie war das mit den Korinthen? 😉
dafür hat wohl extra mal jemand das Tag klugscheißerei eingeführt.
Trotzdem schön, das einmal zu wissen.👍
Ist das tatsächlich "offiziell"?
Das Weglassen der Leerzeichen? Ja. Leerzeichen werden nach Interpunktionszeichen wie Komma, Punkt, Fragezeichen, Ausrufezeichen u.v.m. gesetzt (aber niemals davor).
Außerdem vor öffnenden und nach schließenden Klammern, sofern das nicht der vorherigen Regel widerspricht.
In der Ära der Schreibmaschinen-Typographie galt auch die Regel, dass ein Bindestrich, der von zwei Leerzeichen eingerahmt ist, als Gedankenstrich galt. Und in Fällen, wo nur der ASCII-Zeichensatz zur Verfügung steht, wird das heute noch so praktiziert.
Einen schönen Tag noch
Martin
Hallo Martin,
und weil das hier ein Forum ist, wo Beiträge per Default in einem Monospace-Font erstellt werden und sich ein Leser auch zum Lesen einen Monospace-Font einstellen kann, finde ich jegliche Diskussion über Typographie in Forenbeiträgen komplett abwegig. Weshalb ich Dir ein - (-) verehrt hatte. Vielleicht auch ein − (−) oder – (–).
Rechtschreibung ist was anderes, aber auch da gilt eigentlich die uralte Netiquette-Regel: Wer Rechtschreibfehler findet, darf sie gerne behalten, sollte aber nicht drüber reden. Das Selfforum ist traditionell eine Ausnahme, aber keine rühmliche.
Dieses Posting gilt nicht für Typo- und Orthographie auf publizierten Webseiten…
Rolf
Hallo Rolf,
und weil das hier ein Forum ist, wo Beiträge per Default in einem Monospace-Font erstellt werden und sich ein Leser auch zum Lesen einen Monospace-Font einstellen kann, finde ich jegliche Diskussion über Typographie in Forenbeiträgen komplett abwegig.
was ist das für ein Zusammenhang?
Plenken ist bei einem Monospace-Font ebenso störend wie bei einem Proportionalfont.
Weshalb ich Dir ein - (-) verehrt hatte. Vielleicht auch ein − (−) oder – (–).
Ach du warst das. Von mir aus.
Rechtschreibung ist was anderes, aber auch da gilt eigentlich die uralte Netiquette-Regel: Wer Rechtschreibfehler findet, darf sie gerne behalten, sollte aber nicht drüber reden.
Da bin ich 180° anderer Ansicht. Im Netz ebenso wie IRL.
Dieses Posting gilt nicht für Typo- und Orthographie auf publizierten Webseiten…
Ich mache da keinen Unterschied.
Einen schönen Tag noch
Martin
@@Der Martin
Rechtschreibung ist was anderes, aber auch da gilt eigentlich die uralte Netiquette-Regel: Wer Rechtschreibfehler findet, darf sie gerne behalten, sollte aber nicht drüber reden.
Da bin ich 180° anderer Ansicht.
Ich bin da 90° anderer Ansicht und würde da unterscheiden.
🖖 Живіть довго і процвітайте
Hallo,
Rechtschreibung ist was anderes, aber auch da gilt eigentlich die uralte Netiquette-Regel: Wer Rechtschreibfehler findet, darf sie gerne behalten, sollte aber nicht drüber reden.
Da bin ich 180° anderer Ansicht.
Ich bin da 90° anderer Ansicht und würde da unterscheiden.
an typische Tippfehler[1] (Buchstbaendreher, eine Taste daneven) hatte ich dabei nicht gedacht. Die zähle ich nicht zu den eigentlichen Rechtschreibfehlern.
Trotzdem lasse ich sie auch in einem Forenbeitrag nicht einfach stehen, sondern korrigiere sie vor dem Absenden. Geschätzte 90% davon bemerke ich beim Korrekturlesen; ab und zu geht mir aber mal einer durch die Lappen.
Einen schönen Tag noch
Martin
Geht das schon als Pleonasmus durch? 😉 ↩︎
@@Der Martin
Trotzdem lasse ich [Tippfehler] auch in einem Forenbeitrag nicht einfach stehen, sondern korrigiere sie vor dem Absenden.
Ich meist erst danach. 😄 Gut, dass das jetzt geht.
BTW, ich hab in dieses Posting noch was reineditiert.
🖖 Живіть довго і процвітайте
@@Der Martin
dafür hat wohl extra mal jemand das Tag klugscheißerei eingeführt.
Kann man in seinen Nutzereinstellungen Postings mit bestimmten Tags nicht automatisch abonnieren, damit man sie nicht übersieht? 🤔😆
Ja. Leerzeichen werden nach Interpunktionszeichen wie Komma, Punkt, Fragezeichen, Ausrufezeichen u.v.m. gesetzt (aber niemals davor).
Sag das mal den Franzosen! SNCF äh SCNR.
In der Ära der Schreibmaschinen-Typographie galt auch die Regel, dass ein Bindestrich, der von zwei Leerzeichen eingerahmt ist, als Gedankenstrich galt. Und in Fällen, wo nur der ASCII-Zeichensatz zur Verfügung steht, wird das heute noch so praktiziert.
Protip: Das hiesige Forum ist kein solcher Fall, wo nur der ASCII-Zeichensatz zur Verfügung steht. 😉
In Zeiten von Unicode und UTF-8 sollte solch ein Fall auch nirgendwo mehr auftreten.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
allerdings ertappe ich mich gelegentlich auch beim absichtlichen Plenken. Je nach dem, mit welchem Font eine Seite Dinge darstellt, ist ein Ausrufezeichen kaum erkennbar.
Es ist eine Qual! – Er gewinnt die Quali! – hier geht das gerade noch, auf Github dagegen könnte ich l, i und ! kaum unterscheiden. Mag natürlich auch an meinen trüben Augen liegen.
Rolf
Wobei, was heißt heutzutage in Zeiten dieses fürchterlich-ideologischen Genderwahns in der deutschen Sprache schon "offiziell"? 😕
Du könntest auch versuchen selber voran zu gehen, und die Debatte weniger ideologisch führen, zum Beispiel indem du auf politische Kampfbegriffe wie "Genderwahn" verzichtest. Ich will das Thema hier nicht schon wieder[1][2] aufrollen, aber ich möchte solche Seitenhiebe auch nicht unkommentiert lassen.
Hallo,
Bis später wieder...bin echt gespannt, woran es diesmal hakt.
Jetzt habe ich eine Lösung, aber den Fehler nicht. Das ist nicht schön.
Beim Generieren der 2. Seite des PDF wird eine Datei second.php eingebunden.
Diese öffnet mit <?php und schließt mit ?> . Wenn ici das (eigentlich ja nicht nötige) schließende ?> heraus nehme, dann läuft mein Script sauber durch.
Ich weiß dann aber immer noch nicht, warum das so ist, denn ich nutze das Script schon seit x Jahren und habe und hatte das schließende ?> bisher immer in der second.php drin. Nur bei dieser installation dieses Scriptes ist das anders.
Und nun?
Jörg
Hallo Jörg,
Beim Generieren der 2. Seite des PDF wird eine Datei second.php eingebunden.
Diese öffnet mit
<?phpund schließt mit?>. Wenn ici das (eigentlich ja nicht nötige) schließende?>heraus nehme, dann läuft mein Script sauber durch.
ah, ein alter Bekannter! Nach dem schließenden ?> folgt bestimmt noch ein Blank oder ein Zeilenumbruch. Diese Zeichen werden dann 1:1 ausgegeben.
Ich weiß dann aber immer noch nicht, warum das so ist, denn ich nutze das Script schon seit x Jahren und habe und hatte das schließende ?> bisher immer in der second.php drin. Nur bei dieser installation dieses Scriptes ist das anders.
Schau mal nach, ob ich mit meiner Vermutung recht habe,
Und nun?
Lass das schließende PHP-Tag weg. Das ist durchaus eine "good practise".
Einen schönen Tag noch
Martin
Hallo Martin,
Das ist durchaus eine "good practise".
Ich würde das sogar als eine Nutzungsvorschrift sehen. Aus genau dem Grund, den Du genannt hast.
PSR-1 formuliert das so:
Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both.
Eine includete Datei, die Code enthält und auf ?> endet, produziert mit 99% Sicherheit einen Output hinter dem ?>, es sei denn, man hat einen Editor mit dem man tatsächlich den Zeilenumbruch hinter dem letzten ?> entfernen kann; die sind seltenst zu finden. Möglicherweise war die second.php mal so getrimmt, dass hinter dem letzten ?> nichts mehr kam. Und nun, beim Kopieren oder einem unachtsamen Editieren, ist ein Linefeed hineingekommen, der nun das PDF ruiniert.
Output hinter einem ?> am Dateiende kann in seltenen Fällen unschädlich sein, zumeist ist er aber eine Spaßbremse.
Für Jörg ist aber auch die Frage: ist der PHP Code in second.php "lokal"? Oder werden da Funktionen deklariert, die auch außerhalb von second.php genutzt werden? In dem Fall gehört das Ding geteilt, nach den Maßgaben von PSR-1. Das ist ein durchaus sinnvoller Coding-Styleguide für PHP.
Wenn alles PHP im second.php aber nur innerhalb von second.php genutzt wird, dann ist das ok - weil es dann ein include "with side-effects" ist.
Ein Include, das Funktionen für übrige Programmteile bereitstellt, muss gemäß PSR-1 aber nach außen hin "stumm" sein, d.h. außer dem Erstellen von Variablen, Funktionen, Klassen und Konstanten darf es nichts tun. Das gilt natürlich nicht für die Inhalte der Funktionen und Methoden in den Klassen. Wenn die aufgerufen werden, aber nur dann, dürfen sie sich austoben.
Rolf
Hi Rolf,
Das ist durchaus eine "good practise".
Ich würde das sogar als eine Nutzungsvorschrift sehen. Aus genau dem Grund, den Du genannt hast.
Mach ich auch länger schon so, das hatte mir dedlfix schonmal nahe gelegt. Jetzt aber hatte ich die Datei nur "kopiert".
Möglicherweise war die second.php mal so getrimmt, dass hinter dem letzten ?> nichts mehr kam. Und nun, beim Kopieren oder einem unachtsamen Editieren, ist ein Linefeed hineingekommen, der nun das PDF ruiniert.
Genau so ists passiert.
Für Jörg ist aber auch die Frage: ist der PHP Code in second.php "lokal"? Oder werden da Funktionen deklariert, die auch außerhalb von second.php genutzt werden? In dem Fall gehört das Ding geteilt, nach den Maßgaben von PSR-1. Das ist ein durchaus sinnvoller Coding-Styleguide für PHP.
Nein, die second.php ist ne ganz liebe. Die macht nichts weiter, als ein paar Logos und ein wenig Schrift einzubinden.
Jörg
Hi Martin,
Schau mal nach, ob ich mit meiner Vermutung recht habe,
Hast Du. 👍
Das genau machte den Unterschied.
Aber wie wird sowas protokolliert? Also wie hätte ich diesen fehler schneller debuggen können als ichs gemacht habe?
Jörg
Hallo Jörg,
Schau mal nach, ob ich mit meiner Vermutung recht habe,
Hast Du. 👍
Das genau machte den Unterschied.
das ist tatsächlich ein häufiges Problem. Darüber stolpert so ziemlich jeder, der mit PHP mal etwas anderes generiert als nur HTML-Output.
Aber wie wird sowas protokolliert? Also wie hätte ich diesen fehler schneller debuggen können als ichs gemacht habe?
Hmm. Die Weiterleitung löst du doch bestimmt aus, indem du den Location-Header mit der PHP-Funktion header() setzt. Und genau da hätte in deinem Fall in der Ausgabe bzw. im Error-Log von PHP die Meldung "Cannot modify header information - headers already sent" erscheinen müssen. Denn mit dem ersten Zeichen, das ein PHP-Script ausgibt, werden alle HTTP-Header gesendet.
Einen schönen Tag noch
Martin
Hallo Martin,
Hmm. Die Weiterleitung löst du doch bestimmt aus, indem du den Location-Header mit der PHP-Funktion header() setzt. Und genau da hätte in deinem Fall in der Ausgabe bzw. im Error-Log von PHP die Meldung "Cannot modify header information - headers already sent" erscheinen müssen. Denn mit dem ersten Zeichen, das ein PHP-Script ausgibt, werden alle HTTP-Header gesendet.
Ja, diese meldung kenne ich. Im vorliegenden fall ist sie aber nicht erschienen.
Jörg
Hallo Jörg,
hast Du mal eins von diesen beiden Dingen probiert, die ich gestern schrub? Vielleicht erkennt man dann mehr. Wenn deine Response mit application/pdf (oder so) ankommt, rennt der PDF-Viewer im Browser los, und wenn der kein valides PDF findet, könnte es durchaus sein, dass er die Arbeit verweigert.
Mit dem Browser in den Sourcecode der weißen Seite geschaut? Stehen da versteckte Überreste drin? Bzw. man könnte auch in den Netzwerktools in den Inhalt der Response schauen.
Wenn Du PDFs erzeugst, müsstest Du ja auch einen Content-Type Header setzen. Ersetze das versuchsweise durch text/plain, und such dann in dem, was im Browser ankommt (ist hoffentlich etwas) nach Fehlern
Rolf