nicht angemeldet
Datei erstellen -> danach zum Download anbieten
1 0 0 0 Wie geht das?
0 0
0
0
0
Datei erstellen -> danach zum Download anbieten
Hallo,
ich erzeuge auf meiner Webseite Pdf Dokumente per PHP. Das dauert leider gerne mal 30-60 Sekunden. Die Dateien werden nach der Erstellung heruntergeladen. Nun mein Problem ist, das ich nicht 30 Sekunden und mehr einen leeren Bildschirm zeigen möchte. Am liebsten wäre es mir die Ergebnis Seite auszugeben mit einen "Bitte warten" Text und sobald diese Dateien fertig erstellt worden sind diesen Text durch den Link zu den Dateien ersetzen. Ich suche dazu eine Lösung oder einen Ansatz weil irgendwie habe ich dazu keine wirklich brauchbare Idee.
Danke schonmal
Markus
-
Hi!
ich erzeuge auf meiner Webseite Pdf Dokumente per PHP. Das dauert leider gerne mal 30-60 Sekunden. Die Dateien werden nach der Erstellung heruntergeladen. Nun mein Problem ist, das ich nicht 30 Sekunden und mehr einen leeren Bildschirm zeigen möchte. Am liebsten wäre es mir die Ergebnis Seite auszugeben mit einen "Bitte warten" Text und sobald diese Dateien fertig erstellt worden sind diesen Text durch den Link zu den Dateien ersetzen. Ich suche dazu eine Lösung oder einen Ansatz weil irgendwie habe ich dazu keine wirklich brauchbare Idee.
Du hast das Problem, das Du meines Wissens nicht so ohne weiteres die TCP-Verbindung zwischen Server und Browser aus PHP kontrollieren kannst. Das heißt, Du kannst nicht einfach den HTML-Code vorab zum Browser schicken (z.B. inkl. Ajax-Code, der in einer Schleife ein anderes Script abfragt ob die Datei fertig ist...), die TCP-Verbindung schließen, das PDF erstellen und wenn per Ajax gemeldet wird, dass die Datei fertig ist, wird per Javascript der Link angezeigt. Da Du die Verbindung nicht vor Ende des Scripts serverseitig trennen kannst, hast Du keine Kontrolle über verschiedene Puffer und Caches, die möglicherweise verhindern, dass Deine "bitte warten" Seite auch tatsächlich angezeigt wird (wenn das bei Dir funktioniert, muss das noch lange nicht bei allen anderen Besuchern funktionieren).
Als Workaround kannst Du z.B. mit flush() versuchen sämtliche Puffer zu leeren bevor Du mit dem Generieren des PDFs anfängst, aber 100% klappt das nicht überall (siehe Manual-Kommentare zu flush()). Das könnte dann z.B. so aussehen:
<html> <body> <div id="wait">Bitte warten...</div> <div id="link" style="display:none">Fertig: <a href="./datei.pdf">download</a></div> <?php flush(); sleep(5); // alternativ was sinnvolles machen... ?> <script type="text/javascript"> document.getElementById("wait").style.display = "none"; document.getElementById("link").style.display = ""; </script> </body> </html>Alternativ könnte man auch versuchen per header() vor der Generierung auf eine "bitte warten" Seite umzuleiten, die wiederum per Ajax prüft wann das PDF fertig ist. Allerdings kann es hierbei passieren, dass die Umleitung erst ausgeführt wird, wenn das PDF fertig ist.
<?php ignore_user_abort(); header('Location: http://example.com/bitte_warten.html'); ob_flush_end(); flush(); sleep(5); // alternativ was sinnvolles machen... ?>Eine zuverlässigere aber auch deutlich kompliziertere Lösung wäre, einen Dämon zu schreiben, dem Du im aufgerufenen PHP-Script irgendwie die notwendigen Informationen übergibst, der dann das PDF generiert. Man könnte z.B. per Socket kommunizieren, oder der Prozess überwacht ein Verzeichnis in das Du die "Aufträge" legst... dann müsstest Du jedenfalls nur die Daten übergeben und könntest direkt die "bitte warten" Seite ausgeben, was dann zu 100% funktioniert da die TCP-Verbindung nach Übergabe der Daten und Senden des HTML-Codes beendet wird. Auf der ausgelieferten HTML-Seite könntest Du dann mit Ajax wieder ein Script aufrufen, welches Dir sagt ob die Datei bereits zum Download bereit steht oder nicht.
Eine bessere Lösung ist mir nicht bekannt. Die dritte Variante wird in den meisten Fällen aufgrund von technischen Beschränkungen nicht möglich sein, dann muss man entweder mit den Problemen der ersten beiden Variante leben (bzw. so gut wie möglich drum herum arbeiten), oder halt drauf verzichten und vorher dem Besucher gegenüber eine entsprechende Ankündigung machen.
Grüße
Andreas-
Hello,
Du hast das Problem, das Du meines Wissens nicht so ohne weiteres die TCP-Verbindung zwischen Server und Browser aus PHP kontrollieren kannst. Das heißt, Du kannst nicht einfach den HTML-Code vorab zum Browser schicken (z.B. inkl. Ajax-Code, der in einer Schleife ein anderes Script abfragt ob die Datei fertig ist...) [...]
Aber es gibt ja zum Glück noch dit guten alten Framesets.
So ein Frameset kannst Du dem Client schicken, nachdem Du auf dem Server die Generierung des PDF gestartet hast und eine Kontrolldatei schreiben lässt, mit dem Inhalts-Prozentsatz.1. HTML-Datei erzeugen, mit dem Inhaltsbalken 0% und einem kleinen Text.
2. PHP-Instanz mittels Exec() und php-cgi/cli in den Hintergrund stellen, die das PDF erzeugt
und die Kontrolldatei (zu 1.) immer auf den neuesten Stand bringt
3. Frameset an den Client schicken, dass in einem Teil das PDF anfordert und im anderen Teil
die Kontrolldatei mittels JavaScript immer wieder anfordert.Problem ist nur, dass die Platte so langsam mit Dateien vollmüllt.
Das kann man zwar auch mit dem abgespaltenen Vorgang bereinigen, indem man ihn einfach noch eine Weile weiterlaufen lässt, und dann die beiden Dateien löschen lässt... Aber dann hat man nachher eventuell lauter "freilaufende Prozesse" auf dem Server. Hängt also davon ab, wieviel Traffic vorhanden ist, wie man es machen sollte.Bliebe noch die Überlegung, was man einbauen muss ins Frameset, für die Leute, die kein JavaScript unterstützen oder diejenigen die keine Frames können...
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hi,
Bliebe noch die Überlegung, was man einbauen muss ins Frameset, für die Leute, die kein JavaScript unterstützen oder diejenigen die keine Frames können...
Eine Fortschrittsanzeige funktioniert auch mit PHP pur also ohne JS (mit JS sieht sie nur hübscher aus ;-)), und Nicht-Framer bekommen einen Download-Link.
Ansonsten ist es kein Problem, mit PHP selbst (innerhalb des gleichen Scripts) festzustellen, ob der Browser (I)Frames kann und JavaScript aktiviert ist. Man könnte es also auch so machen, daß "normale Browser" die Super-Duper-Variante bekommen, und "merkwürdige Browser" bekommen gleich den Download (ohne Hinweis).
Das Script selbst kann auch aufräumen, und z.B. regelmäßig alle alten PDF-Leichen entfernen. :-)
Ich sehe da keinerlei Probleme ...
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hello,
Ansonsten ist es kein Problem, mit PHP selbst (innerhalb des gleichen Scripts) festzustellen, ob der Browser (I)Frames kann und JavaScript aktiviert ist.
Wie geht das?
Hab ich wohl gepennt, als das hier dran war.Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hi,
Wie geht das?
Vereinfacht: Indem das PHP-Script IFrames (als HTML & JS-generiertes HTML) ausgibt mit einer (PHP-)Resource die ihren Status sichert, auf diesen Status (oder einen Timeout) wartet, und aufgrund des Statusergebnisses fortfährt.
Bei Browsern mit IFrames ist man durch den Test ruck-zuck durch, dem Rest kann man einen Timeout von 2, na 3 Sekunden gönnen.
Geht natürlich auch mit EMBED/OBJECT, sodaß man klar feststellen kann, ob der Client ein Multimedia-Browser (also >=Netscape Navigator 3) und JavaScript aktiviert ist.
Hab ich wohl gepennt, als das hier dran war.
Also da kann ich mich auch nicht dran erinnern. :)
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hello,
Vereinfacht: Indem das PHP-Script IFrames (als HTML & JS-generiertes HTML) ausgibt mit einer (PHP-)Resource die ihren Status sichert, auf diesen Status (oder einen Timeout) wartet, und aufgrund des Statusergebnisses fortfährt.
Dann geht es also nicht beim Initial Request.
Genau das wollte ich aber wissen.
Man weiß also frühestens beim zweiten Request, ob der Client JavaScript unterstütztDas das funktioniert, ist ja ein alter Hut!
Ich hatte schon angenommen, dass ich 'was verpasst hätte.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hi,
Dann geht es also nicht beim Initial Request.
Doch, natürlich. =:-o
Man weiß also frühestens beim zweiten Request, ob der Client JavaScript unterstützt
Nein, nicht "beim", sondern *mit dem*!
Die Haupt-Resource "wartet" halt auf die Test-Resource und fährt dann weiter fort. Für den Anwender bleibt es bei *einem* Request, für den Script-Coder praktisch (im Sinne der Seitenentwicklung/-Verwaltung ebenso - quasi ein Resource-Fork :)).
Was man so gemeinhin liest, ist, daß man zwei "*Haupt*-Resourcen" nacheinander haben muß, getreu dem Motto: JS wird erst nach PHP ausgeführt (was IMHO mißverständlich ist, da das PHP-Script noch immer rödeln kann, während das JS der Seite längst "durch" ist). Also: Script1 macht die Prüfung, Anwender klickt auf Link zu Script2 (oder JS leitet ihn automatisch dorthin). So meinte ich das allerdings nun wirklich nicht ...
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hello,
Die Haupt-Resource "wartet" halt auf die Test-Resource und fährt dann weiter fort. Für den Anwender bleibt es bei *einem* Request, für den Script-Coder praktisch (im Sinne der Seitenentwicklung/-Verwaltung ebenso - quasi ein Resource-Fork :)).
Tut mir leid. Ich bin wohl zu blöd, das zu verstehen.
Wenn ich in meinem (neu geöffneten) Browserfenster in die Adresszeile "http://bitworks.de" eintippe und auf "wechseln zu" klicke oder "Enter" drücke, wir ein Initial Request auf die Seite ausgeführt. Wie kann das dahinterliegende Script nun feststellen, ob JavaScript eingeschaltet ist?Bitte erkläre das einem Doofen...
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hi!
Wenn ich in meinem (neu geöffneten) Browserfenster in die Adresszeile "http://bitworks.de" eintippe und auf "wechseln zu" klicke oder "Enter" drücke, wir ein Initial Request auf die Seite ausgeführt. Wie kann das dahinterliegende Script nun feststellen, ob JavaScript eingeschaltet ist?
Gar nicht.
Wie Du schon sagtest braucht man dafür einen 2. Request (dass der erste Request das Ergebnis des 2. Request nutzt ändert nichts an dieser Tatsache). Das man das so gestalten kann, dass es für den User so wirkt als sei es nur ein Request steht auf einem anderen Blatt.
Allerdings finde ich diese Information auf der Serverseite ziemlich unwichtig...
Grüße
Andreas-
Hi,
Allerdings finde ich diese Information auf der Serverseite ziemlich unwichtig...
Ich setze es praktisch nicht ein - das Script entstand nur aus einer Laune heraus.
Aber ich kann mir vorstellen, daß es praktisch nutzbar sein kann, um "normal übliche Browser" von "nicht üblichen Browsern" innerhalb eines Scripts/einer Resource zu unterscheiden (also keine 2. resource, keine Sessiosn, ...). ist der Client "nicht üblich", dann kann man ihn, bis zum Beweis des Gegenteils, unter "Bot-Verdacht" stellen. *Ein* Steinchen im Mosaik eines "Scores", ob jemand was "Böses" im Schild führt, oder ein normaler Surfer ist ...
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
-
-
Hi,
Bitte erkläre das einem Doofen...
Andreas hat es ja schon auf den Punkt gebracht.
Beispiel: jstest.php (Source
) ruft als "Fork" jstester.php auf (Source)(Einige "Basis-Funktionen" sind dabei in der nicht-öffentlichen basiclib.php, d.h. die Scripte laufen mangels dieser Lib also so nicht anderen Servern. Ich wollte das jetzt nicht noch aufdröseln, aber ich hoffe, was ich meinte, kann man damit trotzdem nachvollziehen ...)
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hello,
Beispiel: jstest.php (Source
) ruft als "Fork" jstester.php auf (Source)(Einige "Basis-Funktionen" sind dabei in der nicht-öffentlichen basiclib.php, d.h. die Scripte laufen mangels dieser Lib also so nicht anderen Servern. Ich wollte das jetzt nicht noch aufdröseln, aber ich hoffe, was ich meinte, kann man damit trotzdem nachvollziehen ...)
Das ist die Ressource, die beim ersten Request ausgeliefert wird.
Woher weiß da nun das PHP-Script auf dem Server, dass JavaScript eingeschaltet ist?
Ich verstehe trotz Deiner Ausführungen nicht, wie das mit einem einzigen generischen Request (über die Adressleiste des Browsers) möglich sein soll.<html>
<head>
<title>Inline-JS-Test</title>
</head><body>
<object style="position: absolute;
top:-50px;"
data="jstester.php?tmp=jstestOllDvp&js=%3f"
type="text/html"
width="0"
height="0"><embed
src="jstester.php?tmp=jstestOllDvp&js=%3f"
type="text/html"
width="0"
height="0"
hidden="true"></embed></object><script type="text/javascript">
<!--
document.write('<object style="position: absolute; top:-50px;" data="jstester.php?tmp=jstestOllDvp&js=on" type="text/html" width="0" height="0"><embed src="jstester.php?tmp=jstestOllDvp&js=on" type="text/html" width="0" height="0" hidden="true"></embed></object>');
//--></script><noscript><object style="position: absolute; top:-50px;" data="jstester.php?tmp=jstestOllDvp&js=off" type="text/html" width="0" height="0"><embed src="jstester.php?tmp=jstestOllDvp&js=off" type="text/html" width="0" height="0" hidden="true"></embed></object></noscript><h1 align="center">JavaScript ist AUS<br><small>(Client ist <b>kein</b> Multimedia-Browser)</small></h1>
<h4 align="center">Testdauer: 2.1051</h4>
</body>
</html>Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hi,
Das ist die Ressource, die beim ersten Request ausgeliefert wird.
Woher weiß da nun das PHP-Script auf dem Server, dass JavaScript eingeschaltet ist?
Ich verstehe trotz Deiner Ausführungen nicht, wie das mit einem einzigen generischen Request (über die Adressleiste des Browsers) möglich sein soll.1. Der "generische Request" (Haupt-Script) erzeugt eine temporäre Datei und flusht HTML-Code der den Aufruf neuer Resourcen beinhaltet: OBJECT-Resource & EMBED-Resource - einmal als "normale" HTML-Elemente, einmal mit JS erzeugt, und einmal im NOSCRIPT-Bereich. Dabei werden dem "Fork-Script", das als Source angegeben wird, unterschiedliche Parameter übergeben: HTML->js=?, JS->js=on & NOSCRIPT->js=off, sowie natürlich der Name der temporären Datei.
2. Das Haupt-Script fragt nun in einer while-Schleife den Inhalt der temporären Datei ab (also das, was das Fork-Script jeweils loggt), und macht dabei immer mal ein "Nickerchen". ;-)
3. Das "Fork-Script" "loggt" seine jeweiligen Aufrufe nun in die temporäre Datei.
4. Wenn alle Ergebnisse der versch. "Fork-Resourcen" vorliegen, oder ein Timeout-Wert erreicht wurde, hat das Haupt-Script den Status des Clients aus dem "Log" ausgelesen: on/off/nix, beendet die Warteschleife, löscht die temporäre Datei, und kann mit dem eigentlichen Programm fortfahren (Ausgabe der eigentlichen HTML-Seite, Verarbeitung von Formulardaten, was-auch-immer) ...Ein üblicher Multimedia-Browser (also alles seit Navigator 3) beherrscht im Gegensatz zu Bots oder "ungewöhnlichen" (im Sinne von "seltenen") Browsern entweder EMBED und/oder OBJECT (alternativ kann man natürlich auch das testen, was man halt konkret wissen will: z.B. kann der Browser Bilder darstellen, oder eben IFrames - Hauptsache, es handelt sich um (mindestens) eine weitere Resource). Ergebnis: Im Log erscheint ein "?" wenn es ein Multimedia-Browser ist.
Jetzt ist noch die Frage, ob die JS- oder die NOSCRIPT-Resourcen angefordert werden. Bei aktivem JS steht jetzt im "Log" auch "on", ohne "off".
Ein z.B. Bot-Request hängt ein wenig länger in der Warteschleife, halt bis der Timeout erreicht ist (wie man sieht, läuft der Test üblicherweise recht zügig durch, der Timeout-Wert kann also auch recht niedrig sein).
Bleibt noch ein Sonderfall IE, bei dem man einstellen kann, daß jedes JScript explizit um Erlaubnis bitten muß. Hier wird der Timeout aufgehoben, und das Haupt-Script wartet solange, bis der User dem JS die Erlaubnis gegeben, oder verweigert hat (mit entsprechendem Ergebnis, daß das Haupt-Script nach der Warteschleife verwenden kann).
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hello,
- Der "generische Request" (Haupt-Script) erzeugt eine temporäre Datei und flusht HTML-Code der den Aufruf neuer Resourcen beinhaltet:
Dass das so geht, ist mir schon klar gewesen.
Es gingt aber bei meinen "Verständnisschwierigkeiten" darum dass ich nicht sehen konnte, wie dies mit einem einzigen Request öglich sein sollte.Mittels Umleitung (header) habe ich das in meinem eigenen CMS schon ewig drin, um festzustellen, ob COOKIES zugelassen werden. Bei der Gelegenheit wird dann auch gleich auf JavaScript geprüft.
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
-
-
-
-
-
-
-
Hi!
Wie geht das?
Zumindest um Javascript festzustellen kann man auch einfach per Javascript einen zusätzlichen Parameter an den Link zum PHP-Script anhängen, der dann entweder vorhanden ist oder nicht. Bzgl. iframes wüßte ich keinen relevanten Browser, der das nicht unterstützt. Ich denke Netscape 4 ist in den meisten Fällen vernachlässigbar.
Grüße
Andreas
-
-
-
Hi Tom!
Aber es gibt ja zum Glück noch dit guten alten Framesets.
So ein Frameset kannst Du dem Client schicken, nachdem Du auf dem Server die Generierung des PDF gestartet hast und eine Kontrolldatei schreiben lässt, mit dem Inhalts-Prozentsatz.- HTML-Datei erzeugen, mit dem Inhaltsbalken 0% und einem kleinen Text.
- PHP-Instanz mittels Exec() und php-cgi/cli in den Hintergrund stellen, die das PDF erzeugt
und die Kontrolldatei (zu 1.) immer auf den neuesten Stand bringt - Frameset an den Client schicken, dass in einem Teil das PDF anfordert und im anderen Teil
die Kontrolldatei mittels JavaScript immer wieder anfordert.
Ich weiß nicht ob ich da jetzt richtig verstanden habe, aber Du kannst aus einem PHP-Script heraus nicht einfach einen Hintergrundprozess anstoßen und das Script beenden bevor der Prozess zu Ende gelaufen ist. Wenn Du exec() ausführst, wartet das Script so lange, bis der per exec() gestartete Prozess beendet wird. Und wenn Du es mit irgendwelchen Tricks doch schaffst, wird spätestens beim Trennen der TCP-Verbindung auch der per exec() oder sonstwie gestartete Prozess abgebrochen. Du kannst also in dem Fenster, das den Request sendet nicht mit einem Frameset antworten, das bringt jedenfalls nichts. Man kann höchstens auf der Seite mit dem Link, der den Request auslöst schon Frames verwenden, wenn der Link zum Generieren des PDFs in einem anderen Frame liegt als die angezeigte Meldung bzw. header() / erzeugter Download-Link. Dann braucht man auch nicht unbedingt flush().
Bliebe noch die Überlegung, was man einbauen muss ins Frameset, für die Leute, die kein JavaScript unterstützen oder diejenigen die keine Frames können...
Ohne Javascript geht das nicht per "bitte warten", da muss man dann halt ohne Meldung warten.
Grüße
Andreas-
Hello,
[...] Du kannst aus einem PHP-Script heraus nicht einfach einen Hintergrundprozess anstoßen und das Script beenden bevor der Prozess zu Ende gelaufen ist. Wenn Du exec() ausführst, wartet das Script so lange, bis der per exec() gestartete Prozess beendet wird.
Das ist nicht so, wenn man ihn, wie in den UCN zu "exec()"
http://www.php.net/manual/en/function.exec.php
Note vonjuha at kuhazor dot idlegames dot com
03-Aug-2005 11:32
This technique was post posted by someone else earlier, however it did not work for me. This works with all Linux distros as long as path to your PHP processor is correct. The exec will return the PID for the process.<?
$pid=exec("/usr/local/bin/php run.php > /dev/null & echo $!");echo $pid;
?>My run.php script is here, it is good for testing.
<?
function getmicrotime()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}$starttime = getmicrotime();
$date=date("d/m/Y H:i",time());
echo "Started sleeping\n";
sleep(30);
$endtime = getmicrotime();
echo "Woke up\n";echo "Slept ".round(($endtime-$starttime),2)."\n";
?>
Das habe ich auf PHP 4 und 5 in Apache1.x und 2.x auf Linux diverse Male impelemnetiert, und bisher überhaupt keine Probleme damit gehabt.
Und ein Fork (Abtrennung des Child vom Vaterprozess) durch das "&" auszulösen, ist eine durchaus geläufige Technik unter Linux
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
-
Hi Tom!
Ich war jetzt von einer typischen Hosting-Umgebung mit CGI ausgegangen. Wenn ein CGI-Skript beendet wird, werden auch alle gestarteten Child-Prozesse beendet. Bei mod_php sieht das etwas anders aus. Allerdings sollte man bei solchen Sachen wissen was man macht...
Grüße
Andreas
-
-
Hi,
Ohne Javascript geht das nicht per "bitte warten", da muss man dann halt ohne Meldung warten.
Nein, s.PHP/JavaScript-Countdown. Mit JS: Dynamische Änderung, ohne JS: eine "einfache Statusanzeige für "HTTP/1.1"-Clients.
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hi!
Ohne Javascript geht das nicht per "bitte warten", da muss man dann halt ohne Meldung warten.
Nein, s.PHP/JavaScript-Countdown. Mit JS: Dynamische Änderung, ohne JS: eine "einfache Statusanzeige für "HTTP/1.1"-Clients.
Ja gut, per flush() halt. Aber wie gesagt ist das nicht 100%ig zuverlässig.
Grüße
Andreas-
Hi,
Ja gut, per flush() halt. Aber wie gesagt ist das nicht 100%ig zuverlässig.
Sorry, aber die paar Clients, die da noch durchs Raster fallen, kannst Du mit der Lupe suchen (da wird außer Bots im Log kaum was auftauchen). Und die User, deren Client damit wieklich nichts anfangen kann, haben trotzdem volle Funktionalität, nur eben keinen (Wartehinweis-)Komfort.
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!-
Hi!
Sorry, aber die paar Clients, die da noch durchs Raster fallen, kannst Du mit der Lupe suchen (da wird außer Bots im Log kaum was auftauchen). Und die User, deren Client damit wieklich nichts anfangen kann, haben trotzdem volle Funktionalität, nur eben keinen (Wartehinweis-)Komfort.
Ich spreche eher von Problemen mit verschiedenen Puffern auf Webserver-, Betriebssystemebene, Caches, Proxies...
Grüße
Andreas-
Hi,
Ich spreche eher von Problemen mit verschiedenen Puffern auf Webserver-, Betriebssystemebene, Caches, Proxies...
Ja, wo ist das Problem? Entweder der Client kriegt die Daten stückweise und stellt sie auch peu a peu dar, oder er kriegt sie erst am Ende auf einen Rutsch und der User sieht halt keinen Warnhinweis. Die Funktionaltät leidet nicht, der Komfort ist verzichtbar.
Außerdem: Chunked-Encoding ist *Pflicht* für HTTP/1.1-Cients. Da wirst Du, auch "unterwegs", IMHO nicht viel Probleme zu erwarten haben ...
Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!
-
-
-
-
-
-
-
Hi,
Ich suche dazu eine Lösung oder einen Ansatz weil irgendwie habe ich dazu keine wirklich brauchbare Idee.
1. Einen "Bitte warten"-Text mit flush() ausgeben (mind. 1 KByte muß dafür ausgeben werden, damit alle Browser loslegen).
2. Einen (unsichtbaren) IFrame erzeugen, dessen Source ein "Download-Script" für die PDF-Datei besteht (also ein Script, das die Datei nicht angezeigt, sondern per "Download-Header" zum Download "empfiehlt").
3. Für die (extrem wenigen) Browser, die das alles nicht können, kommt zusätzlich noch ein Link auf das PDF ...Gruß, Cybaer
--
Hinweis an Fragesteller: Fremde haben ihre Freizeit geopfert, um Dir zu helfen. Helfe Du auch im Archiv Suchenden: Beende deinen Thread mit einem "Hat geholfen" oder "Hat nicht geholfen"!