cags

Theres a function called urlencode that will fix that for you. Just bare in mind you will probably need to use urldecode on the other end. <?php echo '<a href=index.php?dir="'. urlencode($foldersArray[$i]) . '">' . $foldersArray[$i] . '</a>'; ?>

Just out of interest what result do you get if you use this... $parts = explode("05/10/2009"); $day = $parts[0]; $month = $parts[1]; $year = $parts[2]; echo date("D M d, Y", strtotime($year . "-" . $month . "-" . $day));

You seem to be confused between concepts here. Passing a variable between forms using the submit button is all to do with using the $_POST and $_GET superglobal arrays. $_SESSIONS is another superglobal array which is generally used to maintain a value during that users visit to a site, regardless of the page they are on. Page1.php <form action ="Page2.php" method="post"> <input type="text" name="username" /> <input type="submit" value="Send" /> </form> Page2.php <form action ="Page2.php" method="post"> <input type="text" name="username" value="<?php echo $_POST['username']; ?> /> <input type="submit" value="Send" /> </form>

This is a common misconception of how mod_rewrite works. The actual purpose of mod_rewrite is the opposite of what your attempting to do. If a user puts http://www.mysite.com/profile/john-smith into their browser, mod_rewrite can be used to point the user towards http://www.mysite.com/profile.php?id=john-smith, but the address in the users Address bar will not change. To disguise a url in the manner you are talking about is done with frames as RusselReal has pointed out.

Most likely reason is you are doing something like $_POST['LeftSideText'] and the $_POST array doesn't contain an element with the key 'LeftSideText' Not 100% sure but fairly confident it's the same problem, but rather than being an associate array it's for a numeric indexed array.

So you wish to output $line['email'] only if it contains distributor11111111K? while($line = mysql_fetch_assoc($results)) { if (strpos($line["Email"], "distributor11111111K")) echo "<item>" . $line["Email"] . "</item>\n"; }

Glad it's fixed for you btw, can you mark the topic as solved, (bottom left corner).

If you wish to format each column differently (ie add in $ sign etc.) just replace the inner loop with a more specificy pieces of code <?php // this foreach($items as $item) { echo '<td>' . $item . '</td>'; } // with this echo '<td>' . $line[0] . '</td>'; echo '<td>' . $line[1] . '</td>'; echo '<td>' . $line[2] . '</td>'; echo '<td>' . $line[3] . '</td>'; echo '<td> $' . $line[4] . '</td>'; ?>

Put them in a table, then you can style it how you like with CSS. <php include 'pcinfo.php'; $lines = explode("\r\n", $serialpurchase); echo '<table>'; echo '<tr>'; echo '<td>header 1</td>'; echo '<td>header 2</td>'; echo '<td>header 3</td>'; echo '<td>header 4</td>'; echo '<td>header 5</td>'; echo '</tr>'; foreach($lines as $line) { echo '<tr>'; // if you need to then $items = explode(" ", $line); foreach($items as $item) { echo '<td>' . $item . '</td>'; } echo '</tr>'; } echo '<table>'; ?>

Perhaps I should have been more specific... <?php echo $PHP_SELF; ?> // should be <?php echo $_SERVER['PHP_SELF']; ?> As for the preg_match, it's because regex patterns used with preg_match must have delimeters. But nevermind. EDIT: Btw if problems solved, theres a SOLVED button in the bottom left of your screen to click.

These three variables are also deprecated I believe... $browser = $HTTP_USER_AGENT; // should be $_SERVER['HTTP_USER_AGENT']; $ip = $REMOTE_ADDR; // should be $_SERVER['REMOTE']; <?php echo $PHP_SELF; ?> // should be $_SERVER['PHP_SELF']; On this line... if ((!ereg(".+\@.+\..+", $Email)) || (!ereg("^[a-zA-Z0-9_@.-]+$", $Email))){ ereg should probably be replaced by preg_match as the function is either deprecated, or very soon to be, not entirely sure which. But the reason it isn't working is this line here.... $dcheck = explode(",",$require); Replace $require with $_POST['require']

What version of PHP are you using? I believe $HTTP_POST_VARS is a deprecated variable as of ver. 5. Try changing any instances of that to $_POST.

Indeed, which is why I included the word arguably. Regardless of speed I personally prefer the single quote approach in this case because it saves you escaping the double quotes for the HTML attributes. I have PHP 5.2.9, when running your test code the single quotes were between 0.05 and 0.1 secs faster. As we're talking about 50,000 iterations hardly worth worrying about. I was simply pointing out that if ProXy_ felt the need to correct the OP's usage, that there was IMO a better way. At the end of the day it's all down to personal preference anyway, they all do the same job.

Ahh I see, in that case it shouldn't be too difficult. Something like this suit? <?php include 'pcinfo.php'; $lines = explode("\r\n", $serialpurchase); foreach($lines as $line) { // do something with the line // if you need to then $items = explode(" ", $line); foreach($items as $item) { // do something with item } } ?>

How about? echo preg_replace("~@(\w+)?~", "@<a href=\"profile/$1\">$1</a>", $src);

If you wanted to use the more 'standard' double quotes for the HTML, why not use what is (arguably) faster and certainly easier PHP of... echo '<a href="syntax">';

LIMIT 1 means only fetch 1 row from the database, as you are searching by unique id you should only ever match one variable it's just a way of potentially speeding up the. I'm not certin it's required when searching a Unique field I just thought I'd add it in there. Your getting the error because you passed x. My code assumed the id is an integer. Strings passed to MySQL should be enclosed in single quotes.

Hmm... I would assume that the site must be parsing the URL in some other way like using mod_rewrite. To my knowledge it would be impossible to attack a site otherwise. It's possible I'm wrong, but I'd be surprised as I've never seen anything about it.

Sounds like your looking for something like this... <input type="checkbox" name="id[]" value="5" /> <input type="checkbox" name="id[]" value="10" /> <input type="checkbox" name="id[]" value="15" /> <?php if(isset($_POST['id'])) { foreach($_POST['id'] as $item) { $sql = "SELECT * FROM table WHERE id=$item LIMIT 1"; mysql_query($sql) or trigger_error("SQL: $sql, ERROR: " . mysql_error(), E_USER_ERROR); // do something with item } } ?>

I certainly wouldn't consider myself an expert, but heres my 2 pence worth. There are alot of different types of attacks that can occur on a website, some are generalised things that all sites should be wary of, others are tailored more specific to a single site. Some of the most widely used hacking/security terms are as follows... SQL Injection Attacks - Where a hacker uses sql to insert unwanted commands into a query. In it's least dangerous form this may allow a user to authenticate without a valid username/password, in more complex forms it could give them complete access to your db structure etc. etc. XSS - Also called CSS sometimes, but that has an obvious confusion factor. Cross-site scripting attacks are where you allow a hacker to insert information into your site (whether it be db or flat file) that will be displayed back to other users. If this information isn't filtered there are all kinds of nasty tricks hackers can employ. CSRF - Sometimes called session riding because it exploits the trust a website has in an authenticated user to cause damage. In a more specific response to your question, can somebody damage your site by adding information to the end of a standard URL, the answer is no. Assuming that the page doesn't parse the URI in anyway ($_GET, $_REQUEST) there's no way anything put on the end of a URL can cause damage. The basic ethos of securty DON'T TRUST ANYTHING THE USER CAN DIRECTLY CONTROL. Never use a value from $_GET, $_POST, $_REQUEST or $_COOKIE without validating it. Validating with JavaScript is fine for user feedback, but not for security. Don't assume that a user cannot change a form variable just because it's not visible on the site. It's very easy for a user to change the value of an <input type"hidden" /> or any other type of form element. Providing you do that and you do it well, you should be safe.

Ahh right, yes, I see what your saying now.

From my experience the value in the "type" section of the array is far from accurate with regards to comparing it in the manner you have. For some reason, which I'm sure theres an explanation for, a file doesn't always have the correct type associated with it. A work around could be to check what the file extention of the filename is using the string functions or regex. This obviously this isn't a perfect solution as somebody can change a file extension. No doubt somebody has a better idea, but since you seemed to be in a hurry I thought I'd share what I know.

The input string definately contains a colon immediately by a capital letter p? Theres nothing wrong with your code in as much as $new_string2 will contain the <img tag if $string contains ''. Though I would have thought what you really want is more along the lines of... $string = str_ireplace($sweararray, $replacearray, $string); $string = str_replace ($smilearray, $smileyarray2, $string); ... though bare in mind that it could cause some 'kooky' behavior if any of the swearword $replacearray contains the characters used in $smilearray. It would make more sense (IMHO) to put the smileys in the same arrays as the swear words and just do a single replace.

Never really worked with OOP in PHP, but from what I remember from using them in C# back at uni shouldn't a single interface do the job? Ie. you have an interface 'Database' that must include function query(), function num_rows(), etc, etc. You'd then have classes 'DB_MsSQL', 'DB_MySQL' etc that implents the 'Database' interface. Then within the 'User' class you would have a private member of type 'Database' called $db (or whatever you wish). The 'User' class would then have functions that would use $this->db to call database functions. If the person employing the class 'User' wishes to change to a different type of database they would merely have to change the declaration of $db to $db = new DB_MsSQL(); rather than $db = new DB_MysSQL(); Does it not work like this in PHP, or did I miss the point completely (quite possible)?

I did a quick search and came across somebody that claims this solved their problem using... mysql_query("SET CHARACTER SET utf8"); mysql_query("SET NAMES utf8"); ... which is a slight addition to nrobi's suggestion.