Jacques1

It's very simple: Open the PHP manual, go to the page of the split() function and read the big red box. It points you to all alternatives. The tips at the bottom of the reference also explain exactly when to use which alternative. Try it.

Your name_first and name_last parameters are arrays, but you cannot apply htmlspecialchars() directly to an array. PHP wouldn't even know which of the two values you mean. You have to explicitly reference them: $_POST['last_name'][0] // last name from first set $_POST['last_name'][1] // last name from second set It might actually make more sense to swap the indexes: name="name[0][first]" name="name[0][last]" ... name="name[1][first]" name="name[1][last]" Now there are two associative arrays, each containíng a first and a last name. There's no special function for checking if one of the two array values is set. Use plain conditions. Your code is also vulnerable to XSS: $_GET['p'] is dropped into the markup with no protection whatsoever. htmlspecialchars() without any flags and any character encoding is dangerous. It could work out, but it could also fail miserably. You should always specify the character encoding and at least set the ENT_QUOTES flag.

You're using $POST_ instead of $_POST everywhere on your code. Since the former variable doesn't exist at all, any isset() check on it will fail. That would explain why nothing happens after submitting the form. However, since there are dozens of other problems, I suggest you scrap the code and start with a smaller project. Then you can write your own code and actually learn the language. Copy-and-paste programming doesn't get you anywhere. You've probably spent a lot of time putting this script together, but the result is practically useless, and you haven't gained any knowledge. Why don't you start with PDO? Write a simple script, try out a few queries, and learn how to safely pass variables to a query with prepared statements.

Skip the “nooby” stuff and tell us specifically what your problem is. In standard English. Which parts don't work as expected? What happens instead? Which errors does PHP display? etc. Right now, all we can tell you is that your code is hopelessly outdated. For example, the mysql_* functions are obsolete since more than a decade and have been removed from the current PHP version. Both PHP itself and the PHP manual explicitly warn against using those functions. And hashing with SHA-256 has become unacceptable somewhere around the year 2000. This is PHP from the 90s. If you want to learn the language, you should use good, up-to-date resources. The PHP manual is a good starting point. To be specific, every current log-in script should use PDO (or mysqli) for database queries and the password hash API for passwords.

And line 28 is what? Your prepared statements are definitely shaky. Why do you keep inserting $uid straight into the query strings, risking an SQL injection vulnerability? You know how to safely bind parameters. And then there's that at the top of the script: $query = "SELECT COUNT(*) FROM table WHERE memberID = '".$uid."'"; $stmt = $db->query($query); $stmt->bindParam(':memberID', $uid,PDO::FETCH_ASSOC); $stmt->execute(); You execute the query. Then you suddenly decide to bind a parameter which doesn't exist and execute the statement again?

Unless you're planning to run IIS on your production server as well, I suggest you get rid of it and install a more common webserver, namely Apache. For Apache, there are complete development packages like XAMPP which are preconfigured and already include all relevant software (PHP, MySQL, phpmyadmin, ...). IIS is exotic. You won't get a lot of help for it outside of specialized Microsoft forums, and you might actually have to do your own research (that's scary, I know).

So you're talking about a foreign key used to join the two tables? Then the ID is better, because it's stable and efficient. Names change, which means the database has to keep the tables synchronized. And names are long, which means it's relatively expensive to compare them. Numeric IDs, on the other hand, are unlikely to ever change, and they have a fixed length.

Post your code. The solution is to first do all PHP processing, and then generate the HTML markup: <?php // PHP code goes here ?> <!DOCTYPE HTML> <!-- HTML markup goes here --> This way there will never be any output before a header() call. It also leads to much cleaner and more maintainable code, because the business logic (PHP) is cleanly separated from the representational part (HTML).

A 404 error means that a file could not be found. So either your jquery-3.0.0.min.js script doesn't exist on the server at all, or you've put it into the wrong location. To match the URL, it must be located next to the index.html file: src="jquery-3.0.0.min.js" If you want it to be in your "js" folder instead, you must adjust the URL: src="js/jquery-3.0.0.min.js"

That's silly. When your code doesn't do what it should, the solution is to fix it, not make your users click on links. You'll probably encounter the same problem many more times, so why don't you take the chance to understand it and avoid it in the future?

JavaScript code is executed by the browser, not the server. So what do the developer tools of your browser say? The Network tab shows HTTP errors (404 etc.), the JavaScript console reports JavaScript errors.

That is what I'm suggesting. You first delete all old associations, and then you insert all new associations. Note that your code is subject to race conditions. If two instances of the script run simultaneously, you can end up with a mixture of data.

Remove all associations for the c1 value that should be updated, then insert all new associations.

And why do you want that? Search engine trickery? What you describe is obviously terrible for performance and bandwidth, because the client has to download the exact same image over and over again (unless you literally redirected all image URLs to myhouse.jpg, which would be very confusing). If you map arbitary paths to arbitary paths, that also means you'll have to manually maintain a long list of all mappings. A better approach would be to clearly separate the physical path from the descriptive stuff: /images/actual_file_path--this-is-some-comment // cut off everything after "--" with a rewrite rules /images/actual_file_path?this-is-some-comment // no rewriting required; the query part is simply discarded

There is no magical function for getting the project root, because PHP doesn't know that path. What you can do is have the webserver set an environment variable with the project root (how exactly that works depends on your webserver; google it). PHP has then access to that variable: require_once $_SERVER['MY_PROJECT_ROOT'].'/path/to/script.php'; Alternatively, you could define a constant with the path within PHP (e. g. in a configuration script). But that means you always need to load the initial script with an “ugly” path before you can use the constant for everything else: <?php define('MY_PROJECT_ROOT', $_SERVER['DOCUMENT_ROOT'].'/path/to/project/'); <?php require_once __DIR__.'/../relative/path/to/config.php' require_once MY_PROJECT_ROOT.'/path/to/some/script.php'; // now MY_PROJECT_ROOT is available

This is about a transaction to an external site, not a simple POST request within the application. And as I already said, anything that involves money falls into a different category than normal operations. Relying on (session) cookies is perfectly fine if the goal is to, say, prevent duplicate blog posts. If it fails, there isn't really any damage. But if the user ends up with duplicate payment transactions, that is a problem which must be prevented at all cost.

This is getting boring. Again: If you cannot get the syntax right, use an IDE. This far more efficient than going back and forth in a forum. Screenshot:

Your quotes are all over the place. If you cannot fix them yourself, install a proper IDE (integrated development environment) to assist you with the syntax. You also need to URL-encode and HTML-escape the title before you can insert it into the anchor. It's most definitely not URL-compatible by itself and can also lead to cross-site scripting attacks.

Write the code yourself. Or find somebody who does that for less than 2,500. We've explained the technical aspects. The decisions are up to you.

So what does happen when you leave the fields empty? Are you getting an error? A blank page? Are you magically logged in? Be specific. Programming is an exact science, not a guessing game. Right now, all I can tell you is that a lot of your checks lack an else branch. If there are no POST parameters, or if the token is wrong, you keep quiet and don't give any feedback at all, which is obviously a problem.

Any serious transaction must involve a unique transaction ID or nonce. Client-side techniques like disabled buttons, cookies etc. may be sufficient for unimportant actions, but they are by no means reliable. When actual money is involved, you must implement a server-side mechanism which is technically guaranteed to only accept a single submission. What exactly is this payment processor? A professional service? Then it should already have transaction IDs.

What exactly are you struggling with? The “technology” as you call it is unimportant and mostly a matter of personal preferences. If you like XML, then XML-RPC is just fine. Implementing the actions is routine work. Do make sure that your interface is secure: Protect the traffic with HTTPS, and use randomly generated individual API keys to authenticate the clients.

You skip the first user, because you fetch one row manually (for whatever reason) and then immediately overwrite the variable in the loop. And you really shouldn't do three queries when you only need one. Not only does it bloat the code. It can (at least theoretically) lead to wrong results if a user is logged out just between selecting the users and counting them. Simply join the two tables and then select all users who are currently online. This gives you both the count and the details.

Use conditional template sections wrapped in {% if %} ... {% endif %} instead of assembling the HTML markup from strings. Make the template readable, not as short as possible.

You're wrong. And it's not really a good idea to reject valid answers when you haven't even tried the code and don't understand the topic.