| Eregi possible problem [message #169353] |
Wed, 08 September 2010 08:02  |
GarryJones
Messages: 21
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
To fix another problem I turned errors reporting on (I normally have
it off so users dont see errors that are not a problem).
I then received a surprising message about another line of code that
has worked for years. It says that eregi is depreciated, I am unsure
what that means as my code was still working so its strange that this
error came up as it is not an actual error. Maybe depreciated means we
dont want you to use this any more but if you do its okay?
Anyway I thought it best to change it just in case. I googled and
found a link to a function called preg that looks like it does the
job.
My question is are there any differences in the performance of eregi
and preg?
if (!eregi("^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.
[a-z]{2,3})$", $allepst)){
$emlstatus = 0; // invalid
} else {
$emlstatus = 1; // valid
}
if(!preg_match("/^[_\.0-9a-zA-Z-]+@([0-9a-zA-Z][0-9a-zA-Z-]+\.)+[a-zA-
Z]{2,6}$/i", $allepst)) {
$emlstatus = 0; // invalid
} else {
$emlstatus = 1; // valid
}
On a sidenote to this I wonder who changes the internet and why. If a
line of code works perfectly and serves a purpose and works for years
and years and years I don't get why anyone would want to change it.
Maybe it was not working on Google crome, firefox or macintosh, but I
always feel people who dont use a pc and msie can blame themselves
when websites dont work properly as most websites are written for msie
on a pc. I do now try to get things working in firefox. I still can't
get any of my flash code on my websites to work on my iphone but thats
not a question for this newsgroup.... Any feedback on eregi
APPRECIATED - do the two snippets of above code produce absolute
identical results for all input?
..
|
|
|
|
| Re: Eregi possible problem [message #169354 is a reply to message #169353] |
Wed, 08 September 2010 08:16  |
rf
Messages: 19
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
"GarryJones" <morack(at)algonet(dot)se> wrote in message
news:1d2e8599-6295-437e-b75b-2933ef09db24(at)q2g2000yqq(dot)googlegroups(dot)com...
> To fix another problem I turned errors reporting on (I normally have
> it off so users dont see errors that are not a problem).
What errors would not be a problem?
That is that an error means. A problem with your code. The interpreter finds
a problem and raises an error.
|
|
|
|
| Re: Eregi possible problem [message #169355 is a reply to message #169353] |
Wed, 08 September 2010 09:04 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 08/09/2010 10:02, GarryJones escribió/wrote:
> To fix another problem I turned errors reporting on (I normally have
> it off so users dont see errors that are not a problem).
>
> I then received a surprising message about another line of code that
> has worked for years. It says that eregi is depreciated, I am unsure
> what that means as my code was still working so its strange that this
> error came up as it is not an actual error. Maybe depreciated means we
> dont want you to use this any more but if you do its okay?
Deprecated means "obsolete": the function has been replaced by something
better, it's no longer maintained by the PHP team (if it has bugs, they
will never get fixed) and it will possibly get removed in a future
release. The notice is provided so you can update your code now you have
the chance and time, rather than a few years later when the server gets
updated and your program just stops working.
You don't need to rush and refactor right now all your legacy code
that's using this function but there's no excuse to use it in software
you are coding now.
> Anyway I thought it best to change it just in case. I googled and
> found a link to a function called preg that looks like it does the
> job.
Exactly. And there's no need to Google, it's explained right there in
the eregi manual page: http://php.net/eregi
"As of PHP 5.3.0, the regex extension is deprecated in favor of the PCRE
extension. Calling this function will issue an E_DEPRECATED notice. See
the list of differences[1] for help on converting to PCRE."
[1] http://es2.php.net/manual/en/reference.pcre.pattern.posix.php
> My question is are there any differences in the performance of eregi
> and preg?
Yes, there is. PCRE is supposed to be faster.
>
> if (!eregi("^[_a-z0-9-]+(\.[_a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.
> [a-z]{2,3})$", $allepst)){
> $emlstatus = 0; // invalid
> } else {
> $emlstatus = 1; // valid
> }
>
> if(!preg_match("/^[_\.0-9a-zA-Z-]+@([0-9a-zA-Z][0-9a-zA-Z-]+\.)+[a-zA-
> Z]{2,6}$/i", $allepst)) {
If you use the "i" modifier you don't need to specify both lower and
uppercase: [a-zA-Z]
> $emlstatus = 0; // invalid
> } else {
> $emlstatus = 1; // valid
> }
>
> On a sidenote to this I wonder who changes the internet and why. If a
> line of code works perfectly and serves a purpose and works for years
> and years and years I don't get why anyone would want to change it.
Well, computers running from punch cards were doing their job just fine...
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: Eregi possible problem [message #169357 is a reply to message #169355] |
Wed, 08 September 2010 12:12 |
GarryJones
Messages: 21
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
>> What errors would not be a problem?
Thanks for your answers, they really helped.
Some errors, such as the one above just confuse users. If the code is
still working its nothing they need to worry about. Seeing errors is
okay for testing. If for instance you are on holiday on the day they
right in the "depreciated" code you wont know about it. In the
meantime hundreds of people might be clicking away from your website
and not ordering your products.
Another common claimed "error" that is not an error: I use "post" to
read in values from a form. According to what the user clicks on in
the first form I show a different number of checkboxes in the second
form. But to make things easier I still check for all checkbox values
each time the code runs, its easier to run the entire code so I dont
miss something. But useing post on a 'varname' from a checkbox that
has not been displayed leads to the undefined index error message. Its
not an error, I don't care that I am checking for something that is
not there. But users who see error messages get worried.
>
> Well, computers running from punch cards were doing their job just fine...
>
:) Yep, thats me. I used to load and punch those, back in the good old
days, started out in the 1970's on mainframes with paper tape and
punch cards......... before the masses got involved.....
|
|
|
|
| Re: Eregi possible problem [message #169358 is a reply to message #169357] |
Wed, 08 September 2010 12:55 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 08/09/2010 14:12, GarryJones escribió/wrote:
>>> What errors would not be a problem?
> Some errors, such as the one above just confuse users. If the code is
> still working its nothing they need to worry about.
Exactly. That's why the recommended setting for "display_errors" in
production environments is "Off":
http://es.php.net/manual/en/errorfunc.configuration.php#ini.display-errors
> Another common claimed "error" that is not an error: I use "post" to
> read in values from a form. According to what the user clicks on in
> the first form I show a different number of checkboxes in the second
> form. But to make things easier I still check for all checkbox values
> each time the code runs, its easier to run the entire code so I dont
> miss something. But useing post on a 'varname' from a checkbox that
> has not been displayed leads to the undefined index error message. Its
> not an error, I don't care that I am checking for something that is
> not there. But users who see error messages get worried.
Actually, you don't get an error, you get a _notice_. PHP tells you that
you are trying to read a value from an array that does not exist. That's
a very useful piece of info for you as developer. Notices help you to
identify potential bugs.
You're free to configure your environment so it doesn't trigger any sort
of error, warning or notice[1], but it won't make your coding task
easier. On the contrary, it'll make it harder in the long term. Trust me :)
[1] http://es.php.net/manual/en/function.error-reporting.php
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: Eregi possible problem [message #169360 is a reply to message #169357] |
Wed, 08 September 2010 15:13 |
matt[1]
Messages: 40
Registered: September 2010
Karma: 0
|
Member |
|
|
On Sep 8, 8:12 am, GarryJones <mor...@algonet.se> wrote:
>>> What errors would not be a problem?
>
> Thanks for your answers, they really helped.
>
> Some errors, such as the one above just confuse users. If the code is
> still working its nothing they need to worry about. Seeing errors is
> okay for testing. If for instance you are on holiday on the day they
> right in the "depreciated" code you wont know about it. In the
> meantime hundreds of people might be clicking away from your website
> and not ordering your products.
Another reason to control error_reporting. You can simply turn this
off in production, or get advanced and override PHP error handling
methods to selectively display errors based on user permissions or
automatically email you when an error is encountered.
> Another common claimed "error" that is not an error: I use "post" to
> read in values from a form. According to what the user clicks on in
> the first form I show a different number of checkboxes in the second
> form. But to make things easier I still check for all checkbox values
> each time the code runs, its easier to run the entire code so I dont
> miss something. But useing post on a 'varname' from a checkbox that
> has not been displayed leads to the undefined index error message. Its
> not an error, I don't care that I am checking for something that is
> not there. But users who see error messages get worried.
That's PHP telling you that your code is sloppy. Unchecked checkboxes
don't get passed with POST/GET operations, so you are in effect doing
the same as the following:
$a = array(0, 1);
echo $a[2];
PHP is a loosely-typed language and lets you get away with things like
this. Stricter languages would consider this a fatal error.
Fortunately, PHP provides you with a host of functions to check your
variables before accessing them.
$checkbox1 = isset($_POST['checkbox1']) ? $_POST['checkbox1'] : null;
I recommend functionalizing the above:
function post($varname)
{
return isset($_POST[$varname]) ? $_POST[$varname] : null;
}
$checkbox1 = post("checkbox1");
$checkbox2 = post("checkbox2");
// etc.
>> Well, computers running from punch cards were doing their job just fine....
>
> :) Yep, thats me. I used to load and punch those, back in the good old
> days, started out in the 1970's on mainframes with paper tape and
> punch cards......... before the masses got involved.....
Then you've been around long enough to recognize the value of
explicitly checking data and doing research before performing upgrades
without doing an impact analysis on existing code...
|
|
|
|
| Re: Eregi possible problem [message #169362 is a reply to message #169360] |
Wed, 08 September 2010 15:40 |
GarryJones
Messages: 21
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
> That's PHP telling you that your code is sloppy. Unchecked checkboxes
> don't get passed with POST/GET operations, so you are in effect doing
> the same as the following:
I "solved" this today in a different way....
First I set all values to nej.
<input name="boksin" type="hidden" value="nej">
<input name="boksil" type="hidden" value="nej">
<input name="boktav" type="hidden" value="nej">
<input name="boklic" type="hidden" value="nej">
<input name="bokncg" type="hidden" value="nej">
<input name="bokpap" type="hidden" value="nej">
Then if they are later displayed as checkboxes the value is
redeclared, if not then the "post" reads from the above. Your answer
was obviously more professional and correct but isn't the main thing
to get things working?
> Then you've been around long enough to recognize the value of
> explicitly checking data and doing research before performing upgrades
> without doing an impact analysis on existing code...
:) Perhaps, but sometimes I have taken sledgehammers to crack nuts.
With 7-8 websites runnung mostly at use withing non-profit making
sports organisations I just want things to work. I love php and wish I
was better at it. I can fix most things but its largely due to the
fantistic help I have received over the years from this newsgroup. I
am forever indebted to all that take the time to help me. This last
week I have been recoding a poorly written asp site that I inherited
into php. Php is really fantastic, but even so its many many hours
googling and trying to understand the syntax better. I often know what
I want to do and know its possible, but can't quite grasp it. I've
spent 16-18 hours a day on this for a week. The closest I came php in
my past was Vollie (tpo06 in an in-house CICS system), certain bits of
php logic remind me of that. We used Vollie mainly to access VSE
queues under CICS but there where so many other uses. I wonder, does
php have its roots in Vollie from the early 80's?
|
|
|
|
| Re: Eregi possible problem [message #169364 is a reply to message #169362] |
Wed, 08 September 2010 16:13 |
gordonb.s1b9p
Messages: 1
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
>> That's PHP telling you that your code is sloppy. Unchecked checkboxes
>> don't get passed with POST/GET operations, so you are in effect doing
>> the same as the following:
A lot of my code for dealing with input involves checking whether
the variable is not set, or it wasn't filled in, and either ignoring
that field or returning an error that filling it in is required.
isset() gets used a lot.
> I "solved" this today in a different way....
> First I set all values to nej.
> <input name="boksin" type="hidden" value="nej">
> <input name="boksil" type="hidden" value="nej">
> <input name="boktav" type="hidden" value="nej">
> <input name="boklic" type="hidden" value="nej">
> <input name="bokncg" type="hidden" value="nej">
> <input name="bokpap" type="hidden" value="nej">
>
> Then if they are later displayed as checkboxes the value is
> redeclared, if not then the "post" reads from the above. Your answer
> was obviously more professional and correct but isn't the main thing
> to get things working?
Are you sure that is guaranteed to work on all browsers? Including
IE12, when it comes out? You might get it to work on most of them
but a few strange ones will use the first value only. Check the
HTML spec to see if what you are doing is safe.
> :) Perhaps, but sometimes I have taken sledgehammers to crack nuts.
Just be sure the sledgehammer doesn't miss and crack something
you didn't want to crack along with the nuts.
|
|
|
|
| Re: Eregi possible problem [message #169379 is a reply to message #169362] |
Wed, 08 September 2010 20:25 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Wed, 8 Sep 2010 08:40:05 -0700 (PDT), GarryJones wrote:
>> That's PHP telling you that your code is sloppy. Unchecked checkboxes
>> don't get passed with POST/GET operations, so you are in effect doing
>> the same as the following:
>
> I "solved" this today in a different way....
> First I set all values to nej.
> <input name="boksin" type="hidden" value="nej">
> <input name="boksil" type="hidden" value="nej">
> <input name="boktav" type="hidden" value="nej">
> <input name="boklic" type="hidden" value="nej">
> <input name="bokncg" type="hidden" value="nej">
> <input name="bokpap" type="hidden" value="nej">
>
> Then if they are later displayed as checkboxes the value is
> redeclared, if not then the "post" reads from the above. Your answer
> was obviously more professional and correct but isn't the main thing
> to get things working?
Some right answers are better than others. Something involving checking
if (isset($_POST['foo']) && $_POST['foo']="bar") { ...
might be useful.
--
Science is like sex:
sometimes something useful comes out, but that's not why we're doing it.
-- Richard Feynman
|
|
|
|
| Re: Eregi possible problem [message #169386 is a reply to message #169362] |
Thu, 09 September 2010 06:54 |
alvaro.NOSPAMTHANX
Messages: 277
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
El 08/09/2010 17:40, GarryJones escribió/wrote:
> I "solved" this today in a different way....
> First I set all values to nej.
> <input name="boksin" type="hidden" value="nej">
> <input name="boksil" type="hidden" value="nej">
> <input name="boktav" type="hidden" value="nej">
> <input name="boklic" type="hidden" value="nej">
> <input name="bokncg" type="hidden" value="nej">
> <input name="bokpap" type="hidden" value="nej">
>
> Then if they are later displayed as checkboxes the value is
> redeclared, if not then the "post" reads from the above.
But, why do you need to receive explicitly both checked and unchecked
options in the first place? You are supposed to know what the available
options are and whatever option does not show up as checked, well, it
must be unchecked.
I presume *you* know the options but your PHP code doesn't. In this
cases, it can be useful to define an array at the top of your code:
$options = array(
// Code name => Descriptive label
'boksin' => 'Receive the Boksin newsletter',
'boksil' => 'Receive the Boksil newsletter',
'boktav' => 'Receive the Boktav newsletter',
'boklic' => 'Receive the Boklic newsletter',
'bokncg' => 'Receive the Bokncg newsletter',
'bokpap' => 'Receive the Bokpap newsletter',
);
You can then use this data array to:
1. Print the appropriate checkboxes
2. Validate user input
3. Derive unchecked options
switch() and foreach() are your friends :)
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--
|
|
|
|
| Re: Eregi possible problem [message #169397 is a reply to message #169379] |
Thu, 09 September 2010 12:46 |
matt[1]
Messages: 40
Registered: September 2010
Karma: 0
|
Member |
|
|
On Sep 8, 4:25 pm, "Peter H. Coffin" <hell...@ninehells.com> wrote:
> On Wed, 8 Sep 2010 08:40:05 -0700 (PDT), GarryJones wrote:
>>> That's PHP telling you that your code is sloppy. Unchecked checkboxes
>>> don't get passed with POST/GET operations, so you are in effect doing
>>> the same as the following:
>
>> I "solved" this today in a different way....
>> First I set all values to nej.
>> <input name="boksin" type="hidden" value="nej">
>> <input name="boksil" type="hidden" value="nej">
>> <input name="boktav" type="hidden" value="nej">
>> <input name="boklic" type="hidden" value="nej">
>> <input name="bokncg" type="hidden" value="nej">
>> <input name="bokpap" type="hidden" value="nej">
>
>> Then if they are later displayed as checkboxes the value is
>> redeclared, if not then the "post" reads from the above. Your answer
>> was obviously more professional and correct but isn't the main thing
>> to get things working?
>
> Some right answers are better than others. Something involving checking
>
> if (isset($_POST['foo']) && $_POST['foo']="bar") { ...
<nitpick>
$_POST['foo'] == "bar"
</nitpick>
:)
|
|
|
|
| Re: Eregi possible problem [message #169405 is a reply to message #169397] |
Fri, 10 September 2010 01:55 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 9 Sep 2010 05:46:55 -0700 (PDT), matt wrote:
>> if (isset($_POST['foo']) && $_POST['foo']="bar") { ...
>
> <nitpick>
>
> $_POST['foo'] == "bar"
>
> </nitpick>
>
Yeah, that... Been up to my earlobes in ksh this week....
--
With a Dremel tool and a cut-off wheel, _everything_ takes a flat-blade
screwdriver.
-- Matt Roberds in the Monastery
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]