requinix

What is "etaDate"? According to the code.

Put the spinner in the place where the content is going to go, initially hidden, then unhide it when the button is clicked.

That is the correct answer. Why do you not want to do it?

Pretty sure nobody has an email address 65,535 characters long. Nor 150 either, for that matter. The technical limit is 320, but if you find someone complaining that their 151-character long email address isn't working in your system, you can deal with it then.

I don't think I understand. Are you suggesting there's at least one other equally-valid solution besides increasing the length of the column? Why is it even limited to 32 in the first place?

Not if you don't show the controls.

<embed> is so 1990s. Use <audio>.

Ugh. That's really not that great. So the "stuff up until the next single quote" I said won't work because it'll stop just before "King". Only other option is to match anything, but be "ungreedy" about it: meaning to match as little as possible so that the regular expression can keep going. Immediately after that comes the closing apostrophe, then letters and an equals sign. That last part won't match when it hits "King", so the engine will go back and match Nat + King. Then it won't match again with Cole, so it'll finally go all the way through "Song" at which point everything will work.

What about that? If you're responding to my thing about apostrophes, I don't see any in there. Besides the ones used around the StreamTitle and StreamUrl values. I meant a title with an apostrophe in the value, like... maybe "Frankie Carle - Ridin' High, Vocalion". On that note, the guy's name is apparently Frankie Carle.

By the way, you should probably find yourself a stream that has an apostrophe in the title and see what the corresponding StreamTitle looks like.

I'm thinking a regular expression that matches letters + '=' + single quote + stuff up until the next single quote + single quote.

If you know what JPEG compression is then I would expect you to know that JPEGs are already compressed. If you're looking to vary the degree of compression then take a closer look at imagejpeg()'s third argument. The one you have set at 75.

What do you think "compressed" means? What would an "uncompressed" JPEG be?

Fixed.

If all you want is the isokresult then you can get it... well, I won't say "easily" because SOAP just loves using namespaces, but it is a one-liner. Kinda. Don't need XPath. (string)$xml ->children("http://schemas.xmlsoap.org/soap/envelope/") // switch to soap namespace ->body // <soap:body> ->children("http://tempuri.org/") // switch to this isokwhatever namespace ->isokresponse // <isokresponse> ->isokresult // <isokresult> (still in the isok namespace)

Yes, by all means, continue using a debugger that has clearly been abandoned and at a minimum does not work with any supported versions of PHP. It's definitely better for you to stick to the things you feel most comfortable with, even if that means working with a programming language that stopped receiving meaningful updates almost three years ago. It's not like the tech industry is constantly growing and evolving. It's unfortunate that Xdebug is too "lame" to support things like step-by-step debugging or code profiling or code coverage reporting. Really makes you wonder why anybody uses it at all, doesn't it? I bet if you searched Google for ways to debug PHP you wouldn't find a single result recommending Xdebug.

Forget Zend Debugger. It's three years out of date and four releases of 7.x behind. Use Xdebug like everyone else.

Then yes: it is possible for someone to hijack your contact form to send spam or whatever to any address they want, through header injection with $contact_name and/or $from.

After you fix the SQL injection problem with $event, The error message means your query failed because of a syntax error. Try running the query yourself manually to see what the error is.

Secret means secret. It does not mean you should post it publicly for the internet to see. Tell Google you want to revoke/delete these credentials and create new ones.

Here's a list of all the things I can see that should be changed: 1. filter_spam() takes its argument by-reference. It does not need to use references. Don't pass variables by reference. 2. The regular expression to preg_replace (in filter_spam) is incorrect. Check the syntax. 3. You cannot trim nothingness from a string. 4. The "SERVER" superglobal variable is supposed to have an underscore in its name. 5. Same for "POST". 6. Variables need to be set before they can be used. Make sure that no matter what path the code follows, the variables you need to use are being given some value beforehand. 7. $sent_show_response = $sent_show_response is pointless. In addition, 8. Security is not about throwing str_replace and preg_replace and filter_var and trim and whatever other functions you can think of at your input. You need to understand what each one does, why you should use them, when you should use them, and whether they should be here too. 9. You have two sanitization functions that do similar things. You also have inline code that repeats a lot of the same things. See also #8. 10. The code is very poorly formatted. Especially the last part. Isn't it hard for you to read? 11. You've invented some form of cheap CAPTCHA. That rarely ever works well. Poor security is worse than no security, so remove it. If your form starts getting abused then you can worry about adding *real* CAPTCHA to it. Finally, 12. Don't do any of the above yet. 13. Find your local php.ini and change two settings: make display_errors=on and error_reporting=-1. Restart your local web server. 14. Then try using your page as it is now. See what errors you get. Try with proper inputs. Try with a short message. Try with a bad email. Try every possible scenario you can think of, note what error messages come up, learn what they mean, and fix them. The point of that list is not to say you're doing things wrong. The list is to show you that thinking about people hacking your form is admirable and generally good but you're too early for it. If you're new to PHP then you should learn the most important parts of it first with a little bit of security here and there as it comes up. Because it's very hard to learn about code security when you're not familiar with code in the first place.

And what I'm saying is, that code you posted, it does not work correctly. Fix the code so that it does work correctly, so that it does what it's supposed to do when you enter in (safe) information, and then we can worry about whether it's safe.

Worry about that after you've made sure that it actually works.

There is no "shell_exec" php.ini setting. Not unless your hosting provider is doing something special. I take it you're ignoring what kicken and I said and just going with what you thought the fix to what you thought the problem was?

Yeah.