ManiacDan

The very first example I gave you will work.

$password = $_POST['p']; // The hashed password. Your code contains no input named "p". Even if it did, the password would not be hashed. I'm still not sure how you think randomly commenting half the script proves POST is working. Ignore the fact that you have two separate and unrelated pages. Fix ONE first.

Your code does 2 redirects (both incorrectly). POST generally doesn't follow redirects. How are you sure POST is being set and yet it's not being set? How can you view it if it's not there? Your problem description doesn't make sense. Do a print_r($_POST); at the top of your page, that will show you what's in $_POST.

Will MySQL continue to evaluate CASE statements? What if the description contains 8 different special characters? Will all 8 of the replacements evaluate?

The queries are designed to replace "special" foreign characters with their latin equivalent in a field called "description." It's assumed these are actual descriptions, longer than one character. The case given will only replace descriptions that are one character long and ignore the rest. That's why he was using the REPLACE function with no WHERE.

That case won't work. Running them all one at a time is going to be slightly slower but not so much that you'd care. My script will work, though The Little Guy provided my "other" solution, right in the cron line.

You may be surprised to learn that none of what you posted was PHP. This PHP script will run the queries as long as you establish the proper database connection: mysql_connect(/*proper values here*/); $statements = array( 'UPDATE `property` SET `description` = replace(description, "é", "e")', 'UPDATE `property` SET `description` = replace(description, "á", "a")', 'UPDATE `property` SET `description` = replace(description, "St.", "St ")', 'UPDATE `property` SET `description` = replace(description, "Ãœ", "u")', 'UPDATE `property` SET `description` = replace(description, "È", "e")', 'UPDATE `property` SET `description` = replace(description, "ü", "u")', 'UPDATE `property` SET `description` = replace(description, "ü", "u")', 'UPDATE `property` SET `description` = replace(description, "ß", "ss")', 'UPDATE `property` SET `description` = replace(description, "Ö", "o")'); foreach ( $statements as $statement ) { mysql_query($statement); } You can also do this through bash, or pipe a file full of statements to mysql right from the cron interface.

Just like we told you on devshed, this is a major security hole and you attempting to do it may actually be illegal.

He appears to be looking to do something nefarious with user accounts and package tracking data. Hey PANDIYAN, guess what? I'm a mod here too and I will ban you from this site as well if you continue asking how to steal cookies and track packages which belong to other people.

Ubuntu is a type of linux, like cinnamon, redhat, gentoo, and dozens of others. I'm using Ubuntu 12.04 right now. Boot to the Ubuntu CD and it will walk you through the process of partitioning your drive and installing GRUB bootloader. Note that you need half your hard drive free, if you have a lot of music or something on the drive it won't work. So you have a bootable USB copy of Ubuntu but it's not booting? Try a CD/DVD. Are you sure you're booting it right?

Time and money is what you should focus on. Don't use words like "annoying" or "trouble," tell him that you did the math, and it costs the company $400/mo to give these people access to the data.

But he says that he can't do that:

When you revamp them, at least make them a monospaced font. Helvetica does not make for easy to read code.

If they're typing raw queries, this will still allow them to break things.

The "real" code had multiple syntax errors in it (which won't run at all) and wasn't using str_replace properly. I think we can safely assume those were his problems.

This code is so convoluted it's going to require YOU to do some debugging. This is what it looks like to me: Your code accepts X number of POST boxes, and doesn't check to see if they exist. It then queries Y number of records from a database, and assumes X=Y It then loops for C = 0 through C = Y-1, querying one of the X variables in POST to get the get the index of the headers of the CSV file somehow. Once you have the index of the headers of a CSV (which is based on the order of the records in your mysql table keyed off the unseen POST variables), you then read an entire ROW from the csv file (despite the fact that the POST value determining the... You know what, this is way too much for me to bother with. This is your problem: Whether or not you expect that to happen, this line doesn't do that: while((${"fileop$i"} = fgetcsv($handle,10000,",")) !== false) That goes to the end of the file and stops. You have to re-open the file or store it in memory if you want to run through the file X times. Your use of variable variables, unknown numbers of un-validated POST fields, un-ordered queries, and reliance on everything to always match all the time makes this too much to figure out. Describe what you have, and what you want to happen. There's a better way.

What's wrong with the syntax highlighting? $a = "foobar"; echo strrev($a); edit: I guess the highlighting is kind of bare-bones, not as nice as plain old highlight_string. Also, what I do is usually save my viewing preferences for PHPF to be one size larger than standard. Hit ctrl+= (control plus the equals/plus key) to increase the size of the font on a page, then next time you visit that domain in chrome (and probably firefox) it will render slightly bigger.

Like Jesi said, give them accounts with only SELECT access, then they can't do anything but lock the tables.

This is the basis of the MVC coding style. You're mixing display logic (adding formatting and currency symbols) in with controller-level logic. If you ever do anything with these prices other than printing them (like adding them or sorting them) you will get the wrong result and not understand why.

Stop using formatted dates, only format dates when you're ready to display them, it's not smart to continuously re-format and parse formatted dates throughout your code. php > $date = time(); php > $due_date = strtotime('-14 days', $date); php > echo date('c', $due_date); 2012-09-17T11:05:44-04:00 only use date() when you output. PHP has no way of telling if 20121001 is a date stamp or a formatted date-time string.

You should always be adding things like formatting and currency symbols at the very instant you display them. Otherwise, you run into problems like this. Are you remembering that there may be a comma in these numbers if you format them using number_format? Do you know: $a = "123,456.78"; echo $a * 2;//echoes "246"

You're trying to get the date of the string '{start}'. That's not a date. You can't just assume CMS variables will be replaced in random bits of PHP code, you need to use the actual date. Also, if '{start}' looks like '1346689843', you can't call strtotime on it. If you have PHP 5.3+, use the datetime library for stuff like this.

MySQL and PHP are separate languages. If your MySQL programs (queries) are wrong, fix them, don't try to have PHP automatically correct the wrong output from MySQL. JOIN conditions are your answer.

Storing time spent online is always an estimate. You can never tell when they leave the site, or if the human is still at the keyboard doing things. You can just say that every page load represents 30 seconds online, then keep a page load counter in the user table.

Well maybe you can help me with my dog. She's really sick, here's a photo: , /-. ((___/ __> / } \ .--.( \\ \\ It's not actually her, but that shouldn't be a problem right? We absolutely positively cannot help you fix your code by looking at someone else's. Show a before and after proof that a built-in language function that works for tens of millions of people every day is not working for you.