Adam

Here's an 8 page debate that describe it in a lot of detail, and eventually goes on to explain how to do it properly: http://forums.phpfreaks.com/index.php?topic=254277.0

Your templates should be logic-less. There's no reason to have to include PHP within a template. Take a look {{mustache}} as an example; simple tags allow for echoing variables, including partials and looping through data sets. You shouldn't need to do anything more in them.

Why? @Ricky55 I'm guessing given that you're not using a framework, you have some kind of 'master' include file? In there I would just construct an object with the user's language and a translation array (if not English). Then whenever you output text just pipe it through a method in the object: <p><?php echo $lang->t('Some text here.') ?></p> If the user's language is English, or your default language, it would do nothing but return the string. If another language it would attempt to look it up in the translation array. The array could simply be created from a JSON file: translations/fr.json { "Some text here.": "Certaines parties du texte ici." } (Thanks Google translate!)

Never mind.

Referring to it as "java", I'm going to guess you're not too fluent in JavaScript. jQuery is extremely popular and very easy to learn, I would recommend using that.

I meant, a click on the submit button, should trigger the submit event on the form.

Click will trigger first. When an event is triggered, it propagates up through the DOM tree. So when the click happens, it will be first matched on the input, but will then begin to travel up the DOM tree until it finds the form element with the submit event: http://jsfiddle.net/kdrxD/ In this 'chain of events', we could bind clicks to any number of elements sitting between the input and form in the tree, and each would be triggered from deepest element up: http://jsfiddle.net/XhXwu/ Not the bind orders too, they're completely irrelevant in this case. What I believe the spec I quoted before is saying, is that the events bound to elements further up the DOM tree that could be deemed the same action should trigger the same event(s). So a click on the submit event, fires the same submit event.

http://www.w3.org/TR/DOM-Level-3-Events/#event-flow-activation So yes, this is specified as correct DOM behaviour. I'm not sure when it was added, but it also existed in the previous spec (dated 31/05/2011). Specification doesn't mean it's supported across the board though. Given that there's still people using 11 year old browsers, for the sake of 5 seconds to switch it to the other, correct event, I don't see why you wouldn't.

Looks fine to me. The syntax error probably starts a few lines before, but only triggers the error there.

I didn't say your solution was invalid, I said the mark-up it produced was invalid. There's a certain amount of tolerance towards breaking standards 'to get the job done', but the reason the OP is having difficulty doing what he wants to do is because you're not meant to do it. That's why throwing together hacky code to get it working is frowned on. There's a reason for standards..

Works != valid.

@pseud That's invalid mark-up; you can't have a button within an a tag. @Techrits I don't understand why you want to open results in another tab/window? That's just going to annoy the user when they can't click back. If I want pages to open in a new tab I do it manually

Sounds like his girlfriend has been on holiday..

One other perspective to throw in is the product owner (or whoever decides the priority of a piece of development). The PO doesn't give a shit if it's running IIS5 on XP, or if there's a thousand hamster wheels running crazy to power the servers. If it works, it works. Of course ops would generally sort this but they'll need say-so from the man upstairs as well. You need to convince them, not us.

Really? Perhaps that's when the buzzword "AJAX" came about, but MS first introduced the concept back in 1999. The "XMLHttpRequest" object as we know it today came from Mozilla a year later.

That's because you're now effectively saying:

Can you post that?

Can you explain what exactly isn't working?

It was only meant to be an "FYI" on usability. In regards to your error, the code is really hard to follow, the indentation is all over the place. Looking specifically at the admin/user checks after fixing the indentation: if ($group_check == "Administrators") { if($pm_count >= '50000') { $error = 'The user you are trying to send a message to has 50,000 private messages, sorry but we cant send your message until that user deletes some of their messages.'; } } if($group_check == "Users") { if($pm_count >= '50') { $error = 'The user you are trying to send a message to has 50 private messages, sorry but we cant send your message until that user deletes some of their messages.'; } } else { mysql_query("INSERT INTO messages (reciever, sender, subject, message) VALUES('$reciever', '$user', '$subject', '$message')") or die (mysql_error()); $pm_count++; mysql_query("UPDATE authorize SET pm_count='$pm_count' WHERE username='$reciever'"); } Notice a problem? You're only executing the query when $group_check does not equal "Users". So it will execute it for admins, but the admin PM check won't have any impact on anything, escape perhaps the error shown later. Indentation makes a huge impact, I would certainly try to re-indent the code and you'll probably spot more logic errors.

So now the recipient replies by email instead? Possibly. Then again, it could be easier for them to delete a few messages and hit reply if the process is made simple enough. You can forgive a site for making you do that. Someone's email address may not be public though, which would cut off all possible communication in the first place. Not to mention you're punishing (for lack of a better word) someone who hasn't overloaded their inbox, by making them go to extra effort to get in contact with someone. It's a blatant usability no-no.

FYI .. I wouldn't restrict messages from being sent to people that already have too many, you're blocking communication. Just prevent the recipient from replying until they clear some of their backlog out. That way no information is lost, and the sender isn't likely to email them directly and cut out your service altogether.

Ah, yes. I saw the title saying "is it CSS or PHP?" and saw the link and skimmed the rest - TL;DR. Ha ignore me.

That website is actually done just using PHP for the logic. The integer "i" parameter passed in the URL dictates which image is shown.

By this I didn't mean "generally shouldn't be done all of the time". I meant, shouldn't be done in a "general way across every input". You can't sanitize every input as one. You're not sanitising the inputs by doing that.

Sanitisation shouldn't be done generally.