requinix

Increase the sleep time a bit, switch the signal handler to SIGINT (I was mistaken before about SIGTERM), then run and ^C it. Or I may be out of date when it comes to signal dispatch. What I'm thinking of might not apply to async-dispatched signals.

No idea. Xdebug might have a tool that can help, but I would probably just go through the code and trace where the variables are being stored. Or at least being sent. But like I said in the other thread, don't use destructors as a shutdown mechanism. They're about dealing with memory and resources that were used by the instance being destroyed.

debug_zval_dump shows you refcounts, but the very act of passing a value into the function increases the refcount. The solution was call-time byref variables, but that was removed a few PHP versions ago. So the refcount isn't as accurate anymore and debug_zval_dump isn't really useful now. Xdebug provides something else.

Your editor is saving the file with a UTF-8 BOM at the beginning of the file. Tell it not to do that.

Don't download and install manually. Use your distro's repositories. They exist specifically so you can use them.

You cannot delete an object. Stop using it and PHP will delete it automatically. In your example code, $func is using $obj.

Don't do at all. ticks are old and fragile when it comes to signal handling. Use pcntl_async_signals like I posted. It will matter when you stop using ticks. If you don't know what zend.signal_check does then read the docs. Don't just guess at what it means. Stop what you're doing and learn about systemd services. Try without and see what happens.

And you restarted Apache? And there's nothing in Apache's or PHP's error logs - just the normal startup messages? If that's still not working then it's going to be some minor thing somewhere. Or you could just ignore it all and install from the repo.

I was on the phone, be patient. "w" should have done the job, but forget that code. The author doesn't know PHP. file_put_contents("logFile.txt", date("r")); That's all you need. If it's not creating the file then you're probably facing a file permissions issue; create the file yourself, change the permissions to 0666, and try running again.

It compilation didn't work then you wouldn't have an xdebug.so in the first place. Did you edit the correct php.ini or other settings files? Apache and php-fpm and php CLI all use different files. And any particular reason why you are doing all this yourself? If you installed PHP from Debian's repos then why not install Xdebug the same way?

So there's a small issue. If you just write when the server starts up, you can't actually know if it's still running. All the log really tells you is the last time it started - who knows if it shut down since then. But you say this is a server? Like an actual server running something you can connect to? Wouldn't the easiest way to know if it's running be to simply try to connect to it?

Can you be a little more specific than that? What kind of program? What starts and stops it?

Look here. Read and try to understand. It's a very small change. But you really don't want to do that. It means only one message will ever be in the file at a time. The most recent message. Everything else got lost. So forget that code. Where did it come from? Whoever wrote it doesn't know about PHP, and getting PHP code some someone who doesn't know much about it is a pretty bad idea. What problem are you trying to solve? In unrelated news, I edited your thread title to put a little more effort into it than you did. Please try to write something useful in there next time.

Is the extension enabled? Does the php.ini setting to enable it use zend_extension= and not extension=? Anything in the error log about being able to load the extension?

Destructors are about cleaning up resources used by the class and are not suitable as some sort of "shutdown" event. They're tied to variable and memory usage, not script execution. If you want to run some code when the service is shutting down then do exactly that: set up signal handlers as needed to allow your code to terminate gracefully, and/or use register_shutdown_function(). For example, <?php pcntl_async_signals(true); $running = true; pcntl_signal(SIGINT, function() use (&$running) { echo "Caught ^C\n"; $running = false; }); while ($running) { echo "."; sleep(1) && pcntl_signal_dispatch(); } (if you had problems catching signals then it's likely you were missing pcntl_async_signals) edit: ^C is SIGINT, not SIGTERM

Let me put it this way: Is $sql supposed to be a prepared statement or not?

There is no difference. I just posted the problematic code. For reference. Ideally you would take another look at it and realize what the problem is, but if not you, someone will.

$sql = "SELECT * FROM users WHERE email = $email"; $stmt = mysqli_stmt_init($conn); if (!mysqli_stmt_prepare($stmt, $sql)) { echo 'SQL error 2'; $my = mysqli_report(MYSQLI_REPORT_ERROR|MYSQLI_REPORT_STRICT); echo "- $my (2)"; exit();

Where the data comes from is completely irrelevant. All the PHP has to do is return the correct JSON. That part looks fine. How about the Javascript that makes the AJAX call? What have you tried for that?

If expires is a Unix timestamp (ie, a number and not a string), which is what date(U) suggests even though the placeholder says it's a 's'tring, then instead of CURDATE() it would be UNIX_TIMESTAMP().

What have you done for the AJAX stuff so far?

Not since the death of XHTML. <br> is correct. HTML does not do self-closing tags.

You're trying to call send() on a PEAR_Error object. That would be $smtp. Apparently, $smtp is an error. You should check what the error is.

Approach #2 sounds like #3, and they both sound like #1 but with more work. If the token is for a single purpose and it inherently includes the necessary information to determine what that purpose is then the token by itself has everything you need.

Okay, yeah, that's not really "overloading" as the rest of the software industry calls it. I didn't even remember PHP called it that. Creating properties and methods dynamically like that isn't a great practice, even if it is somewhat common in PHP. It can create unusual behaviors that are hard to debug. Try to avoid it. However, using __get/set/isset* as a means of accessing fake properties is alright. It's mostly a matter of using the -> syntax as shorthand for something else. Consider a Config class that loads data from a file. The pure OOP method of accessing that a value "foo.bar" would be like $config->get("foo")->get("bar"), but you could repurpose the -> operator for properties to allow $config->foo->bar. Neither "foo" nor "bar" should be defined as properties on the object because they're dynamic, so you implement __get to behave the same way as a get() method. In fact, very often a Config class will have both and __get calls get() - mostly because get() tends to support a default value, which you can't supply through ->. __call is similar in that you might need to call fake methods, but it's less common and I avoid using it. Methods are basically never the sorts of things that should be done dynamically and should only happen in rare cases, none of which come to mind right now. __callStatic is even rarer and is pretty much only for static singletons. * If you implement one of those then you should implement all three of them: __get and __isset are an important pair because getting values often includes checking if it is set first, and __get and __set should be a pair to keep consistency with how someone may use the -> operator (even if that means, for read-only objects, that __set always errors).