php-general Digest 12 Sep 2010 07:30:37 -0000 Issue 6936
Topics (messages 307956 through 307972):
Re: Elegance is the goal... Sticky form submit help
307956 by: Jason Pruim
307957 by: Jason Pruim
307958 by: Jason Pruim
307959 by: Jason Pruim
307962 by: Jim Lucas
307963 by: tedd
307964 by: tedd
307972 by: Tamara Temple
Re: Disabling an extension on a perdir basis.
307960 by: Richard Quadling
307961 by: Jim Lucas
New to PHP and the list
307965 by: MikeB
307966 by: Tom Sparks
307967 by: MikeB
307969 by: viraj
Re: How to handle a submitted form with no changes -- best practices sought
307968 by: viraj
307970 by: Shawn McKenzie
Re: php cli question
307971 by: Shawn McKenzie
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Sep 11, 2010, at 11:55 AM, tedd wrote:
At 9:49 AM -0400 9/11/10, Jason Pruim wrote:
Hey everyone!
Hope you are having a great weekend, and I'm hoping someone might
be coherent enough to help me find a more elegant solution to a
problem that I have...
I have a form for submitting an event to a website, and if the form
is not submitted successfully (such as they didn't fill out a
required field) I want it to redisplay the form with inline errors
as to what happened and display the values they selected...
-snip-
Any ideas what I'm missing?
Jason:
I think what you are missing is that this data collection should be
split between client-side and server-side operations.
Hey tedd,
Thanks for the response but for this particular project I'm avoiding
using anything but standard HTML since it will be used almost
exclusively by people using screen readers and other assistive
technology so I'm going a little old school with it to make sure it
all works for everyone else first.
For client-side simply use javascript to monitor what they user
enters and then immediately respond to the requirements imposed upon
the user.
After the user fills out the information correctly and clicks
submit, then have your server-side scripts check the data again and
respond accordingly.
Here are a couple of examples:
http://webbytedd.com/c/form-calc/
http://webbytedd.com/c/form-submit/
I will definitely be checking out your examples though! Some of the
cleanest, well documented, and easiest to read code I have seen in a
long time!
--- End Message ---
--- Begin Message ---
Hey Ash,
On Sep 11, 2010, at 10:58 AM, a...@ashleysheridan.co.uk wrote:
For a month selector, using a loop to output the months is good, as
you can then within the loop check for that value sent and set the
selected html attribute for that select element.
that's what I was thinking too... Now just to work out the logic :)
I should warn you that your code will throw a warning when no data
has been posted to it. Consider using isset() instead to check for
posted values rather than comparing a value (which might not exist)
with true.
I have other code that will catch it if it's empty but a good
suggestion none the less! If I stick with that code for some reason
I'll be updating it to use isset()
Thanks Ash!
Thanks,
Ash
http://www.ashleysheridan.co.uk
----- Reply message -----
From: "Jason Pruim" <li...@pruimphotography.com>
Date: Sat, Sep 11, 2010 14:49
Subject: [PHP] Elegance is the goal... Sticky form submit help
To: "PHP-General list" <php-gene...@lists.php.net>
Hey everyone!
Hope you are having a great weekend, and I'm hoping someone might be
coherent enough to help me find a more elegant solution to a problem
that I have...
I have a form for submitting an event to a website, and if the form is
not submitted successfully (such as they didn't fill out a required
field) I want it to redisplay the form with inline errors as to what
happened and display the values they selected...
I have a working solution but was hoping for something a little more
elegant. And something that would work better for a month selector as
well... Here is the relevant code that I have that works:
<?PHP
if ($_POST['hidSubmit'] ==TRUE & $_POST['type'] == "meeting"):
echo <<<HTML
<select name="type" id="type">
<option value="0">-- select type --</option>
<option value="meeting" selected>Meeting</option>
<option value="event" >Event</option>
</select>
HTML;
elseif ($_POST['hidSubmit'] == TRUE & $_POST['type'] == "event"):
//if ($_POST['hidSubmit'] == TRUE & $_POST['type'] == "event") {
echo <<<HTML
<select name="type" id="type">
<option value="0">-- select type --</option>
<option value="meeting">Meeting</option>
<option value="event" selected>Event</option>
</select>
HTML;
else:
//if ($_POST['hidSubmit'] != TRUE):
echo <<<HTML
<select name="type" id="type">
<option value="0" selected>-- select type --</option>
<option value="meeting">Meeting</option>
<option value="event">Event</option>
</select>
HTML;
endif;
?>
which works BUT I don't want to have to have that for a month selector
or a day selector :)
Any ideas what I'm missing?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Hi Tamara,
On Sep 11, 2010, at 12:39 PM, Tamara Temple wrote:
Rather than repeating all that code, I suggest the following:
<select name="type" id="type>
<option value="0">-- select type --</option>
<option value="meeting" <?php echo (isset($_POST['hidSubmit'] &&
$_POST['hidSubmit'] == TRUE && $_POST['type'] == "meeting") ?
"selected" : '' ?>
<option value="event" <?php echo (isset($_POST['hidSubmit'] &&
$_POST['hidSubmit'] == TRUE && $_POST['type'] == "event") ?
"selected" : '' ?>
</select>
That's actually what I'm trying to get away from. I was hoping to do
it all in HEREDOC syntax. I've always thought it made it cleaner. But
that is a personal opinion :)
For a month selector, try:
<?php
// assume current month number is in $curr_month
$months = array(1 => "January", "February", "March", "April",
"May", "June", "July", "August", "September", "October", "November",
"December"); // will create an array of month names, with a starting
base of 1 (instead of zero)
echo "<select name=\"month\" id=\"month\">\n";
foreach ($months as $m => $mname) {
echo "<option value=\"$m\"";
if ($curr_month == $m) echo " selected ";
echo ">$mname</option>\n";
}
echo "</select>\n";
?>
There are other possiblities as well. One time, I didn't want to
actually store the month names, perhaps allowing them to be
localized. Instead I used strftime, which will return appropriate
names based on locale:
<?php
// assume current month number is in $curr_month
echo "<select name=\"month\" id=\"month\">\n";
for ($m = 1; $m <= 12; $m++) {
echo "<option value=\"$m\"";
if ($curr_month == $m) echo " selected ";
echo ">";
$mname = strftime("%B", 0,0,0,2010, $m, 1); // time, year and day
don't matter, all we're after is the appropriate month name set in
the locale
echo $mname;
echo "</option>\n";
}
echo "</select>\n";
?>
I'm actually doing something similar to that right now...
<?PHP
if (isset($_POST)) {
$date = date("n", $i);
echo $date;
$i++;
}
?>
Prints just the numeric reference to the month.
--- End Message ---
--- Begin Message ---
On Sep 11, 2010, at 1:03 PM, Debbie . wrote:
Jason,
I don't really understand the responses you got to this email, I
have attached the sticky form I made from a book called "PHP Visual
Quickstart guide. It uses an if conditional to print a response if
the field is empty.
If I'm not helping, sorry, I'm new!
Good luck!
live, love and be happy!
Deb
Hi Deb,
Welcome to the list! It will be the best and worse place you'll ever
come for help! :)
What you sent is helpful, but due to a personal preference I'm trying
to avoid going in and out of PHP like you do in there... Trying to use
HEREDOC for the entire page. It makes more sense to me that way :)
Thank you though! :)
--- End Message ---
--- Begin Message ---
Jason Pruim wrote:
Hi Tamara,
On Sep 11, 2010, at 12:39 PM, Tamara Temple wrote:
Rather than repeating all that code, I suggest the following:
<select name="type" id="type>
<option value="0">-- select type --</option>
<option value="meeting" <?php echo (isset($_POST['hidSubmit'] &&
$_POST['hidSubmit'] == TRUE && $_POST['type'] == "meeting") ?
"selected" : '' ?>
<option value="event" <?php echo (isset($_POST['hidSubmit'] &&
$_POST['hidSubmit'] == TRUE && $_POST['type'] == "event") ? "selected"
: '' ?>
</select>
That's actually what I'm trying to get away from. I was hoping to do it
all in HEREDOC syntax. I've always thought it made it cleaner. But that
is a personal opinion :)
For a month selector, try:
<?php
// assume current month number is in $curr_month
$months = array(1 => "January", "February", "March", "April", "May",
"June", "July", "August", "September", "October", "November",
"December"); // will create an array of month names, with a starting
base of 1 (instead of zero)
echo "<select name=\"month\" id=\"month\">\n";
foreach ($months as $m => $mname) {
echo "<option value=\"$m\"";
if ($curr_month == $m) echo " selected ";
echo ">$mname</option>\n";
}
echo "</select>\n";
?>
There are other possiblities as well. One time, I didn't want to
actually store the month names, perhaps allowing them to be localized.
Instead I used strftime, which will return appropriate names based on
locale:
<?php
// assume current month number is in $curr_month
echo "<select name=\"month\" id=\"month\">\n";
for ($m = 1; $m <= 12; $m++) {
echo "<option value=\"$m\"";
if ($curr_month == $m) echo " selected ";
echo ">";
$mname = strftime("%B", 0,0,0,2010, $m, 1); // time, year and day
don't matter, all we're after is the appropriate month name set in the
locale
echo $mname;
echo "</option>\n";
}
echo "</select>\n";
?>
I'm actually doing something similar to that right now...
<?PHP
if (isset($_POST)) {
$date = date("n", $i);
echo $date;
$i++;
}
?>
Prints just the numeric reference to the month.
Here is a combination of Tamara's method and they way that I would do it
based off her example. Some of hers didn't work for me out of the box,
so I modified it to my liking. Then I included your request to do
HEREDOC syntax for outputting the list.
<?php
$o = array();
for ($m = 1; $m <= 12; $m++) {
$sel = ($curr_month == $m ? ' selected="selected"':'');
$mname = date('F', mktime(0,0,0,$m));
$o[] = ' <option value="'.(int)$m.'"'.$sel.'>'.
htmlspecialchars($mname).'</option>';
}
$select_month_options = join("\n", $o);
echo <<<HTML
<select name="month" id="month">
{$select_month_options}
</select>
HTML;
?>
Jim
--- End Message ---
--- Begin Message ---
At 11:42 AM -0500 9/11/10, Tamara Temple wrote:
The debate on client-side vs. server-side form validation is
ongoing. Client-side is more responsive, and attempts to keep bad
data from ever reaching your application, but relies on javascript
being enabled. Since this is something easily turned off by users,
one can't always rely on it to do form validation. So server-side
validation is needed as well to allow your full application to
gracefully degrade in the absence of working javascript on the
client's side. Coding defensively helps!
It's not a debate.
You can provide progressive enhancement to your form to help your
users *IF* you want.
You should *always* validate all the information coming from the outside world.
The question of *if* you want to do both is your choice without any
debate. Those are only choices that you can elect to follow or not.
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
At 1:09 PM -0400 9/11/10, Jason Pruim wrote:
Hey tedd,
Thanks for the response but for this particular project I'm avoiding
using anything but standard HTML since it will be used almost
exclusively by people using screen readers and other assistive
technology so I'm going a little old school with it to make sure it
all works for everyone else first.
That goes without saying.
Regardless of *if* your users use screen readers, or not, progressive
enhancement should be followed.
Cheers,
tedd
--
-------
http://sperling.com/
--- End Message ---
--- Begin Message ---
On Sep 11, 2010, at 12:14 PM, Jason Pruim wrote:
On Sep 11, 2010, at 12:39 PM, Tamara Temple wrote:
Rather than repeating all that code, I suggest the following:
[snip]
That's actually what I'm trying to get away from. I was hoping to do
it all in HEREDOC syntax. I've always thought it made it cleaner.
But that is a personal opinion :)
Well, from a maintainability aspect, the way i showed makes more sense
because if there are changes to be made (such as adding another
option), you only have to make one change, not n changes.
--- End Message ---
--- Begin Message ---
On 11 September 2010 17:56, Jim Lucas <li...@cmsws.com> wrote:
> Richard Quadling wrote:
>>
>> Hi.
>>
>> Can't seem to see a way to do this.
>>
>> Is there a way to do this?
>>
>
> Are you talking about a PHP extension or a file extension?
>
I sat there for about a minute reading Ashley's comment, thinking
"what the f__k is he talking about!". Then your comment made it all
make sense.
I want to disable a PHP extension from 1 directory.
Initially I thought that I could use disable_class and
disable_function ini options, but these are php.ini only (according to
the docs).
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
Richard Quadling wrote:
On 11 September 2010 17:56, Jim Lucas <li...@cmsws.com> wrote:
Richard Quadling wrote:
Hi.
Can't seem to see a way to do this.
Is there a way to do this?
Are you talking about a PHP extension or a file extension?
I sat there for about a minute reading Ashley's comment, thinking
"what the f__k is he talking about!". Then your comment made it all
make sense.
I want to disable a PHP extension from 1 directory.
Initially I thought that I could use disable_class and
disable_function ini options, but these are php.ini only (according to
the docs).
As I thought, looking through the docs, it looks like the only way to
set the options that are only settable via the php.ini file is to use a
per directory php.ini file. But, the problem with that is, it only
works with the CGI/FASTCGI SAPI version of php. It won't work with the
apache mod version.
So, I guess the question back to you is, what is your setup like? And
if it isn't CGI/FASTCGI SAPI are you willing to change to that setup?
Read More: http://www.php.net/manual/en/configuration.file.per-user.php
Jim
--- End Message ---
--- Begin Message ---
Hello, I'm new to PHP and also new to using newsgroups/mailing lists
directly. So if I make a mistake, please forgive me this once and I'll
try to do better in the future.
Please help me understand, my head is absolutely spinning and I can't
get my mind around this.
In the php.net site there is an example on uploading a file via a
form. http://www.php.net/manual/en/features.file-upload.post-method.php
This is the sample code for the form:
<form enctype="multipart/form-data" action="__URL__" method="POST">
<!-- MAX_FILE_SIZE must precede the file input field -->
<input type="hidden" name="MAX_FILE_SIZE" value="30000" />
<!-- Name of input element determines name in $_FILES array -->
Send this file: <input name="userfile" type="file" />
<input type="submit" value="Send File" />
</form>
Is MAX_FILE_SIZE passed to PHP as $MAX_FILE_SIZE?
Assuming I want to make it a variable in my PHP code, can I do this:
<?php
$MAX_FILE_SIZE = 30000;
echo <<<_END
<form enctype="multipart/form-data" action="__URL__" method="POST">
<!-- MAX_FILE_SIZE must precede the file input field -->
<input type="hidden" name="MAX_FILE_SIZE" />
<!-- Name of input element determines name in $_FILES array -->
Send this file: <input name="userfile" type="file" />
<input type="submit" value="Send File" />
</form>
<<<_END
<?
In other words, simply omitting the "value" clause in the form field?
And can I make that value a global constant somehow so that I can
later also test the actual size of the uploaded file in another
function?
Or do I have to do this:
<?php
$MAX_UPLOAD_SIZE = 30000;
echo <<<_END
<form enctype="multipart/form-data" action="__URL__" method="POST">
<!-- MAX_FILE_SIZE must precede the file input field -->
<input type="hidden" name="MAX_FILE_SIZE"
value="$MAX_UPLOAD_SIZE"/>
<!-- Name of input element determines name in $_FILES array -->
Send this file: <input name="userfile" type="file" />
<input type="submit" value="Send File" />
</form>
<<<_END
<?
I'm also concerned that in the first instance, a malicious user can
modify the value and I will be hosed. Am I correct?
Thanks.
--- End Message ---
--- Begin Message ---
--- On Sun, 12/9/10, MikeB <mpbr...@gmail.com> wrote:
> From: MikeB <mpbr...@gmail.com>
> Subject: [PHP] New to PHP and the list
> To: php-gene...@lists.php.net
> Received: Sunday, 12 September, 2010, 9:37 AM
> Hello, I'm new to PHP and also new to
> using newsgroups/mailing lists directly. So if I make a
> mistake, please forgive me this once and I'll try to do
> better in the future.
>
> Please help me understand, my head is absolutely spinning
> and I can't
> get my mind around this.
>
> In the php.net site there is an example on uploading a file
> via a
> form. http://www.php.net/manual/en/features.file-upload.post-method.php
>
start off simpler with this version
http://www.w3schools.com/php/php_file_upload.asp
tom
--- End Message ---
--- Begin Message ---
On 9/11/2010 6:51 PM, Tom Sparks wrote:
--- On Sun, 12/9/10, MikeB<mpbr...@gmail.com> wrote:
From: MikeB<mpbr...@gmail.com>
Subject: [PHP] New to PHP and the list
To: php-gene...@lists.php.net
Received: Sunday, 12 September, 2010, 9:37 AM
Hello, I'm new to PHP and also new to
using newsgroups/mailing lists directly. So if I make a
mistake, please forgive me this once and I'll try to do
better in the future.
Please help me understand, my head is absolutely spinning
and I can't
get my mind around this.
In the php.net site there is an example on uploading a file
via a
form. http://www.php.net/manual/en/features.file-upload.post-method.php
start off simpler with this version
http://www.w3schools.com/php/php_file_upload.asp
I think I have that much under my belt, I'm more or less trying to dig a
little deeper.
--- End Message ---
--- Begin Message ---
On Sun, Sep 12, 2010 at 5:07 AM, MikeB <mpbr...@gmail.com> wrote:
> Hello, I'm new to PHP and also new to using newsgroups/mailing lists
> directly. So if I make a mistake, please forgive me this once and I'll try
> to do better in the future.
>
> Please help me understand, my head is absolutely spinning and I can't
> get my mind around this.
>
> In the php.net site there is an example on uploading a file via a
> form. http://www.php.net/manual/en/features.file-upload.post-method.php
>
> This is the sample code for the form:
>
> <form enctype="multipart/form-data" action="__URL__" method="POST">
> <!-- MAX_FILE_SIZE must precede the file input field -->
> <input type="hidden" name="MAX_FILE_SIZE" value="30000" />
> <!-- Name of input element determines name in $_FILES array -->
> Send this file: <input name="userfile" type="file" />
> <input type="submit" value="Send File" />
> </form>
>
> Is MAX_FILE_SIZE passed to PHP as $MAX_FILE_SIZE?
err! print_r and var_dump is your friend!
>
> Assuming I want to make it a variable in my PHP code, can I do this:
>
> <?php
>
> $MAX_FILE_SIZE = 30000;
>
> echo <<<_END
> <form enctype="multipart/form-data" action="__URL__" method="POST">
> <!-- MAX_FILE_SIZE must precede the file input field -->
> <input type="hidden" name="MAX_FILE_SIZE" />
> <!-- Name of input element determines name in $_FILES array -->
> Send this file: <input name="userfile" type="file" />
> <input type="submit" value="Send File" />
> </form>
> <<<_END
> <?
>
> In other words, simply omitting the "value" clause in the form field?
>
> And can I make that value a global constant somehow so that I can
> later also test the actual size of the uploaded file in another
> function?
if this is about getting the size of the uploaded file, you better try
print_r($_FILES) after the form submit. there you have size in bytes.
MAX_FILE_SIZE in html form will be used to early notify the up-loader,
in case of a bigger file which exceeds the server side limit imposed
through php.ini. (see http://www.php.net/manual/en/ini.core.php file
uploads section)
>
> Or do I have to do this:
>
> <?php
>
> $MAX_UPLOAD_SIZE = 30000;
> <<<_END
> <?
>
> I'm also concerned that in the first instance, a malicious user can
> modify the value and I will be hosed. Am I correct?
and yes, never trust client side.
~viraj
>
> Thanks.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
On Sat, Sep 11, 2010 at 10:22 PM, Tamara Temple <tamouse.li...@gmail.com> wrote:
> I have a general question and am looking for best practices.
>
> Is it worth the overhead of passing along the previous values in the table
> in hidden fields so that fields can be checked to see if they've been
without storing all the values in respective hidden fields, calculate
a 'checksum' on data and store in one hidden field. after the submit
and before you decide on the update, you can calculate the checksum of
submitted data, compare against the hidden field checksum and take the
decision.
if you maintain a session, storing checksum in session instead of
client side (hidden field in form) will be more safe/secure and will
help in improving the mechanism (persistent classes, serialized data
etc)
~viraj
> updated or not after the submit? Or is it worth reloading the old values
> from the table to check against the newly submitted form? Or is all that
> overhead not worth the time because an update that overwrites existing
> values with the same values is not that onerous?
>
> (Is that question clear enough?)
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
On 09/11/2010 11:52 AM, Tamara Temple wrote:
> I have a general question and am looking for best practices.
>
> Suppose I present a user with a form for editing an entry in a table,
> i.e., the form has filled in values from the existing table entry.
>
> Now, suppose they click on 'submit' without making any changes in the
> form. (Perhaps, say, rather than clicking 'Cancel' or 'Return to Main'
> or some other option which would get them out of that screen without
> submitting the form).
>
> Is it worth the overhead of passing along the previous values in the
> table in hidden fields so that fields can be checked to see if they've
> been updated or not after the submit? Or is it worth reloading the old
> values from the table to check against the newly submitted form? Or is
> all that overhead not worth the time because an update that overwrites
> existing values with the same values is not that onerous?
>
> (Is that question clear enough?)
I would just submit the query. Unless you have hundreds or thousands of
users per second that load the form and submit the form with no changes,
then there really is no problem.
It could however be a problem if there is a BOT or something that
continually submits to your page. In that case (and in general) I would
recommend using a form token that helps guard against this.
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
--- Begin Message ---
On 09/10/2010 11:13 AM, J Ravi Menon wrote:
> Hi,
>
> I have some basic questions on running php (5.2.x series on Linux
> 2.6) as a standalone daemon using posix methods (fork() etc..):
>
> #!/usr/bin/php
> <?php
>
> require_once ('someclass.php');
>
> // do some initializations
> .
>
> // main 'forever' loop - the '$shutdown' will
> // be set to true via a signal handler
>
> while(!$shutdown)
> {
> $a = new SomeClass();
>
> $a->doSomething()
>
> }
>
> // shutdown logic.
>
> The 'someclass.php' in turn will include other files (via require_once).
>
> The above file will be executed directly from the shell. The main loop
> could be listening to new requests via sockets etc..
>
> Few questions:
>
> 1) Does opcode cache really matter in such cli-based daemons? As
> 'SomeClass' is instantiated at every loop, I am assuming it is only
> compiled once as it has already been 'seen'.
> I am not very clear on how apc (or eaccelerator) works in such cases.
>
>
> 2) What about garbage collection? In a standard apache-mod-php setup,
> we rely on the end of a request-cycle to free up resources - close
> file descriptiors, free up memory etc..
> I am assuming in the aforesaid standalone daemon case, we would
> have to do this manually? In the loop above, would it be better to
> 'unset($a)' explicitly at the end of it before
> it goes to the next iteration?
>
> Note: I have written pre-forker deamons in php directly and
> successfully deployed them in the past, but never looked at in depth
> to understand all the nuances. Anecdotally, I have
> done 'unset()' at some critical places were large arrays were used,
> and I think it helped. AFAIK, unlike Java, there is no 'garbage
> collector' thread that does all the magic?
>
> Thanks,
> Ravi
If I have time when you reply I'll answer the questions, but I must ask:
Is this purely academic? Why is this a concern? Have you encountered
issues? If so, what?
--
Thanks!
-Shawn
http://www.spidean.com
--- End Message ---
