php-general Digest 4 Jul 2010 22:45:37 -0000 Issue 6830
Topics (messages 306670 through 306682):
HTML in emails
306670 by: Al
306671 by: Per Jessen
306672 by: Jonesy
306673 by: Rick Pasotto
306675 by: Per Jessen
306678 by: Paul M Foster
306682 by: Ashley Sheridan
form validation and error display
306674 by: David Mehler
306679 by: Shreyas Agasthya
306680 by: Paul M Foster
306681 by: David Mehler
curl
306676 by: madunix
306677 by: shiplu
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
I know this is a bit off-topic; but close enough.
I'm starting to update the email feature of one of my DB applications and
noticed that it appears most of the fancy emails I receive are using just plain
old, simple html pages, with a note about not being able to see, go here with a
link.
It use to be that we specified content-type text/html, etc. and sent both the
plain ASCII and the html with boundaries and so forth.
Seems like, from my preliminary Google searching, I should not waste time with
the standard's way and just go straight to sending simple html pages since all
modern browsers handle it well. And, it appears to be the way web is going.
What are you folks doing?
Al..........
--- End Message ---
--- Begin Message ---
Al wrote:
> I know this is a bit off-topic; but close enough.
>
> I'm starting to update the email feature of one of my DB applications
> and noticed that it appears most of the fancy emails I receive are
> using just plain old, simple html pages, with a note about not being
> able to see, go here with a link.
>
> It use to be that we specified content-type text/html, etc. and sent
> both the plain ASCII and the html with boundaries and so forth.
Yes, multipart/alternative that was.
> Seems like, from my preliminary Google searching, I should not waste
> time with the standard's way and just go straight to sending simple
> html pages since all modern browsers handle it well.
> And, it appears to be the way web is going.
>
> What are you folks doing?
We follow the standard and send both text and html.
--
Per Jessen, Zürich (24.5°C)
--- End Message ---
--- Begin Message ---
On Sun, 04 Jul 2010 11:43:59 -0400, Al wrote:
> I know this is a bit off-topic; but close enough.
>
> I'm starting to update the email feature of one of my DB applications and
> noticed that it appears most of the fancy emails I receive are using just
> plain
> old, simple html pages, with a note about not being able to see, go here with
> a
> link.
>
> It use to be that we specified content-type text/html, etc. and sent both the
> plain ASCII and the html with boundaries and so forth.
>
> Seems like, from my preliminary Google searching, I should not waste time
> with
> the standard's way and just go straight to sending simple html pages since
> all
> modern browsers handle it well. And, it appears to be the way web is going.
>
> What are you folks doing?
In general, I simply do _not_ read "fancy emails". Alpine 2.00 here.
I *browse* with a browser -- nothing more.
html in email seems to be all about eye candy -- not content.
I don't waste time looking for the 'content' in an email where it
appears more effort was applied to the dancing elephants and
flying pigs than was put into the message.
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
38.24N 104.55W | @ config.com | Jonesy | OS/2
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm
--- End Message ---
--- Begin Message ---
On Sun, Jul 04, 2010 at 06:31:38PM +0200, Per Jessen wrote:
> Al wrote:
>
> > I know this is a bit off-topic; but close enough.
> >
> > I'm starting to update the email feature of one of my DB applications
> > and noticed that it appears most of the fancy emails I receive are
> > using just plain old, simple html pages, with a note about not being
> > able to see, go here with a link.
Such emails are stupid. Obviously I can read the email quite fine. The
problem is that there is no useful content. Just an instruction to click
on a link.
> > It use to be that we specified content-type text/html, etc. and sent
> > both the plain ASCII and the html with boundaries and so forth.
>
> Yes, multipart/alternative that was.
>
> > Seems like, from my preliminary Google searching, I should not waste
> > time with the standard's way and just go straight to sending simple
> > html pages since all modern browsers handle it well.
> > And, it appears to be the way web is going.
Then I will never read your email.
Browsers are for web pages, not email.
> > What are you folks doing?
>
> We follow the standard and send both text and html.
The text portion is the *only* portion I read.
--
"When dealing with people, remember you are not dealing with creatures
of logic, but creatures of emotion." -- Dale Carnegie
Rick Pasotto [email protected] http://www.niof.net
--- End Message ---
--- Begin Message ---
Rick Pasotto wrote:
> On Sun, Jul 04, 2010 at 06:31:38PM +0200, Per Jessen wrote:
>>
>> We follow the standard and send both text and html.
>
> The text portion is the *only* portion I read.
>
Cool, that is the whole point.
--
Per Jessen, Zürich (24.3°C)
--- End Message ---
--- Begin Message ---
On Sun, Jul 04, 2010 at 11:43:59AM -0400, Al wrote:
> I know this is a bit off-topic; but close enough.
>
> I'm starting to update the email feature of one of my DB applications and
> noticed that it appears most of the fancy emails I receive are using
> just plain
> old, simple html pages, with a note about not being able to see, go here
> with a
> link.
>
> It use to be that we specified content-type text/html, etc. and sent both the
> plain ASCII and the html with boundaries and so forth.
>
> Seems like, from my preliminary Google searching, I should not waste
> time with
> the standard's way and just go straight to sending simple html pages
> since all
> modern browsers handle it well. And, it appears to be the way web is going.
>
> What are you folks doing?
I use mutt for email, so I only see the text portion. That make me an
anomaly. However, for example there are various listserv software that
will not allow HTML in emails.
Here is the real problem with HTML email. Any straight text message will
swell to many times its size when you HTML-ize it. Okay, so now you're
sending the message around the internet to perhaps hundreds or thousands
of users, using up many times the bandwidth that the actual message
really needs. It's like installing a 100w light bulb when a 60w will do.
There's simply no reason to suck CPU cycles all over the internet just
to make your message "prettier".
I understand that the functions of email and browser seem to be merging.
However, this is what I would consider a bad trend. It stems from folks
like Microsoft who have convinced people, for example, that spreadsheets
function perfectly well as databases. They don't, but that doesn't stop
people from using Excel to keep their mailing lists.
Of course, opinions like mine won't stop the merging of browsing and
reading email. Ah well.
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
On Sun, 2010-07-04 at 17:06 -0400, Paul M Foster wrote:
> On Sun, Jul 04, 2010 at 11:43:59AM -0400, Al wrote:
>
> > I know this is a bit off-topic; but close enough.
> >
> > I'm starting to update the email feature of one of my DB applications and
> > noticed that it appears most of the fancy emails I receive are using
> > just plain
> > old, simple html pages, with a note about not being able to see, go here
> > with a
> > link.
> >
> > It use to be that we specified content-type text/html, etc. and sent both
> > the
> > plain ASCII and the html with boundaries and so forth.
> >
> > Seems like, from my preliminary Google searching, I should not waste
> > time with
> > the standard's way and just go straight to sending simple html pages
> > since all
> > modern browsers handle it well. And, it appears to be the way web is going.
> >
> > What are you folks doing?
>
> I use mutt for email, so I only see the text portion. That make me an
> anomaly. However, for example there are various listserv software that
> will not allow HTML in emails.
>
> Here is the real problem with HTML email. Any straight text message will
> swell to many times its size when you HTML-ize it. Okay, so now you're
> sending the message around the internet to perhaps hundreds or thousands
> of users, using up many times the bandwidth that the actual message
> really needs. It's like installing a 100w light bulb when a 60w will do.
> There's simply no reason to suck CPU cycles all over the internet just
> to make your message "prettier".
>
> I understand that the functions of email and browser seem to be merging.
> However, this is what I would consider a bad trend. It stems from folks
> like Microsoft who have convinced people, for example, that spreadsheets
> function perfectly well as databases. They don't, but that doesn't stop
> people from using Excel to keep their mailing lists.
>
> Of course, opinions like mine won't stop the merging of browsing and
> reading email. Ah well.
>
> Paul
>
> --
> Paul M. Foster
>
I agree. Obviously the proliferation of free webmail accounts like Live,
GMail, Yahoo, etc have had a large impact on the way people consider
email. I actually had a friend ask me what this POP3 email thing was,
and what made it different from normal email, and it took me a moment to
realise his understanding of normal was one of these webmail services
available through the browser!
It is nice to be able to format emails nicely, but you have to realise
when to restrain yourself. I've been getting loads of emails from Adobe
lately that haven't been formatted well at all, and appear awfully in my
email client (Evolution, which I consider to be a very good client)
until I download all the images they've used as backgrounds. It's
situations like this that give HTML emails an awful name.
One feature I've seen in some mailing list software is the ability to
track how people prefer their email formatted, so that you only send
HTML emails to those that want them, and text emails to those who prefer
that method. It's the best of both worlds I reckon, and one that is
likely to upset as few people as possible; at the worst they might
receive one email in a format they don't want before they change their
preferences.
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
Hello,
I've got a form with several required fields of different types. I
want to have the php script process it only when all the required
fields are present, and to redisplay the form with filled in values on
failure so the user won't have to fill out the whole thing again.
One of my required fields is a text input field called name. If it's
not filled out the form displayed will show this:
<input type="text" name="name" id="name" size="50" value="<?php
echo($name); ?>" /> <br />
Note, I've got $_POST* variable processing before this so am assigning
that processing to short variables.
If that field is filled out, but another required one is not that form
field will fill in the value entered for the name field.
This is working for my text input fields, but not for either select
boxes or textareas. Here's the textarea also a required field:
<textarea name="description" id="description" cols="50" rows="10"
value="<?php echo($description); ?>"></textarea>
What this does, if a user fills out this field, but misses another, it
should echo the value of what was originally submitted. It is not
doing this. Same for my select boxes, here's one:
<select name="type" id="type" value="<?php echo($type); ?>">
<option value="0" selected="selected">-- select type --</option>
<option value="meeting"> - Meeting - </option>
<option value="event"> - Event - </option>
</select>
I'd also like for any not entered required fields to have an error box
around them, I've got a css class to handle this, but am not sure how
to tie it in to the fields since any one of the required fields could
not be filled in.
I'd appreciate any help.
Thanks.
Dave.
--- End Message ---
--- Begin Message ---
David,
If I understand your problem/issue here, you are talking about something
called 'sticky forms'.
This means -
(i) the form references itself.
(ii) that the form knows what the previous data was when it encounters any
validation issues.
You achieve (i) and (ii) by re-submitting the form with the usage of a
superglobal variable called $_SERVER['PHP_SELF'].
<form method='POST' action ="<php echo $_SERVER['PHP_SELF'] ?>" >
Regards,
Shreyas
On Sun, Jul 4, 2010 at 11:27 PM, David Mehler <[email protected]> wrote:
> Hello,
> I've got a form with several required fields of different types. I
> want to have the php script process it only when all the required
> fields are present, and to redisplay the form with filled in values on
> failure so the user won't have to fill out the whole thing again.
> One of my required fields is a text input field called name. If it's
> not filled out the form displayed will show this:
>
> <input type="text" name="name" id="name" size="50" value="<?php
> echo($name); ?>" /> <br />
>
> Note, I've got $_POST* variable processing before this so am assigning
> that processing to short variables.
> If that field is filled out, but another required one is not that form
> field will fill in the value entered for the name field.
> This is working for my text input fields, but not for either select
> boxes or textareas. Here's the textarea also a required field:
>
> <textarea name="description" id="description" cols="50" rows="10"
> value="<?php echo($description); ?>"></textarea>
>
> What this does, if a user fills out this field, but misses another, it
> should echo the value of what was originally submitted. It is not
> doing this. Same for my select boxes, here's one:
>
> <select name="type" id="type" value="<?php echo($type); ?>">
> <option value="0" selected="selected">-- select type --</option>
> <option value="meeting"> - Meeting - </option>
> <option value="event"> - Event - </option>
> </select>
>
> I'd also like for any not entered required fields to have an error box
> around them, I've got a css class to handle this, but am not sure how
> to tie it in to the fields since any one of the required fields could
> not be filled in.
> I'd appreciate any help.
> Thanks.
> Dave.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Regards,
Shreyas Agasthya
--- End Message ---
--- Begin Message ---
On Sun, Jul 04, 2010 at 01:57:01PM -0400, David Mehler wrote:
> Hello,
> I've got a form with several required fields of different types. I
> want to have the php script process it only when all the required
> fields are present, and to redisplay the form with filled in values on
> failure so the user won't have to fill out the whole thing again.
> One of my required fields is a text input field called name. If it's
> not filled out the form displayed will show this:
>
> <input type="text" name="name" id="name" size="50" value="<?php
> echo($name); ?>" /> <br />
>
> Note, I've got $_POST* variable processing before this so am assigning
> that processing to short variables.
> If that field is filled out, but another required one is not that form
> field will fill in the value entered for the name field.
> This is working for my text input fields, but not for either select
> boxes or textareas. Here's the textarea also a required field:
>
> <textarea name="description" id="description" cols="50" rows="10"
> value="<?php echo($description); ?>"></textarea>
Textarea fields don't work this way. To display the prior value, you
have to do this:
<textarea name="description><?php echo $description; ?></textarea>
>
> What this does, if a user fills out this field, but misses another, it
> should echo the value of what was originally submitted. It is not
> doing this. Same for my select boxes, here's one:
>
> <select name="type" id="type" value="<?php echo($type); ?>">
> <option value="0" selected="selected">-- select type --</option>
> <option value="meeting"> - Meeting - </option>
> <option value="event"> - Event - </option>
> </select>
The "value" attribute of a select field won't do this for you. You have
to actually set up each option with an either/or choice, like this:
<option value="0" <?php if ($type == 'meeting') echo 'selected="selected"';
?>> - Meeting - </option>
Since doing this is pretty tedious, I use a function here instead:
function set_selected($fieldname, $value)
{
if ($_POST[$fieldname] == $value)
echo 'selected="selected"';
}
And then
<option value="meeting" <?php set_selected('type', 'meeting');
?>>Meeting</option>
HTH,
Paul
--
Paul M. Foster
--- End Message ---
--- Begin Message ---
Hello everyone,
Thanks for your suggestions.
For my variable in the value area of the text input field I enter
value="<?php echo $name"; ?>
Prior to this I assign the variable $name to:
$name = stripslashes($_POST['name']);
I hope this is correct.
Sticky forms sounds exactly what i'm looking for. I've changed my
action attribute to
<?php echo $_SERVER['PHP_SELF']; ?>
The first thing I do once the page is loaded is check whether or not
submit is set, if it is not I display the form, which is in a function
call. If submit is set I want to begtin validation, so i'm deciding to
merge my two files in to one, I like this better. My question is say
for example the name text field is not filled out but all the other
required fields are how do I get the form to redisplay itself? I was
thinking a location redirect, but this doesn't sound right.
Thanks.
Dave.
On 7/4/10, Paul M Foster <[email protected]> wrote:
> On Sun, Jul 04, 2010 at 01:57:01PM -0400, David Mehler wrote:
>
>> Hello,
>> I've got a form with several required fields of different types. I
>> want to have the php script process it only when all the required
>> fields are present, and to redisplay the form with filled in values on
>> failure so the user won't have to fill out the whole thing again.
>> One of my required fields is a text input field called name. If it's
>> not filled out the form displayed will show this:
>>
>> <input type="text" name="name" id="name" size="50" value="<?php
>> echo($name); ?>" /> <br />
>>
>> Note, I've got $_POST* variable processing before this so am assigning
>> that processing to short variables.
>> If that field is filled out, but another required one is not that form
>> field will fill in the value entered for the name field.
>> This is working for my text input fields, but not for either select
>> boxes or textareas. Here's the textarea also a required field:
>>
>> <textarea name="description" id="description" cols="50" rows="10"
>> value="<?php echo($description); ?>"></textarea>
>
> Textarea fields don't work this way. To display the prior value, you
> have to do this:
>
> <textarea name="description><?php echo $description; ?></textarea>
>
>>
>> What this does, if a user fills out this field, but misses another, it
>> should echo the value of what was originally submitted. It is not
>> doing this. Same for my select boxes, here's one:
>>
>> <select name="type" id="type" value="<?php echo($type); ?>">
>> <option value="0" selected="selected">-- select type --</option>
>> <option value="meeting"> - Meeting - </option>
>> <option value="event"> - Event - </option>
>> </select>
>
> The "value" attribute of a select field won't do this for you. You have
> to actually set up each option with an either/or choice, like this:
>
> <option value="0" <?php if ($type == 'meeting') echo 'selected="selected"';
> ?>> - Meeting - </option>
>
> Since doing this is pretty tedious, I use a function here instead:
>
> function set_selected($fieldname, $value)
> {
> if ($_POST[$fieldname] == $value)
> echo 'selected="selected"';
> }
>
> And then
>
> <option value="meeting" <?php set_selected('type', 'meeting');
> ?>>Meeting</option>
>
> HTH,
>
> Paul
>
> --
> Paul M. Foster
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
I have an old unix fedora system with php 4.3.11, with the following
recompiled options
$ php -version
PHP 4.3.11 (cli) (built: Jun 6 2006 16:20:00)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
$ php -info | grep configure
Configure Command => './configure' '--enable-discard-path'
'--enable-track-vars' '--enable-force-cgi-redirect' '--with-gettext'
'--with-mysql' '--enable-so' '--with-apxs2' '--with-gd' '--with-zlib'
'--with-jpeg-dir=/usr/lib' '--enable-libgcc'
am planning to add the curl option to it, what would be the best
approach for that.
stop http, configure with--curl, make, make install feedback appreciated.
Thanks
--- End Message ---
--- Begin Message ---
# yum install php4-curl
or
# yum install php-curl
Shiplu Mokadd.im
My talks, http://talk.cmyweb.net
Follow me, http://twitter.com/shiplu
SUST Programmers, http://groups.google.com/group/p2psust
Innovation distinguishes bet ... ... (ask Steve Jobs the rest)
--- End Message ---
