requinix

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.

Have you been able to shell_exec() PHP in some other way? Yeah, you've mentioned that. Lemme put this bluntly: For most servers, PHP running a website and PHP running from the command line are two different things.

Because PHP isn't installed as a command-line utility? Because it doesn't have the same extensions and configurations as the one running from the web? Because there are restrictions in place to prevent it from running correctly or at all?

How much do you care about good searches? The professional answer is to not use the database for it and to move to services like elasticsearch (which is free). It takes some setup work, and it's not trivial, but it's much better at handling searches than a regular database will be. But definitely don't do a keywords column. That's just not natural. (Tagging, on the other hand, is quite reasonable.) Are you having a specific problem with your searches? Or do you just want to learn more about it?

Is that relevant? Is there something in clearflags.php that can only possibly work from the command line?

Thoughts? Don't do that. Why do you have to run PHP code from a whole new process? It doesn't make sense. You're running PHP already so if you want it to do a thing then make it do the thing. Firing up new PHP processes for it is silly.

It might seem right but you're outputting invalid HTML. <select> </optgroup> <optgroup label='Support & Extras'> <option>On Site Support</option> </optgroup> <optgroup label='Licence'> <option>AllowME Multi Event Licence (Annual)</option> <option>AllowME Multi Event Licence (Quarterly)</option> <option>AllowME Multi Event Licence (2 Months)</option> <option>AllowME Multi Event Licence (Extension)</option> </optgroup> <optgroup label='Scanning Hardware'> <option>Long Range RFID Scanner</option> <option>Handheld Scanner</option> <option>Short Range Catering Scanner</option> </select> Does that look correct?

First you'll have to sort the results by the type. Because otherwise stuff will bounce between one type and another. Then you should probably sort by a secondary another field - I suggest the item name, since that's what the user sees. Really, most of the time you're running a query for data that gets displayed to a user, you'll want to sort by something. Even if you don't need anything grouped or sorted alphabetically, picking and sorting by a unique column (like an ID) guarantees that you'll get the same data in the same order every time. Anyway, when you have that sorting, your loop will need to know when the type changes. That means remembering what the previous one was. Get yourself a variable for it. Start it off empty. Inside the loop, if the current type doesn't match the previous type (and the first row definitely will not) then that means you need to start a new group. If there was a previous type then there was a previous <optgroup> already going for it and you'll need to close that out, then either way you start the new <optgroup>. Finally, you need to think about that last group. When the loop finishes you'll have been working on one group but the <optgroup> will still be open. So close that one out too.

You don't have to reinstall. They don't make the source code browsable on the internet for some reason, so it's not like you can go off to GitHub and grab the file, but at least they do support you downloading a few hundred megabytes (for the x86 version, whose index.php will be the same as the x64's) to grab one single file.

There shouldn't be any empty arrays... What's the code now and what do the arrays look like?

Considering how it will be extremely hard to know what the problem is without being able to see any sort of HTML or CSS, you should probably go ahead and post that URL.

That's the same code from before, right? The $cronograma array has data from both groups mixed into it. That means it will be hard to work with. What is the code you have to fill that array? Instead of putting everything into one single array, use multiple arrays. One array for each group. An array of arrays would be a good idea for that.

Which part? What code have you written so far and what problem are you having with it?

So... I'm right, then? You need those 4 pairs of start/end dates? What I said before about splitting the one array into two (one for each subject), then go through each array looking for the total=0 and total=34 dates and then for the total=34+time (that allows you to support any class duration instead of total=36 which only works for 2 hour classes) and total=68 dates.

Then it would probably work better if you had said something like "how do I translate the below equations into PHP code" instead of "PHP doesn't have a ln function so what do I do". What are PREBUN and POSTBUN and TIME and all those? Do you already have them set up as variables?

But aren't the subject dates different for each group? One goes from 09-21 to 02-01 and then 02-08 to 06-14, while the other goes 09-22 to 02-09 then 02-23 to 06-22.