Recent Profile Visitors

The ugly truth is that's it's practically impossible not to leak this information. Even if you show the same message, anybody can easily tell the difference between the two execution paths by comparing the response times. Since modern password hash algorithms are expensive by design, there will be noticable difference between an invalid e-mail address (which is instantly recognized) and an invalid password (which requires the server to compute the hash).
You can make such attacks harder by designing the system appropriately, but this requires a lot of work, experience and complexity.
A much better solution is to not use the e-mail address as a user identifier at all. Make the user choose a public name which doesn't have to be protected. This may be slightly less convenient, but the e-mail address will at least be somewhat protected.

All versions up to and including 5.5 have already reached end of life, so the password API should now be available in all common setups. If the server runs some kind of long-term-support version, there's a compatibility library which works exactly like the API but supports PHP versions down to 5.3.
Sure. I just have my doubts as to whether this is really helpful. Threads in a forum like this generally don't age well, because there's no proper mechanism for keeping them up to date or at least downvoting them (like on SO). You'll find the same problem – and much worse advice – in many other old topics, so trying to fix that seem futile. It's difficult enough to promote best practices in current threads.
Personally, I tell people to take all security-related advice with a grain of salt and just stay away from old threads. Security has never been a priority in the PHP community, and even the most basic concepts take a very long time until they're finally adopted. Posts from the last, say, 5 years may get it right, but anything before that is probably garbage.

The implementation is not secure.
First off, UUIDs are not meant for security purposes, and there's no guarantee whatsoever that they're difficult to guess. The only promise is that they're unique (with a reasonably high probability). Some UUID implementations do use secure random numbers, but others are simply time-based.
EIther way, using constant plaintext IDs as authenticators is the worst possible choice, because anybody who manages to obtain the IDs effectively gets unlimited access to the accounts. This is even worse than plaintext passwords, because passwords can at least be changed easily. If you're using the UUIDs for other purposes as well, they may also be leaked all over the place.
It also doesn't sound like you've even thought about a mechanism to terminate those persistent sessions or detect obvious abuse. What happens when the user hits the log-out button? What happens after 24h when the session should expire? Are you just hoping that the user will respect the cookie timeout? You understand that this can be completely ignored, right?

Guys. I understand that PHP people love to turn simple problems into fugly hacks with lots of bugs, but let's not be ridiculous. This is JSON. PHP knows JSON. Turning an array into a JSON document takes one function call. One. No loops, no string fumbling, no comma gymnastics. One function call. Writing this down is a matter of, say, 30 seconds including a quick check of the manual. Instead, you've already spent an hour banging your head against the wall. Even as a non-programmer, you should be able to see that this is not very smart.

PHP says otherwise, and I'm inclined to believe it rather than you.
The error message tells you exactly where the output started. Open that file and check the line. If you cannot see anything that would generate output, open the file in a hex editor. Maybe there are hidden characters like a byte order mark.
No. As I already said, this is a hack, not an actual solution. The solution is to get rid of the output.

A quick Google search will tell you that this is one of the classical PHP mistakes.
The simple answer: You must not generate any output before calling session_start(). No HTML, not even blank space, nothing. Starting a session involves sending a cookie, but this isn't possible when you've already sent the HTTP response (and therefore the headers) to the client. So make sure the session_start() happens before that.
If the code worked before, my guess is that you lied about the “nothing has changed” and actually deactivated output buffering. Either way, the proper solution is to get rid of the premature output.

If I got a dollar every time somebody says this, I would be a rich man.
I don't know what kind of college is this, but my professors actually checked my work and would have immediately rejected a submission which doesn't even survive the most basic tests. This is not just wrong. It shows a fundamental misunderstand of programming basics.

This script will delete anything the user asks for as long as the webserver has permissions to do so. Since a lot of web applications are both running under and owned by the same webserver account, this means a user can probably wipe your entire document root – and maybe more.
Do – not – trust – user – input. Do not let it anywhere near a file path, unless you've extensively validated the input and made sure it's harmless. Using GET requests to delete data is also a very bad idea, because this violates the HTTP protocol. GET is strictly for getting data (hence the name) and mustn't have any side effects. If you break that assumption, you quickly end up with accidental deletions due to page reloads, bookmarks etc. On top of that, your code is wide open to CSRF attacks, which means that more or less everybody can freely delete files on your server.
Learn the basics of HTTP, especially the meaning of GET and POST. Understand that the WWW is a public infrastructure with a lot of hostile activity. Even if you think your website is restricted to a handful of users, that's not actually the case. The script you've shown can be attacked by anybody who has read a few Wikipedia articles.

This may disappoint you, but none of us is a mind reader. We cannot identify the API you're using just by looking at the words “NULL bool(true)”, and we aren't able to deduce the inner workings of that API from this piece of (non-)information. Sure, it would make life a lot easier, but unfortunately, we're mere mortals.
Any halfway professional API is extensively documented (if yours isn't, look for an alternative). So the first step is to RTFM. Have you done that? The authentication procedure will involve credentials like an API key which you've received during the registration procedure and which has to be submitted in an API-specific way.

I didn't even get to the topic of security. The point is that the code is broken on every single level and one of the worst possible choices you could have made.
If you simply accepted that half of the features will never work and the other half will randomly crash, sure, you could do that. But you're obviously here to get this stuff fixed, and I'm telling you that's hopeless.

His reply contained more useful information than any other resource you've learned/copypasted from so far. When you're completely new to a topic, it's a good idea to actually listen to those who know what they're talking about.
Whether you like to hear it or not, the code you've chosen is amateur crap which is at least 13 years out of date and hasn't been updated in the last 6 years. As soon as your hoster decides to update the PHP version (the 5.x branch has already reached the end of active support), the whole application will cease to function.

Yes, it's common practice to spend all day long trying to come up with the most obscure solution to an imaginary problem.
However, your approach is not optimal. You should foo the bar into the baz, then bla the baz together the qux until the garply is ready.