Jacques1

You have to start the session before you can use it. Putting all the user data into the session doesn't make much sense. Store the user ID and then look up the data in the database when needed.

A human-readable version of your query: SELECT player_details.player_id AS P_id, CONCAT(player_details.Fname, ' ', player_details.Lname) AS pname, positions.position_id, positions.position FROM Soka_player_details_tbl AS player_details JOIN Soka_players_team_tbl AS team_players ON team_players.player_id = player_details.player_id JOIN tbl_season AS seasons ON seasons.SeasonID = team_players.SeasonID JOIN Soka_position_tbl AS positions ON positions.position_id = team_players.position_id WHERE seasons.Publish AND team_players.Team_catId = '1' ORDER BY team_players.position_id ASC ; (untested) Your table and column names definitely need to be improved (rAnDOM ChAnGES oF CHarActER caSE and random tbl_ prefixes and suffixes aren't very helpful). I've used aliases for now.

Filling up missing rows with NULLs is the whole point of a left join. If you don't want that, don't use it. Your excessive use of subqueries is also a bit strange. You know that you can operate on tables directly, right? SELECT col1, col2, ... FROM table1 JOIN table2 ON ... WHERE ...;

For a good introduction, see this PDO tutorial. By the way, kudos for taking care of validation and security right from the start. That's pretty rare in the PHP community. A few improvements (apart from what benanamen already said): is_numeric() accepts floating point expressions in scientific notation (e. g. “+.35E6”), which doesn't really make sense for an ID. To check for integer expressions, use ctype_digit(). When the user has made a mistake, tell them exactly what went wrong (e. g. “Missing ID parameter” or “Invalid ID parameter”). That's more helpful than simply redirecting them. Avoid returning numbers that have a special meaning (also known as Magic Numbers). Use values which are immediately obvious like true/false. Use meaningful function names. “SecurityCheckPoint” doesn't say much about what the function does. How about “checkUserID”? You should generally avoid inline JavaScript code. And don't use the obsolete language attribute. Either use the type attribute (which accepts values like “application/javascript”) or no attribute at all; JavaScript is already the default.

Whether or not semicolons are required has nothing whatsoever to do with curly brackets. It depends on the form of the statement. Control flow statements (if, while, ...) have no terminating semicolon. Statements of the form <expression> ; (which includes assignments, calls etc.) do require a semicolon. There's no such thing as an optional semicolon in PHP. When you add a semicolon where it doesn't belong, you're creating a new (empty) statement.

This has nothing to do with PHP. If you still have trouble finding the Miscellaneous section, bookmark it: https://forums.phpfreaks.com/forum/24-miscellaneous/

Function array dereferencing was added in PHP 5.4. However, the last supported PHP version of the 5.x branch is 5.6. That's the absolute minimum. You should consider upgrading to the 7.x branch.

In your form, there must be a field for the old password. Let's call it “oldpassword”. This is what you need to verify: if (!password_verify($_POST['oldpassword'], $row['password'])) { // wrong password } ...

Yes, you verify a plaintext password against a stored password hash. As in: password_verify($_POST['password'], $row['password']) The POST parameter may be called differently in your script. I can't tell from the fragment you've posted.

The password script is odd as well. This defines a class, but you're using functions. So the whole script is just dead code which isn't used in the application (at least not in the parts you've shown).

You're trying to verify the user ID against the password hash. How is this supposed to work? You're also injecting that ID straight into the query string, which circumvents the entire prepared statement. You need a parameter.

Isn't that exactly what I've said? That aside: Another way to overcome the chicken-and-egg problem of a custom base directory is to use environment variables. You can make the webserver set the base directory as an environment variable and then use it in any script: <?php require_once $_ENV['MY_APP'].'/path/to/config.php';

Like I said, relative paths can be relative to anything. When running PHP in a web server context, the working directory should be the directory of the script which has been triggered by the server -- or not. When running PHP in CLI mode, the working directory depends on the parent shell. If you want to be sure that your paths are always resolved correctly, use __DIR__ (if, for some strange reason, you cannot use your own constants).

Working with Magento is definitely not fun. If you have to do anything serious, I strongly recommend you spend a few days learning the infrastructure. Otherwise you'll quickly get lost in gigantic class hiearchies and arcane OOP tricks.

What class? Methods can be entirely dynamic (via the __call method), and this makes a lot of sense for a simple getter. If you want to get a better understanding of the program, I recommend you use a debugger (e. g. XDebug). This lets you inspect all kind of values, analyze stack traces and whatnot.

The problem with relative paths is that it depends on the environment what the paths are relative to. The current directory could be anything. So do use absolute paths. You can still start with the current script by using the __DIR__ constant: require_once __DIR__.'/../oldstuff.php'; Another option is to define your own constant for the base directory of the application and start from there: <?php define('APPLICATION_DIR', $_SERVER['DOCUMENT_ROOT'].'/mninfo'); <?php require_once APPLICATION_DIR.'/oldstuff.php'; Then you don't have to jump around with “..”.

And there's your problem. It looks like what you actually want to do is scrape a website and look for links. That's what HTML parsers are for. Parse the page, search for a elements (I assume that's what you're interested in), get their href attribute. This is far more readable, robust and flexible than any string fiddling code you may find online.

If you need the particular features offered by an abstract class, use an abstract class. This is perfectly fine. The point is that the main tools in OOP are still interfaces and concrete classes. When programmers use abstract classes a lot, that can indicate the hammer syndrome (“When all you have is a hammer, everything looks like a nail.”). Remember when you used lambdas for almost every task and came up with strange solutions to simple problems? That's what I mean. Abstract classes are just one option. Sometimes a concrete base class works just as well. Sometimes a Trait is more useful. And sometimes it makes sense to just duplicate the code. Building complex class hierarchies and writing dozens of lines of OOP boilerplate code only to reuse a few lines of functional code is obviously not very clever. So this is neither about avoiding abstract classes nor about desparately trying to find ways to put them into your code. It's about knowing the whole spectrum of tools.

Read my reply.

You cannot set a header when you've already generated output. The HTTP headers come before the body, so once you start rendering the page content, it's too late to do anything with the headers. This means you must organize your script properly and separate the programming logic from the output. In your case, I suggest you forget about the output and just send the document. Making the user wait 5 seconds and messing with page refreshes is annoying and antiquated. Your mail code is also badly broken, but that's another story.

You said you want to update some static HTML file, but “your” code (which I assume you have copied and pasted from somewhere) has nothing to do with that at all. It generates a list of files dynamically. So what is it? A dynamic list is definitely the better approach. However, it makes no sense to print the entire directory content. If you want a simple directory listing, use your webserver. Apache, nginx etc. all have this feature. If you want a more intelligent approach (pagination, meta data, previews, ...), I recommend you store references to your files in a database where you can manage them properly. PHP usually comes with MySQL, so all you have to do is learn a few SQL basics – which you'll need anyway, sooner or later.

By the way, you really need to stop believing any random guy who tells you that your site is “secure” now. There's a difference between being able to make an error message go away and actually understanding the problem.

Forget about trying to apply handcrafted procedures to individual PHP fragments. requinix really loves to do this, but it's disastrous for security. You need systematic protection for your entire site. Modern template engines like Twig support automatic escaping of all HTML input which is far more realistic than doing it by hand. If, for some strange reason, you have to use oldschool PHP, write your own escape function and manually apply to it all dynamic input, not only when you feel like it: <?php function html_escape($raw_input, $encoding) { return htmlspecialchars($raw_input, ENT_QUOTES | ENT_SUBSTITUTE, $encoding); } Make sure the HTML document is delivered with an explicit character encoding, and use Content Security Policy as an additional layer of protection. CSP tells the browser which scripts are legitimate and which scripts should be blocked. A complete example: <?php require_once '/path/to/functions.php'; // you may set those headers with your web server rather than with PHP header('Content-Type: text/html;charset=utf8'); header("Content-Security-Policy: default-src 'none'"); $input = '<script>alert("XSS");</script>'; ?> <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <!-- also declare the encoding within the document itself --> <title>Title</title> </head> <body> <!-- escape all input, regardless of whether you think it's safe or not --> <p><?= html_escape($input, 'UTF-8') ?></p> <!-- testing CSP: this will be blocked in modern browsers --> <script>alert("XSS");</script> </body> </html>

Go with hard facts, not “beliefs”. Google specifically says that migrating to HTTPS is considered a site move, and there are detailed guides on how to do this properly. The insecurity of HTTP is real, and I'm surprised that you've been doing business for 10 years and appearently never even thought about that. When your site processes any kind of relevant data, you must use HTTPS on the entire site, ideally with Strict Transport Security. If you cover just a few pages, an active attacker can circumvent the protection by simply removing the “https” from all links. You can get free certificates from Let's Encrypt.

Perhaps you should talk less and do more. You know how division with remainder works, right? Do it then.