Jacques1

Get a proper IDE or editor.

Perhaps you can forget about the tech stuff for a moment and just explain the situation in plain English. So you are sending e-mails to your friends and family, and now you think you need an unsubscribe feature in those e-mails? Bollocks. Either you've completely misunderstood what the providers are actually saying (a link would be helpful), or somebody is pulling your leg.

Why would you want that? Duplicating columns is a bad sign and sounds like the usual MySQL-is-Excel confusion.

Yes, this is Ruby. No, you cannot run Ruby within PHP, and there's no way to automatically translate one language into another. I see two possibilities: You try to understand the concept and then write your own PHP implementation from scratch. You pay somebody to do a manual translation. This will be expensive. There aren't many programmers who are proficient in both Ruby and PHP, and the job is tedious rather than challenging.

What is “ORDER BYRAND()” supposed to mean? Otherwise, the usual problems: You have no error checks whatsoever. No, mysqli doesn't do that for you, unless you explicitly ask for error reporting. Your PHP error reporting also seems to be off. You should be seeing a big fatal error in your log. The Ajax script is unable to handle errors, which is a problem.

No. A break would be entirely redundant.

This is an awful hack even for WordPress standards. Dumping variables straight into a shell and accepting arbitrary commands from a remote(?) server is a sure way to get compromised. Tell us what you want to do, not how you think it should be done. What's the matter with those shell commands you want to execute?

The factory is an abstraction layer which provides more flexibility than instantiating objects directly. When you just put hard-coded Button subclasses into your code, you're restricted to those exact classes once and forever. You cannot switch to a different implementation. It's also your job to prepare everything for the object instantiation, which can be a lot of effort for complex classes (not in this trivial example, of course). The Factory Pattern is smarter than that: The factory decides which class is instantiated. You can plug in a different class at any time by subclassing the factory. Choosing the right implementation can also be more sophisticated than mapping strings to classes. The factory is free to choose the optimum based on any parameter. The entire preparation procedure is delegated to the factory. This can greatly simplify the code. However, the Factory Pattern is now often replaced with Dependency Injection.

Do your own homework-

Obtaining the ID from the _inc table with a simple INSERT and a session variable would be boring, right? You just need the thrill of finding creative ways to screw up your data.

Why are you running a PHP script on your PC to connect to a database on some castrated server? What are you even trying to do?

Who said anything about a composite key? Use a plain old auto-incremented integer ID for your entire zoo. If you're worried about the counter leaking information, use purely random IDs. This thread reminds me of the people who spend days trying to figure out how to fill gaps in numeric IDs and end up with hideously complex, bug-ridden locking gymnastics – so that they can have a “beautiful” sequence which nobody cares about. The point of an ID is to identify data. That's it.

The fact that the proposed “solution” is yet another hack which only “works” with MyISAM. We had the exact same discussion last year. Sacrifcing data integrity and simplicity just to have “pretty” IDs is nonsense. It didn't make sense then, it still doesn't make sense, and it won't make sense in the future.

The code is still nonsense. That unpack() stuff you've taken from the Stackoverflow post does absolutely nothing useful. The full datagram is already in $buf. It's a PHP string, so you can access any character/byte you want directly via its index. Again: Learn the basics. There are thousands of PHP tutorials, videos and free courses just one Google search away (I've already pointed you to one).

The code makes no sense, so there isn't anything we can tell you other than: Get rid of it. Copying and pasting random snippets from the Internet will definitely not teach you proper PHP, and it may not even be allowed. Just because the code is online doesn't mean it's in the public domain. If you want to learn PHP, write your own code. And start small. It doesn't make sense to implement a complex network script when you have no idea how the language basics work. Start with something like Codeacademy, write simple test scripts and then slowly move to more advanced tasks.

I'm not sure if doing low-level grunt work is really a challenge and a good way to learn PHP. Seems more like a waste of time. I understand the scepticism towards libraries/tools/frameworks (not having full control, feeling that the programming part is taken away from you etc.). But this is mostly unfounded. To the contrary, getting rid of routine stuff lets you concentrate on the real programming challenges. When you no longer have to write the same PHPSQLHTML form handling code over and over again, you can think more about the actual features. This also isn't a decision between plain old PHP and "a framework". You can use libraries within your application, you can use framework components, you can use microframeworks. There's a wide range of possibilities.

Delimiters must be chosen specifically for the data format (e. g. JSON) -- and may not even be possible. Length prefixes are generic and always work. On the other hand, it's slightly simpler to look for delimiters than extract and process lengths.

Forget about the XSS vulnerabilities and just use Twig. It will be a major improvement of both the quality and security of your application. Learning the basics of Twig is simple. It's just HTML with a few tags for variable insertion, control flow statements etc.

The two hosts first need to agree on a byte order for the length. How integers are stored is machine-dependent, so there must be a common format on the wire (a good candidate is network byte order, i. e. big endian). C has the htonl() function for the conversion. Then the PHP script can unpack the bytes: <?php // test: 16 in big endian $lengthField = "\x00\x00\x00\x10"; $length = unpack('Nlen', $lengthField)['len']; var_dump($length); Whether you use length prefixes or delimiters is a design choice. Appearently you (or whoever wrote the C++ code) decided against delimiters.

I'm still now sure if you understand the concept of streaming. The data you receive is not the message. It's a portion of a byte stream, which means it could contain anything: a message fragment, a single complete message, multiple message. You never know. That's why the “strange length bytes” exist: They tell you where the messages end. You must process this information and write an assembly logic for the messages.

Trying to remove security vulnerabilities afterwards is a bad strategy which almost never works. Sooner or later, you're going to overlook a vulnerability or simply give up this tedious task. Instead, use secure programming techniques from the beginning. Don't ever let unsafe values near your SQL queries or HTML markup, not even for a quick prototype. As to the HTML, I strongly recommend you use a template engine like Twig. While it's theoretically possible to generate HTML with plain PHP like people did in the 90s, this almost always ends up in an ugly mess of spaghetti code and XSS vulnerabilities. Twig prevents this by strictly separating the code from the markup, by auto-escaping all input and by providing a much nicer syntax. Stuffing all your functions into one giant functions.php script is also a bad idea, because nobody wants to read through that. Instead, modularize your application. Put related functions into separate scripts. The session and security stuff is copied and pasted from wikiHow, right? Don't do that. A lot of people publishing code on random websites know less about PHP than you do. Copypasta also means the code will never receive any updates and just keep rotting in your application. If you want to use existing tools, pick a trustworthy source (active GitHub projects with multiple contributors are good candidates) and use a mechanism which supports updates (e. g. Composer). In your case, you can simply remove the wikiHow stuff and use the Password Hash API instead.

Why on earth would you have that?

$current_script = basename($_SERVER['SCRIPT_FILENAME']); gives you the filename of the current script.

Sorry, but I'm afraid we've run out of crystal balls. Show all the relevant code, not just a random SQL snippet. How do you process the result set? Be more specific. Is there an error? Or does the query succeed and just happens to have an empty result set? Do some basic debugging yourself. Print $player and run the exact query in phpmyadmin (or whatever it is you're using). What happens? An error? An empty result set? The database layout is definitely broken. You don't create a new table for every year, and I agree with benanamen that the 42 columns are fishy.

No offense, but you have a strange tendency to always run into the opposite direction when you've just been told the right way. I just gave you a link to a PDO-for-dummies tutorial. All you have to do is copy and paste the code. <?php $host = '127.0.0.1'; $db = 'test'; $user = 'root'; $pass = ''; $charset = 'utf8'; $dsn = "mysql:host=$host;dbname=$db;charset=$charset"; $opt = [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES => false, ]; $databaseConnection = new PDO($dsn, $user, $pass, $opt); Sounds more like a syntax error, maybe in a different script. The line numbers don't add up.