requinix

Sometimes PHP does unexpected things when you give it relative paths. To be absolutely sure you have it right, construct an absolute path using __DIR__ or the DOCUMENT_ROOT. include __DIR__ . "/../config.php"; include $_SERVER["DOCUMENT_ROOT"] . "/Directory/config.php";

You can do whatever you'd like on the frontend (like return the minimum price with the rest of the data so the UI can perform validation), but you have to verify the data on the backend too. That means making sure you meet two requirements: 1. All necessary information gets passed to the server so that it can determine what that minimum value should be 2. Each piece of information itself also needs to be validated that it is acceptable Consider this: Say you pass the form data as well as a hidden input for each minimum price. That does what you need, except it doesn't meet the second requirement: you can't validate that the minimum from the form really is the correct minimum. Taking a step backwards, instead of the minimum you have the form send the product. Like it's doing. The server will be able to look up the minimum from there, but you also need to validate the product. Which actually you should be doing already, so that shouldn't be surprising. So in summary: return the minimum through your AJAX so the UI can perform client-side validation, then in your PHP use the product information to look up the minimum value and then re-validate.

Privacy Policies are about what data is collected and how it's used. Terms of Use are for basically everything else.

Instead of trying to print it yourself, use print_r() or var_dump(). They exist specifically for this purpose.

Well, the first problem I see is that you're storing two rows for each message. That's a lot of duplicate data. You only need the one: isRead only applies to the receiver, and isStarred and isDeleted could be handled by using two columns.

Look in the database to see what rows there are. Look at who is the receiver, who is the sender, and whether a message is read or unread. You should be able to spot something wrong with the data. The question ended up in the code. Problem is something to do with unread counts.

Then core dumps aren't working yet. A backtrace is what you get from gdb when it looks at a core dump, or sees the crash as it happens. Okay, try this: stop php-fpm, set it up to spawn only one child, then use gdb like $ gdb `where php-fpm` (gdb) set follow-form-mode child (gdb) run Then crash PHP and see if gdb can catch the segfault. If so, post the output to (gdb) bt

That code doesn't look quite right. Try again?

For me to have any chance of telling you what's wrong, you're going to have to describe what "doesn't work" means. It's not like I'm there watching over your shoulder as you try to run it.

To test whether you can get a dump, try crashing PHP: $ php -r 'posix_kill(posix_getpid(), SIGSEGV);' Authentication system. That error is something you should look into. --enable-debug keeps more information in the PHP binary that makes backtraces more useful than without. You don't need it to generate a coredump or get a backtrace. What the backtrace can hopefully tell us is a general indication of where the problem happened - maybe it was within PHP, maybe it was within php-fpm, maybe it was from an extension, that sort of thing. That's at least a first step. Hopefully don't need the extra information in a debug build.

You do it by calling trim(). That's really all there is to it. It is, but don't do it. You're talking about modifying $_POST in place and that's rather strongly frowned upon. trim() the value just before you need it for a query. Using the array to hold the modified values, instead of individual variables, is totally fine.

PHP is going to use the default shell, but first let's see if the shell really is the source of the problem.

Oh shoot, you're right. Sorry. 1. If there are any errors running the command, the shell is sending them to /dev/null and you won't see them. Don't do that. Keep the 2>&1 redirect but remove the 1>/dev/null so you can get output. 2. exec() only gives you the last line of output. Use another shell function that will give you all output.

Copy and paste the command that was outputted into your terminal and see what it does.

You probably need root to change core_pattern, so echo '/tmp/coredump-%e.%p' | sudo tee /proc/sys/kernel/core_pattern You need root at the moment you try to open core_pattern for writing. echo> only works if you're running as root in the shell (since the shell is what tries to open the file), and sudo echo> will only run the echo as root (which won't do anything). If you can reproduce the crash with a CLI command then that's easier. If not, get the core dump and give it to gdb.

And learn about $_SERVER.

You should spend some time learning about... well, the basics. Then you should be able to see what's wrong with what you're trying and know what the correct syntax is.

No.

PHP can recommend a Save dialog by using Content-Disposition: attachment. Which you're already doing. Otherwise it's up to the browser.

You cannot overwrite or delete a file from the client's computer. The user has to tell their browser that they want to overwrite, and that means a Save dialog.

cron to run your script at the designated times, mail() or some emailing library to send the emails.

An Access Denied message suggests they have some sort of system in place to prevent the sort of thing you're doing. Are you sure the website can't help you already? Does adding it to your favorites do anything special? Are the sales you're talking about the sort of thing that would be listed in their weekly ads?

If you want each message then you need to query for each message. Not each message per recipient. The simplest solution is a query in a loop. "A query in a loop" is almost always wrong, and is always the least efficient solution, but it is quick so you can optimize later. Query for the messages. Set up a prepared statement for the recipients. For each message, run the recipient query and deal with it as you see fit.

Okay, no documentation. What's the Java code on the other side of the socket?

PHP should almost never segfault. Can you get a backtrace?