.josh

First, you can't assign echo to a variable, so remove that. Second, htmlentities will make it to where the browser will render the tag as text instead of an actual tag. So on the page, it will show the actual tag, e.g. <strong> but if you rightclick view source, You will see e.g.: <strong&gt This is mostly useful for coding sites that want to show raw html code in a code box so that the browser won't treat it as a real html tag to render. So if you want the browser to render it, remove htmlentities $open = "<strong>"; $close = "</strong>"; $message .= 'Cushion Refilling Service: ' . $open . $_POST['cushion-refilling'] . $close . "\n\n"; echo $message;

This is a bad way to look at it. You are judging the past by present day standards. By that logic, tomorrow you'll be looking down on the standards of today that you are implicitly endorsing by this statement. You need to put yourself in their shoes, with what they had to work with at the time. "Best Practice" is often subjective and highly dependent on current state of technology, current industry standards, current laws, etc.. These things and many other factors change over time and that affects what is considered "Best Practice". Also, I would point out that most of your "pretty 1-liners" you are almost certainly alluding to are really wrappers for frameworks built upon frameworks that require a lot more coding under the hood to make it possible, so that "3000 lines long" statement is especially laughable. And even if we can all agree that a certain piece of code is bad even by proper standards of the time.. you still have to consider other factors, e.g. what were the internal resources/policies behind it? For example, time and time again I see devs of clients publishing bad code and that was a direct result of their hands being tied because of "office politics." Some people choose to sit on a pedestal and claim they'd never compromise for things like that. Others decide that hey, they gave their 2 cents, that's on the boss, sticking to principles don't pay the bills. And chances are, these sort of factors will never be fully known to the public. I guess my overall point here is, don't be so quick to judge a piece of code unless you are judging it within its context. That doesn't mean "leave it be" or "it's okay, don't fix it". If it's not satisfactory to current standards, do something about it. Just save the pretentiousness and snobbery for something else. I echo maxxd. To me, any versioned code that is not the most recent (production) version is considered legacy. Moving from 1.0 to 2.0 could have involved adding new features and nothing in 1.0 version actually changed, so why should 1.0 be considered ugly or bad code? New versions aren't always about fixing bad, broken or outdated code; it's also about adding new stuff, changes due to "politics" or policies, old or new technology, etc..

366 posts is about 365 more posts than most registered members post.

probably because you aren't putting it in code tags. wrap your code in .. tags. If that doesn't work, post it on paste.ee or pastebin.com or jsfiddle and post link to it.

Your problem may actually run deeper than scope. It really depends on what the rest of your code is. For example, even if you remove the var to put it in global scope, you also have a timing issue to deal with, because you are setting it within an ajax callback. So that 2nd alert() isn't really gonna work, even if you make the var global scope. Consider this: $.post(url,data,function(response) { iserror=true; }); console.log(iserror); That $.post is an AJAX call - asynchronous. That means when the request is made, the browser isn't going to wait around for it to send a response back before it moves on to the next code to execute. So even though you're setting iserror on a global level, it's not going to actually get set until the AJAX request receives a response. This could take 50ms or 10s, who knows. Meanwhile, the console.log has already executed. So basically, you need to restructure your code to do something with iserror from within that callback, whether it be moving your code there or wrapping it in some function and calling it from within the callback. $.post(url,data,function(response) { doSomething(iserror); }); function doSomething(iserror) { console.log(iserror); } Point is, you need to restructure your code to have it execute when the callback is executed.

+ is url encoded version of a space. You need to urlencode your token so that it's not decoded to a space when someone clicks on the link. consider this: $x = "foo bar+foobar"; echo urlencode($x); // output: foo+bar%2Bfoobar notice how the space got encoded to a +, but the + got encoded to the encoded value of %2B. You want the generated token to look like the latter, so that when a visitor clicks on a link, it will decode %2B to a literal + instead of decode + to a space.

I would say you need to remove this expectation. Bottom line is there's no way to guarantee what you are sending out is received, so it's pretty silly think that you can achieve this, and it's false advertising to claim that you can. Also, trying to get around people marking your emails as spam so that they can receive your emails shouldn't be your problem. If the client wants to receive emails, they should provide you with an email that they won't block you from. If they are worried that their employees will somehow prevent them from seeing what you send them, that's THEIR problem, not yours. If you don't already offer this, I'd make the info available on my site for them to login and view. Also make viewable a log of when emails were sent out. And then tell them if they don't receive the email, that's on them. It's not your job to ensure their employees aren't blocking your emails so the boss can't see them.

There are a lot of ways to skin this cat, but ultimately it boils down to sorting multi-dimensional data. Now, this can take the form of a multi-dimension array, such as: var students = [ ['Joe',20], ['Jane',19], ['Bella',22] ]; But having each student represented as an object may be more useful to you in the long run, so here is an example of having an array of objects: // this is a custom function to sort by, which we will pass to the native Array.sort() method // first argument is the property name to sort by (e.g. 'age'). by default it sorts ascending // but you can pass true or any truthy value as 2nd arg to make it sort descending function sortBy (p,o) { if(!p)return; var o=(o)?-1:1; return function (a,b) { var r=(a[p]<b[p])?-1:(a[p]>b[p])?1:0; return r*o; } } // here is a simple Student "class" to make each student as an object. // since this is an example, it doesn't really do anything except for // set properties for the student (name, age, etc..) function Student (props) { for (var p in props) { this[p] = props[p]; } } // here is our top level array var students = []; // now lets put some student objects into the array students.push(new Student({'name':'Joe','age':'20','hairColor':'blonde','eyeColor':'black'})); students.push(new Student({'name':'Jane','age':'19','hairColor':'red','eyeColor':'green'})); students.push(new Student({'name':'Bella','age':'22','hairColor':'black','eyeColor':'gray'})); // here is an example of sorting by age: students.sort(sortBy('name')); // and to show that it has been sorted, loop through the students // and just dump the student object to the js console for (var i=0,l=students.length;i<l;i++) { console.log (students[i]); } /* js console will look something like this: Student { name="Jane", age="19", hairColor="red", more...} Student { name="Joe", age="20", hairColor="ginger", more...} Student { name="Bella", age="22", hairColor="black", more...} */

these types of questions come up so often, maybe we should make a sticky explaining it..oh wait...

a) Let me remind you that you are responding to a post that was posted several years ago, when this stuff was a much bigger issue. b) I work in the web analytics industry. I look at web stats all day long. And I talk to corporations all day long about those numbers vs. their web sites and the user experience (UX) of their sites. What I see is the exact opposite of your thoughts about webmasters still striving to cater to <IE8. I have been fighting for clients to ditch IE6/7/8 support for years and they are only just now starting to come around since earlier this year, only because of Microsoft ending support for it. So the ball is rolling, yes, but I'm sorry, I disagree with the notions that web devs are in a place where they can just completely forget about supporting it. If you don't believe people are still catering to IE6/7 then I don't believe you have much experience dealing with corporations, and possibly even clients in general. I don't doubt for a second there are plenty of random no-name sites and even some "cutting edge" sites that are "with the times" and cater to younger crowds. And of course it's easy for people to upgrade. And of course there's no reason for them not to. But the stats show that there's still a fair chunk of people that don't, and nobody wants to throw away potential revenue, even if it's 1% of users. Also, I'm not saying there isn't a non-jQuery or non-framework solution for things. That's just silly. All I'm saying is when you have a complex site doing complex things, and having to deal with making sure it works for the widest audience possible, you will more often than not save yourself a lot of time by using a framework like jQuery. Look, I'm done arguing with you about this. As I mentioned in a previous post, I used to be hardcore on the other side of the fence, absolutely shunning frameworks as extra bloat used by people who can't be bothered to learn "real" javascript. I know exactly where you're coming from because I've been there, so I know there's little point in trying to argue with you about it.

Frank, that's not a fully cross-browser compatible version of ajax for <IE8. Most people still strive to support IE6 and IE7, even though Microsoft stopped officially supporting those versions (and IE8) earlier this year (April 2014 - XP no longer supported, so by extension <IE9 no longer supported). Also sidenote: you gave a simple example of what to do with the response. That example isn't cross-browser compatible either. And in reality, most people use ajax in conjunction with more complex code, from event handlers to selectors, notwithstanding applying previous stuff to whatever dynamically generated content is likely to come from the ajax call. All of that stuff must be applied in a cross-browser compatible way.

Also wanted to mention that I see in your original code you are using intval. FYI ctype_digit expects a string argument, so if you are converting it to an integer type then you are going to get unexpected results from ctype_digit. So to be clear, do not cast/convert the value as an integer before using ctype_digit. Posted variables should always be a string type, so you don't need to do anything special before using ctype_digit, but if you really want to be explicit, type cast to string: // this should be okay.. if ( ctype_digit( $_POST['p1'] ) ) // ..but if you want to be more explicit if ( ctype_digit( (string) $_POST['p1'] ) )

There is a way to do that, yes. You can set the auto_prepend_file directive in your php.ini file. Note though that this will cause it to be executed on every request to a php script.

Yes, overall I agree with Psycho. Sure, it's exceedingly rare, but there is no legal limitation for a person's legal name being "O'Brian£$%^&*()". Famous example: The musician Prince, who at one point changed his name to some random symbol and consequently was referred to "The artist formerly known as Prince". More common examples which are very common, are examples that Psycho listed, as well as names with letters with accents and other symbols above them. And there are no legal limits to name lengths. Many people (especially Asians and Latin Americans) have extremely short names like Xo or Xu and can even be multiple with spaces e.g. "Jo Ra Xu" or "De La Hoya". So, the "best practice" is to only enforce an upper string length, even though there is technically no legal limitations to this either (but at some point you have to be reasonable for sake of storage limits. e.g. it's not reasonable to have to allot a varchar(1000) field for surnames because of the 1 in a million person with a name that long).

On a sidenote, I wanted to point out a few things about your original regex: preg_match('/^[A-Z][\'|A-Z][-|A-Z]{5}/i', $surname) So firstly, you have this: [\'|A-Z] It looks like the intention here is to match for a quote or a letter. You used a pipe in there to signify this. That is not how character classes work. Character classes do not use a pipe for alternation like you do elsewhere in a regex pattern, because everything in a character class is essentially an alternation. So a pipe has no special meaning in a character class context. Which means your pattern would allow for a literal pipe in the name to be matched. Same thing with [-|A-Z]. On that note.. 2nd, you had [-|A-Z]{5}. {5} is a quantifier. It specifies how many of the previous to match. So you specified to match exactly 5 hyphens, pipes or letters. In your later posts, you show that surnames with more than 5 characters should match, so this is also wrong. The regex I posted above will allow for basically any length (minimum 1 char) to be matched. So technically my regex will match this: O'Brian-somereallylooooooooooooooooooooooooooongname There is not an easy way to limit how long it can actually be, given the rest of the regex. It is possible to both limit the total length and ensure there is only one hyphen but this will make the regex significantly more complex. The regex could alternatively be made to limit it and still be somewhat simple if we were to remove the restriction on how many hyphens can appear, but then that is not ideal either. So, overall, if you really want to limit the length, it would be a lot easier if you were to just follow up with a strlen check.

As Ch0cu3r pointed out, I said $ as in dollar sign not * as in star. Also, you still aren't being very clear about what you want to match, but in general, I am guessing what you really want here is to match for something like this: // Code $surname = "O'Brian£$%^&*()"; //$surname = "O'Brian-Stevenson"; if(preg_match("/^([a-z]')?[a-z]+(-[a-z]+)?$/i", $surname)) { echo "$surname <br>"; echo "This is a match"; } else { echo "$surname <br>"; echo "This does not match"; } ^([a-z]')?[a-z]+(-[a-z]+)?$ ^ matches for beginning of string ([a-z]') matches for one letter followed by an apostrophe ? makes that previous match optional [a-z]+ matches for one or more letters (-[a-z]+) matches for a hyphen followed by one or more letters ? makes that previous match optional $ matches for end of string Overall, this will allow for surnames with an O' or M' prefix (or whatever other letter, though I think O and M are the only ones out there), and will also allow for single-hyphenated surnames (multiple hyphens not allowed). This will NOT match for any special letters (e.g. letters with accents). This will NOT match for prefixes that have a space between them and the main surname (e.g. Mac Cartaine) This will match: Brian O'Brian Brian-Stevenson O'Brian-Stevenson This will not match: O'Brian£$%^&*() Brian-Stevenson-foobar Mac Cartaine Mac Cárthaigh

That only works if the parent page and child page are on the same (full) domain. If they are not, then the short answer is you cannot do it*, as this is considered cross-site scripting (google same origin policy). *The longer answer is there are ways around it, along the same principle as FB API but it is kinda complex and involved, though it's somewhat easier depending on what you're coding for. For example there is an html5 method that's a bit less convoluted.

I don't think you're being very clear about what you really want here but it sounds like you just need to end your pattern with a $

Create confusion out of expecting something more explicit? Are you serious? There is already confusion. The confusion is already there because of the language being loosely typed. Since you always argue about security, you should be arguing for this, not against it. When a person fills out a form, you expect them to fill certain things out in certain formats. Unless it is arbitrary data, you enforce those formats. And even then, you still sanitize them to a non-dangerous format. When you write a function, you write it to expect arguments. And you expect certain formats. And you throw exceptions or otherwise reject it if you don't. You expect this and you enforce it. Enforcing variable type is no different in principle. Sure, you make it "easier" on the person using your function to not have to worry about having to explicitly say "hey this is an integer" vs. "hey this is a string" but compare that to the work you have to do as the function writer to ensure that what you do with that "maybe string maybe integer" doesn't break your code. The irony of all this is if php were a strongly typed language, it would allow overloading which is more or less what you're already having to code for when you try to deal with an argument passed as different types. Loose typing only goes so far, and php itself fails at it for most of its own functions. You write a function that expects an array but then you have to write some logic in case someone passes a string since they only want to pass one array element. Can php automatically handle this? No! Many of php's built-in functions will do this internally, but many don't. Good luck figuring out which ones do and which ones don't. String-to-Array not a good example? How about failure to accept an integer instead of string. Go ahead and try if (ctype_digit(123)) see what happens. I am not wholesale saying loose typing is a bad thing, but in a world where code is shared and plugged into other code made by untold number of coders.. loose typing's philosophy of "just gimme whatever and i'll deal" doesn't help things. It hurts things. Standing up and saying "Hey you know what, this is what I expect you to give me" doesn't cause more confusion. It causes less confusion because there already is confusion because of it being loosely typed. There are many people, including some of the @php.net people directly in charge of advancing the language itself, who believe that php being loosely typed is its Achilles's heel. The single biggest benefit of loose typing is it allows for more rapid development of code. However, a lot of people feel it's one of the reasons php attracts noob programmers and why there is a lot of shit code produced by shit programmers out there. Which is exactly what you are always bitching about, so I find it odd that you are arguing for it.

I don't mean to be offensive but regex is one of the hardest things to master (in any language). If you managed that then I'm not sure how a couple of simple loops is troubling you...

Okay, sounds like a generator is what you want. If you aren't using php 5.5+ then you can achieve similar with an iterator.

what are you trying to do... are you trying to just echo out the value of only 1 column? Are you trying to put it into a db?

maybe script is timing out then? did you try increasing script execution time (or making it unlimited) ?

my guess is php is running out of memory, since you are putting each row into $in_data. Try increasing allowed memory in your php.ini file or better yet, restructuring your code to not hold more than 1 row at a time in memory.

I think for most of them, it's because php is their very first programming language, so they haven't yet learned best practices.