On 11-11-16 09:27 AM, Richard Quadling wrote:
On 16 November 2011 13:56, Tim Streater wrote:
I'm looking at the source of a web sockets server and I see these various forms:
"ws://{$host}{$path}"
"HTTP/1.1 ${status}\r\n"
Are these simply equivalent to:
"ws://" . $host . $path
"HTTP/1
On 16 Nov 2011 at 14:27, Richard Quadling wrote:
> If you want to embed $array[CONSTANT], then the {} is used.
>
> I use {} out of habit for non arrays. Not sure if there is an impact.
>
> http://docs.php.net/manual/en/language.types.string.php#example-71
> shows the use.
>
> Oh. I've fixed the
On 16 November 2011 13:56, Tim Streater wrote:
> I'm looking at the source of a web sockets server and I see these various
> forms:
>
> "ws://{$host}{$path}"
> "HTTP/1.1 ${status}\r\n"
>
> Are these simply equivalent to:
>
> "ws://" . $host . $path
> "HTTP/1.1 " . $status . "\r\n";
>
> and if
I'm looking at the source of a web sockets server and I see these various forms:
"ws://{$host}{$path}"
"HTTP/1.1 ${status}\r\n"
Are these simply equivalent to:
"ws://" . $host . $path
"HTTP/1.1 " . $status . "\r\n";
and if so, is there any particular benefit to using that form? Or if no
On Oct 5, 2009, at 7:42 PM, Manuel Lemos wrote:
Hello,
on 10/05/2009 03:02 PM Philip Thompson said the following:
I try to avoid the use of hidden form elements as much as possible,
especially for tracking whether a user has submitted a form or
not...
I use name="submit" for the submit but
Hello,
on 10/05/2009 03:02 PM Philip Thompson said the following:
>>> I try to avoid the use of hidden form elements as much as possible,
>>> especially for tracking whether a user has submitted a form or not...
>>>
>>> I use name="submit" for the submit button instead, that will pass the
>>> valu
On Oct 2, 2009, at 3:00 AM, Manuel Lemos wrote:
Hello,
on 10/02/2009 04:41 AM kranthi said the following:
I try to avoid the use of hidden form elements as much as possible,
especially for tracking whether a user has submitted a form or not...
I use name="submit" for the submit button instead
At 7:25 PM +0100 10/4/09, MEM wrote:
Unfortunately, I'm really REALLY on a rush.
I saw a bumper sticker the other day which read:
Humpty Dumpty was rushed
Cheers,
tedd
--
---
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.
> i agree that it does seem a bit as though Márcio is in such a hurry to
> make
> something work that the tasks of learning and understanding the
> fundamentals
> are being left aside. while that's maybe understandable, it's a bit
> frustrating when we're trying to explain the fundamentals.
Thank
On 10/4/09 10:55 AM, "tedd" wrote:
> At 3:39 PM +0100 10/4/09, MEM wrote:
>>> i don't think so. if the user requests the page "a_form.php" then the
>>> server
>>> will normally execute the a_form.php script regardless whether the form
>>> was
>>> submitted or not.
>>>
>>> to display a blank
On 10/4/09 10:39 AM, "MEM" wrote:
>> i don't think so. if the user requests the page "a_form.php" then the
>> server
>> will normally execute the a_form.php script regardless whether the form
>> was
>> submitted or not.
>>
>> to display a blank form, the user probably requests a_form.php with th
At 3:39 PM +0100 10/4/09, MEM wrote:
> i don't think so. if the user requests the page "a_form.php" then the
server
will normally execute the a_form.php script regardless whether the form
was
submitted or not.
to display a blank form, the user probably requests a_form.php with the
GET
m
> i don't think so. if the user requests the page "a_form.php" then the
> server
> will normally execute the a_form.php script regardless whether the form
> was
> submitted or not.
>
> to display a blank form, the user probably requests a_form.php with the
> GET
> method and probably without any G
On 10/4/09 9:25 AM, "MEM" wrote:
> Thanks a lot. To all.
> For the moment, I'm with the redirect solution that others have pointed.
>
> But after seen tedd example and watch Manuel videos, I'm starting to
> understand how the hidden field solution work as well. Well... I'm
> *starting* to unders
Thanks a lot. To all.
For the moment, I'm with the redirect solution that others have pointed.
But after seen tedd example and watch Manuel videos, I'm starting to
understand how the hidden field solution work as well. Well... I'm
*starting* to understand I've not fully understand it yet, despit
On 10/2/09 10:06 AM, "MEM" wrote:
> I'm now understanding that even if the form is submitted to self, we can
> still use a redirect to a "success_message_page.php". However, we must do
> this redirect, AFTER the form has submitted to himself. It's the only thing
> that we have to pay attention he
At 9:42 AM -0400 10/3/09, Tom Worster wrote:
On 10/2/09 10:24 AM, "tedd" wrote:
At 1:55 PM +0530 10/2/09, kranthi wrote:
and yes i forgot to mention... i avoid hidden form elements because
they can be modified very easily and hence pose a security threat.
That depends upon how sloppy yo
At 7:11 PM +0100 10/2/09, MEM wrote:
I don't want to take another path. The hidden fields seems the way to go.
However, you gave me the example above, and I'm not understanding how can I
pass from your example: A multi-step form.
To what I was looking form: 1 step form with a success page that sh
On 10/2/09 10:24 AM, "tedd" wrote:
> At 1:55 PM +0530 10/2/09, kranthi wrote:
>> and yes i forgot to mention... i avoid hidden form elements because
>> they can be modified very easily and hence pose a security threat.
>
> That depends upon how sloppy you are in coding.
>
> NONE of my hidden va
Hello,
on 10/02/2009 07:11 AM kranthi said the following:
>>> You say you don't use hidden fields because they can be modified too
>>> easily, yet you say you check for the submit button? Which out of the
>>> two do you do, as last time I checked, modifying one form field is as
>>> easy as changin
Hello,
on 10/02/2009 05:25 AM kranthi said the following:
> and yes i forgot to mention... i avoid hidden form elements because
> they can be modified very easily and hence pose a security threat.
How can hidden field be changed in a way that submit buttons can't? I do
not see any security threa
Hello,
on 10/02/2009 05:23 AM kranthi said the following:
>>> That only works if the user clicks on that submit button. If the user
>>> hits the enter key in a text input, the form is submitted but the submit
>>> input variable is not set. That is why an hidden input is a safer solution.
>
> i do
> Yes. But since I don't want to display a success information + form fields,
> but only the success information,
> I believe the only way we have to do this is by either use javascript and
> update a div or similar, or using only php, by redirecting to another page.
>
> Is this correct?
Whether o
At 3:35 PM +0100 10/2/09, MEM wrote:
> You can set it up any number of ways. There is no
absolute need for a redirect. Everything can be
done in one form, or not -- your choice.
Cheers,
tedd
Yes. But since I don't want to display a success information + form fields,
but only the success
> You can set it up any number of ways. There is no
> absolute need for a redirect. Everything can be
> done in one form, or not -- your choice.
>
> Cheers,
>
> tedd
Yes. But since I don't want to display a success information + form fields,
but only the success information,
I believe the only w
At 3:06 PM +0100 10/2/09, MEM wrote:
I want to apologize to you all. I have mentioned two things on the same
basket, but it was not appropriate. Since a confirmation page is not the
same thing as a success page.
Let's forget about the confirmation page, since it's not required.
I'm now understa
At 1:55 PM +0530 10/2/09, kranthi wrote:
and yes i forgot to mention... i avoid hidden form elements because
they can be modified very easily and hence pose a security threat.
That depends upon how sloppy you are in coding.
NONE of my hidden variables pose any security problems whatsoever.
Ch
k
> Cc: Manuel Lemos; php-general@lists.php.net; MEM; Bob McConnell
> Subject: Re: [PHP] Self-Process php forms or not?
>
> >> You say you don't use hidden fields because they can be modified too
> >> easily, yet you say you check for the submit button? Which out o
>> You say you don't use hidden fields because they can be modified too
>> easily, yet you say you check for the submit button? Which out of the
>> two do you do, as last time I checked, modifying one form field is as
>> easy as changing any other!
I completely agree with you. changing submit text
On Fri, 2009-10-02 at 13:55 +0530, kranthi wrote:
> and yes i forgot to mention... i avoid hidden form elements because
> they can be modified very easily and hence pose a security threat.
>
You say you don't use hidden fields because they can be modified too
easily, yet you say you check for the
and yes i forgot to mention... i avoid hidden form elements because
they can be modified very easily and hence pose a security threat.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
>> That only works if the user clicks on that submit button. If the user
>> hits the enter key in a text input, the form is submitted but the submit
>> input variable is not set. That is why an hidden input is a safer solution.
i doubt that, because i use the above mentioned method in nearly all
o
Hello,
on 10/02/2009 04:41 AM kranthi said the following:
> I try to avoid the use of hidden form elements as much as possible,
> especially for tracking whether a user has submitted a form or not...
>
> I use name="submit" for the submit button instead, that will pass the
> value of the submit b
I try to avoid the use of hidden form elements as much as possible,
especially for tracking whether a user has submitted a form or not...
I use name="submit" for the submit button instead, that will pass the
value of the submit button to the action script.
above all i use a template engine, smart
Hello,
on 10/01/2009 09:00 AM MEM said the following:
> One last question about this:
>
> I've done a self submit form, after hearing all the advantages expressed
> here.
> But how could we relate, without using javascript, a self submit form with a
> "success page" or a "confirmation page" that
7;
> Subject: Re: [PHP] Self-Process php forms or not?
>
> On 10/1/09 10:13 AM, "tedd" wrote:
>
> > At 1:00 PM +0100 10/1/09, MEM wrote:
> >> One last question about this:
> >>
> >> I've done a self submit form, after hearing all the advant
On 10/1/09 10:13 AM, "tedd" wrote:
> At 1:00 PM +0100 10/1/09, MEM wrote:
>> One last question about this:
>>
>> I've done a self submit form, after hearing all the advantages expressed
>> here.
>> But how could we relate, without using javascript, a self submit form with a
>> "success page" or
On Thu, 2009-10-01 at 09:30 -0400, Tom Worster wrote:
> On 10/1/09 8:00 AM, "MEM" wrote:
>
> > One last question about this:
> >
> > I've done a self submit form, after hearing all the advantages expressed
> > here.
> > But how could we relate, without using javascript, a self submit form with
At 1:00 PM +0100 10/1/09, MEM wrote:
One last question about this:
I've done a self submit form, after hearing all the advantages expressed
here.
But how could we relate, without using javascript, a self submit form with a
"success page" or a "confirmation page" that doesn't show the form?
Can
Original Message
> From: Mert Oztekin
> To: MEM ; Bob McConnell ; PHP-General List
>
> Sent: Thursday, October 1, 2009 5:16:40 AM
> Subject: RE: [PHP] Self-Process php forms or not?
>
> May be it is best time to for you to start using Zend Framework -> Zend
ent: 01 October 2009 13:01
To: 'Bob McConnell'; 'PHP-General List'
Subject: RE: [PHP] Self-Process php forms or not?
One last question about this:
I've done a self submit form, after hearing all the advantages expressed
here.
But how could we relate, without using javasc
On 10/1/09 8:00 AM, "MEM" wrote:
> One last question about this:
>
> I've done a self submit form, after hearing all the advantages expressed
> here.
> But how could we relate, without using javascript, a self submit form with a
> "success page" or a "confirmation page" that doesn't show the fo
May be it is best time to for you to start using Zend Framework -> Zend_Form
-Original Message-
From: MEM [mailto:tal...@gmail.com]
Sent: Thursday, October 01, 2009 3:01 PM
To: 'Bob McConnell'; 'PHP-General List'
Subject: RE: [PHP] Self-Process php forms or not?
t; To: PHP-General List
> Subject: RE: [PHP] Self-Process php forms or not?
>
> When you have it all in one file, the first thing you do is check to
> see if this request was submitted from the form. If not, you send the
> blank form. If it was, you validate all of the data. When a
Shawn McKenzie wrote:
> PJ wrote:
>
>> AngeloZanetti wrote:
>>
>>> Shawn McKenzie wrote:
>>>
>>>
PJ wrote:
> PROBLEM 1 solved: errant s removed; strange that they were
> inhibiting entry of data into form field?
>
> PROBLEM 2 not resolved: but
Andrew Ballard wrote:
> On Wed, Jun 3, 2009 at 7:13 PM, PJ wrote:
>
>> Tom Chubb wrote:
>>
>>> 2009/6/3 PJ :
>>>
>>>
The code:
...snip
   Â
      accès client >>> name="title" value="" size="10" />
      mot de passe >>> va
On Wed, Jun 3, 2009 at 7:13 PM, PJ wrote:
> Tom Chubb wrote:
>> 2009/6/3 PJ :
>>
>>> The code:
>>> ...snip
>>>
>>>
>>> accès client >> name="title" value="" size="10" />
>>> mot de passe
>>> >> value=" entrez " />
>>> Inscription
>>>
PJ wrote:
> AngeloZanetti wrote:
>> Shawn McKenzie wrote:
>>
>>> PJ wrote:
>>>
PROBLEM 1 solved: errant s removed; strange that they were
inhibiting entry of data into form field?
PROBLEM 2 not resolved: but the form was off the page and
clipped in upper right hand corn
AngeloZanetti wrote:
>
> Shawn McKenzie wrote:
>
>> PJ wrote:
>>
>>> PROBLEM 1 solved: errant s removed; strange that they were
>>> inhibiting entry of data into form field?
>>>
>>> PROBLEM 2 not resolved: but the form was off the page and clipped in
>>> upper right hand corner. What can be
Tom Chubb wrote:
> 2009/6/3 PJ :
>
>> The code:
>> ...snip
>>
>>
>>accès client > name="title" value="" size="10" />
>>mot de passe
>>> value=" entrez " />
>> Inscription
>>
>>> snip...
>>
>> PROBLEM 1: On Firefox3,
Shawn McKenzie wrote:
>
> PJ wrote:
>> PROBLEM 1 solved: errant s removed; strange that they were
>> inhibiting entry of data into form field?
>>
>> PROBLEM 2 not resolved: but the form was off the page and clipped in
>> upper right hand corner. What can be done to get it to show correctly?
>>
2009/6/3 PJ :
> The code:
> ...snip
>
>
> accès client name="title" value="" size="10" />
> mot de passe
> value=" entrez " />
> Inscription
>
> snip...
>
> PROBLEM 1: On Firefox3, the first input (accès client) does not
PROBLEM 1 solved: errant s removed; strange that they were
inhibiting entry of data into form field?
PROBLEM 2 not resolved: but the form was off the page and clipped in
upper right hand corner. What can be done to get it to show correctly?
--
Hervé Kempf: "Pour sauver la planète, sortez du capi
On Wed, Jun 3, 2009 at 11:55 AM, PJ wrote:
> The code:
> ...snip
>
>
> accès client name="title" value="" size="10" />
> mot de passe
> value=" entrez " />
> Inscription
>
> snip...
>
> PROBLEM 1: On Firefox3, the first
The code:
...snip
accès client
mot de passe
Inscription
http://www.ptahhotep.com
http://www.chiccantine.com/andypantry.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/un
On May 20, 2009, at 2:03 AM, Angelo Zanetti wrote:
We have done quite a few projects and we are looking to find better
ways to
implementing forms.
This is fairly simple to roll-your-own.
I do it from metadata. I check MySQL metadata for data types,
lengths, and defaults. In addition, my
re
>> work in the end to develop PHP forms based applications than if I would
>> type HTML manually.
>>
>> Furthermore, the plug-ins that come with the package dramatically reduce
>> the amount of code you need to type to achieve the same generating
>> common HTML input
t you mean.
>
> The Forms Generation and Validation package seems to do exactly what you
> describe and more.
>
>
> IMHO, creating forms by hand is by no means simpler, especially if you
> want to include browser side (Javascript) validation.
>
> I mean, I am not masoch
-Original Message-
From: Manuel Lemos [mailto:mle...@acm.org]
Sent: 22 May 2009 09:56
To: Paul M Foster
Cc: php-general@lists.php.net; Angelo Zanetti
Subject: Re: [PHP] Forms validation and creation- easier solution?
Hello,
on 05/20/2009 11:09 AM Paul M Foster said the following
s by no means simpler, especially if you
want to include browser side (Javascript) validation.
I mean, I am not masochist to create something that will give me more
work in the end to develop PHP forms based applications than if I would
type HTML manually.
Furthermore, the plug-ins that come with th
On Wed, May 20, 2009 at 05:10:57PM +0200, Angelo Zanetti wrote:
>
>
> -Original Message-
> From: Paul M Foster [mailto:pa...@quillandmouse.com]
> Sent: 20 May 2009 16:09
> To: php-general@lists.php.net
> Subject: Re: [PHP] Forms validation and creation- easier solut
-Original Message-
From: Paul M Foster [mailto:pa...@quillandmouse.com]
Sent: 20 May 2009 16:09
To: php-general@lists.php.net
Subject: Re: [PHP] Forms validation and creation- easier solution?
On Wed, May 20, 2009 at 10:08:12AM +0300, Olexandr Heneralov wrote:
>
> 2009/5/20
On Wed, May 20, 2009 at 10:08:12AM +0300, Olexandr Heneralov wrote:
>
> 2009/5/20 Angelo Zanetti
>
> > Hi all.
> >
> > We have done quite a few projects and we are looking to find better ways to
> > implementing forms.
> >
> > Forms seem to be quite time consuming and repetitive.
> >
> > Genera
[snip]
1. Easy creation of forms (fields and layout)
[/snip]
I posted a form function several months ago that will help you with
this. Just search the list archives
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
]
> *Sent:* 20 May 2009 09:08
> *To:* Angelo Zanetti
> *Cc:* php-general@lists.php.net
> *Subject:* Re: [PHP] Forms validation and creation- easier solution?
>
>
>
> Hi!
> Zend framework has a wonderful solution to solve this task. You can
> download even the demo sh
_
From: Olexandr Heneralov [mailto:ohenera...@gmail.com]
Sent: 20 May 2009 09:08
To: Angelo Zanetti
Cc: php-general@lists.php.net
Subject: Re: [PHP] Forms validation and creation- easier solution?
Hi!
Zend framework has a wonderful solution to solve this task. You can download
Hi!
Zend framework has a wonderful solution to solve this task. You can download
even the demo showing how to do this task
Best regards,
Alex.
2009/5/20 Angelo Zanetti
> Hi all.
>
>
>
> We have done quite a few projects and we are looking to find better ways to
> implementing forms.
>
>
>
> Form
Hi all.
We have done quite a few projects and we are looking to find better ways to
implementing forms.
Forms seem to be quite time consuming and repetitive.
Generally are there any classes or libraries that will assist with:
1. Easy creation of forms (fields and layout)
2. V
On Thu, 2009-04-30 at 11:06 +0200, Marcus Gnaß wrote:
> Troy Oltmanns wrote:
> > I have the code below being used to rifle through a list of available
> > categories and create select options for them. The code is being used to
> > query the database and compare the product category to the current
Troy Oltmanns wrote:
> I have the code below being used to rifle through a list of available
> categories and create select options for them. The code is being used to
> query the database and compare the product category to the current
> iteration, if there's a match, then add selected code so the
I have the code below being used to rifle through a list of available
categories and create select options for them. The code is being used to
query the database and compare the product category to the current
iteration, if there's a match, then add selected code so the category is
prechosen. More
Hello,
on 04/24/2009 09:34 AM MEM said the following:
> I’m trying to understand the advantages behind opting by using a
> Self-Process PHP Form, instead of having a form and then point the action of
> the form to another .php page.
>
> Can anyone point me some resources about this. Why using o
ril de 2009 14:20
> To: php-general@lists.php.net
> Subject: Re: [PHP] Self-Process php forms or not?
>
> Having a script that is self executing - when it posts back to itself
> instead of a separate script - has absolutely nothing to do with the
> separation of business and pr
What you are describing is known as a "self executing" script where the
script posts back to itself. In other words it has two passes - the first
uses the GET method to build the screen for the user, which may or may not
be empty, while the second uses the POST method to send the user's changes
moto: "let's separate business from presentation?"
>
>
> Thanks once again,
> Márcio
> -Original Message-
> From: Sándor Tamás (HostWare Kft.) [mailto:sandorta...@hostware.hu]
> Sent: sexta-feira, 24 de Abril de 2009 13:53
> To: 'PHP-General List'
&
t;'Sándor Tamás (HostWare Kft.)'" ;
"'PHP-General List'"
Sent: Friday, April 24, 2009 3:03 PM
Subject: RE: [PHP] Self-Process php forms or not?
So, on your opinion, we can call that method, on some circumstances, a good
practice?
What about the moto: "le
[snip] What about the moto: "let's separate business from presentation?"[/snip]
This depends on how strictly you're following any given model like MVC. IMHO
you should use the right tool for the job.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/uns
From: "MEM"
To: "'PHP-General List'"
Sent: Friday, April 24, 2009 2:34 PM
Subject: [PHP] Self-Process php forms or not?
I'm trying to understand the advantages behind opting by using a
Self-Process PHP Form, instead of having a form and then point the
are.hu]
> Sent: sexta-feira, 24 de Abril de 2009 13:53
> To: 'PHP-General List'
> Subject: Re: [PHP] Self-Process php forms or not?
>
> I think the main advantage is that if something goes wrong processing
> the
> datas, you can show the form again without redirecting a
quot;
To: "'PHP-General List'"
Sent: Friday, April 24, 2009 2:34 PM
Subject: [PHP] Self-Process php forms or not?
I'm trying to understand the advantages behind opting by using a
Self-Process PHP Form, instead of having a form and then point the action of
the form to anot
Im trying to understand the advantages behind opting by using a
Self-Process PHP Form, instead of having a form and then point the action of
the form to another .php page.
Can anyone point me some resources about this. Why using one instead of
another. What are the main advantages?
Regard
Some older browsers didn't send along the button name/value when you
hit enter, for a one-button form...
But I've never heard of one that failed to send anything at all...
It's almost for sure a browser issue though -- PHP doesn't really *do*
anything with the data it gets.
It just stuffs it int
On Jan 24, 2008 3:34 AM, Mark Pashia <[EMAIL PROTECTED]> wrote:
> If I fill in the fields of a form and hit the "enter" key to submit the
> form, no variables seem to be passed along. If I use the submit button,
> everything works perfectly. It seems that other forms on the web work with
> the ent
Mark Pashia schreef:
I am fairly new to the php/mySQL combo and just noticed an unusual behavior
and don't know where to find the answer to fix this. It is probably common
knowledge, but not to a newbie.
If I fill in the fields of a form and hit the "enter" key to submit the
form, no variabl
I am fairly new to the php/mySQL combo and just noticed an unusual behavior
and don't know where to find the answer to fix this. It is probably common
knowledge, but not to a newbie.
If I fill in the fields of a form and hit the "enter" key to submit the
form, no variables seem to be passed alo
On Mon, 2008-01-21 at 23:15 -0500, nihilism machine wrote:
> Why isnt this cleaning my form $_POST's
>
> class forms {
>
> var $UserInputClean;
>
> // Forms to variables
> function forms() {
> if (count($_POST) > 0) {
> foreach($_POST
Why isnt this cleaning my form $_POST's
class forms {
var $UserInputClean;
// Forms to variables
function forms() {
if (count($_POST) > 0) {
foreach($_POST as $curPostKey => $curPostVal) {
$c
Chat: [EMAIL PROTECTED] | SKYPE:
bestplace | Web: bestplace.biz | Web: seo-diy.com
> -Original Message-
> From: Jeffrey [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 23, 2007 4:12 AM
> To: php-general@lists.php.net
> Subject: [PHP] Page not displayed/Forbidden on PHP f
We are running identical web applications with two different hosts. Both
are LAMP.
With one of hosts, we are having reports of users seeing "Page not
displayed" or "403 Forbidden" after submitting forms. These forms are
always sending data to the same page from which they started and the
prob
On Thu, June 7, 2007 9:03 pm, Dylan Bouterse wrote:
> My company has a RH ES4 web server running apache/2.2.2 and PHP 5.1.4.
> Our PHP programmer has developed quite a few PHP email forms and each
> time an email is sent, the FROM: address is
> [EMAIL PROTECTED] I don't know if this is a PHP
> pr
>
> My company has a RH ES4 web server running apache/2.2.2 and PHP 5.1.4.
> Our PHP programmer has developed quite a few PHP email forms and each
> time an email is sent, the FROM: address is
> [EMAIL PROTECTED] I don't know if this is a PHP
> problem or apache problem (or even a sendmail problem
On Thu, 2007-06-07 at 22:03 -0400, Dylan Bouterse wrote:
> My company has a RH ES4 web server running apache/2.2.2 and PHP 5.1.4.
> Our PHP programmer has developed quite a few PHP email forms and each
> time an email is sent, the FROM: address is
> [EMAIL PROTECTED] I don't know if this is a PHP
>
My company has a RH ES4 web server running apache/2.2.2 and PHP 5.1.4.
Our PHP programmer has developed quite a few PHP email forms and each
time an email is sent, the FROM: address is
[EMAIL PROTECTED] I don't know if this is a PHP
problem or apache problem (or even a sendmail problem for that ma
Original Message-
> From: Stut [mailto:[EMAIL PROTECTED]
> Sent: January 12, 2007 11:38 AM
> To: Beauford
> Cc: 'PHP'
> Subject: Re: [PHP] Forms and destroying values
>
> Beauford wrote:
> > So the answer is, there is no way to destroy the values. Question
>
t passing through the database
transaction.
Satyam
- Original Message -
From: "Beauford" <[EMAIL PROTECTED]>
To: "'PHP'"
Sent: Friday, January 12, 2007 5:23 PM
Subject: RE: [PHP] Forms and destroying values
So the answer is, there is no way t
2007. 01. 12, péntek keltezéssel 11.43-kor Robert Cummings ezt írta:
> On Fri, 2007-01-12 at 17:36 +0100, Németh Zoltán wrote:
> > Beauford,
> >
> > The unset() function is for session variables, which are remembered by
> > the server even after the script finished running, that's their
> > purpos
On Fri, 2007-01-12 at 17:36 +0100, Németh Zoltán wrote:
> Beauford,
>
> The unset() function is for session variables, which are remembered by
> the server even after the script finished running, that's their
> purpose. Your variables are not session variables but normal
> variables.
Wrong! Pleas
[mailto:[EMAIL PROTECTED]
> > Sent: January 12, 2007 8:21 AM
> > To: Beauford; PHP
> > Subject: Re: [PHP] Forms and destroying values
> >
> > This issue comes over and over again. The trick, as I
> > learned from this list, is to send a redirect to the browser
On Fri, 2007-01-12 at 11:23 -0500, Beauford wrote:
> So the answer is, there is no way to destroy the values. Question then, what
> is unset() used for as it doesn't seem to do anything? With a language as
> good as PHP I though there would be some way to do this. I have got a
> workaround, but th
n hitting the server again.
Hope that makes it clearer.
-Stut
-Original Message-
From: Satyam [mailto:[EMAIL PROTECTED]
Sent: January 12, 2007 8:21 AM
To: Beauford; PHP
Subject: Re: [PHP] Forms and destroying values
This issue comes over and over again. The trick, as I
learned from t
1 - 100 of 379 matches
Mail list logo
