views_pdf - Link für SaveAs-Dialog ohne Browser-Ansicht ?
Eingetragen von tetri999 (153)am 20.03.2015 - 17:49 Uhr in
Hallo,
mit dem views_pdf-Modul erzeuge ich ein PDF mit der aktuellen Node-ID als Kontext-Filter ( ein PDF-Page-display mit Pfad "/mypdf/%" ).
Das funktioniert so weit mit diesem Pfad.
Nun will ich einen Link erzeugen, der das erzeugte PDF aufruft - aber nicht zur Ansicht im Browser, sondern gleich einen SaveAs-Dialog.
Hier habe ich gefunden:
1) Add this to the last "PHP Code After Output" box
$this->view->pdf->Output("YOUR PDF NAME");
This should go at the very end of any code. As far as I can tell, nothing after it will be rendered.
Außerdem:
In der TCPDF-Dokumentation gibt es zu
TCPDF::Output ( $name = 'doc.pdf', $dest = 'I' )
als Varianten zu $dest:
...
D: send to the browser and force a file download with the name given by name
...
Wenn ich nun wie oben den Link mit dem Pfad aufrufe, wird das PDF natürlich angezeigt, aber kein SaveAs.
Kann mir jemand sagen, wie man den Link anlegen muß, so daß nur der SaveAs-Dialog erzeugt wird?
mfG, Michael
- Anmelden oder Registrieren um Kommentare zu schreiben
Du kannst das über die JQuery
am 20.03.2015 - 21:55 Uhr
Du kannst das über die JQuery machen.
Dazu ergänzt du einfach bei dem Link auf der Seite ein Attribut: download, welches den Namen deiner PDF-Datei enthält.
Tja, die kleinen Wunder von HTML5 machen es möglich :-)
Gruß
Berthold
um das mit jQuery zu machen,
am 21.03.2015 - 13:20 Uhr
müßte das PDF erstmal irgendwo gespeichert sein.
Also, der Ablauf ist folgender:
1. es gibt ein views-display (mit dem views_pdf Modul erzeugte PDF-Page), dieses views-display hat den Pfad "/summary/%" und die aktuelle (Content-) NodeID als Contextual-Filter.
2. diese view stellt bestimmte Felder des über die NodeID bestimmten Content-Nodes zusammen, die dann in dem PDF ausgegeben werden sollen.
3. der Content selber ( unter ".../node/[NID]" ) enthält u.a. eine Multistep-Webform als Block, wo der User einiges eintragen kann, was dann mit in das PDF soll.
auf der letzten Seite (Step 3) wird eine Zusammenfassung der Usereingaben angezeigt - bevor er die Form "submitted".
4. auf dieser letzten Webform-Seite baue ich mit webform_options_form_alter ($node, $submission) einen Link ein:
...$html .= '<div class="pdfBtn">' . l( 'PDF', $base_url . '/summary/' . $node->nid, array('attributes' => array('target'=>'_new')) ) . '</div>';
return $html;
(die interessierenden Inhalte werden hier aus $submission geholt, in $_SESSION['summary'] geschrieben und im aufgerufenen view wieder ausgelesen)
5. wenn ich diesen Link anklicke, wird der view aufgerufen, das PDF erzeugt und im neuen Browser-Tab angezeigt - soweit richtig.
Genau das will ich aber nicht, sondern einen Link, der mir sofort den SaveAs-Dialog bringt für das durch den view "on-the-fly" erzeugte PDF - das existiert ja bis hierher noch gar nicht als downloadbare Datei!
Und diese Angaben zu TCPDF::Output ( $name = 'doc.pdf', $dest = 'I' )
I: send the file inline to the browser (default). The plug-in is used if available. The name given by name is used when one selects the "Save as" option on the link generating the PDF.
D: send to the browser and force a file download with the name given by name.
F: save to a local server file with the name given by name.
S: return the document as a string (name is ignored).
funktionieren so nicht, das PDF wird - wenn überhaupt - unter "Benutzer/.../AppData/Local/Temp" gespeichert (kommt auf die Browsereinstellungen an).
Meine Frage müßte also richtiger lauten, wie kann ich diese PDF-Page-view programmatisch aufrufen, um das PDF zu erzeugen und an definierter Stelle auf dem Server zu speichern (sites/default/files/...), um es dann mit jQuery oder sonstwie zum Download anbieten zu können ?
Das ist sicher ein etwas sehr spezielles Problem, aber schön, daß überhaupt jemand darauf reagiert; vielleicht hast Du - oder sonst jemand - ja doch noch einen Rat; vielleicht habe ich ja auch irgendwas im Umgang mit dieser TCPDF-Lib grundsätzlich falsch verstanden?
Also vielen Dank erstmal, Michael
Speichern tust du das PDF in
am 21.03.2015 - 18:42 Uhr
Speichern tust du das PDF in der Regel über eine Rule.
Und dort gibst du dann auch genau den Pfad an, wo das PDF gespeichert wird.
Damit weißt du genau, wie das PDF heißt und wo es liegt.
Der Rest geht dann per JQuery, wie oben schon erwähnt.
Gruß
Berthold
das nächste Problem:
am 23.03.2015 - 12:24 Uhr
nachdem ich mit Rules eine "save PDF as file on server"-Aktion für das event "Content is viewed" eingerichtet habe, mit [node:nid] als views argument - wie ich es hier gefunden hatte, bekomme ich nun das:
TCPDF ERROR: Unable to create output file: sites/default/files/output/test.pdfalle Google-Ergebnisse dazu haben mir nichts gebracht, das Verzeichnis existiert, die Rechte stimmen ...
den Store-Path hab ich absolut und relativ probiert - immer dasselbe.
Ich bin ratlos - was fehlt denn hier noch an Konfiguration? Wär gut, wenn Du mir nochmal weiterhelfen könntest,
Michael
(PS: lokal, Win7, XAMPP)
Hast Du denn mal nachgesehen,
am 23.03.2015 - 13:47 Uhr
Hast Du denn mal nachgesehen, ob das Unterverzeichnis output in files existiert und beschreibbar ist? Manchmal können die Module nämlich keine neuen Verzeichnisse kreiren.
Zitat: das Verzeichnis
am 23.03.2015 - 14:02 Uhr
das Verzeichnis existiert, die Rechte stimmen ...
Dann kann es wohl an dem Verzeichnis oder den Rechten nicht liegen.
Hast du denn im sites/all/libraries auch das tcpdf-Plugin drin und funktioniert das auch. Gibt es vielleicht Mecker im Statusbericht ?
daß das TCPDF-Plugin funktioniert,
am 23.03.2015 - 15:08 Uhr
schließe ich daraus, daß das views-pdf funktioniert - wenn ich ".../summary/[NID]" direkt im Browser aufrufe, kriege ich das PDF richtig.
Unter aktuelle Protokollnachrichten habe ich
Warning: fopen() [function.fopen]: remote host file access not supported, file://sites/default/files/output/test.pdf in TCPDF_STATIC::fopenLocal() (Zeile 2440 von ...\sites\all\libraries\tcpdf\include\tcpdf_static.php).und
Warning: fopen(file://sites/default/files/output/test.pdf) [function.fopen]: failed to open stream: no suitable wrapper could be found in TCPDF_STATIC::fopenLocal() (Zeile 2440 von ...\sites\all\libraries\tcpdf\include\tcpdf_static.php).Aber im Statusbericht hatte ich nicht nachgesehen - da stand tatsächlich
TCPDF directory Non-writable permissionsYou must change the sites/all/libraries/tcpdf/images permissions to be writable, as TCPDF requires write-access to that directory.
Aber in diesem tcpdf-Verzeichnis gab es bei mir gar kein images-Verzeichnis!
Das hab ich jetzt selber angelegt, der Eintrag im Statusbericht ist jetzt weg, aber es geht trotzdem nicht ...
Ich habe übrigens noch einige andere PDF-Module/libs aktiv, weil ich damit experimentiert hatte
- PHPWkHtmlToPdf
- mpdf
stören die sich vielleicht gegenseitig?
Kann DAS die Lösung sein?
am 24.03.2015 - 12:16 Uhr
nach der Warnung aus den Protokollnachrichten (s. letzter Eintrag) hab ich in der angegebenen Funktion
TCPDF_STATIC::fopenLocal() (Zeile 2440 von ...\sites\all\libraries\tcpdf\include\tcpdf_static.php)diese beiden Zeilen (/////------->) auskommentiert - und jetzt geht's:
<?php/**
* Wrapper to use fopen only with local files
* @param filename (string) Name of the file to open
* @param $mode (string)
* @return Returns a file pointer resource on success, or FALSE on error.
* @public static
*/
public static function fopenLocal($filename, $mode) {
if (strpos($filename, '://') === false) {
/////-------> $filename = 'file://'.$filename;
} elseif (strpos($filename, 'file://') !== 0) {
/////-------> return false;
}
return fopen($filename, $mode);
}
?>
Aber das kann doch nicht richtig sein !?
Weiß vielleicht jemand, was diese Funktion bedeutet/macht ?
mfG, Michael
die Funktionalität ist auskommentiert
am 24.03.2015 - 14:55 Uhr
Aber das Script ist klar nachvollziehbar:
public static function fopenLocal($filename, $mode) {if (strpos($filename, '://') === false) { //wenn :// nicht vorkommt
/////-------> $filename = 'file://'.$filename; //hänge ein file:// vorne dran
} elseif (strpos($filename, 'file://') !== 0) { // steht file:// nicht am Anfang, ist der fielename unbrauchbar.
/////-------> return false; // brich die Verarbeitung mit der Rückmeldunge "FALSCH" ab.
}
return fopen($filename, $mode); //öffne die Datei
}
Du musst natürlich die auskommentierten Zeilen aktivieren, indem die die Kommentarzeichen entfernst, ansonsten tut diese Funktion nichts, bzw. versucht jeden beliebigen Dateinamen zu öffnen.
Ich hatte geschrieben,
am 24.03.2015 - 15:41 Uhr
daß es grade DANN funktioniert, wenn diese Dateinamen-Kontrolle übersprungen wird,
und eben NICHT, wenn sie ausgeführt wird.
Darauf gekommen war ich bei dem Versuch, eine PDF-view mit rules als PDF abzuspeichern, was folgende Fehlermeldungen ergeben hat:
TCPDF ERROR: Unable to create output file: sites/default/files/output/test.pdfbzw.
Warning: fopen() [function.fopen]: remote host file access not supported, file://sites/default/files/output/test.pdf in TCPDF_STATIC::fopenLocal() (Zeile 2440 von ...\sites\all\libraries\tcpdf\include\tcpdf_static.php).
und
Warning: fopen(file://sites/default/files/output/test.pdf) [function.fopen]: failed to open stream: no suitable wrapper could be found in TCPDF_STATIC::fopenLocal() (Zeile 2440 von ...\sites\all\libraries\tcpdf\include\tcpdf_static.php).
DAS ist das Problem, um es nochmal zusammenzufassen,
Michael
neuer Lösungsansatz:
am 24.03.2015 - 18:06 Uhr
als StorePath in der rule-action "Save PDF as file on server" hatte ich bisher nur
sites/default/files/output/testund
[site:url]/sites/default/files/output/test
Das hier hat mich auf folgende Variante für den StorePath gebracht:
<?php$myPath = substr( $_SERVER['SCRIPT_FILENAME'], 0, strrpos($_SERVER['SCRIPT_FILENAME'], "/") );
print $myPath . '/sites/default/files/output/test';
?>
Ist das OK so, oder kann das andere Probleme verursachen? - ich hab's bis jetzt nur lokal unter XAMPP getestet.
Dann könnte man das Thema ja beenden,
mfG, Michael