salathe

Your PHP code snippet contains invalid syntax, I'm going to assume that does not occur in your actual code (since a different error would be issued). Can you give an (or some) example of the values for $HW_dev as that would help us to diagnose why they cannot be formatted as a number.

Are you using preg_match? It looks like you probably want to be using preg_match_all.

"hello world".replace(/(?!^)\w/g, "_") gives us h___ _____

Do you need to cater for more than one 'extension': co.uk for example? Will there ever be any subdomains: www.example.com?

What value is returned from get_magic_quotes_gpc ?

Change the following line from the code in your first post: $data = implode("", file($feed)); To use cURL instead: $curl = curl_init($feed); $data = curl_exec($curl);

It looks like you might be wanting something more like the following, which brings back the values from the com column. $data = array(); while ($row = mysql_fetch_assoc($result_mq1)) { $data[] = $row['com']; } A more generic version of the above would be to use mysql_fetch_row and $row[0].

Firstly, IRC generally only answers the question for the individual doing the asking. A forum thread will preserve the questions and answers in perpetuity for everyone to discover. Secondly, I've no idea which IRC you've been hanging around in but hardly anyone hangs around in there and those that do are idly 95% of the time: it is a common occurrence for people to drop in for a quicky bit of help and be met with silence, even over long periods of time.

Maybe. Sure, why not. It's a faithful reflection of my personality.

Of course, the call to fgets used when calling preg_match reads the line that you are really interested in. Then when you call fgets again, it continues from where it left off and reads the following line. You probably want something like: while( ! feof($file)) { $line = fgets($file); if (preg_match("/^Number\b/", $line)) { echo $line; } }

Except you changed from using addslashes to mysql_real_escape_string, thus spoiling the whole purpose of that if/else block. Admittedly, using a SQL query like that was a bad choice and the manual example should be updated to reflect that (along with a big, red don't use magic quotes, they're deprecated warning). Today's practice is to remove the added slashes if magic quotes are enabled and deal with escaping values for SQL queries, or output to the page, as appropriate.

There is a whole spectrum of things that I might commonly validate on. Basic things like minimum/maximum lengths (of strings, of items in a collection, etc.), character restrictions (alphanumeric, etc.) to whether a specified value (e.g. an order under) satisfies our application-specific structure, any form of user input so things like telephone numbers, credit card numbers, URLs, email addresses, date and times, and so on. Also I would bear in mind that regular expressions, while a useful tool, are not a catch-all solution. You'll probably want to use "basic" string/number/etc. functions and much more complex logic all alongside some regex, as part of the validation.

Absolutely do not do this. If magic quotes are enabled, you will be feeding unsanitized (except for the magic quotes escaping) user input into your query! As in the example link provided by mjdamato, check if magic quotes is enabled and undo what it has done then regardless of the magic quote setting, escape the input when adding it into the queries.

Three characters. Also, the short tag might not be turned on (there's a php.ini short_open_tag setting for that) so you cannot always assume it will be available.

Yes, but you have to be using some really mammoth codebase or doing something silly to reach that "too much" level.

Try and bunch and work it out for yourself. This question is so subjective that any editor or IDE that we named could really not suit you.

Fire away in this thread.

Necessary, no. Them? Since OOP isn't needed, I guess the answer is from zero complexity to more complex than you can fathom. Sorry, I couldn't do that.

Most likely, not. Until you run proper profiling on the system, to discover and analyse weak points, it is usually not worth worrying about "small" things (of which this is one). If at some point the loading and parsing of this file becomes troublesome, you will (or should have in place the resources to) know it and the answer would be obvious. Of course, there are various ways to get that data loaded cross-request in a less memory/time/etc. way which you might like to discuss here regardless of whether it is really necessary at this stage, if you really want to?

Yay, party time.

I'll be in the Freenode one: irc.freenode.net ##phpfreaks Note that, as of writing this, the channel is moderated so you won't be able to talk.

Hopefully Eric will notice and restart the IRC server, it was finally starting to get some activity before it was nuked. That he hasn't made any announcement, note, explanation or apology for the downtime of the site and other services leads me to believe, if it were ever in question, that Eric really doesn't give two hoots about this place, which is a real shame. You mightn't care, but other people here would like it back up. Just for a sense of being back to normal, if nothing more.

There are 10 numbers of the format that you are looking for in the HTML from the last post, your previous post showed 10 matched numbers. What's the problem? Edit: If you're looking to match 12345/67890 as two numbers, then you could do something like the following. $search = '~(?<=/)\d+(?=/)~' This uses a lookbehind* and lookahead* to search for numbers surrounded by forward slashes. * More info: lookaround

As was mentioned, the report is flagged as "bogus" which means it's not a bug at all. It will remain in the system so that anyone else wishing to submit a similar report in the future might stumble upon yours and notice their error.

That flag (SplFileObject::SKIP_EMPTY) was only added in PHP 5.2.0 so you cannot use it with your 5.1.1 I'm afraid. Seems the documentation needs to note when this (and a couple others) were first introduced.