Executing PHP Tasks While Letting A User Continue To Browse?

[Good Man]

Hi there

I was wondering if someone could help me out with the following two
situations.

In a lot of my web apps, it seems that if i launch a PHP script that takes
a long time to complete, the user is unable to browse/use the rest of the
website until the tasks completes. Is there a way to avoid this?

Specifically, app #1 let's a user choose which files to include in a zip
file, then PHP makes the .zip file on the server and streams it to the user
via fopen/fread. So, as the user is downloading a file on the side (it
presents them with the open/save dialog) they are unable to browse the rest
of the PHP-based site until the download completes; clicking on any links
to pages does nothing, the browser just sits there until the file has been
downloaded, THEN the screen advances.

I am experiencing a similar thing with a PHP mail delivery system. I tried
to create a work-around: a pop-up window that sends an 'exec' command to
the a php-script that sends the email to a few hundred recipients. Again,
even though this action is being done in a pop-up window (and via the
command line, no less), the user is paralyzed in the main window until the
action completes.

Can anyone tell me why this is happening, and what some workaround might
be?

Thanks.

[robert]

pop-up...meaning ie's createpopup, js window.open(), a div, or the result of
target='go.process.it.php'?

i usually use the target= and have some kind of message with an animated
image indicating processing is underway. when php is done processing
whatever it is, you can use js to give some kind of alert that it's done
and/or close the window. i haven't found that that ties up the other browser
windows.

if you're not opposed to using frames, then that may be somthing to think
about too.

what browser are you testing this with?

"Good Man" <he***@letsgo.com> wrote in message
news:Xn************************@216.196.97.131...
| Hi there
|
| I was wondering if someone could help me out with the following two
| situations.
|
| In a lot of my web apps, it seems that if i launch a PHP script that takes
| a long time to complete, the user is unable to browse/use the rest of the
| website until the tasks completes. Is there a way to avoid this?
|
| Specifically, app #1 let's a user choose which files to include in a zip
| file, then PHP makes the .zip file on the server and streams it to the
user
| via fopen/fread. So, as the user is downloading a file on the side (it
| presents them with the open/save dialog) they are unable to browse the
rest
| of the PHP-based site until the download completes; clicking on any links
| to pages does nothing, the browser just sits there until the file has been
| downloaded, THEN the screen advances.
|
| I am experiencing a similar thing with a PHP mail delivery system. I
tried
| to create a work-around: a pop-up window that sends an 'exec' command to
| the a php-script that sends the email to a few hundred recipients. Again,
| even though this action is being done in a pop-up window (and via the
| command line, no less), the user is paralyzed in the main window until the
| action completes.
|
| Can anyone tell me why this is happening, and what some workaround might
| be?
|
| Thanks.

[Good Man]

"robert" <[e-mail]-alama-ding-dong> wrote in
news:56*************@fe05.lga:

pop-up...meaning ie's createpopup, js window.open(), a div, or the
result of target='go.process.it.php'?
it's actually using javascript if i recall correctly (for the email
delivery that is - the file streaming is just straight PHP script).

i usually use the target= and have some kind of message with an
animated image indicating processing is underway. when php is done
processing whatever it is, you can use js to give some kind of alert
that it's done and/or close the window. i haven't found that that ties
up the other browser windows.
i'll try the target=""; i use js currently to both open and close the
window.

if you're not opposed to using frames, then that may be somthing to
think about too.
i'd rather not, as these features are just one component of an overall
site.

what browser are you testing this with?

ie and firefox.
I'm actually more upset/interested in the file-streaming preventing
additional usage, as opposed to the email delivery/new window thing.

[robert]

"Good Man" <he***@letsgo.com> wrote in message
news:Xn************************@216.196.97.131...
| "robert" <[e-mail]-alama-ding-dong> wrote in
| news:56*************@fe05.lga:
|
| > pop-up...meaning ie's createpopup, js window.open(), a div, or the
| > result of target='go.process.it.php'?
|
| it's actually using javascript if i recall correctly (for the email
| delivery that is - the file streaming is just straight PHP script).
|
|
| > i usually use the target= and have some kind of message with an
| > animated image indicating processing is underway. when php is done
| > processing whatever it is, you can use js to give some kind of alert
| > that it's done and/or close the window. i haven't found that that ties
| > up the other browser windows.
|
| i'll try the target=""; i use js currently to both open and close the
| window.
|
|
| > if you're not opposed to using frames, then that may be somthing to
| > think about too.
|
| i'd rather not, as these features are just one component of an overall
| site.
|
|
| > what browser are you testing this with?
|
| ie and firefox.
|
|
| I'm actually more upset/interested in the file-streaming preventing
| additional usage, as opposed to the email delivery/new window thing.

i understand. i had to lookup the exec function in php again b/c i was
almost certain there was an additional arg used to specify a wait time.
there isn't, which i find odd.

are you having the problem in both ie and firefox? while i love ff, i have
noticed some quirks like this...just not this one in particular.

i stay away from frames as much as possible as well. i really think the
target= method will work, however i don't see why window.open wouldn't
work - which is preferable since you have control over how the window
displays, and where. do you have the "dependant" property set to "no"...it
may default to "dependant=yes" in one browser, if it's not specified at all,
while in another it may be "dependant=no"...this would definitely give you
the symptoms you're describing.

[Andy Jeffries]

On Wed, 26 Apr 2006 10:57:59 -0500, Good Man wrote:

Specifically, app #1 let's a user choose which files to include in a zip
file, then PHP makes the .zip file on the server and streams it to the
user via fopen/fread. So, as the user is downloading a file on the side
(it presents them with the open/save dialog) they are unable to browse the
rest of the PHP-based site until the download completes; clicking on any
links to pages does nothing, the browser just sits there until the file
has been downloaded, THEN the screen advances.

Let me guess, you use session_start() near the top of every page (maybe
through a include auto_prepended).

This has bitten me before, if you do that, other requests to open that
session file will block until the other request closes the session file
(i.e. at the end of your download script).

You could force the session finished/closed before doing any
long/non-interactive tasks. This releases the lock on the session file
for that session ID.

Cheers,
Andy
--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

[Good Man]

Andy Jeffries <ne**@andyjeffries.co.uk> wrote in
news:pa****************************@andyjeffries.c o.uk:

Let me guess, you use session_start() near the top of every page
(maybe through a include auto_prepended).
Why yes, I certainly do!

This has bitten me before, if you do that, other requests to open that
session file will block until the other request closes the session
file (i.e. at the end of your download script).

You could force the session finished/closed before doing any
long/non-interactive tasks. This releases the lock on the session
file for that session ID.

As they say on those wacky tv-shows, "you the man".

Much thanks!!!!!

[Good Man]

Good Man <he***@letsgo.com> wrote in news:Xns97B19AFA6FE94sonicyouth@
216.196.97.131:

Andy Jeffries <ne**@andyjeffries.co.uk> wrote in
news:pa****************************@andyjeffries.c o.uk: You could force the session finished/closed before doing any
long/non-interactive tasks. This releases the lock on the session
file for that session ID.

As they say on those wacky tv-shows, "you the man".

Much thanks!!!!!

oh, for future reference, I achieved this through:

session_write_close();

before sending anything to the browser/undertaking a big task.

[Andy Jeffries]

On Wed, 26 Apr 2006 14:14:26 -0500, Good Man wrote:

Let me guess, you use session_start() near the top of every page (maybe
through a include auto_prepended).

Why yes, I certainly do!

This has bitten me before, if you do that, other requests to open that
session file will block until the other request closes the session file
(i.e. at the end of your download script).

You could force the session finished/closed before doing any
long/non-interactive tasks. This releases the lock on the session file
for that session ID.

As they say on those wacky tv-shows, "you the man".

Much thanks!!!!!

No worries...

Glad that my previous misfortune has now helped someone else (I spent AGES
trying to track down why that was happening).

Cheers,
Andy

--
Andy Jeffries MBCS CITP ZCE | gPHPEdit Lead Developer
http://www.gphpedit.org | PHP editor for Gnome 2
http://www.andyjeffries.co.uk | Personal site and photos

[robert]

"Andy Jeffries" <ne**@andyjeffries.co.uk> wrote in message
news:pa****************************@andyjeffries.c o.uk...
| On Wed, 26 Apr 2006 14:14:26 -0500, Good Man wrote:
| >> Let me guess, you use session_start() near the top of every page (maybe
| >> through a include auto_prepended).
| >
| > Why yes, I certainly do!
| >
| >> This has bitten me before, if you do that, other requests to open that
| >> session file will block until the other request closes the session file
| >> (i.e. at the end of your download script).
| >>
| >> You could force the session finished/closed before doing any
| >> long/non-interactive tasks. This releases the lock on the session file
| >> for that session ID.
| >
| > As they say on those wacky tv-shows, "you the man".
| >
| > Much thanks!!!!!
|
| No worries...
|
| Glad that my previous misfortune has now helped someone else (I spent AGES
| trying to track down why that was happening).

i'll have to note this one...gj.