maxxd

If you're setting a max of 45, the field is only going to have at most 2 digits in it. Why try to allow 3 when 2 is going to happen? If you're worried about browsers that don't support a number form field, add that check to your javascript validation when the form is submitted.

Your log out link goes to logout.php, but you've only shown us the code for index.php. The problem would be in the logout.php script (as that's where the browser is going once the link is clicked), so show us that code as well.

This may not be the most efficient solution, but it worked in the couple easy tests I just ran on it: $err = "SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'cowboy@dfwit.co' for key 'username'' in /var/www/html/dfwit/register.php:36 Stack trace: #0 /var/www/html/dfwit/register.php(36): PDOStatement->execute(Array) #1 {main}"; $colMarkStart = "' for key '"; $colMarkEnd = "' in /var/"; $startKey = strpos($err, $colMarkStart) + strlen($colMarkStart); //the first occurrence of the first character in the search string plus the length of the search string $endKey = (strpos($err, $colMarkEnd) - 1) - $startKey; //-1 from the end string position to account for the end quote, then subtract the starting position to get the desired span of characters $column = substr($err, $startKey, $endKey); //pull that span of characters from the error string print("<p>Duplicate column : {$column}</p>");

Actually, the scenario you're concerned about is exactly what SQL is designed to do, and it does it very quickly. Because you're indexing everything by user ID, that's the only column that needs to be scanned. Of course, speed of transactions can slow down, but that's usually due to bad programming - for instance, selecting every column in a row when only 1 is needed. Read up on database normalization - a good article or three should shed some light on the situation and why working as you've proposed is actually far more wasteful than working the way you're concerned about working...

The image is scaling - what results are you expecting to see? You've got a set pixel width on your header and footer elements that need to be either turned into a percentage width or adjusted manually with media queries.

If you format and re-read your code, I think you'll see what the issue is. There are only 2 ways I can see that you're not going to be redirected to ./continue.php - if there's nothing in $_POST['username'], $_POST['email'], and $_POST['p'], or if your e-mail is invalid. You don't have an else clause for any of your prepare() statement checks, so the code skips those parts. Nothing is assigned to $error_msg so, when you check the value of $error_msg, it's empty, and you create a password hash only to fail (and therefor skip) the third prepare statement without an else clause, and lickety-split you're being redirected to ./continue.php. Try adding else{ $error_msg = 'Yup. Failed a prepare'; } after the closing brace of both the if ($stmt) { ... } segments, and the if ($insert_stmt = $mysqli->prepare("INSERT INTO members (username, email, password) VALUES (?, ?, ?)")) { ... } segment of code and see what happens. I'm not saying that exactly this is happening, it just looks to me like the most likely possibility.

Wait, now it sounds like the problem isn't in the code that writes the ID into the header location string, but in the receiving page? Show us the code you're working on. Without seeing the code that's not working and having a detailed and complete description of what 'working' means in the context of the code and project, folks here are stabbing blindly in the dark and can't help, even though they may want to.

Are you having difficulties with php output for screen or php output for JavaScript?

If you use AJAX to load the page content the lag time shouldn't be too bad depending on the amount and type of content. Obviously if you're loading 1006 large images per page, that's going to drag your page load no matter how you navigate through it. You will have to crack into the History API to enable bookmarking and browser navigation. Also, depending on how you set everything up, you may need to build in additional checks at initial page load to make sure you're loading the proper content in case the user is navigating to a page on your site that's not your home page. For instance, if they've bookmarked a specific page and then use that bookmark next time. The only other thing I'd recommend considering early in your dev cycle is whether and how to handle non-JavaScript browsers. If a user has JS turned off, that could seriously affect the display and functionality of your site. Whether it's worth it to enact a back-up methodology or not is obviously up to you, but it's better to think about at the beginning than the end of things...

If I'm understanding your question properly, in WordPress you'll want to take a look at the register_script(), localize_script(), and enqueue_script() functions fired from the wp_enqueue_scripts action hook. function enqueueStuff(){ wp_register_script('script_id',$this->getPluginDirectory()."/js/yourJSFile.js"); wp_localize_script('script_id','script_data',array( 'postCode'=>$this->getPostCode(), 'latitude'=>$this->getLatitude(), 'longitude'=>$this->getLongitude() )); wp_enqueue_script('script_id'); } add_action('wp_enqueue_scripts','enqueueStuff'); Of course, the pathing to your JavaScript file and the methods getting the post code, latitude, and longitude will be different for you - these are random stubs, but that's the basic idea of it.

Basically, change this: $stmt = $con->prepare("SELECT username, password, status FROM users WHERE username=? AND password=? AND status=?"); $stmt->bind_param("ssi", $username, $password, $status); to this: $stmt = $con->prepare("SELECT username, password, status FROM users WHERE username=? AND password=?"); $stmt->bind_param("ss", $username, $password); The rest of your script should work as you expect.

You're using the status as a parameter for your query, so it's only going to return records that match the username, password, and the supplied status. Keep 'status' in your select field list, but don't use it in the conditional. That way you'll pull the record that matches the username, password, and any status. Then you can check the value of that status and be on your way.

As the error states, your syntax is wrong. You're probably missing a closing parenthesis before your opening brace on line 69.

Turn on error reporting at the top of your script: ini_set('display_errors',true); error_reporting(-1); These lines instruct php to print all errors and warnings to the screen, so you'll them instead just a blank white screen. Obviously you'll want to comment these lines out before you take your site live, but you should always have error reporting enabled while developing.

Looking at the way you're building your WHERE clause, it looks like there's no way it's not going to start with an AND keyword. You define $where with a blank string, then every if() branch concatenates a string beginning with ' AND...'. This will throw a syntax error in SQL - try printing the query before you run it and I think you'll see that's the error. There are a couple ways around this. You could test the value of $where in each if() branch to see if it's blank or not before concatenating the keyword 'AND', like so: $where = ''; if(!empty($sbidDate)){ if(!empty($where)){ $where .= " AND "; } $where .= "b.BidDate = '{$sbidDate}'"; } if(!empty($sdueDate)){ if(!empty($where)){ $where .= " AND "; } $where .= "b.DueDate = '{$sdueDate}'"; } ... Or, you could set up a blanket condition in the SQL before you append $where - something like: $sql = "... WHERE 1=1 {$where};" As mac_gyver pointed out in his replies, there are other issues with the code you've posted (you're wide open to SQL injection, the query as written will throw a SQL error if no search criteria is supplied, there's a lot of repeated code, etc.), but it looks like the main cause of the specific issue this thread is about is SQL syntax and the logic behind building the WHERE clause.

Well that doesn't help anybody... Does it override error_reporting(-1), though? Because I'm fairly certain the code above should be throwing some errors - if nothing else than for trying to grab values from the apparently undefined $data array. It's been forever since I built development Ubuntu server and I can't remember if I had to modify the php.ini for error display.

Honestly, I can't see how this is working even on your local host. You're using mysql_real_escape_string() with mysqli() functions, which I'm pretty sure won't work. Admittedly, I could be wrong about that, but you really should be using prepared statements and avoiding the issue entirely. You're already halfway there by using mysqli() instead of mysql(), so why not go the extra step and save yourself work in the long run? Also, you're trying to pull array values from $date which isn't defined in the code you posted. You just try to grab a value from it on line 19. In addition, it's a bit misleading to call a variable $date when it includes student id and last login date - this obviously won't stop your script from running, but it will make life harder when you inevitably revisit the code later on. Maybe $student_login_info would be a better name for the array? Finally, do you have error reporting and display turned on, and what are the specs of the two servers?

Remove the error suppression (@) in front of the mail() call and see if that throws any errors for you. Maybe?

You technically can store the php statements and functions in a database and run it using eval(), but, as Ch0cu3r pointed out (with massive understatement, btw), it's really not a good idea. You'd be far better off either creating or using an existing CMS or framework (think WordPress, Yii, Laravel, Drupal, etc.) that includes the functionality you need to run, but in a safer and more controlled manner.

Could you not use DateTime() objects? function getAge($dob='1/1/1970'){ $today = new DateTime(); $dob = new DateTime($dob); $diff = $dob->diff($today); print("You are ".$diff->format('%Y years')." old"); } getAge();

Unless it happens in _admin_functions.inc.php, $Auth is not instantiated; hence the error about it not being an object.

@cyberRobot: Hunh. Interesting read - thanks! So, unless that's changed in the 5 years since that article was written, it's not possible to boldface visit links. However, you can change the color - you may have to get a bit more specific than the example code above ('li a:visited' or something similar). Off to do some research about the current handling of :visited links...

URL encoding in PHP. And yes, your example is almost correct: echo "<a target='_blank' href='".$url."'>This Is Example Text</a>"; Note the single quotes around the attribute values and the closing '>' on the opening tag, plus closing quotation marks on the string.

It looks like that's being routed on the recipient end. So what you've got is the equivalent of www.crime-statistics.co.uk?postcode=EX23 9DZ. Although I'm not sure this will work properly with the space - I should think it should be url-encoded.

Change line 32 from .visited to a:visited and see if that does what you're looking for. You want to use the native :visited pseudo-class instead of specifically setting a separate style on the element. The browser will read and understand :visited and invoke the rule when the user has followed a link to it's target page. I think that's what you're attempting to do.