Re: [PHP] Random 404 screens
On Sat, 9 Feb 2013, Jim Giner wrote: Lately, my web pages are giving me some problems. Once a day or so one or more of my pages/scripts will give me a 404 error page saying my web page has timed out. Problem is that the page was just displayed. I click on a link, the page shows up, I click on a button on it to trigger some activity and voila! An error. I hit refresh and my page is back and things work ok. Since someone mentioned network issues, I will ask this question. Is it actually a 404 page? That is to say, does the string 404 actually appear in the error document? If it does, then this would rule out your home network, as 404 is a response code returned by the webserver. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Some date() oddities
On Tue, 8 Jan 2013, Arno Kuhl wrote: Starting with a unix timestamp for 31 December 2012 13:12:12 (which is 1356952332) I calculate a week number: $ux_date = 1356952332; $weeknumber = date(W, $ux_date); // returns 01 instead of 52 I'm not that familiar with date, I tend to use strftime myself (no idea why there's both). Sounds like date's W is equivalent to strftime's %V which does indeed return 01 for this date as there's at least 4 days of the new year in that particular week. Both %U and %W seem to return what you want, using strftime. I'd guess that date would also have flags for these. Cheers, Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Boolean type forced on string assignment inside if statement
On Thu, 3 Jan 2013, Jim Giner wrote:
The only time I use a single '=' symbol in an if statement is when I forget
to use two of them! Must be my old school, old languages habits but this
style of programming reminds me of the days when we used to pack empty spaces
in assembler code with constants or byte-size vars in order to save memory
back when memory was the most precious resource one had.
The only time I'd consider doing it is if the next thing I was going to do
would be check to see if the assignment itself worked. for example:
if (file_handle = fopen(foo, r)) {
...
}
Geoff.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Wrong time being displayed by PHP!
On Wed, 17 Oct 2012, Richard S. Crawford wrote: I've confirmed that the server is set to PDT. The value of date.timezone in php.ini is America/Los_Angeles, which should be (currently) -8 hours from UTC, but it looks like the PDT offset is only set to -4. Does that even make sense? Actually, PDT is UTC minus 7, not 8. But that's not the point. I know people are pointing at a configuration issue, and it may well be. But the fact that PHP seems to have the correct idea for what UTC is suggests that perhaps either PHP or the (presumably) C routines that it uses may be at least contributing to this. This is not the first time I've seen strangeness with default timezones, and I guess there's a reason why using them generates a warning. Best to deliberately set your timezone. Now if it still does it when you actually set it to America/Los_Angeles then we've got a bigger problem. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP Time
On Mon, 2 Jul 2012, Rob Weissenburger wrote: I know php time() gives the current unix time which you can format out to a normal date and time. Is there a way to format a specific date and time back to unix time? mktime() and strtotime() will do it, depending on the form your time is in. There's probably others. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] slicing and dicing strings
On Wed, 27 Jun 2012, tamouse mailing lists wrote: RTFM with no hint of where to look is a problem. But the dictum of Read here in the manual will surely be the best thing. You will then know where to look for future questions. Personally, I've got better things to do with my time than spend it committing the syntax and semantics of every single PHP function to memory. I nearly always have the php.net front page with its function search open in a browser whenever I'm writing something more than a few lines. The function search seriously rocks. Even if I can't remember which string function I want, I can search for *any* string function and I'll get the list of all of them, along with a quick summary to help me find the one I want. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] regexp novice
Stuart Dallas stu...@3ft9.com wrote: On 18 May 2012, at 14:50, Jim Giner wrote: Daft is a little harsh. :) 00:40 is just not a time value that is generally accepted. It may appear harsh, but as far as I'm concerned it is daft to make assumptions like that. You've essentially disallowed 12:nn am, but allowed 1:nn am, 2:nn am, 3:nn am, etc, because you're not validating the data in a non-ambiguous way. I have no idea what you're developing, but you're making a big assumption about the data that you're getting, which may appear reasonable to you, but to me it's daft. Nothing personal, just my opinion, which is all I have to offer. Unless I've missed something, he hasn't disallowed 12:nn am, only 00:nn. If you're going to only accept 12-hour input, this is the right thing to do. 00:nn is not a valid 12-hour representation - only times from 1:nn to 12:nn are acceptable. If you were to accept 00:nn, you'd have to also accept 13:nn-23:nn as well, for consistancy. Granted, not specifying am or pm adds a layer of ambiguity, but maybe that's not relevant for this query. For example, maybe there's also a select field that has am and pm as options. As it appears that accepting only 12-hour input is part of the brief, Jim is IMHO doing the right thing. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] strftime silliness
On Wed, 10 Apr 2012, Tim Streater wrote: I want to format a date/time using a 12 hour representation of the time part. I can do this with, say, %d %b %Y %l:%M %p, where the first time format specifier is the lower-case L. But, this gives me a leading space in the case that the hour is less than 12. I don't want this space. Anyone know of an simple way to avoid it? There appears to be no specifier to do this. Of course, I can call strftime twice, once for the date portion and once for the time portion, trimming the latter, but that seems clumsy. You can use %-l to achieve this. You could also use %-I as this will also drop leading zeros if present. I forget where I read about this. I'm almost certain that it was *not* in any PHP documentation. HTH, Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] basic captcha
On Fri, 17 Feb 2012, Ashley Sheridan wrote: I would avoid making a user type in something they see in a picture, as you've just succeeded in pissing off a bunch of blind people. Thank you! Glad someone pointed this out so I didn't have to. And if you use a system like Recaptcha which has an audio option, you've still locked out deafblind users. Also, avoid relying on javascript. It can be turned off, disabled, blocked and sometimes isn't available at all, such as with some speech/Braille browsers. Or lynx. Yes I'm a blind person, but even a person who isn't may want to use it quickly from a shell to get something done. One popular route is to ask a question that only a human could answer. I use this method on the contact page of my site. I just ask a question such as Multiply the number of heads a person has by the number of legs on 2 dogs. It's easy for a human, but requires context, something a bot can't do effectively. Since the person was looking for a ready-made solution, I'd like to recommend TextCaptcha.com. It claims to have 180,243,205 easy questions, and even has an article on ways to avoid needing a CAPTCHA in the first place. I once (and only once) struck a test like this on a New Zealand government website. I nearly died of shock. And I was able to use it with lynx with no problems at all. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Update mailing list docs - How to unsubscribe?
On Mon, 23 Jan 2012, Matty Sarro wrote: I have been trying to unsubscribe from this list. I've gone through the directions at http://www.ezmlm.org/ezman/ezman1.html as suggested by http://us.php.net/mailing-lists.php. They don't seem to apply for these lists as written (the method listed for unsubscribing involves sending an email to mailinglist-unsubscr...@example.org, which in this case would be mailinglist-unsubscr...@lists.php.net which sends back a lovely invalid email address response). list-unsubscribe: mailto:php-general-unsubscr...@lists.php.net Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sniping on the List
Hi, Apologies if this has moved on, I've not read all my mail from the last day and a half. On Mon, 21 Nov 2011, Tedd Sperling wrote: Let's consider this -- you are in a different time zone than me, right? You said UTC and mine is America New York. As such you claim is that your strtotime() function will return a different result for you as compared to me because of the time zone differences, right? Only some of the time. It depends on the input. If so, then tell me why I can take both sites (your and mine) and click the Submit buttons at the same time and the forms will report back the exact same number of elapsed seconds. Try it (you got to be quick): The timezone affects two things, the input and the output. If your input is absolute and not timezone dependent, both scripts will output the same seconds calculation. But if it is affected by timezone, then the seconds count will be different. Here's an example from a previous message. The string 1 January 1970 00:00:00 is timezone dependent, as it is midnight according to the particular timezone. Output from your copy: String Given: 1 January 1970 00:00:00 Seconds Computed from String: 18000 Output from my copy: String Given: 1 January 1970 00:00:00 Seconds Computed from String: 0 This is because the number of seconds (aka the Unix Timestamp) is *not* affected by timezones - it's the number of seconds since 1 January 1970 00:00:00 UTC. This is why it's 0 on my server and 18000 on yours, as midnight was 5 hours later in New York. But if you enter a string like now, you'll get the current time with the same timestamp from both scripts. String Given: now Seconds Computed from String: 1322033486 Here's where the output side comes in. The various date display functions will output according to the selected timezone, or the system default if none is selected. So this will display differently on your server and on mine. Lets use the value of 'now' above to demonstrate: $ php -r 'date_default_timezone_set (America/New_York); echo date (r, 1322033486);' Wed, 23 Nov 2011 02:31:26 -0500 php -r 'date_default_timezone_set (UTC); echo date (r, 1322033486);' Wed, 23 Nov 2011 07:31:26 + Same input, different output. Now if you combine these two factors, it explains all the results you see. If you use strings like today or 1 January 1970 00:00:00, the scripts will print the same date (and time if you asked it to), but they aren't actually the same, as one is 5 hours behind the other. But if you use an absolute time like now or 1 January 1970 00:00:00 + (which specifies the timezone), the scripts will print different times based on the timezone. Now, to the point under debate. Since values like 0 and null are absolute rather than relative, the output will vary depending on which timezone is in use. $ php -r 'date_default_timezone_set (UTC); echo date (r, null);' Thu, 01 Jan 1970 00:00:00 + $ php -r 'date_default_timezone_set (America/New_York); echo date (r, null);' Wed, 31 Dec 1969 19:00:00 -0500 Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sniping on the List
On Sat, 19 Nov 2011, Tedd Sperling wrote: My observations are demonstrated here: http://www.webbytedd.com//strtotime/index.php this code would IMHO be more useful if it also displayed time, not just date. It's also not clear what timezone you're using, as it's not set as far as I can see. Please note that regardless of time zone, the strtotime() function works (or at least it does for me) such that: If you enter '-1', the function will report back Todays Date with current seconds. Note there is no difference between entering 'Today' or '-1'. This is not what your code shows. String Given: -1 Seconds Computed from String: 1321805103 Date from Seconds Computed: 20 November, 2011 : Sunday ___ Current Time (seconds): 1321819503 Current Date: 20 November, 2011 : Sunday This is a difference of 14400 seconds or 4 hours. String Given: today Seconds Computed from String: 1321765200 Date from Seconds Computed: 20 November, 2011 : Sunday ___ Current Time (seconds): 1321819877 Current Date: 20 November, 2011 : Sunday This is a much larger difference. 'today' is meant to return the same as 'today 00:00:00'. I know it used not to, it was a PHP bug awhile back... which begs the question, which PHP version are you using? If you enter '0', the function will report back December, 31, 1969. You'll also notice that the value of seconds computed from string is blank (i.e. not 0). This is because strtotime() doesn't know what to do with a value of '0'. Whether it should or not is probably a phillosophical debate. If you enter nothing (i.e., null), then it reports back December, 31, 1969. It does, but we dont' know exactly when this is because your script doesn't show time. It could be actually returning a 0 timestamp. We can force your script to show us what 0 time is according to its timezone by entering an absolute date including UTC offset. String Given: 1 January 1970 + Seconds Computed from String: 0 Date from Seconds Computed: 31 December, 1969 : Wednesday ___ So your script shows 31/12/1969 for the epoch, so we dont' know if the null value is the epoch or before. To further prove my point, witness the number of seconds calculated from 1 January 1970 in your script's timezone: String Given: 1 January 1970 Seconds Computed from String: 18000 Date from Seconds Computed: 1 January, 1970 : Thursday ___ This means your script is using a timezone of UTC -0500 (US Eastern). So any time within the first 5 hours of the epoch will show as being in 1969. To avoid this, explicitly set your script to use UTC. Or use US Eastern but be up front about the fact that your'e doing this. It's clear (and by definition) that unix zero time (i.e., 00:00:00) happened in 1970. It's also clear that time before unix zero happened before 1970 (i.e., 'December 31, 1969'). As such, null (and not the string 'null' as stated my someone else, duh) should come back as undefined OR December, 31, 1969. It doesn't for me, using either PHP 5.2.6 or 5.3.3. php -r 'echo date (r, strtotime ());' Thu, 01 Jan 1970 00:00:00 + Furthermore, the string '-1' should default to '-1 second' instead of being the same as if I entered 'Today'. Apart from the fact that for me at least, strtotime (today) returns today at midnight, whereas strtotime (-1) seems to return something else (time() + 3600 on boxes set to UTC, time() + 10800 on my box set to local time in Israel), strtotime is meant to turn textual representations of time into a unix timestamp. Surely the meaning of -1 is at the very least ambiguous, and the fact that it returns anything is surprising. Now, where are my observations wrong? The code is shown in the demo. To summarise, your observations are wrong because they do not take timezone into account and do not show the time, only the date. And some of your observations as given above do not match what your script outputs. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Parsing the From field
On Sat, 19 Nov 2011, Ron Piggott wrote: Also the formatting of the from field changes in various e-mail programs: From: Ron Piggott ron.pigg...@actsministries.org From: Ron Piggott ron.pigg...@actsministries.org From: ron.pigg...@actsministries.org From: ron.pigg...@actsministries.org I've also seen: Piggott, Ron ron.pigg...@actsministries.org And that's before you get to people who only use their first name and people who use some kind of alias. I think you did well to abandon this. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sniping on the List
On Sun, 20 Nov 2011, Tedd Sperling wrote: I appreciate your time and comments. However, you missed the point I was trying to make, which does not have anything to do with timezones. If you copy my code and place it on any server in the world, you'll observe the same results as I did. NO I won't, and timezones do matter. I've copied your code to http://quitelikely.com/~geoff/strtotime/ Sorry if any of the visuals are mangled, I had to massage the script a little to pullin the header and footer, and I downloaded your logo, but I didn't go and dig out your CSS or javascript. This server is set to UTC and uses PHP 5.2.6. Lets skip right to your point. From your script on your server: String Given: null Seconds Computed from String: null Date from Seconds Computed: 31 December, 1969 : Wednesday ___ From the script on my server: String Given: null Seconds Computed from String: null Date from Seconds Computed: 1 January, 1970 : Thursday __ You touched on my point with: You'll also notice that the value of seconds computed from string is blank (i.e. not 0). This is because strtotime() doesn't know what to do with a value of '0'. Whether it should or not is probably a phillosophical debate. But you did not contribute to which side of the debate would you side. I didn't, because the debate was on whether or not NULL == Wednesday, not whether or not strtotime(0) should return 0. I agree there's a good case for it doing so, you could file a bug if you feel strongly about it. My prior opinion was that 0 should return 'Jan 1, 1970'. However, Stuart pointed out a flaw in my code. You see, I was assuming that using the return from strtotime(0) in the getdate() function would return the correct date, but this was a cascade error. As I think I mentioned before, using strtotime at all is the problem, as we are talking about null as a concept, not null the alphabetical string. Since null is nominally a numerical value, we can pass it directly as a timestamp. php -r 'echo date(r, null);' Thu, 01 Jan 1970 00:00:00 + Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Sniping on the List
On Thu, 17 Nov 2011, Tedd Sperling wrote: On Nov 17, 2011, at 11:58 AM, Stuart Dallas wrote: The epoch specifies the exact time that 0 represents. It makes no claims as far as that being the start of anything... defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of Thursday, January 1, 1970 (Unix times are defined, but negative, before that date) [http://en.wikipedia.org/wiki/Unix_time] Good reference to support your point, but strtotime() doesn't qork that way. Yes it does. $ php -r 'echo strtotime (31 Dec 1969 23:59 +);' -60 For example, if you push '-1' though strtotime(-1), you'll get Wednesday only one day a week -- whereas 'null' works every time. Technically I see that as a bug. I believe strtotime(null) should return null, but due to the way type inference works, null is interpreted as 0. The point here being that you're not getting the time at null, you're getting the time at 0. Nope, zero time is absolutely January 1, 1970 00:00:00 -- which was a Thursday. If you pass zero through strtotime(), it reports December 1969 and I claim that to be a bug. Not here it doesn't. $ php -r 'echo date (r, strtotime (zero));' Thu, 01 Jan 1970 00:00:00 + But it might for you (see below). In addition, passing -1 through strtotime() simply returns today, Here it returns a time an hour later than now. $ date -R; php -r 'echo date (r, strtotime (-1));' Thu, 17 Nov 2011 20:41:06 + Thu, 17 Nov 2011 21:41:07 + whereas 'null' returns a date prior to the start of everything and that makes more logical sense to me. but here we hit the crux of the problem. 'strtotime(null)' isn't returning a null timestamp, it's simply returning the value for an inability to convert the string null to a timestamp. Of course, now that I try to reproduce the null == Wednesday result, I find that I can't. Everything comes up as Thu, 01 Jan 1970 00:00:00 + which probably invalidates much of what I've written above. Maybe I'm not running a new enough PHP (latest I have access to is 5.3.3). But if this is the case, this suggests this behaviour changed relatively recently. Anyway, as I was going to say, the correct way to find out what null is is to do something like: echo date (r, null); But this thread has gone through so many twists now that I can't remember if this is where we began or not. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Think I found a PHP bug
On Tue, 15 Nov 2011, Jim Lucas wrote: Also, I recalled something from the early 5.1.0 version that was related to the introduction of the date_timezone_set() function. So, from there I searched Google for php changelog and found the changelog for php v5. Then I searched that document for 'date_' and found that under the 5.1.0 they added the above function. How it is stated, it makes me think that PHP now requires you to call this function prior to any use of other date functions. I cannot find anything in the php manual confirming my last statement. YMMV If you don't use date_default_timezone_set(), it's supposed to use the server timezone. I recalled reading that a notice/warning would be logged if you did this, but like you, I can't find any reference to this now. I've searched my apache error logs and can't find anything there either, which seems to suggest that this in fact is not the case. In case it wasn't obvious in my original post, this worked just fine during UK summer time. It's only since the clocks changed two weeks ago that PHP has been thinking that the server timezone is UTC rather than Europe/London. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Think I found a PHP bug
On Wed, 15 Nov 2011, Tim Streater wrote: I find I need to do this: date_default_timezone_set (@date_default_timezone_get ()); in all my scripts since 5.x.x to avoid rude messages. Apart from the fact that I've not seen the rude messages of which you speak, even though I expected to, this won't help in this case. date_default_timezone_get() is returning the wrong timezone. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Think I found a PHP bug
Hi, A couple of weeks ago, I discovered what I'm pretty sure is a PHP bug. In addition, I looked in the PHP changelog and I haven't seen any mention of a fix for it. I'm writing here because I was wondering if anyone else can confirm it and what to do about it. The bug is that if a server's timezone is set to Europe/London and you don't set an explicit timezone in your script, if it's winter time in the UK, PHP thinks the timezone is UTC instead of Europe/London. Example: First, lets confirm that the system time is in fact set to Europe/London. $ cmp --verbose /etc/localtime /usr/share/zoneinfo/Europe/London $ echo $? 0 Now lets see what PHP thinks it is. $ php -r 'echo date_default_timezone_get();' UTC What about if we set it in the environment? $ export TZ=Europe/London $ php -r 'echo date_default_timezone_get();' Europe/London OK, so we appear to have an issue. But is this just semantics? Well no. consider the following (with TZ once again unset): $ php -r 'echo date (r, strtotime (1 July 2011 12:00 pm' Fri, 01 Jul 2011 12:00:00 + But of course, Europe/London isn't on + in July. $ export TZ=Europe/London $ php -r 'echo date (r, strtotime (1 July 2011 12:00 pm));' Fri, 01 Jul 2011 12:00:00 +0100 The problem comes in when we view times created in one and printed in the other: $ unset TZ $ php -r 'echo strtotime (1 July 2011 12:00 pm);' 1309521600 $ export TZ=Europe/London $ php -r 'echo date (r, 1309521600);' Fri, 01 Jul 2011 13:00:00 +0100 And the opposite: $ export TZ=Europe/London $ php -r 'echo strtotime (1 July 2011 12:00 pm);' 1309518000 $ unset TZ $ php -r 'echo date (r, 1309518000);' Fri, 01 Jul 2011 11:00:00 + This last one is what led me to discover this bug. We use automation software to run our Internet radio station. The playout system is written in C and the web front-end is written in PHP, with the data they work on the only point of commonality between them. The station was set up during the European summer. When the clocks changed, the playout system coped but the PHP front-end was showing everything an hour out. Now of course, I personally can force the front-end to use Europe/London and it will work for me. And I guess ultimately it would make sense to program the system to allow the user to specify a timezone rather than relying on the server default. But right now it doesn't, and any solution would need to take the playout system into account. At any rate, none of this is the point. If you're using the system default timezone, you expect it to (a) be correct and (b) be consistant. Note that this bug may affect other timezones which are on UTC durin the winter or summer, but I've not tested any other timezones as this would mean changing the system timezone and I'm not real keen on doing that on any of my systems. This bug was found on a Debian Squeeze system running the following version of PHP: PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 08:24:40) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies I realise this is 5.3.3 and that 5.3.8 is now out. It's possible that this has been fixed but I could not find any traces of such a fix in the changelogs. I'd be interested to know if anyone else can confirm this bug and, if confirmed, what I should do about it. Thanks, Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] question about best practice for coding sql statements
On Sat, 12 Nov 2011, tamouse mailing lists wrote: I'm curious how others feel about this. When I'm creating an SQL string, either for a non-prepared or prepared execution, I build it in a variable and then pass the variable to the query or prepare function. This lets me easily add something to view the SQL statement, and also if there's an error, emit the SQL statement. I do this. This means that when a user encounters an error, they can actually give you a meaningful error report which should reduce the time it takes to fix it by a considerable amount. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Execute permission question
On Thu, 27 Oct 2011, Tedd Sperling wrote: You answered a question I wasn't prepared to ask, which was How can php scripts be executed when their execute permissions aren't set? Because as far as the system is concerned, the thing which is being executed is either PHP itself or something in which PHP is being run (e.g. Apache). The fact that PHP then loads a script and executes it is not really the point. When used in websites, it's the webserver itself which loads the PHP interpreter which in turn loads the script. So the webserver needs to be executable. The Apache module, for example, does not because Apache loads it into Apache which is already running. If you're not actually running programs on the host itself via a shell, then you probably won't need execute permissions most of the time. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Variable question
On Sat, 1 Oct 2011, Mike Mackintosh wrote:
Best bet would to toss this into either an object or array for
simplification, otherwise that type of syntax would need the use of
eval.
example: eval('echo $trivia_answer_'.$correct_answer.';');
You could do:
$var = trivia_answer_.$correct_answer;
echo $$var;
But I agree that an array would be simpler.
best bet would be to..
$trivia_answer = array();
$trivia_answer[1] = 1000;
$trivia_answer[2] = 1250;
$trivia_answer[3] = 2500;
$trivia_answer[4] = 5000;
echo $trivia_answer[$correct_answer];
You can define this a bit more simply:
$trivia_answer = array (
1 = 1000,
2 = 1250,
3 = 2500,
4 = 5000
);
You can do it even more simply by just giving the values, but indexes wil
start at 0:
?php
$trivia_answer = array (1000, 1250, 2500, 5000);
print_r ($trivia_answer);
?
Array
(
[0] = 1000
[1] = 1250
[2] = 2500
[3] = 5000
)
While manually defining an array like this is only slightly less tedius
than using 4 numbered variables, it's a lot easier to do if you're getting
data from somewhere else (e.g. a database of trivia questions). To use
the original way proposed, you'd have to keep constructing variable names,
which arrays avoid quite nicely.
In my opinion, the only real usefulness for a syntax like $$var (above) is
if you want to do something with a bunch of variables in one go. For
example:
foreach (array (title, artist, album, label) as $field)
echo ucwords($field) . ': ' . $$field . 'BR';
The above comes from a function which manages only a single record, so no
real need to use an array. I could of course, e.g. record['title'] etc,
but I don't see much could be gained unless I needed to be able to manage
an entire record as a single unit.
Geoff.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] scroll down list -visible, but not possible to choose
On Wed, 31 Aug 2011, rob...@myself.com wrote: I have the below function with array for satus of issues where I need to have 'Resolved/Closed' visible but not available for choice This as closing is a separate function to ensure correct resolution code is selected Already tried removing 'Resolved', and got everything working only to notice when testing that when viewing issues the Resolved ones showed up as 'Support Working' even though closed in the system There are two possible points of failure here, your code and browser behaviour. Whenever I'm faced with this sort of problem, I look at the source code in my browser to see the HTML my code generates. Then I can determine if my code is outputting what I'd intended. If it is, then my code is right but the implementation is wrong, as the correct HTML produces the incorrect result. If you'd done this, you'd have seen what the problem is. The problem is that, having taken away Resolved as a possible option, all items marked Resolved are unable to be listed as selected. Consequently no items are selected and the browser defaults to the first item in the list which is Support Working. I've never had to do this, but http://www.w3schools.com/TAGS/tag_option.asp says you can use the disabled attribute to disable an option. So your resulting HTML could look like this: option value=Resolved disabledResolved/option or option value=Resolved disabled selectedResolved/option as appropriate. A simple if statement could be used to set the disabled attribute for the Resolved selection only. IMHO this is vastly preferable to any trickery you may use with javascript to prevent the user from selecting Resolved. I've never struck a select field like this and am now interested in coding one up just to see how it works in practice. HTH, Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Code should be selv-maintaining!
On Mon, 29 Aug 2011, Rico Secada wrote: You go into your homemade library of code to re-use some piece that you already are using 12 other places in production. Now, last time you worked on the code you thought it was almost perfect. While working on the code this time you find an undiscovered bug or some part of the code that looks like you where on drugs when you made it. This is why it's good to write this kind of thing as functions. Then if you find some great problem with it later, you can drop in the replacement functions and the code that calls it (hopefully) won't need modification. Of course, it's easier to be cleverer after the event. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Dreaded Premature end of script headers
On Fri, 26 Aug 2011, tamouse mailing lists wrote: The log says what I said: Premature end of script headers filename I put this into Google and got this: http://htmlfixit.com/cgi-tutes/tutorial_Common_Web_dev_error_messages_and_what_they_mean.php#premature As I understand it, the webserver is complaining that it did not get all the headers it expected from the script before it terminated. Given that you say this is for a cron job, the script may well be doing exactly what you want it to do, but it's not outputting anything which is why you get an error. Presumably, you are calling this cron job with some process which runs the PHP script through a URL on your webserver. To fix this, I'd suggest one of the following. Either: 1. Modify the script so that it does actually output something, thereby making the error go away. or 2. Run the script directly with PHP instead of via your webserver. E.g.: php -f yourscriptname IMHO, 2 would be the better way to go if you can do this. HTH, Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Using stand-alone PHP scripts with Drupal
Hi, I know this is probably more a Drupal question, but I'm guessing some here have probably had to deal with this. I've written some PHP code which works just fine on its own. Now someone wants to include it in their Drupal site, with the regular headers and footers for their site surrounding the output from my scripts. Is there an easy way to include the PHP in a page on their site? Not sure which version of Drupal they're running, trying to find out. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Login with Remember me Feature
On Sun, 14 Aug 2011, Alekto Antarctica wrote:
I have tried to implement a cookie to remember the login for 48 hours, but
it still logs the user out after the default 24min for a session like this:
* //We compare the submited password and the real one, and we
check if the user exists*
*if($dn['password']==$password and mysql_num_rows($req)0)*
You don't show us anything before this, so we have to assume it's all
good up to here.
*{*
**
*//If the password is ok, we set the $loginok var to
true*
*$loginok = true;*
*//If the password is good, we dont show the form*
*$form = false;*
**
*}*
Maybe I'm just like this, but I always comment my closing braces. I've
been in situations where I'm missing one or I need to review code I wrote
months ago and understand its logic, and I find this practice useful.
Yes, in this case the opening is a few lines up, but you could have a code
block that runs for hundreds of lines, and it's good to remember what
started it.
* if ($loginok = true)*
* {*
First, off, as someone else mentioned, this should presumably be:
if ($loginok == true)
This one mistake will mean that $loginok will always be true.
Second, since if statements are always looking for true conditions, you
can simply type:
if ($loginok)
Finally, since $loginok is assigned the true value in the previous block,
then, unless it is also possibly assigned elsewhere, you can just put the
below code in the same code block as the above code, rather than closing
and starting a new one with this if statement.
* if ($remember==on)
*
*setcookie(username,
$username, time()+7200*24);*
This is not very intuitive. You're saying to add 2 hours times 24, which
is a bit strange if you're trying to understand the code. I'dve found
3600*48 much more intuitive. A comment mightn't go astray here either.
* elseif ($remember==)
Are these the only two values that $remember can have? May as well just
use else here without testing for another condition (either the user is
remembering or they're not).
*
* //We save the user name in the session username and the
user Id in the session userid*
I think we might have an left brace missing here, unless it's gotten lost
in translation.
Also, I notice you're storing username and userid here, but above only
stored username in the cookie.
* $_SESSION('username')=$username; *
This line should read:
$_SESSION['username']=$username;
I see the next line has it right. I'm surprised that your code didn't
generate an error for this one, and since it didn't, this may indicate
that this code is never reached (possibly due to the elseif test above).
* $_SESSION['userid'] =
$dn['id'];*
* $_SESSION['usr_level'] =
$dn['usr_level'];*
I see a mixing of styles here. While it's all perfectly good syntax, you
may want to find a style you like and stick to it. I personally find
$foo = $bar;
much more readable than
$foo=$bar;
or
$foo =
$bar;
but each to their own.
Another problem I am now facing, is to check whether to user is logged in,
and if it is the user should be redirected from the index-page(with the
login-form) to its user area based on the user level(newbie, advanced or
admin).
For now I have written a function, in the config.php.
*function loggedin()*
*{*
* if (isset($_SESSIONS['username']) || isset($_COOKIE['username']))*
* {*
* $loggedin = true;*
* return $loggedin;*
* }*
*}*
As someone else pointed out, you could simply return true instead of
assigning to a variable. They also pointed out that you don't return
false if the person is not logged in. You could rewrite the above
function like so:
function loggedin()
{
if (isset($_SESSIONS['username']) || isset($_COOKIE['username']))
return true;
else
return false;
}
However, this doesn't actually check the values of these items, it simply
checks to see if they have been set.
I have both tried to include the config.php into the index-page(login-form)
and into the connexions.php script (where cookie is implemented). Along with
this code:
*?php*
*
*
*if (loggedin==true)*
You need to call a function with parentheses, even if it takes no
arguments, like so:
if (loggedin() == true)
or simply
if (loggedin())
*{*
* if($usr_level == admin)*
*{*
* ?*
*div class=messageYou have successfuly been logged in. You can now
access the
Re: [PHP] using wget in shell for download(snort)
On Sun, 10 Jul 2011, Tamara Temple wrote: On Jul 10, 2011, at 5:38 AM, Negin Nickparsa wrote: I want to make a batch file and then exec it in php I have a problem in batch file wget have been installed in Yast I want to download a RuleFile from snort.org I used this on shell: $ wget http://www.snort.org/reg-rules/snortrules-snapshot-2900.tar.gz/c0e9480af637e53c7aae823a40a131edc1343db5\-O snortrules-snapshot-2900.tar.gz that string is an oinkcode from the site this commandline has error and I don't know why What is the error? This: b5\-O at the end of URL looks suspicious. That's the problem. The \ should be a space. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] What type of PHP5 shall I install to learn PHP5 together with Apache, Please specify the Apache type too Since There are Two Apache types also
On Fri, 8 Jul 2011, Varuna Seneviratna wrote: I am Using Ubuntu 11.04 Desktop as my OS.Below are the two types of PHP5 available for installation php5 - server-side, HTML-embedded scripting language (metapackage) php5-cgi - server-side, HTML-embedded scripting language (CGI binary) I got the above by running the command apt-cache search PHP5 1 What is the difference between the two. One is part of the other. I'm running Debian (which Ubuntu is based on), and by looking at the php5 package you can see that it depends on php5-cgi and a few other packages. 2 What shall I install to learn PHP with apache(Please specify the apache version too since there are two types available for Ubuntu) Can't really help you much there without more information, though again assuming the Debian packages are the same or similar, installing the apache2 package should pull in everything you need. HTH, Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Time zones are spinning my brain
On Wed, 29 Jun 2011, Brian Dunning wrote:
$start = gmdate('Y-m-d\TH:i:s.00\Z', strtotime(yesterday 00:00:00));
$end = gmdate('Y-m-d\TH:i:s.00\Z', strtotime(yesterday 23:59:59));
I think this is right, since it's 7 hours off California time, but I
just need someone to double check my spinning head. Will this give me
the PayPal transactions that arrived during California's yesterday, or
do I need to change something?
Assuming your timezone is set to California time (
date_default_timezone_set ('America/Los_Angeles') ), then yes.
Geoff.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Time zones are spinning my brain
On Wed, 29 Jun 2011, Richard Quadling wrote: And UTC is not the same as GMT. Ish. GMT is only valid for 6 months of the year. Then, due to DST, it becomes BST. UTC is just UTC. This is incorrect. For all practical purposes, GMT and UTC are the same. The fact that the time in Greenwich is not GMT/UTC for half the year is not relevant. http://www.diffen.com/difference/GMT_vs_UTC All the GM* functions (gmdate, gmstrftime, etc) are intended for dealing with Universal Co-ordinated Time. As a side note, there is (or at least was) no gmstrtotime function. I get around this by putting + at the end of the string. HTH, Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Time zones are spinning my brain
On Wed, 29 Jun 2011, Brian Dunning wrote:
Thanks everyone. It seems to be working correctly. You gave me some
extra peace of mind. I did set the
date_default_timezone_set('America/Los_Angeles') but it looks like that
was in the defaults anyway. :-)
It probably is if this is where your site is hosted. But all you need to
do is change hosting providers to one somewhere else, or for someone who's
not careful to mess something up on the system, and the script will break
all because you assumed it would always be right. So better to set it and
know it's right.
Geoff.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP] phpsadness - P.C. shmee seee.
On Sun, 5 Jun 2011, Tim Streater wrote: Anyone whose site says that sort of crap needs a good smack. Don't get me started on Facebook. If they don't like your browser, they redirect you to theirWe don't support your browser page. They don't even let you try with your unsupported browser, which might well work if you're clicking on a link to a particular status update. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: phpsadness - P.C. shmee seee.
On Sun, 5 Jun 2011, Richard Riley wrote: Why do you feel FB should support some antiquated browser that doesnt support any of the newer technoogies which enable security and more advanced client side rendering? I don't. I just don't want them to lock out my browser just because they don't support it. Many pages which don't work optimally under Lynx can still be read, which is all I'm wanting to do anyway. I can use the mobile site fine, but if someone posts a link to a status message or some other item on Facebook, it's to the main site and not the mobile one. I don't even bother clicking because I know Facebook won't even try to send me the page I want. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: phpsadness - P.C. shmee seee.
On Sun, 5 Jun 2011, Richard Riley wrote: I don't. I just don't want them to lock out my browser just because they don't support it. Many pages which don't work optimally under Lynx can still be read, which is all I'm wanting to do anyway. They need to or there can be unintentional side affects that will reflect badly on them and possibly you. Rubbish. All they need to do is what everyone else does and say This site may not work well on your browser, we recommend using Internet Explorer or firefox (or whatever they support). Then if I choose to use it, it's on my own head, which is fine by me. If you really want a half arsed user experience then set your browser string ;) Would that not work for you? It probably would. But this tangent began with the principle of Use IE or Firefox and how we hated sites that said that. It's the principle of the thing. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: phpsadness - P.C. shmee seee.
On Sun, 5 Jun 2011, Richard Riley wrote: If they allowed incompatible browsers that caused havoc then before you know it the great unwashed would be demanding more and better support or complaining about lack of functionality. Doing what they do they make it very clear from day one. This would be a fair enough attitude if they only applied it to their member sections, but they don't. They set themselves up as publishers of information, page hosts of sorts, then don't let anyone in who wants to *read* them. Dont like it? The APIs are open. Write your own interfaces to their authentication and graph API and target the parts that wont result in your accuont being banned for chucking access tokens around and breaking their security model. Totally not the point. Quite aside from the fact that Mobile Facebook works extremely well with Lynx, and so did Facebook Lite until they sadly took it away, it's not what I'm having trouble with. An example of what I'm talking about is the following tweet: ABCGrandStand: #nrl : NSW ORIGIN team game two.. Dugan, Hayne, Hopoate, Gasnier, Uate, Soward, Pearce, Gallen, Ennis, Mannah,... http://fb.me/uPHxKiFC http://twitter.com/abcgrandstand/status/77271757383413760 Now, correct me if I'm wrong, but there's no need to log in or anything remotely 21st-century required to read the rest of this post. All you need to do is click the URL and the appropriate Facebook status will come up, which you're free to read without any further clicking on your part. But only if you're using a browser that's been blessed by the Facebook gods. If you're not, you're sent to http://www.facebook.com/common/browser.php with no other course of action. I hope you can appreciate my point. The choice to use Facebook was a decision made by the person sending the tweet, not me. It's not going to kill them to either let me see the page with appropriate functionality warnings, or to flick-pass me to the equivalent mobile Facebook page. I can't view it on the mobile site myself without first resolving where the shortened URL points to, changing the www to m and hoping it works, or signing in and trying to find it myself. Even Twitter, who don't let me login to the regular site without javascript, are quite happy to let me view tweets unauthenticated on their site with Lynx. If I want to login, I need to use their mobile site. Not a problem - if I try to use their main site and it doesn't work, it doesn't work. At least they let me try. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: [PHP-WEBMASTER] encoding issue
On Thu, 2 Jun 2011, Richard Quadling wrote: There are other possibilities, but they could have legal repercussions - essentially reversing the encoding may be considered as an attempt to bypass a copyright protection system which could contravene the http://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act. Note that the DMCA is United States legislation and may not be relevant. Copyright law is pretty universal though and you could get into trouble with this anyway. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] smart auto download file
On Wed, 1 Jun 2011, Ali Asghar Toraby Parizy wrote: I need to tell something to the user before starting download. something like Your download will begin in a moment... . So header couldn't help me. If I try to echo anything header doesn't work! Couldn't you just do an HTML redirect? !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN html head titleFile Download/title meta http-equiv=REFRESH content=10;url=http://www.example.net/download;/HEAD BODY PYour download will start in a few seconds./P PIf your download fails to start automatically, A HREF=http://www.example.net/download;click here/A./P /BODY /HTML Of course, this is the resulting HTML you want to produce (or something like it). You'll obviously get PHP to echo the appropriate URL. This approach has the benefit that it'll work on anything. My prefered browser does not support javascript, so you look me out of your site if you use it. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] iPhone sadness
On Mon, 30 May 2011, Andre Polykanine wrote: most of you post your messages *after* the quotes. It's really not comfortable: I use screenreading software here and I need to scroll with my down arrow key before I see the actual message. I use screen reading software as well and prefer bottom-posting. Of course, those who quote an entire message (or messages) before their post should be shot, but thankfully this is a minority of people. Since we're all pitching in with our arguments for top/bottom posting, I'll briefly state mine: 1. Bottom (or at least not top) posting allows you to interleave your responses amongst the quoted text. This makes it a lot easier to know what is being responded to, and actually also makes it a lot more likely that all points that need answers will actually be answered. 2. Particularly if #1 is followed, quoted material more often than not tends to be trimmed to what is relevant. Top-posting not only usually results in the entire message being quoted, but often the entire thread right back to the beginning (or at least back to whoever bottom-posted last on it). This can cause very large messages fairly quickly, especially if combined with HTML mail (don't get me started on *that* one). Unfortunately, Outlook Express (and perhaps others) seem to actively discourage doing the right thing. One reason is that at least in Outlook Express, it's impossible to set different quoting settings for replies and forwards. So you either end up with forwards with all quoted lines (very annoying to listen to I assure you), or replies where it's impossible to tell what's quoting and what's new text (unless you're sending as HTML mail of course). And of course, the single reason (IMHO) why it's likely more people top-post - it's less work. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] iPhone sadness
On Sun, 29 May 2011, Richard Quadling wrote: On 29 May 2011 01:36, TR Shaw ts...@oitc.com wrote: (sorry for the top posting) Sent from my iPad Are you telling me that you can't scroll down the page on an iPad? I refer back to my comment that the Sent from my iPad/iPhone is inherently an apology. Ironicly, it's on by default. It can be turned off, however. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Detecting HTTPS connections under Apache
On Fri, 27 May 2011, Curtis Maurand wrote: $_SERVER['HTTPS'] I don't see this at all. I'm definitely connecting securely. Here are the status lines from Lynx when surfing to https://MintFM.net/phpinfo.php: 1. Looking up mintfm.net 2. Making HTTPS connection to mintfm.net 3. Verified connection to mintfm.net (cert=mintfm.net) 4. Certificate issued by: /C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA 5. Secure 128-bit TLS1.0 (DHE_RSA_AES_128_CBC_SHA1) HTTP connection 6. Sending HTTP request. 7. HTTP request sent; waiting for response. 8. HTTP/1.1 200 OK 9. Data transfer complete So it's definitely secure, but I'm not seeing anything in $_SERVER that says so. So I'm wondering if Apache is not exporting something properly. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Detecting HTTPS connections under Apache
On Thu, 26 May 2011, ad...@buskirkgraphics.com wrote: So when you echo $_SERVER['SERVER_PORT']; You get port 80 even if the url currently is https://www.yoursite.com ? Yes. If this is the case good luck. Because you have serious issues. OK. This on its own is not particularly helpful. Surely I can't be the only person in the universe who has experienced this. I'm running a minimally-altered stock Debian Apache and PHP setup. Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Detecting HTTPS connections under Apache
Hi, Apologies if this is covered somewhere but I've searched fairly extensively and not found anything. I'm working on an application which has a function for redirecting to a given URL. This is generally used for redirecting after a form has been submitted. Right now it sends an HTTP URL in the redirection, which means it can't work under a secure connection. I'd like to be able to use it over HTTPS but don't want to force people to do this. So ideally I'd like to be able to detect the protocol in use and send the appropriate protocol in the Location header. The problem is that, at least on the system I'm working on, I can't see any way of detecting the protocol. _SERVER[SERVER_SIGNATURE] and _SERVER[SERVER_ADDR] both give the port as 80, even if I specify port 443 in the URL. I've seen references to _SERVER[HTTPS] or something similar but it's not in the output I get from either print_r ($_SERVER) or phpinfo (). I'm running PHP Version 5.3.3-7+squeeze1 on Apache/2.2.16 (Debian). The machine is an x86-64 VPS running Debian Squeeze. I have full access to the VPS, so if something needs tweeking in Apache (or anything else) then I can do this. Thanks in advance, Geoff. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Detecting HTTPS connections under Apache
On Thu, 26 May 2011, ad...@buskirkgraphics.com wrote:
The %{HTTPS} variable is not an Apache core variable. A more-portable
solution is to check %{SERVER_PORT} for port 80 or port 443 -- or for not
port 80 or not port 443.
ah but this doesn't actually work for me, I get 80 regardless of whether I
use HTTP or HTTPS, even if I use https://example.com:443
Also, you're requiring an *exact* match on not /user or not /admin,
meaning that directory and file paths below these directories will not be
matched -- They will always be redirected by the second rule.
{snip other rewrite stuff}
uh... I didn't say anything about matching URL patterns or the like. I
just want my application to do whatever is already being done. And
hard-coding URL paths is a bad idea because someone else might want to
install the code under some other path.
I don't really want to use rewrite rules to achieve this. If I did, every
time my code redirects the browser, it will cause a rewrite from an HTTP
URL to an HTTPS URL, which surely is inefficient.
Surely it should be simple enough for me to detect whichever is being used
and continue to use it. This makes my code separate from whatever the
webmaster decides to do regarding being secure or not.
Geoff.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
