requinix

Digest authentication is rather complicated. Do you have any way to change the authentication system it wants to use? Perhaps to "Basic"?

Exactly my point.

Look carefully at the condition for your first rewrite. Have one redirect that does just the extension and one that does just the slash. (And in that order.) Don't try to do half of both at the same time.

So every time you log out, clear your browser cookies, blah blah blah, and log back in, you get the same token? Every time? And when you log in using PHP code they give you the same token as well?

Then that could be it. They're tracking client IP address with the token, and the token is not valid when used from another location. You'd have to generate the token from within PHP. Can't just copy and paste what your browser is doing.

Are you running PHP locally? That's the only thing I can think of.

At the moment the only thing I can guess is that you're updating all messages in a thread when you should be updating individual messages.

It seems right. Is there any more information you can get from the remote service? More detailed error message? An error log? Any logs at all?

Not unless you're a high-traffic site. You can't run PHP code unless something triggers it, and relying on people hitting your website isn't safe. If you need to run some code at a particular time then cron, or scheduled tasks on Windows, are the correct answer.

$tools is not a collection of tools. It is an associative array containing 2 or 4 values. foreaching over an associative array is almost always incorrect. if (isset($tools["good_quality"])) { printf("We have %s good quality tools at $%.02f each", $tools["good_quality"], $tools["good_price"]); } if (isset($tools["broken"])) { printf("We have %s broken tools at $%.02f each", $tools["broken"], $tools["broken_price"]); }

ping has absolutely nothing to do with web servers. It will tell you absolutely nothing about whether a web server is set up and configured properly. It might tell you whether the server as a whole is up.

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.