requinix

Except that can actually be a real problem. At least with PHP the rule is clear and narrow: only if it's the last statement.

Oh no, it wasn't you. I was stuck on an issue that needed changes at the VM layer for our instance. But that's just been dealt with, so I've finished the switchover. We're now (back to) running with Sphinx.

I've been trying to get Sphinx running for the last couple hours so that's been on-and-off broken. It's back to the slow method for now pending some tweaks to the server that I can't make myself. I specifically did it around this time because hey, would who care about search on a Sunday morning? Oh well.

If your database server is running on the same machine as your web server then that dumpfile thing is certainly a way to do it. But you won't be able to execute it from phpMyAdmin unless you can find a way to stop it from adding the LIMIT clause. What about phpMyAdmin's Export tab?

No, your query was select * LIMIT 0, 25 into dumpfile '/var/www/filename.txt' from calendarSpend a moment to familiarize yourself with the syntax for a SELECT query.

That's just the way the author(s) designed and wrote their code: ImageManager uses namespaces, FirePHP uses a singleton pattern, and mpdf doesn't use namespaces. Sometimes there's history behind the decisions, sometimes there's history to the project itself that predates some PHP features or best practices. Not really much you can do about it.

It is too late to sort $tags at that point. You need to sort it earlier: either in the database query you used, or with something else. Where is $tags defined and where are the values coming from?

Are you storing the dates as DATEs or VAR/CHARs? That's the type of the column. You need to be storing them as DATEs, and when you do you can use functions like MONTH, YEAR, and DATE_FORMAT.

Is this in a database?

Nervous breakdown? Nah, you're just not worth the time and aggravation.

PHP 7 changed how syntax like that gets interpreted.

It's fine for smaller projects, but like maxxd said it should do things like fix backslashes and test that the file exists. strtr() is much simpler. $fixed_class_path = strtr($class, "\\", DIRECTORY_SEPARATOR); I'm not going to argue with him if he comes in and says something, but "security checks" implies someone is able to craft an arbitrary class name and cause your code to execute it, and possibly also got an unauthorized file onto the server. But I'm not even sure it's possible to trigger autoloading on an invalid class in the first place. spl_autoload_register(function($class) { var_dump($class); }); $c = "!@#$%^&*()\\Abc"; class_exists($c); // no output new $c(); // no output

When PHP encounters a class that hasn't been loaded, it triggers autoloaders. If you called spl_autoload_register then all of those will be called in order until one of them causes the class to be defined (like through an include/require). Since your autoloader indiscriminately tries to include "classes/*.class.php", and $class is set to "LoginAttemptsLog", then it will try to include "classes/LoginAttemptsLog.class.php" using the normal rules for including a file with a relative path. If you tried to instantiate a "Site\LoginAttemptsLog" then the code would try to include "classes/Site\LoginAttemptsLog.class.php". What else is there to know... about the code you posted? About autoloading in general? PSR-4? Namespaces?

Given that nobody has said anything about your bug report, likely not. You could probably use a shell command (ie, unzip) as a workaround.

You should probably change some of the code.

So that part works. The email was sent, but your provider bounced it due to a reverse DNS issue: the forums are on a .53 server, the email is from @phpfreaks.com, but phpfreaks.com is still on the old .52 server. I'll change the email to be @forums.phpfreaks.com as a hack for now.

I don't know of any problems with on-site notifications. And I can't be sure but I think that "user adding users" thread may have been moved into MySQL from somewhere else. I just made a test thread. Did you get a notification for it?

There really isn't much more to say than that. The query is retrieving every single user in the database. That's slow. If you used a WHERE to only retrieve the user with the matching username then it would happen in less than a second (probably). Well, one more thing. Are you hashing passwords? It doesn't look like it. You need to.

I see two places in that code that deal with hyphens in strings. Try replacing them with underscores.

Yeah, known issue that I created when I rolled the IPB 4 upgrade back (we had Sphinx before, now it's vanilla MySQL searching). Since the upgrade won't happen soon I should at least get Sphinx back up and running.

Has anybody not been receiving HTML notifications... and then started receiving them again about two, maybe three days ago? If you do text-only then you probably weren't affected. I found a problem whose fault lies squarely with IP.Board* but apparently there was a workaround/fix coded into the forum so it was easy to deal with. I did some quick testing before and after and it should be fixed, but I haven't heard anybody else (except one person) mention not getting notifications so I'm not sure. And normally registrations drop to 0 when there are email problems but that didn't happen. (* They abused PHP's mail function in such a way that a security fix made to PHP prevented HTML emails from being sent. Insert rant about IPS/IPB here.) And by the way, if you ever have problems about emails - like are suddenly not receiving them anymore - PLEASE SAY SOMETHING! And that applies to anything that's clearly broken. IPB doesn't give any clear notice or warning about problems like that happening so I don't know if/when emails break. Which they've done multiple times before. AND in the course of posting this, I discovered that notifications were COMPLETELY BROKEN. White-screen-of-death-showing-a-500 broken. #@*&^%( vim. Fixed.

Are you getting a notification for this?

Did you read the error message?

To be clear, I'm not saying no. I'm saying I don't see a need for it: nobody is asking Ruby or Java questions. Yeah... There's always going to be an "other" forum because there's always going to be questions that don't fit into other categories. Reductio ad absurdum 1. Being easy has absolutely no bearing on any of this. 2. Why should there be a forum/a few forums for subjects that nobody (on this site) asks questions about? If there was a demand I'd have no problem with this, but currently there isn't a demand. 3. We are PHP Freaks. Would you go to RailsForum.com to ask a PHP question if they had a forum for it?

What about the Other Programming Languages forum we already have? It's a bit of a catch-22: we don't know how popular it would be to have one because people aren't really asking questions about them, but people aren't asking questions partly because we don't have one.