Jacques1

Like I explained in #4: One script for logging in and one script which checks the log-in status. The log-in script can be as simple as <?php session_start(); if ($_POST['name'] == 'foo' && $_POST['password'] == 'bar') { $_SESSION['logged_in'] = true; echo 'Log-in successful'; } else { echo 'Log-in failed'; } The point is that you should test and fix your cURL code before you go to the next step of using it on an actual site. It's not helpful to end up with some blank page and no idea what might be wrong. Um, what? You do realize that the end result is always an HTTP request, right? Or did you think JavaScript performs some kind of magic?

Did you check your phpinfo() as explained in #10?

Hi NotionCommotion, we've actually discussed this topic a week ago. The thing is this: Yes, you can use PHP as a template engine, and that's indeed what is was originally designed for. But PHP is a template engine of the 90s. It may have been good enough in the early days of the Internet when amateurs wrote cute little home pages, but compared to the state of the art, it's hopelessly outdated. Modern template engines can do much more than just insert values into HTML markup. If you look at Twig, for example, you'll find a lot of useful features: A proper syntax. After a while, you'll wonder why on earth you've spent your time writing down stupid PHP tags. You can also define your own statements. Values can be automatically escaped: Instead of cluttering your templates with htmlspecialchars() calls, you simply define an escaping strategy and let the template engine do the work. Sandboxing makes sure that the templates indeed only render HTML documents and don't execute arbitrary PHP code. Template inheritance lets you reuse templates and keep them simple (much like inheritance in OOP). I think using Twig instead of plain PHP is similar using jQuery instead of plain JavaScript: Of course you don't need jQuery. An Ajax request can also be implemented in 100 lines of pure JavaScript code. But why would you do that? Programming is about getting things done, not writing down boilerplate code. Regardless of that: Hard-coding the character encoding isn't really a good idea, and the magic numbers you pass to the second parameter are extremely confusing. That's what constants are for.

Like I said, you should actually fix the error, not use some workaround to make PHP shut up. It's hardly a solution to clutter your entire code with PDO::closeCursor() calls. There's obviously an issue with the MySQL driver, because it doesn't support buffered queries.

With all due respect: What on earth are you doing there? You keep talking about “standard methods”, but this is one of the oddest hashing attempts I've seen in a while: $encrypt = crypt($Password,'6!68$7435!'); What is this strange string supposed to do? Do you realize that the second function argument is for the hash parameters and must follow a very specific format? And where do you generate the cryptographic salt? I don't see that anywhere in your code. When you just enter some gibberish on your keyboard, the following happens: You get the hopelessly obsolete DES-based hash algorithm from the early 80s. There's no salt, which means the hashes are completely unprotected against brute-force attacks and precaculated tables. All passwords are truncated to 8 characters. An attacker who obtains the hashes will be very, very happy, because they can try around 100 million passwords per second on stock hardware. Since you also allow the whole world to fetch arbitrary data through SQL injections, you might as well publish all user passwords on your website. The rest of the code doesn't look any better. My suggestion is this: Throw away the code, learn PHP and start over. I know that this sounds brutal, and it's probably not what you wanted to hear. But it's the only valid advice. If I told you that you just need to fix some small detail, I'd be lying. The mysql_* functions are obsolete since more than 10 years, and you don't even use them correctly (never heard of escaping?). Nowadays, we access the database with the PDO or MySQLi extension. To prevent SQL injection attacks, we use prepared statements. Passwords are hashed with a strong algorithm like bcrypt. This DES stuff may have been good enough in the 80s when people cracked passwords on their C64 or something, but a lot has changed since. An attacker today can get a massive amount of computing power for just a few dollars.

You're getting an error about an unbuffered query, right? That's an issue of an unfetched result set, not the statement itself. By default, PHP automatically fetches the entire result set into memory. However, if you (unwillingly) disable this, make a query, don't fetch all rows an then make another query (like the code above), you're getting an error. Sure, you can use closeCursor() as a workaround. But the real question is: Why on earth are buffered queries disabled on your machine? Maybe you're using the old libmysqlclient library instead of mysqlnd. Look for "PDO Driver for MySQL" in phpinfo().

There's no such problem. UPDATE and DELETE queries lock the row or table, and if other processes need to access the same data, they wait until the lock is released. Also note that it's not possible to explicitly close a prepared statement in the PDO extension. The best you can do is kill the object in order to trigger the destructor.

No, it's not secure. At least not as secure as it should be. Like I already said, this is not a prepared statement. The code just escapes the values. If the escape mechanism breaks (due to encoding issues, for example), then you end up with no security at all. See this example attack.

This is not a prepared statement! By default, PDO just takes the parameters, escapes them and literally inserts them into the query template. So this is really just a kind of auto-escaping. You might as well escape the values yourself. If you want actual prepared statements, you need to set the PDO::ATTR_EMULATE_PREPARES option to false: $link = new PDO("mysql:host=$hostname;dbname=gambling", $username, $password, array( PDO::ATTR_EMULATE_PREPARES => false // important! turn off fake prepared statements )); And, yeah, do get rid of all those useless (and harmful) try statements. I have no idea what you're trying to achieve with them. Printing the error messages on the screen is already the default behaviour on a development system. There's absolutely no point in writing that down. Even worse, now the error messages are always printed on the screen, even if you publish the website on the internet.

This LIKE hack is really not a good solution. Use the DATE() function as suggested by Barand.

You're not sending the cookies anywhere. And the entire log-in procedure looked more complicated to me than just sending the name and password to the site. Like I said, do this step by step. Create a simple test script on your PC and try out cURL in a controlled environment before you jump to some live site.

To be fair, they've actually improved. They're just a good or bad as any other amateur site. But if you want reliable information from people who actually know what they're doing, that's not enough.

Are you sure MySQL is running?

If you actually have several entirely different slider models, there's nothing wrong with making different tables. Your data simply requires this. You can put common attributes (like the image and the text) into a separate table to avoid repeating them in all tables. There's also the entity-attribute-value model. It's complex and ugly, but compared to the JSON massacre, it may still be the better choice.

Search for something like “php curl login”. On the first page, there's already a Stack Overflow thread where this problem is discussed in great detail and with many examples. The relevant cURL options are CURLOPT_POST and CURLOPT_POSTFIELDS for making the initial POST request. You'll also need CURLOPT_COOKIEJAR for writing the session cookie to a file and CURLOPT_COOKIEFILE for reading the cookie from that file.

There are literally hundreds of examples on Google. Why don't you look for them yourself and come back when you have a concrete question? To get familar with the authentication procedure, it might be a good idea to set up a simple test application on your localhost. Make one log-in script and one script which requires a valid session. See if you can post your credentials to the log-in script and store the session cookie you get back. If that works, see if you can access the protected script with the stored cookie.

This site uses a cookie-based session system. If you inspect the cookies in your browser, you'll see one called “ASP.NET_SessionId”. This obviously carries the session ID. So you need to send your credentials to their ASP.NET application, store the session cookie and then send it along with every request. This is way beyond the capablities of file_get_contents(). Use the cURL library instead. Note that you'll need a basic understanding of how HTTP works.

First of all, Wordpress is not exactly known for quality, so I wouldn't use their stuff for inspiration. The problem with storing JSON data (or any other violation of the First normal form) is that you work against the database system. You essentially break all features of MySQL and reduce it to a primitive string store. There's no type safety, no referential integrity, no way to actually query the data. You just have one big pile of characters that is meaningless for MySQL. This also means you lose MySQL's ability to handle concurrent queries. Imagine the following scenario: Two PHP processes try to edit the same JSON document at the same time. The first process makes its changes and writes the result back to the database. Then the second process changes the original data and also writes the result to the database. Unless you have a special locking mechanism in your application, you've now overwritten all changes of the first process. That's obviously a problem. However, the biggest argument against breaking the relational model is that it's usually done for the wrong reasons. You somehow assume that you need one table per slider, but I don't see why that would be the case. If you post your concrete data model, I'm pretty sure we can figure out a proper relational implementation.

No, he or she doesn't. Read the question again: The goal is to make an equality check. Yes, I already said that.

There are no “single-quoted regexes” or “double-quoted regexes”. What you have there are two different string expressions which are parsed according to the usual rules. In your case, the result is the same. The content of the string is then used as a regex. If the conents were different, then of course you'd have two different regexes. But since the content is the same, it's the same regex, regardless of whether it comes from a single-quoted string or a double-quoted string.

You're using the assignment operator “=” instead of the equality operator “==”, and you've confused yourself with exotic precedence rules. Fix the operator, and use parentheses to define the order of evaluation. When you find yourself juggling with different variations of the logical “and” operator, that's a sure sign you need to stop. The condition can also be simplified to $comparisonTimeH != 0 || $comparisonTimeM >= 1 If $comparisonTimeH != 0 is false, then $comparisonTimeH == 0 is automatically true, so no need to write that down.

Have you guys ever wondered why PHP is generally regarded as a toy language for kiddies and gets as much respect as a fart in the elevator? I think now you know why.

Psycho, it's incredibly frustrating that whenever I try to explain something and get people to think for themselves, you or one of your buddies jumps in and posts the solution. Do you know the saying about teaching a man to fish? You've spent many years handing out free fish, now it might be the time to teach.

I'm saying that you need to sit down with a pencil and a piece of paper and write down the procedure for getting from one date to another. That's how you solve problems: You start with a vague idea, you come up with a concrete solution, and then you implement the solution. If you cannot do the solution in your head, write it down. I'm trying to get you from the first stage (the vague idea) to the second (the concrete solution). So again: How exactly do you get from one date to the other? From our perspective, it is. MySQL will take care of jumping to the next year if necessary.

Well, just write down how exactly you derive the Processed Date “1996-02-09” from the Received Date “1996-02-03”. The year is always the same, the day is always the 9th. And the month? If ... In fact, what's the point of physically storing the Processed Date when you can calculate it ad hoc?