Jacques1

It doesn't matter if you have only 16 fields. When your columns are named "account.1.sip_server.1.address", you clearly don't understand the relational model. But of course you're free to keep trying.

Your entire table layout is obviously bogus. 400 columns are already a warning sign, but when the names contain indexes and aren't even syntactically valid, there's a major design problem. If you want to use SQL, you must understand the relational model and structure your data accordingly. This means you have to analyze the data, identify entities and the relationships between them, define tables and finally store your data in those tables. You can't just dump all your configuration entries into one giant row (or whatever it is you're trying to do). If you don't want to do this work, or if the relational model simply isn't suited for you case, then don't use SQL. Maybe you just need a static XML/JSON/... file. Maybe a document store like MongoDB or CouchDB fits your needs. If you describe specifically what your data looks like and how you're going to use it, I'm sure we can help you with that decision.

Being able to assign the same video to multiple users (and vice versa) is the whole point of a junction table.

How about simply reading the replies?

The current layout doesn't make sense, because you simultaneously want videos to be user-bound (there's a comment field) and not user-bound (you only use the Youtube ID as an identifier). Either you add the user ID to the video table and make the pair(!) of Youtube ID and user ID the primary key. Or you create an extra junction table where you assign user IDs to video IDs and store user-specific data like the comment.

First off, you definitely don't want a script which allows anybody to put arbitrary files into arbitrary locations on your server. What if somebody uploads malware and uses it to attack the server? What if your server is abused to host illegal material? You can't have that. Secondly, you don't transfer 300,000 images in one go. Network operations can fail. PHP scripts can fail. If anything goes wrong, good luck figuring out which of those 300,000 images are missing or broken. This needs to be done intelligently: Implement an authentication mechanism (e. g. a a strong password) so that only you can use the script. Only store files in a special download folder, do not let the user specify arbitrary paths. You'll also need a mechanism to prevent duplicate names. If you take the basenames of 300,000 URLs, you're almost guaranteed to end up with collisions. The initial request should only store the list of URLs on the server, ideally in a database. Then the server can split the work into realistic chunks and periodically download a set of images. If a particular download failed, the URL is simply kept on the list and tried again next time. If the script fails, it will be restarted next time. This is a lot more robust than just hoping everything will work on the first try.

It's actually a valid suggestion compared to fantasizing about how evil hackers stole your PHP variables. Sometimes code has to be nuked from orbit.

And a few more. Sure, git is more hip right now (for whatever reason), but if the OP is looking for simplicity, I'd check out Mercurial first: no staging area, no arcane syntax, no history rewriting gymnastics (if you need that, you can still enable it through plug-ins). Like I said, I use both, but Mercurial is the one I find a lot more straightforward.

This is not a code-for-free service. requinix provided the relevant data, now it's your job to do some basic research and integrate the feature into your code. Of course we can help you with specific questions. But if you expect us to do the work for you, that won't happen, no matter how kindly you ask for it.

Just that teeny tiny Mozilla Foundation.

Cool story, bro.

You've copied and pasted the entire code (which is ancient, by the way), so why can't you copy and paste some IP script as well?

Again: You cannot comment out a database script when the rest of the code needs that script. This -- obviously -- breaks everything. Page loading issues are a separate problem. The above errors are caused by your own changes.

I'm not sure if those “bulletproof sessions” are worth the trouble. The class misses fundamental aspects of secure sessions, performs a lot of questionable checks and has some features that are downright user-hostile. The author mentions the risk of an attacker guessing the ID, but for some reason he doesn't manage to actually fix that with strong randomness. Session fixation is also mentioned, but again a crucial feature to prevent this (cookie-only sessions) just doesn't exist in the code. It's sufficient to regenerate the session ID right after the log-in, yet large parts of the text and code deal with changing the ID on random requests and the problems that arise from that. This could be made a lot simpler. Binding the session to an IP address and user agent may be well-meant, but it's extremely annoying for users who change those often (e. g. due to tools like Tor). You just cannot assume that everybody uses the Internet in the same way you do. Nothing about secure log-outs. No code, no explaination. Like many times, you'll probably get a lot more security through proper configuration rather than installing some third-party class. And maybe one day the PHP core developers will manage to design a session system that is secure by default and doesn't require us to write entire tutorials on fixing the current one.

The include statement for the connection is commented out, so where is $mysqli supposed to come from?

I've worked with all three version control systems, and I think this is BS. You're free to use any tool you want, but if you like to make an intelligent decision, I recommend you do some more research and actually try out the different options.

This topic has been discussed to death. Spend 5 minutes on Google, look up the different version control systems, and I'm sure you'll find what you need. Subversion is a centralized system, git and Mercurial are distributed systems. Distributed means everybody has a fully functional local repository which may be synchronized with any other repository of the same project. This provides a lot more flexibility: You can work offline, you can push your changes to a central server, you can exchange them with your coworkers.

What requirements said anything about the mysql_* functions? Where is that other than in your head? I'm baffled that somebody would tell a student not to learn and not to think for herself as it might “jeopardize her grade”. Is that how your education worked? Where I come from, learning is the whole point of going to university, and professors appreciate students who do more than required. Thinking for yourself is actually encouraged and leads to better grades if anything. But maybe things work differently in Trumpland.

Yeah, she mixes up the versions. We know. We got it. The point is nobody told her to use PHP 7. benanamen recommended PDO, and now you're busy sabotaging that and telling her to go back to ext/mysql. Because that's “future-proof”.

Who said anything about PHP 7 anyway? PDO was introduced in PHP 5.1 back in 2005. The mysql_real_escape_string() function even existed in PHP 4! What do you think she should learn, cyberRobot? Rasmus Lerdorf's PHP/FI from 1995? I guess somebody is still using that, and maybe they need help converting it. A future-proof job, eh? On a more serious note: I don't know about you, but when I started programming, I absolutely hated those people who called me a “newbie” and patted me on the back rather than actually teaching me something. It's condescending bullshit.

If you actually want to learn, you need to stop begging for quick answers and start talking about solutions. “I don't care what's wrong, plz just answer the question” is what little schoolkids say when they've been lazy and need the Internet to do their homework. But you're a grown-up, so I do expect more from you. What matters is the underlying problem, not those few lines of code you've written. Code by itself isn't worth anything; when it's inadequate, you just throw it away and start over. Sure, this sometimes hurts, but it's the only way to make progress and not waste any more time on a mistake. Running predefined shell commands on remote machines is a simple problem with simple solutions. We can have a reasonable discussion and find the one that best fits your needs, or you can go back to your homework forum. Your choice.

I wonder why you need dynamic method calls in the first place. If you have lots of short actions, use an array of closures: <?php class Command { protected $commands = []; public function register($cmd, $action) { if (isset($this->commands[$cmd])) { throw new InvalidArgumentException('Command '.$cmd.' is already registered.'); } $this->commands[$cmd] = $action; } public function execute($cmd, $data) { if (!isset($this->commands[$cmd])) { throw new InvalidArgumentException('Unknown command '.$cmd.'.'); } $this->commands[$cmd]($data); } } // build the command instance $command = new Command(); $command->register('a', function ($data) {echo 'Doing a.';}); $command->register('b', function ($data) {echo 'Doing b.';}); $command->register('c', function ($data) {echo 'Doing c.';}); // execute a command $command->execute('a', ['foo' => 'bar']); If you have lots of complex actions, it makes more sense to have decicated objects, similar to the Command Pattern. If you have just a few fixed actions, use a plain old if statement which hard-coded method calls.

The above code is actually a perfect example for why manual escaping just doesn't work. He escapes the input somewhere on top of the script (essentially mimicking Magic Quotes), then runs the query somewhere below. Oops, he missed the referrer, so all those mysqli_really_really_escape_this_please() calls are useless. And if he happens to need the data for something other than a query, the script silently fails. Or there are “strange backslashes” on the site. Or we're back to the days of stripslashes(). Manual escaping is like those abstinence-only programs for horny teenaders: In theory, it works great. In practice, not so much – or so I've heard.

Have you read the replies? Expecially the part about why none of your userExists() methods is valid?

What does “Commands” do? What is “otherStuff”? If you want a shot in the dark, I'll say you should pass your “otherStuff” to the Command method you call as additional context. However, this is hardly a good approach to begin with. Right now, you don't even know which method you end up calling, which is fragile at best and dangerous at worst. $cmd could be some internal method that doesn't even have a parameter. There's no guarantee that it's one of your predefined “command methods”. To fix this, you should always call the same fixed(!) method which then maps $cmd to some action, using a closure or an actual method after checking a whitelist.