Probleme mit TCPDF

[plakart]

Hallo,

nachdem ich heute das Update auf 2.81 gemacht habe, hat mir ein Kunde mitgeteilt, dass seine "Artikel drucken"-Funktion nicht mehr läuft.

Es kommt die folgende Fehlermeldung:
"TCPDF ERROR: [Image] No such file or directory in (...)"

Dabei wird unter (...) ein Link zu einer Grafikdatei im Ordner "/system/html/" aufgeführt. Diese Datei lässt sich aber manuell problemlos öffnen.

Die Rechte für den Ordner "/system/html/" habe ich geprüft. Ich habe auch das aktuelle Diagnose-Tool nochmal laufen lassen. Auch alles unauffällig.

Da das aktuelle Update nichts mit "TCPDF" zu tun hat, bin ich mir unsicher, ob das Problem wirklich erst seit heute besteht oder zufällig heute aufgefallen ist.

Leider habe ich im Forum nichts zu einem solchen Problem gefunden.

Für einen hilfreichen Tipp wäre ich dankbar.

Grüße, Jens

[plakart]

Ach so, kleiner Nachtrag: Bei Seiten, die keine Grafiken beinhalten läuft die "Artikel drucken"-Funktion einwandfrei.

[Hauge]

Hallo - habe gleiches Problem...
Hast Du schon eine Lösung?

Kurze Info (Vielleicht hilft es weiter):
Habe dompdf installiert - hier wird auf der pdf-seite das Bild nicht angezeigt.
Gibt man die Url aus der Fehlermeldung (ohne dompdf) manuell in den Browser ein, so erhält man aber das Bild...

[plakart]

Hallo.

Ja, habe es gelöst, lag allerdings nicht an Typolight sondern an den Apache-Einstellungen. Die Darstellungsfehler mit dompdf waren bei mir übrigens identisch, wie bei Dir.

Nachdem ich in der php.ini folgende Einstellungen ergänzt habe, lief es:

allow_url_fopen = On;
allow_url_include = On;

Ist vielleicht sicherheitstechnisch nicht so optimal, aber erstmal läuft es und wenn ich eine bessere Lösung finde, werde ich es mal posten.

Grüße, Jens

[Hauge]

Klappt - thnx - Hauge

[jan]

Eine andere Möglichkeit wäre, in /system/libraries/Controller.php folgende Zeilen hinzuzufügen:
line 973

$arrSearch = array
(
+	'/http:\/\/'.$_SERVER['HTTP_HOST'].str_replace('/', '\/', TL_PATH).'\//',
	'@(<pre.*</pre>)@Use',

line 984

$arrReplace = array
(
+	'/',
	'str_replace("\n", "<br />", "\\1")',

Dateien auf dem lokalen Host werden dann übers Dateisystem statt über HTTP geladen.

[okni]

Hallo,

gibt es schon eine Lösung des Problems?
Der Fehler kommt seit dem ich von 2.7.6 auf 2.8.1 geupdatet habe!
Bei mir geht der Druck mit Bild nicht aber ohne!?
Habe nicht DOMPDF installiert.

Am Anfang war ich von TL sehr angetan jetzt habe ich immer mehr Probleme mit banablen Sachen :-( Link in PDF Druck falsch, nach Update keine lightbox (wahrscheinlich wegen ner lumpigen meta.txt) PDF Druck mit Bildern geht nicht.
Sorry, is aber so.
Das soll ich mal den Kunden erzählen...

MfG
RW

ach so, nachtrag wer mir bitte diese Probleme lösen kann den bezahl ich gerne. ich bin nicht so der Programmierer, dafür ist ja auch ein CMS da, um nicht im Core was zu ändern und bei jedem Update schauen was wo wie geändert wurde. ne danke!
also, wer macht mir das! auf Rechnung! Danke!
Und gleich noch das kleine Lupe Bild auf die Vorschau-Bilder einbauen. Denn das geht auch nicht mehr. Da die entsprechend modifizierten Templates rausgeflogen sind. Die User sollen ja wissen, das die zum vergrößern sind.

[armin41]

Die Methode von jan funktioniert bei mir.

Ist leider nicht updatesicher!

[phochstr]

@Jan: Deine Methode funktioniert.
Hast Du das als Bug mit Lösungsvorschlag schon erfasst?

Vielen Dank & Grüsse
P.

[jan]

Nö, streng genommen ist das ja auch weder ein Bug, noch ist mein Patch eine verlässliche Lösung. Der Fehler tritt nur auf, wenn mit fopen keine HTTP-URLs geöffnet werden dürfen.
Mein Patch sorgt nur dafür, das lokale Bilder übers Dateisystem statt über HTTP eingebunden werden. Sobald externe Bilder verlinkt sind, tritt das Problem wieder auf.
Meint Ihr, man sollte das trotzdem melden?

Grüße
Jan

[althoffc]

Hallo,

bei mir funktioniert es leider nicht mit Jan's Lösung. Ich erhalte weiterhin eine Fehlermeldung, dass eine Bild-Datei nicht gefunden werden könne. Dabei wird der komplette, korrekte Pfad zu der Bilddatei angezeigt.

Es sind doch nur die zwei mit einem '+' gekennzeichneten PHP-Zeilen in Controller.php zu ergänzen, oder?

Kann es sonst noch einen Grund geben, dass es trotzdem nicht läuft?

Gruß
Carsten

PS: Was hat sich denn eigentlich zwischen 2.7.6 und 2.8.1 in diesem Punkt geändert? In 2.7.6 konnten ohne Probleme PDF-Dateien erzeugt werden, in 2.8.1 geht es nicht mehr. Kann das mit dem SMH zusammenhängen?

[xchs]

PS: Was hat sich denn eigentlich zwischen 2.7.6 und 2.8.1 in diesem Punkt geändert? In 2.7.6 konnten ohne Probleme PDF-Dateien erzeugt werden, in 2.8.1 geht es nicht mehr. Kann das mit dem SMH zusammenhängen?

Laut Changelog das hier:

Updated TCPDF to version 4.8.009 (#1033)

[althoffc]

Hallo xchs,

danke für die Info. Könnte es eventuell helfen, das tcpdf (<TL>/plugins/tcpdf) aus TL 2.7.6 zu verwenden? Da funktionierte bei mir alles.

Gruß
Carsten

[xchs]

danke für die Info. Könnte es eventuell helfen, das tcpdf (<TL>/plugins/tcpdf) aus TL 2.7.6 zu verwenden? Da funktionierte bei mir alles.

Kann ich Dir leider nicht genau sagen. Wäre aber auf Dauer auch keine Lösung...

[okni]

Ich habe die Zeilen eingefügt. Allerdings generiert er mir leere PDF´s?!

[Andreas]

Ich habe das Problem von okni gerade mithilfe von Post #6 gelöst, danke.

Wenn dem so ist, dass das Problem mithilfe von Post #4 behoben werden kann und für Betreiber, welche keinen Zugang zur php.ini habe mithilfe von Post #6. Sollte man dann nicht eine Möglichkeit finden, dass es standardmäßig auch dann funktioniert, wenn allow_url_fopen auf Off steht? Denn Post #6 geht ja nur über die Änderung einer Core-Datei und ist somit nicht updatesicher.

[Andreas]

Ich sehe gerade, dass es auf meinem Server jetzt mit Revision 275 auch nicht mehr geht.
allow_url_fopen = On
allow_url_include = Off
Das sind die Standardeinstellungen von PHP.

Mit dem Patch aus Post #6 geht's, aber die Links in der PDF beginnen anstatt mit
http://example.org/...
mit
file:///

Kann jemand bestätigen, dass es in Revision 275 mit
allow_url_fopen = On
allow_url_include = On
funktioniert?

[beduw]

kann mir jemand sagen in welchem verzeichnis ich die php.ini finde?

[Andreas]

/apache/bin/

[Brains]

... gibt es auch eine Lösung. 1&1 macht es einem ja bekanntlich nicht leicht, so verbieten sie beispielsweise den Einsatz von php_value und php_flag in der .htaccess, was mein erster Ansatz war um allow_url_fopen zu setzen. Allerdings erlauben sie php.ini-Datein auf Verzeichnisebene (was ihr Sicherheitskonzept m.E. ad absurdum führt aber das ist ein anderes Thema).
Wenn Ihr also Eure Typolight Webseite auf 1&1 hosten müsst und o.g. Problem auftaucht, legt einfach eine php.ini mit nachfolgendem Inhalt im DocRoot an:

#Allow fopen to use URLs
allow_url_fopen = On
allow_url_include = On

Nun noch die php.ini gegen ungewollten Download schützen indem man in die .htaccess folgendes einträgt:

##
# Disable download of php.ini
##
<Files "php.ini">
  deny from all
</Files>

HTH

[webseven]

Hallo zusammen

weshalb ist dies kein Bug? Damals wurde der SMH gebaut, damit TYPOlight auch auf shared-Serverlösungen laufen kann, bei denen php als Modul läuft. Das war einer der Schlüssel für die heutige Verbreitung des TL-CMS.

?Nach dem Update? läuft der Druck als PDF nicht mehr, wenn sich Bilder auf der Seite befinden. Also liegt das Problem doch nicht an der Serverlösung? Provider überlegen sich ja auch, weshalb sie gewisse Funktionen unterbinden.

Gruss aus der Schweiz
cy

[webseven]

Hallo zusammen

das Ticket zum Thema ist invalid (und ich brauche auch einen Rollstuhl)
Habe leider noch nicht kapiert, worauf das Problem eigentlich zurück zu führen ist. Als Photoshop-Dummie sehe ich einfach, vor dem Update lief es, nach dem Update nicht mehr. Kann mir jemand vielleicht verbalisieren, worauf ich meinen Provider ansprechen muss, dass das mit den Bildern im PDF wieder geigen tut?

Willkommen auf meinem sinkenden Schiff
cy

Hier der —> TYPOlight-Check

[leo]

allow_url_fopen = On;
allow_url_include = On;

Das ist auf keinen Fall die Lösung! Leider war das Ticket nicht besonders ausführlich, so dass das eigentliche Problem an mir vorbei ging. Selbstverständlich sollten interne Ressourcen nicht über http:// geladen werden. Fürs Erste hilft das Auskommentieren der Zeile 947 in der Datei system/libraries/Controller.php:

// $strArticle = $this->convertRelativeUrls($strArticle); 

Es sollten hier nur relative Links und nicht auch relative Bildpfade umgewandelt werden (im Gegensatz zu RSS-Feeds, wo auch die Bildpfade absolut benötigt werden).

[webseven]

Hi Leo

herzlichen Dank für die guten Neuigkeiten! Xgüsé für meinen lausigen Fehlerbeschrieb. Ist eben so, wenn man's nicht besser versteht.

Vielen Dank und beste Grüsse nach München
Hannes alias cy

[leo]

Mach Dir keine Gedanken, von einem nicht reproduzierbaren Fehler auf "allow_url_fopen" zu kommen liegt nicht gerade auf der Hand

[danielk]

Fürs Erste hilft das Auskommentieren der Zeile 947 in der Datei system/libraries/Controller.php:

// $strArticle = $this->convertRelativeUrls($strArticle); 

Diese Zeile ist in 2.8.2 nicht mehr vorhanden, richtig? Ich habe gerade auf diese Version geupdatet und leider funktioniert bei mir der PDF-Druck ebenfalls nicht. Beispiel: http://www.dipos.de/anleitung-displa...anbringen.html

Gruß Daniel

[xchs]

Diese Zeile ist in 2.8.2 nicht mehr vorhanden, richtig? Ich habe gerade auf diese Version geupdatet und leider funktioniert bei mir der PDF-Druck ebenfalls nicht. Beispiel: http://www.dipos.de/anleitung-displa...anbringen.html

TYPOlight v2.8.2: "/system/libraries/Controller.php" Zeile 947

[danielk]

Ich habe die Zeile auskommentiert, im Ergebnis funktioniert es leider nicht.

Der Firefox zeigt viele Zeichen, im IE wird lediglich das erste Bild in einer HTML Datei angezeigt.

[webseven]

hi danielk

mit etwas Geduld zur 2.8.3 wird der Fehler dank Leo's Bugfix behoben sein. Du könntest ja den PDF Ausdruck solange ausschalten. Ich lasse es bei der entsprechenden Problemseite so wie es ist und hoffe darauf, dass unterdessen niemand auf "PDF Ausdruck" klickt.

Grüsse
cy

PS: Grazie mille Leo für die Reparatur

[danielk]

Hallo cy,

so werde ich es machen, ist ja keine "lebenswichtige" Funktion ;-)

Gruß Daniel

[AndyOne]

Hallo,

ich habe das gleiche Problem. Sobald ein Bild im Artikel ist, kommt der Fehler
Warning: imagejpeg() [function.imagejpeg]: open_basedir restriction in effect. File(/tmp/jpg_EM9rEM) is not within the allowed path(s):....

Alle oben angesprochenen Änderungen in der Controller.php haben nichts bewirkt.

AndyOne

[downunder006]

Hallo,

würde das hier gerne nochmal aufwärmen.

Ich habe nämlich dieses Problem mit Version 2.8.3 und finde leider keine Lösung.

Warning: imagepng(): SAFE MODE Restriction in effect. The script whose uid is 10006 is not allowed to access /tmp/mska_pbLVsa owned by uid 30 in /srv/...xxx.../httpdocs/plugins/tcpdf/tcpdf.php on line 5533

TCPDF ERROR: [Image] No such file or directory in /tmp/mska_pbLVsa

Hat irgendjemand noch eine Idee ?

mfG

Volker

[do_while]

Hallo downunder006,

eigentlich steht es doch in der Meldung klar drin:
Der User 10006 (deine Installation) kann die gewünschte Datei im Verzeichnis /tmp nicht erstellen!
Das kann folgende Ursachen haben:

• Das Verzeichnis ist nicht vorhanden
• Das Verzeichnis hat keine Schreibrechte für den User
• Der tmp-Pfad ist für die gdlib nicht richtig definiert
• Der SafeMode verhindert den Zugriff (ungünstige PHP-Konfiguration)

Der Fehler kommt dann daher, das die nicht erstellte Datei nicht gelesen werden kann.
Bei welchem Provider bist Du?
Hast Du schon mal gesucht, ob es hier im Forum schon Ratschläge gibt?

[downunder006]

Hallo Hagen,

du sagst das so leicht, steht doch klar in der Meldung drin .

Also...

• Das Verzeichnis tmp muss doch im Verzeichnis system liegen oder ?!
  
• Das Verzeichnis tmp im Verzeichnis system hat volle Rechte (777)
  

• Der tmp-Pfad ist für die gdlib nicht richtig definiert

  Kannst du mir dazu noch etwas mehr sagen ?
  
• TYPOlight Safe Mode Hack (SMH) Check V1.0.1
  

  Current settings:
  
  FTP host     = xxx
  FTP username = xxx
  FTP password = ****** (hidden for security)
  FTP TL-path  = httpdocs/
  
  
  Warning: realpath(): SAFE MODE Restriction in effect. The script whose uid is 10006 is not allowed to access /tmp owned by uid 0 in /srv/...xxx.../httpdocs/smhcheck.php on line 69
  
  #0 [internal function]: __error(2, 'realpath(): SAF...', '/srv/www/vhosts...', 69, Array)
  #1 /srv/...xxx.../httpdocs/smhcheck.php(69): realpath('/tmp')
  #2 {main}
  
  System temporary dir:
  Checking tmpfile() ... success!
  Creating TYPOlight temporary file system/tmp/b5bfb2614defc78c7830ec0ef8af766b ... success!
  Connecting to FTP server ... success!
  Login with FTP username and password to server ... success!
  Check for correct directory ... success!
  Upload file httpdocs/smhcheck.dat ... success!
  Check file httpdocs/smhcheck.dat ... success!
  Delete file httpdocs/smhcheck.dat ... success!
  Create directory httpdocs/smhcheck.dir ... success!
  Delete directory httpdocs/smhcheck.dir ... success!
  Delete TYPOlight temporary file system/tmp/b5bfb2614defc78c7830ec0ef8af766b ... success!
  
  Safe Mode Hack is enabled and appears to be working.

• Was meinst du mit ungünstige PHP Konfiguration ?
  

Die Installation liegt übrigens auf einem eigenen Server.

Ich werde schonmal weiter suchen.

Gruß

Volker

[do_while]

Nach der Fehlermeldung ist das /tmp-Verzeichnis und nicht das system/tmp-Verzeichnis gemeint. In meinen Augen betrifft das den tmp-Pfad der PHP-Installation und hat so erstmal nichts mit TL/Contao zu tun.

So gut kenne ich mich mit Serverkonfigurationen auch nicht aus.
In einem Hosteurope-Beitrag findet man ähnliches:

putenv('TMPDIR='.ini_get('upload_tmp_dir'));

http://www.contao-community.de/showt...ghlight=tmpdir

Vielleicht ist das ein Tipp zur Fehlersuche.

[downunder006]

hallo,

also alleine komme ich erstmal nicht weiter.

Das muss also bis morgen warten.

Trotzdem danke @hagen

mfG

Volker

[downunder006]

Es ist ja wirklich das tmp der php-installation und da hat tcpdf jawohl eigentlich nichts zu suchen oder ?!

Warum arbeitet der denn nicht einfach im Contao Verzeichnis ?

[zonky]

Hallo,

per googlen habe ich zu der Fehlermeldung "TCPDF ERROR: Not a JPEG file" nichts gefunden.

Auf der Seite ist ein Akkordeon sowie ein Bild http://www.almconf.de/Agenda.html - auf anderen Seiten funktioniert die Sache...

Gruss zonky

[Andreas]

Firefox sagt mir, dass dieses Bild http://www.almconf.de/tl_files/almco..._anmeldung.jpg eine PNG-Grafik ist. Vielleicht hilft das ja.

Gruß Andreas

[zonky]

o.k.! das wars - habe den Redakteuren mal auf die Fuße getreten... ;-)

Dank und Gruss

zonky