Jacques1

As I told you multiple times, jQuery is not required. The above library is a single JavaScript file with 150 lines of code. You can copy-and-paste those straight into your HTML markup or wherever you want it. Hell, you could even strip the code of everything but the get() method. Then you're at 40 lines of code. What more do you need?

I understand what you're trying to do. What I do not understand is why you cannot or don't want to install a library. The js-cookie library has merely 150 lines of code. Put it on your server, adjust the above code, and you'll be done in 5 minutes.

This is really vague. What exactly is the problem? Are you getting an error? A false positive? A false negative? What have you tried to debug the problem? And what are the “limitations” you're dealing with? If you think jQuery is too heavy, there are plenty of lightweight libraries specifically for cookies. Manually parsing document.cookie sucks, so you'll want to avoid that.

The OPcache contains the bytecode of PHP scripts, i. e. an optimized representation of the programs you've written as source code. It doesn't know anything about the request parameters from a particular run.

Why do you need a physical column for the AND operation when the value can simply be derived ad hoc? Precalculating the result is actually a bad idea, because you need to update it whenever any of F1 or F2 change. And if you forget to update it just once, you'll end up with garbage data. Simple calculate the AND result in the query. You could also use a view which contains a virtual F1_F2 column that is calculated from the physical F1 and F2 columns.

Well, what are we supposed to do now? Without knowing anything about your database content, your files and your server environments, it's impossible to find out the exact difference between your local server and your production server. But you can investigate the problem, because you're sitting right in front of the screen: Do the expected database entries exist? Do the slider images exist in the right path? Are there any PHP errors in the server log? Are there any client-side errors in the browser console? We need specific information. Besides that, there are plenty of other issues: Your first query is vulnerable to SQL injection attacks, because mysql_real_escape_string() is useless when the result isn't wrapped in single quotes (the function only escapes the content of an SQL string). Since you already know PDO and prepared statements, I wonder why you're still running around with the ancient mysql_* functions and putting your server at risk. Parts of your code don't make much sense: Why do you replace “..” path segments with spaces in your image paths? Won't that fudge up the entire path? Why is there a fetch loop after the first query when you only want to fetch a single record? Why not just fetch once? Why do you select all columns when you only want a single one of them? Why not just select this specific column? You really need to stop cramming all your PHPSQLHTMLCSSJavaScript into a single file. If a few lines of PHP code are buried in hundreds of lines of unrelated stuff, this drastically decreases readability, increases the error rate and makes people shy away from your code. JavaScript code belongs into JavaScript files, CSS markup belongs into CSS files, and HTML markup belongs into template files (or should at least be separated from the code: PHP at the top, HTML at the bottom).

None of us is going to write the code or query for you. You know what you need to do, now it's your job to start researching and programming. If you have a specific, non-trivial question (i. e. something that cannot be answered with a 10-second Google search), we can help you with that, but don't expect us to do the work for you. That's something you can easily find out: The MySQL manual Google (or any other search engine) That's impossible to tell without knowing your exact server environment (Unix with root access, Windows, maybe an administration GUI, ...). But it again sounds like a great question for a search engine. I'm sure somebody before you has already solved that problem.

Your PHP scripts don't run “all the time”, only when there's actually an HTTP request. You said you want to send the notifications at 12:00 p. m. What if there's no request at 12:00 p. m.? It could happen hours later or not at all (depending on the traffic). Are you OK with delaying the notifications for an indefinite amount of time? And why would you do that? Isn't this feature important?

Waiting for the user to log-in doesn't really have anything to do with alerts or notifications. It also means the user will miss events if they don't regularly visit the site. I have no idea why the OP even mentioned “no cronjob”. If it's supposed to run daily, it is by definition a cronjob, be it an actual Unix cronjob or a task which is triggered daily through some other mechanism (a commercial service, lovephp's PC, ...).

Yes, do use a CAPTCHA at all times.

You keep saying that you need to circumvent the URL encoding. Why? To make the URL look pretty? The URL encoding is performed automatically by the browser, and it happens for a good reason: unambiguity and robustness. For example, how is the server supposed to interpret the following URL?: http://foo?x=http://bar?y=1&z=2 Does the z parameter belong to the foo or the bar URL? A human would probably say it's part of the bar URL, but it's actually a second parameter of foo. There's no such confusion with properly encoded parameters. Of course you can do pretty much anything with URLs if you're able and willing to mess with the low-level details. But I definitely don't recommend that to a beginner. Just let the browser do its job.

I hope you're now using the numeric days property rather than fumbling with format strings.

If you don't want sequential IDs, use a proper(!) random number generator like random_bytes() and encode the result with your favorite encoding (Base64, hexadecimal, ...). <?php // random_bytes() is natively available in PHP 7; if you have PHP 5, use the random_compat library: // https://github.com/paragonie/random_compat $random_id = bin2hex(random_bytes(16)); You do not need a loop, because the chance of a collision is practically zero.

tail and grep are fundamental Unix commands. They're far more basic and efficient than your PHP script. If you insist on reinventing the wheel: fgets()

What do you mean by “impersonating”? Phishing? This cannot be fixed with code, because phishing attacks happen outside of your application. However, you can do something about other attacks: The entire site including the reset pages should be delivered over HTTPS so that e-mail addresses and passwords cannot be intercepted. Use a CAPTCHA on the request page so that an attacker cannot automatically make you send a large amount of e-mails to an arbitrary address. Make sure the request page doesn't reveal if an address is registered or not. Either ask for the public username instead of the e-mail address. Or send out an e-mail for any address (if it's not registered, simply say that in the e-mail itself).

What a weird hoster. PHP 5.6 is indeed the current PHP version (together with the new PHP 7 branch). But before you upgrade, you should definitely ask Bluehost what on earth they mean by “beta”.

I'm not sure what you're trying to do. Which reset page is this about? The page where users enter their e-mail address to request a reset link? Or the page where people actually reset their password after they've clicked on the link? Either way: Which specific threat are you worried about? The Referer header is not reliable. In many cases it's not sent at all, be it because the user suppresses it for privacy reasons, be it because the URL has been entered directly (which should be perfectly fine). And of course the user can set their headers to any value they want.

So what is line 19 in your password.php script? There's no opening brace on line 19 in any of the official versions. Is it “namespace {”? Then you're appearently running an ancient, long-abandoned PHP version (something prior to 5.3).

The second code snippet doesn't make a lot of sense, because you're blindly applying urlencode() to a complete part of the URL. This will not only fudge up forward slashes. A query or fragment will also be affected. You need to apply the encoding while you assemble the URL or URL part so that you know exactly what you encode (e. g. an individual path segment or parameter).

Why do you want a PHP script? Unix has tail or tailf to do exactly that: tail -f log.txt | grep MATCH The Windows PowerShell has Get-Content with similar features.

Yes. It does not somehow alter the PHP configuration to send a 400 response code forever – if that's what you're worried about. Only the pending response is affected.

The function sets (or gets) the HTTP code of the upcoming response. It does not send any headers. The big advantage over setting the code manually with a header() call is that you can omit the HTTP version as well as the reason phrase (“OK”, “Not Found”, ...). PHP will figure those out for you. I use the function regularly, e. g. for error handling (issue a 400 code if the input validation failed).

Your example numbers don't seem to match your actual data, but if you want to count the school/domain combinations, you need to group by both the school and the domain: SELECT escola.escola, dominios.dominio, COUNT(*) AS the_count FROM estatistica_atividades JOIN escola ON estatistica_atividades.id_escola = escola.id_escola JOIN dominios ON estatistica_atividades.id_dominios = dominios.id_dominio GROUP BY escola.escola, dominios.dominio ; (You really need to get rid of all those useless backticks)

You actually can keep the tokens in a separate table as long as you have a one-to-one or one-to-many relationship between the tokens and the users (i. e. you store the current token ID in the user table rather than the other way around). Trying to hide the existence of usernames is futile. For example, bcrypt will cause a huge delay during the password check, so it's immediately obvious if the name or the password is wrong. You could try to prevent this by hashing a dummy password if the name is already wrong, but this doesn't really fix the problem. There may still be suble timing differences or other factors which reveal the control flow (like errors which only happen in a particular branch). I think a much better approach is to not use secret names in the first place. Instead of, for example, (mis)using the e-mail address, simply make the user choose a public name.

Have you looked at the example code in the PHP manual? By the way, PDO is a lot easier than mysqli, especially when dealing with prepared statements. So unless you've reached the point-of-no-return, you should seriously consider switching to PDO.