Jacques1

Yes. It's not required to use meaningless div tags, though. You can and should still write semantic markup with sensible elements.

The password is hashed with MD5. A couple of people have already posted long explanations in the previous thread, but the code is still the same.

C'mon. After 8 years, you should have figured out that “doesn't work” is not a valid problem description. Learn to analyze issues and provide relevant information. What exactly happens? Do you see a white page? An error message? An application-specific message? Something else? What does the PHP error log say? Make sure to enable error reporting and logging. A couple of var_dump() calls or a professional debugger like XDebug allow you to analyze the control flow of your program (i. e. what happens where). Right now, all we can do is speculate. Your include statement tries to load a script from /functions/dbconnect.php (note the leading slash). That's an odd location, because it's directly under the root filesystem. I'm fairly sure you want the relative path functions/dbconnect.php which points to a directory next to the current script. Besides that, your code is insecure and weird, and it seems you have ignored every single advice we gave you. You're free to do that, but then we get the impression we're wasting our time with you.

Then you need to learn the basics of SQL, particularly joins.

I don't know anything about the underlying data structure and whether it even makes sense, but you could turn one of the two arrays into a lookup table with (year, week) as the key. This allows you to immediately associate the values while iterating over the other array. As pseudo code: // lookup table for credits: (year, week) -> credit credit_lookup = [] for credit_data in credits: credit_lookup[credit_data.year][credit_data.week] = credit_data.credit for debit_data in debits: // get credit credit = credit_lookup[debit_data.year][debit_data.week] difference = credit - debit_data.debit

Pick whatever you like best. To me, a loop or array_replace() is a lot clearer than an operator which I constantly need to look up in the manual, but if you prefer the operator, use it.

Yeah. Use a loop then.

You must enable it, not get rid of it. You want peer verification. It does't make sense to silently override the authentication method with CURLAUTH_BASIC. What if you (or whoever uses the function) has already set a different method? Your handling of URL parameters is odd. If the method is GET, the caller of your function must not include a query in the URL (because that will result in a nonsense URL), but for all other methods you do expect the caller to put the query into the URL. Pick one. Or parse the URL so that the function doesn't screw up URLs with a predefined query. You also cannot handle multiple parameters with the same name. Consider supporting arrays as parameter values. The DELETE method cannot have parameters in the request body (well, it technically can, but they're ignored). Are you sure the parameters of the PUT method must be manually URL-encoded? Why not an array?

Without certificate verification (CURLOPT_SSL_VERIFYPEER), HTTPS is a joke and a waste of energy. The whole point of encrypting the HTTP traffic is that only one specific peer can read it. If you don't verify that peer, the whole exercise is useless. If you don't want HTTPS, use plain HTTP. If you do want HTTPS, you must enable certificate verification. Problems usually come from not providing the trusted certificates. Your $options parameter is also useless, because you immediately overwrite it in the function. I guess what you actually want to do is merge the arrays.

Your coding style in general is awkward. You've managed to use three(!) different naming styles in a single table: all_lowercase, ALL_UPPERCASE and PascalCase. C'mon. Pick one style and stick with it. I recommend all_lowercase for identifiers. If your scripts start with a long list of variable declarations, you're doing it wrong. Does it even make sense to blindly initialize all data with an empty string? This means you may end up with records that are entirely empty. Shouldn't there be a warning instead? Either way, there are arrays, and there are loops. There's never any need for cluttering your code with dozens of variables. For some strange reason, you've decided to tell your users that your database connection failed or that you couldn't select a database. What are they supposed to do with that info? This is your problem, not theirs, so the error belongs into an internal error log on the server (PDO can do that automatically). Your formatting looks entirely random. I recommend you grab a proper editor or IDE (integrated development envirnoment) and fix that. Formatting is very important for the readability of your code.

What exactly is the point of having two tag lists for the same video?

Formal validity doesn't imply safety. For example, a perfectly valid e-mail address can still be used for SQL injection attacks, simply because the address format was never meant to be SQL-safe. Another problem is that validation (as well as escaping) is performed by the application rather than the database system itself, and the application may interpret the input differently. For example, if there's a mismatch between the character encodings, the exact same input can look completely harmless to the application but still wreak havok in the database system. Last but not least, a lot of data cannot be validated at all (like this text), so you'd have to constantly switch between different security strategies. This makes the approach very fragile. Many programmers cannot even get a single strategy right, so I wouldn't necessarily trust them to manage two or three at the same time. So prepared statements are really the only valid approach, and I'd stay away from anything else. The PHP filter library in particular often causes more harm than good, because it's weirdly primitive and deceptive. For example, FILTER_SANITIZE_STRING sounds like it somehow makes every string safe for every context, but in reality it's just a horribly broken HTML tag mangler.

First off: This is mysqli, not PDO. No, your code is not secure, because you print the MySQL error right on your website for everybody to see. This will leak critical information about your database system. Never print internal errors. They are meant for you (or the server admin), not your users. In fact, forget about manual error handling. Simply enable exceptions and leave the error reporting to PHP: // enable mysqli exceptions mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT); $database_connection = mysqli_connect( ... ); Besides that, your static example query is far too trivial to discuss your understanding of mysqli. Security comes into play when you're dealing with dynamic queries. That's when you need security mechanisms like prepared statements.

MD5 isn't the right tool for anything except legacy applications where it's the only tool. There are so many design issues in MD5 that the whole algorithm is just plain obsolete. It's also awfully slow when (mis)used for non-cryptographic purposes. If you want a non-cryptographic hash, use a modern algorithm like MurmurHash or FarmHash which was actually designed for that purpose. If you want a simple checksum, use CRC-32. If you want a cryptographic hash, use SHA-2 or SHA-3. If you want to generate keys, use a cryptographically secure random number generator or a key derivation function. MD5 isn't good in any of those areas, because it was never meant to be. It's supposed to be a cryptographic hash function, but it failed to meet this design goal.

The problem is that you're trying to implement a non-relational data concept with a relational database. This is like choosing an object-oriented programming language and then writing purely procedural code all crammed into a single method. Sure, that's technically possible. But it means you're working against the language/database rather than with it. You get none of its strengths but all of its downsides. SQL expects you to store your data in tables. That's the precondition for all SQL features (data integrity, performance, the ACID properties etc.). If you violate this contract and start cramming your data into a couple of TEXT fields, the database system cannot really promise anything. There's no data integrity, the performance may be abysmal, and concurrent updates can go horribly wrong depending on the concrete scenario. Even worse, you now have a weird mixture of a database language you don't really need (SQL) and a lot of application code to re-implement data processing features for your own model. If the tool doesn't match your concept, one of them is wrong. Personally, I'd go back to the original problem and ask a simple question: What's the best way to store the data? If the answer is “as JSON documents”, forget about SQL and use a document store. If the answer is “as relations”, forget about JSON and use an SQL database.

A small correction: Arrays in class constants are already supported by PHP 5.6. PHP 7 merely added support for arrays in runtime constants (the define() construct). Long story short: Instead of “primitive values”, the book should say “constant scalars (or arrays in newer PHP versions)”.

I agree with ginerjm. Using JSON or comma-separated lists in SQL is a hack, especially when the database system has no native support for this data type (like MySQL). Sometimes hacks are valid, but they should be the last resort. If you need JSON a lot, that indicates you either a) aren't using SQL correctly or b) don't really want SQL (there are many other models, e. g. document stores like MongoDB). This isn't just a theoretical question. Going back to your initial example: If the e-mail addresses are properly stored as rows in a table, adding and deleting addresses is trivial. If you try the same thing with a comma-separated list, you suddenly have to worry about race conditions. If two processes load the list, one of them deletes an entry, the other adds an entry, then one of the two updates will be lost (depending on which process comes last). Note that database systems with native list support (like PostgreSQL) don't have this particular problem.

You indeed cannot assign objects to constants, so this is more of a wording issue. What exactly can be assigned to class constants depends on the PHP version. Prior to 5.6, you could only have scalar literals (booleans, integers, floats and strings). Then costant expressions (like 1 + 2) were added. And in PHP 7 you can even have arrays.

You're using the worst possible regex for the input, so it's only natural that your script blows up. Since you're using a greedy quantifier in the middle part, the entire input after “BEGIN DENY LIST” is consumed. Then the regex engine has to go all the way back to “END DENY LIST”, character by character, each time checking the lookahead. If you anaylze the regex with a tool like Regex Buddy, you can actually see the excessive backtracking and the large number of required steps. If the deny list is very small compared to the part after the “END DENY LIST”, try a nongreedy quantifier (like “*?”). Or simply use strpos() and strrpos(). Regular expressions aren't the solution to everything.

Setting a custom error handler overrides the error_reporting value. Note that custom handlers installed at runtime generally cannot catch errors which happen at compile time or during the startup sequence (syntax errors, extension issues etc.). You should set the handler in an auto-prepended script so that it's executed before the actual application. Also note that there are plenty of professional logging libraries like Monolog. Before you write your own, check if they already do what you want.

Yes. If you want to omit the data for a column that is declared as NOT NULL, you need a default value. The implicit default values you talked about earlier (0, 0.0, the empty string etc.) are a MySQL quirk which I'd only use as a workaround for completely broken legacy systems. If you can fix the problem, fix it.

You need to repair your database schema, not try to bring back MySQL misfeatures. A quick hack to get the old (wrong) behavior is to disable strict mode. However, this also disables important validity checks and doesn't solve anything.

The tutorial is very old, and it's not enough to merely append an “i” to all mysql_* calls. I suggest you learn to use a modern database interface, ideally PDO (it's much better than mysqli). Then try to understand how pagination works. And finally write your own code. I'm sure this will be a lot faster, informative and enjoyable than trying to copy-and-paste somebody else's code from 2008.

It's hard to tell without knowing the exact library. How do you even want the items to be displayed? One per line? As bullet points? As something else?

If the form uses the GET method, all parameters are automatically appended to the target URL in the format name=value.