Daniel0

I don't know what you mean with "complex", but I would say it's more complex given that it has more features and you can dynamically change the size of it without having to reallocate memory manually.

In C, strings are arrays of chars, but that's not the case in PHP. Actually, there isn't even a char data type in PHP.

It is supposed to process multiple URLs in parallel, but not in the way you're saying. Say you have your URLs in an array called $urls. Then you can do this: <?php $mh = curl_init_multi(); $handles = array(); foreach ($urls as $i => $url) { $handles[$i] = curl_init($url); curl_setopt($handles[$i], CURLOPT_HEADER, false); curl_setopt($handles[$i], CURLOPT_RETURNTRANSFER, true); curl_multi_add_handle($mh, $handles[$i]); } do { curl_multi_exec($mh, $running); } while ($running > 0); // get content using curl_multi_getcontent() here foreach ($handles as $handle) { curl_multi_remove_handle($mh, $handle); curl_close($handle); } curl_multi_close($mh);

If e.g. $_POST['name'] doesn't exist then why would you want to reassign a non-existent value to another variable? That doesn't make sense. You shouldn't run with display_errors=on in a production environment. It doesn't remove the error, it suppresses it. As a general rule, you should never suppress errors, you should make sure they do not happen. Using the error suppression operator @ is also inefficient. It's equivalent to doing this: $oldErrorReporting = error_reporting(0); $name = $_POST['name']; error_reporting($oldErrorReporting);

That might be bad to base your script around assuming its off. What if down the road you end up on different hosting where its on, and you cant' control it? you totally forget about ti and now site is messed up and your pulling your hair going threw the code your forget how it works and it was commented bad... yadda. lol Then you should probably find another host. It's been turned off by default for several years, been bad practice for even longer, and it's officially deprecated right now. It can solve it, but it doesn't necessarily do it, and it certainly does not enforce it. Re #2: No, that is still up to yourself to do. Smarty doesn't prevent you from calling die() in your business logic if you don't know any better. Re #1: Ironically, you have mixed presentational logic with business logic in the code you posted. Touché yourself

That's not how the curl_multi_* stuff works. If you want to create multi threaded scripts, have a look at the pcntl functions.

Yeah, load it using GD and then use the quality parameter for imagejpeg.

Or you know, he could just not add the HTML stuff right before he is going to treat it as a numeric value...

As AlexWD said, this is a non-trivial change. Essentially the script is designed fundamentally bad. This is more easy. A salt is something that is hashed along with the actual password. While a hash cannot be "decrypted" (that word doesn't even make sense in this context, but that's another story), a brute-force or dictionary attack would be possible if you somehow obtain the hash. Salting foils this attack because there are lots of random stuff added to the hash (which makes dictionary attacks useless) and it becomes longer (which makes brute-forcing take a long time). Of course if you get the salt and know where it is positioned, you're back to where you started. A good idea may be using a salt that changes occasionally and is stored in the user row, and another static salt that doesn't which is stored in a config file. You can change the user specific salt whenever you've got the plaintext password (that would be when the user logs in or changes his password). Read up on salting on the internet, or search the forum archives here. This is trivial, turn of magic_quotes_gpc off in php.ini. See #1. Things such as empty, isset and key_exists will help you with that. So instead of if (!$_POST['username']) you could do if (empty($_POST['username]']) because empty() checks that the index is actually exists as well. In this case, just remove that statement entirely. It's redundant, you aren't using it and you're overwriting it a little while later. Just use the same info throughout the entire script. This should be fairly trivial. Just remove the while structure (though retain the statement within it) including the brackets that belong to it. First of all, md5() isn't vulnerable to SQL injection attacks, so escaping isn't needed. Actually it's incorrect because it changes the string. Secondly, when he checks the password in his script, he needn't select where that password matches as well. Actually, when he implements salting he might store the salt in the database and in that case he cannot do what you're suggesting.

Exactly how doesn't it work then? Some distributions of Linux use different php.ini files for CLI and Apache. If you changed the include_path for the Apache one you might have to change it in the other one as well.

Just thought of another thing: Assuming your variable upholds the invariant that usernames are unique, you needn't use a while loop when fetching the info because there will only every be at most one row returned. Seeing as you've also verified that a row was actually returned, you don't even need to check that mysql_fetch_array() returns the result. If it doesn't it would be a bug in PHP.

Have a look at these topics. They might help you. http://www.phpfreaks.com/forums/index.php/topic,274461.0.html http://www.phpfreaks.com/forums/index.php/topic,273616.0.html http://www.phpfreaks.com/forums/index.php/topic,273665.0.html

Try searching our regex board. You're not the first person to get the idea of scraping things off web pages.

Zend Framework requires that it's in the include_path unless you use it's namespace auto loader.

There is no function called file_get_html() in the PHP standard library.

Well, there are a couple of things: 1) Calling die() is not an appropriate way of handling errors. 2) You should use some sort of salting along with the password hashing. 3) Your usage of stripslashes() seems to suggest that you are running with magic quotes on; turn it off. 4) You should separate your presentational logic from your business logic (separations of concerns). 5) You are assuming that $_POST['username'] and $_POST['password'] are both set. If they are not you will get an E_NOTICE. You should check that an index exists in an array before you use it (unless you already know it does). 6) You don't need to MySQL escape $_POST['password'] seeing as you aren't using it in any query. 7) You are selecting the same user from the database twice, which is obviously redundant.

That's exactly like a CPU works...

Ah, right. No, certainly not.

So are you See str_word_count.

You cannot develop/create/use MVC. It's a proper noun, a name of a particular design pattern. The model in MVC doesn't refer to a database or database access object (otherwise we would just call it MDC or whatever). The model is the domain-specific representation of the data you're working with. You always have some sort of data because otherwise you cannot have any output. The factory and singleton patterns are creational patterns while MVC is an architectural pattern. You cannot compare factory/singleton with MVC the same way you cannot compare a car to an apple.

An infinite number of mathematicians walk into a bar. The first one orders half a beer, the second one orders a quarter of a beer, the third one orders 1/8 beer. Then the bartender says "You're all idiots" and pours one beer.

Oh, I didn't notice there was an element of time as well.

We would encourage everybody to introduce themselves here so we might get to know you and "old" members are very welcome to introduce themselves as well.

echo strstr($email, '@', true); Edit: Ha... maybe I should check date stamps before I post. Well, whatever.

$lastRun = time(); if ($lastRun + 3600 < time()) { runIt(); }