Adam

antonyfal, you are making no sense. Please explain properly in sentences why you can't just replace the old jQuery library with the new one, because there's literally no reason why you can't do it.

Your DIV stores your variables? Please rephrase your question or provide more details, it doesn't make a great load of sense.

Great business strategy.

Maybe I'm missing something, but why don't you just modify the external script tag to point to the new version?

file_get_contents file_put_contents

First off, jQuery is JavaScript wrapped in a framework. Though understanding JS is not essential to write jQuery, as the framework wraps a lot of the main constructs really well. Personally though I would say having at least a foundational knowledge before hand will benefit you, from debugging to writing more efficient scripts. Also understanding the DOM, objects, etc. will give you a better insight as to how it works under the hood, and ultimately make better use of it. Creating a tooltip field or tabbed menu will inevitably be faster with jQuery, because that's what it's designed for. One of the major benefits is that it deals with all the browser quirks and handles what would probably be quite drawn out with vanilla JS -- doesn't mean understanding JS itself isn't a good idea though.

Likely a permissions issue. Using your FTP client or through SSH, set the permissions to 755. This just means you're trying to use a custom 404 error page that doesn't exist itself.

In short, no. GPS is the vital ingredient for plotting accurate positions, which laptops and desktops don't commonly have. You could base it on IP but that would give mixed results, the majority of which would not be accurate enough to be useful.

.... Exactly how we've been describing for 5 pages.

You should just use a link (and technically if you follow REST practises that is how you should do it - through the URL). If you're worried about tampering with the URL to delete other items, then surely they user could just go back and click the button on the item they wish to delete? Permission checks should prevent them deleting anything they shouldn't be able to.

Kind of. You will likely use both for the same piece of data, but at different times. If you use htmlentities/htmlspecialchars whenever you read and write the data from the database, this could lead to issues. For example if it's a blog or forum post, every time it's edited by the user it will encode the encoding. Slowly you'll get an encoded ampersand, for an encoded ampersand, for say a space: When it's inserted: The first time it's modified:   The second time it's modified:   etc. Do not use a generic function to handle all types of sanitization.

They're likely just simple bots spidering websites looking for files/software that have, or have been known to have, exploits.

'password' is not a reserved word in MySQL (see here for full list). You need to handle errors that could be returned from the query. Change any calls to: mysql_query(...) or trigger_error(mysql_error(), E_USER_ERROR); That will trigger a fatal error explaining the problem.

If by "the script a few pages back" you mean the sanitize() and sanitize_array() functions that were posted, then no. Do not use them for the reasons listed in the last few posts. That implies that all data can be sanitized in the same way, which it can't. They do sanitize data, but for use in different situations. mysql_real_escape_string() is used for sanitizing data before it's used in a database query, and htmlentities() is used before outputting data into a web page. mysql_real_escape_string() IS the standard function to use when escaping data for use in a MySQL query. htmlentities() is one of two similar functions, there's also htmlspecialchars(). The difference is that htmlentities() will convert any character that has a HTML entity equivalent, where-as htmlspecialchars() is bit more reserved and generally is all you will need. Read the manual for a clear explanation of any function and to decide, if there's a few that are similar, which is the right one to use.

Not really, because in a realistic situation $str would be user input. You have no idea how many slashes will be needed.

Nope. Saying that if you sanitize the data correctly there won't be any issue of users injecting exploits. One situation to be aware of is when you use numeric data, and don't include quotes within the SQL: select * from TableName where id = $id; Here the user could insert an SQL injection, like for example "1 OR 1=1", that would break the where condition logic. This wouldn't be secured against by mysql_real_escape_string() as there's no quotes or special characters used. You need to validate or cast the data as an integer. Obviously in this case it wouldn't do any actual damage, but consider if there was an UPDATE statement with the same exploit... It's also down to your application code to prevent any logic-based security holes. For example, if the user modified the GET parameters to try and view a page they didn't have permission to see, your application should check this every time. Security is a very broad subject, I would recommend reading this tutorial for a better understanding.

I'm not really sure who's post you're referring to here, but if you sanitize data *before* validation, it might not be the same after. For example: // 15 character length string $str = "15 'chars' long"; // Sanitize the string $sanitized = mysql_real_escape_string($str); // Now validate the data is no more than 15 characters long if (strlen($sanitized) <= 15) { // ... } This would fail because mysql_real_escape_string() would insert a slash before each single quote, making the string 17 characters long. If you switched around the validation and sanitization it would work fine.

Sanitization is not about the type/form of data, it's about protecting the user/server from the data. When you use data within a SQL query for example, people can use SQL injections to modify what the query does. When outputting HTML, users can use XSS to inject potentially harmful JavaScript, or just code that will break the HTML and render the page incorrectly. There's no need to protect against XSS when you're inserting data into a database, likewise there's no need to protect against SQL injections when you're displaying data in the browser. That's why we use different sanitization techniques depending on what we're doing. Validating/ensuring the integrity of data is a slightly different, but related subject. For example, if you're storing an email address you want to validate the string matches the form of an email address. If it's currency or a decimal number, you cast the data as a float. If it's a whole number, integer. After validation you would then know these types of input cannot contain SQL injections, because they match a pattern that would make it impossible. Certain data cannot be validated except for say minimum or maximum length, like a forum post. In this case you would just have to sanitize the data to ensure any SQL injections are prevented.

There's no need to escape the data within the database, it won't do any harm there. It would also take up more memory with all the HTML in its entity form. Escaping is only required when you *output* the data. Of course, you should still sanitise the data from SQL injections before using it within a SQL string.

Okay, though removing the contents of every tag would leave the posts not making sense. The reason strip_tags() only removes the actual tags, is so that any text in <b>bold</b> for example will still be readable. If you don't want your users to be able to insert HTML, just escape it with htmlspecialchars as you output it. <?php echo htmlspecialchars($str); ?>

Are wanting to remove all tags or just script and embed?

As people keep saying, the reason there's no one solution to this is because different data needs to be sanitised in different ways. Having a read through just page 3 of this thread, three or four people must have said that already. Like in the most common example, when outputting HTML you're not sanitising against the same problems as when you insert data, because you're not dealing with the same security issues. Having such a complex function to do everything would just over complicate the use of it, or waste resources protecting against things you don't need to. Therefore you have several functions to do different types of sanitation. Instead of fighting back against what experienced developers are telling you, you should start learning the vast amount of security issues there are and how to protect against them. You'll also notice amongst the more experienced developers there are fairly standard (read: the most efficient / correct) ways of doing things.

Whoops made a little mistake with the line-feed characters; should be "\r\n", not "\n\r".

Browsers will convert any whitespace (tabs, new-lines, etc.) into a single space when rendered. If you look at the data into the source it will be new lines.

There should be a "<br>" before each file name. I suspect the data is split by new line feeds, not spaces. That could explain the results you're seeing.. try splitting by this instead: preg_split('/(\n|\n\r)/', $var_test); That will use a regular expression to split the string on either "\n" (Linux format line-feed) or "\n\r" (Windows format).