kicken

You can't just take one figure as reality. Look at some of the other tables on that same page and you'll see that IE and Chrome seem to be roughly equal in their share around 30%. That said it doesn't make a huge difference which browser a person is using these days. All the major browsers work about equally well for most things, it's only when you start getting into cutting-edge stuff that you run into issues. There's a lot of libraries out there also that will handle differences for you for the most part also so just make appropriate use of them and it should be a snap to get things working cross browser.

Change this: if(!$rs=mysql_query("SELECT tblRestaurants.RestName, tblLocations.CityID, tblLocations.AreaID, tblLocations.CuisineID, tblLocations.RestID, tblRestaurants.RestPage, CONCAT(tblLocations.StreetNumber,' ', tblLocations.Street) AS Address, tblLocations.Phone, tblLocations.Price, tblLocations.Rating, tblDetails.DetailName FROM tblRestaurants INNER JOIN tblLocations ON tblRestaurants.RestID = tblLocations.RestID INNER JOIN tblLocDet ON tblLocations.LocationID = tblLocDet.LocationID INNER JOIN tblDetails ON tblLocDet.DetailID = tblDetails.DetailID WHERE tblLocations.CityID='16' AND tblLocations.AreaID='131' AND tblLocations.CuisineID='3' AND tblDetails.DetailName='$DM' ORDER BY tblRestaurants.RestName ASC ")) { echo "Cannot parse query"; } To this: $sql = "SELECT tblRestaurants.RestName, tblLocations.CityID, tblLocations.AreaID, tblLocations.CuisineID, tblLocations.RestID, tblRestaurants.RestPage, CONCAT(tblLocations.StreetNumber,' ', tblLocations.Street) AS Address, tblLocations.Phone, tblLocations.Price, tblLocations.Rating, tblDetails.DetailName FROM tblRestaurants INNER JOIN tblLocations ON tblRestaurants.RestID = tblLocations.RestID INNER JOIN tblLocDet ON tblLocations.LocationID = tblLocDet.LocationID INNER JOIN tblDetails ON tblLocDet.DetailID = tblDetails.DetailID WHERE tblLocations.CityID='16' AND tblLocations.AreaID='131' AND tblLocations.CuisineID='3' AND tblDetails.DetailName='$DM' ORDER BY tblRestaurants.RestName ASC "; if(!$rs=mysql_query($sql)) { echo "Cannot parse query. <p>The error is: ".mysql_error()."</p><p>The query is:<br><pre>{$sql}</pre></p>"; } Then post back with what it says the error is along with the query text it shows.

We don't know what $DM = implode(',',$selections); is, thus we can't get an accurate picture of what exactly your query is. That is why you were asked to: You need to take your query text and echo it out *AFTER* your variables have been substituted into it. That way you and we can see what the final query being sent to mysql actually looks like.

Don't use one insert per row. Build up a multi-row insert query and use that instead. How many rows you can do at once will depend on how big they are as there is a limit to how large the query can be (around 16megs by default I believe).

The only "risk" I can think of that you may be taking about is someone monitoring your clipboard and taking the code. If you've got a bug on your computer doing that, you likely have bigger problems to worry about. There's nothing wrong with copy/pasting your code around from editor to editor or whatever.

Cross-origin resource sharing only applies to javascript, not PHP. I'd say that most likely the issue is that your host has a firewall enabled which is preventing your script from connecting on that port.

You can do what you want and still have them in the same form. Just use a bit of PHP to pre-select whatever the currently selected option was for each select box. <option value="%" <?=($colorselect=='%')?'selected="selected"':''?> >All</option> <option value="Red" <?=($colorselect=='Red')?'selected="selected"':''?> >Red</option> ...

Setup a network drive and mount it on both servers. You can either do this through a third server just to store the images or use one of the existing ones as the base.

Make both select boxes part of the same <form> </form> tag, that way they both get sent when you submit the form.

Your script is generating output prior to your call to session_start(). According to the error message, this output is being generated by the script /homepages/my_WEB - published/contact.php at line #3. Headers and cookies have to be sent prior to any other script output. Output consists of anything that would be sent to the browser, even blank lines or spaces before your opening <?php tag would be counted as output. You need to figure out where the output is coming from, then re-structure your script so you call session_start() prior to that output.

Browsers will typically unencode url's when displaying them so that it's easier to read a url. You just need to view the source and you'll see it properly encoded.

You just messed up. You're not decoding the proper value, your decoding a string with a few extra characters. If you split things up and add a few more echo's you can easily see that: $encoded = base64_encode($a); $pass = randLetter() . $encoded . randLetter() . randLetter() . randLetter(); $stripped = substr($pass, 1, (strlen($pass) - 2)); $db_pass = base64_decode($stripped); $final = substr($db_pass, 0, (strlen($db_pass) - 1)); echo 'Original: ' . $a . PHP_EOL; echo 'Encoded: ' . $encoded . PHP_EOL; echo 'Padded: ' . $pass . PHP_EOL; echo 'Stripped: ' . $stripped . PHP_EOL; echo 'DB Pass: ' . $db_pass . PHP_EOL; echo 'Decoded: ' . $final . PHP_EOL; Produces the sample output: Original: Tranvaj889 Encoded: VHJhbnZhajg4OQ== Padded: cVHJhbnZhajg4OQ==lN3 Stripped: VHJhbnZhajg4OQ==lN DB Pass: Tranvaj889 M Decoded: Tranvaj889 Notice how your encoded value is VHJhbnZhajg4OQ==, but your trying to decode the value VHJhbnZhajg4OQ==lN? You're only stripping one of the three characters you appended to the end of the string. So you are right, the -2 shouldn't be -3. It should be -4 to take off all three characters. There's no need to be doing a substr on the result of the base64_decode either.

rawurlencode isn't there for protecting sensitive data, it's there because some characters are invalid in a URL and therefore have to be encoded. For example a space character needs to be encoded as either + or %20. That code works fine, and outputs: <a href='?page=home&g=Battlefield%203'>BF3</a> If your expecting something else you'll have to clarify what it is you are expecting. @Jessica echo actually accepts multiple arguments so doing echo $a, $b, $c is essentially the same as echo $a.$b.$c; but saves having to perform the concatenation step.

Because you're running two separate and independent checks. Your check for the user is not connected in any way to your check for the security number. if($sec_no == ''){ ... } if($uname == ''){ } Those are separate independent if conditions, both will run. You could change the second if to an else if which would cause the checks to be serialized so you'd only get back a single error at time, as in: - if the security # is empty, show just that error - otherwise if the username is empty show just that error - otherwise check the valid user Alternativly you could only check the valid user if the first two validations pass. Use a flag to keep track of that. eg: $hasErrors=false; if($sec_no == ''){ $hasErrors=true; ...} if($uname == ''){ $hasErrors=true; ...} if (!$hasErrors){ //check valid user }

You can use MySQL's UNIX_TIMESTAMP() to convert mysql's DATETIME or TIMESTAMP columns into a unix timestamp when you select them which you can then pass on to your javascript code.

Check /etc/motd. That file is displayed after login. If the drawing is not in there it is likely being generated by a program that is run during the profile setup.

They are not really a PHP Prepared statement, just a Prepared Statement. Basically what they are is a way for you to separate the values you need to use in a SQL query from the query itself. You can sort of compare them to a template like you'd use to separate your PHP from your HTML. Within the query text you just input placeholder values using either ? or :name style parameters. For example: $sql = 'SELECT userId FROM users WHERE username=:user AND password=:pass'; Then within PHP you prepare that sql to generate a statement. How to prepare and handle the statement depends on which DB access api you're using. I'll assume PDO for the rest of this example. //$db is an instance of PDO $stmt = $db->prepare($sql); Once you have the statement object you then bind your desired values to the placeholders you put into the query: $stmt->bindValue(':user', $_POST['username']); $stmt->bindValue(':pass', $_POST['password']); Finally you have to execute that statement which actually sends the SQL and the values to the server so it can run it and give you back results: $stmt->execute(); Now, the reason why this is better and prevents SQL injection is because the values are always kept separate from the SQL text. They are not combined into a single string at any point (exception is if you use emulated prepares w/o PDO which you should avoid if possible). Gonna stretch a bit for an analogy here, can't think of a better one, but think of it like you were selling someone a piece of furniture. The older put the values into the SQL method would be like you selling someone the furniture pre-built. If you built it incorrectly then when they try and use the furniture it may break. How badly it break's depends on how badly you put it together. Going the prepared statements method on the other hand would be like instead selling them all the parts they need along with a nice detailed instruction booklet on how to put it together properly. They end up with a nice sturdy piece of furniture. When the query is prepared it is sent the SQL text and parses it, figuring out how it wants to execute to the query and where it needs to use user-defined values. When you execute the query then you're sending the SQL server the actual values you want it to use when executing the previously prepared query. As it executes the query whenever it gets to the point where it needs a value it will look up the value it needs from the values sent to it.

Know that such a task is not really practical, especially with an upper limit of 14 letters. With 14 letters you're looking at 14-factorial combinations (roughly 87 billion). Aside from the time it would take to generate that many combinations, in order to store all of them if you wanted to do a query would cost you 1.1 TB of space. Querying all the dictionary words and checking against them as you generate each combination would cut down on the memory requirement, but you'd still be looking at a fairly substantial time investment just to generate the combinations. Something that would probably help to find possible words is to first check for any letter combinations that create common letter groupings, such as 'er', 'ing', 'tion', 'ed', etc and then search for dictionary words containing those combinations. Then you can filter the dictionary words based on whether or not all the letters for the word are present in the available letters list.

For what it's worth, including the input within the label tags is valid, and also eliminates the need for the for attribute as the relationship is then implied by the structure of the html: eg: <label><input type="checkbox" value="y" name="agree"> Yes I agree to the terms</label> will work to set the text as a label for the agree checkbox. I structure my forms like this a lot since it reduces the need for both the for and id attributes most of the time in my cases. @DBookatay: Here's the deal with checkboxes, either they are present or not. So what you need to do is check if the box is checked. If it is you add it's name/value pair to the data string. If it's not you omit it entirely (rather than just set it empty like with a text box). That is going to boil down to code roughly like this: Eg: var checkbox = $('input[name=master_plan]'); if (checkbox.is(':checked')){ data += '&master_plan='+escapeURIComponent(checkbox.val()); } Now, unless there is a particular reason why you're trying to grab these fields individually and build your data string, since you are already using jQuery you may as well just use it's serialize() method. This method will go through the form and return a url encoded string in pretty much exactly the same manner as the browser would when you submit a form. That would take your code down to just something like $(document).ready(function() { $('#submit').click(function () { var name = $('input[name=name]'); if (name.val()=='') { name.addClass('hightlight'); return false; } else name.removeClass('hightlight'); var email = $('input[name=email]'); if (email.val()=='') { email.addClass('hightlight'); return false; } else email.removeClass('hightlight'); $('.text').attr('disabled','true'); $('.loading').show(); $.ajax({ url: "process2.php", type: "GET", data: $(this.form).serialize(), cache: false, success: function (html) { if (html==1) { $('.form').fadeOut('slow'); $('.done').fadeIn('slow'); } else alert('Sorry, unexpected error. Please try again later.'); } }); return false; }); });

The point trying to be made is that your code: $email = $_POST['someone@drpgraphicdesign.com']; $subject = $_POST['BOB -' . $name . 'has submitted a ballot']; Is attempting to look up the value of inputs in your form that look like: <input type="text" name="someone@drpgraphicdesign.com"> <input type="text" name="BOB - something has submitted a ballot"> Which is almost certainly not what you want. You need to just assign $email and $subject to the string values, not try and lookup something in the $_POST array. $email = 'someone$drpgraphicdesign.com';

Because fetchAll returns an array of rows, yet you're trying to use it as if it returned just a single row. You want to use just fetch instead.

The only thing that might change in how you call the function is you may need to pass in a handle for the PDO connection, if it's not available via some other means (ie class variable). You just have to update the code within it to use PDO rather than the mysql_* functions.

SELECT articles.id AS article_id, comments.id AS comment_id, comment , COUNT(DISTINCT comments.id) AS count_comments FROM articles LEFT JOIN comments ON comments.aid = articles.id That is the query that your COUNT() is applied against. That query has no GROUP BY clause to define how the groups need to be created. Basically you applied your GROUP BY to the wrong query.

I've contributed to two different campaigns on IndieGoGo: - Let's Build a Goddamn Tesla Museum - StickNFind- Bluetooth Powered ultra small Location Stickers I don't regularly go there and seek out things to contribute too but sometimes I hear about something and decide I like it. As for their future, their volume may decrease a bit as the coolness wares off but I wouldn't consider them a fad really, and I think they will be around for quite a while. For as many projects as I have seen that seem like crap there are just as many that I find interesting. Whether or not I actually contribute anything depends mostly on how much I would like said project to succeed and whether or not I happen to have spare funds at the time.

It'll be around for a long time.