requinix

This topic is now in MySQL Help. http://www.phpfreaks.com/forums/index.php?topic=357554.0

99% of the time that error message means your query failed. There's a problem with it and MySQL couldn't execute it. The actual problem here is moot because your query needs to change. It won't do what you're trying to do. So give it another shot. Try the most obvious solution first, and once that's working you can think about whether there's a better way of doing it.

A little short on details, and I think you mean spring->summer->autumn, but If the seasons were numbered like Spring=1, Summer=2, Autumn=3, Winter=4 (which is #1 doesn't matter as long as they're all in sequential order) then you could use a little bit of math and a UNION. # the non-special events first SELECT ... ORDER BY MOD(season + 4 - N, 4) UNION ALL # special events SELECT ... If N is the number for the "first" season (ie, the current season) then the MOD() will turn the first season number into 0, the next one into 1, then 2, and 3 for the last season. Thus sorting. An alternative would be a big CASE and could be more efficient.

str_pad() works, but personally I prefer sprintf. $current = "0052"; // absolutely must be a string! $next = sprintf("%04u", $current + 1);

There could be a couple options available. What's the site?

You need to add C:\Windows\Temp to the open_basedir list.

IMO it's not that cut and dry. There is only one major distinction: whether you're a blue pill programmer (learn-by-what) or a red pill programmer (learn-by-why), but even there will be some mixed behaviors. The rest is down to just how long you've spent programming and how much progress you've made since you started. By the way, I'm trying to not rant. I think I did well. Blue pill programmers learn by covering various topics. They copy/paste "codes" they find on the Internet, fiddle with them until they work (or give up or ask someone for help), congratulate themselves, and move on. They look at a subject long enough to remember what it's called. When things don't work it's probably some "bug" in PHP or some really weird behavior (unique to them, of course) and the workaround involves changing their code into something different... but whatever, it works now. They hear about some cool concept, find a tutorial somewhere, copy/paste the code (or download "scripts") and figure out how to make their own code work with it. But they don't actually learn. Sure they've dealt with lots of subjects but they don't actually learn what's going on. SQL injection is because someone didn't addslashes() on some input and/or haven't turned on magic_quotes. $_FILES["name"]["type"] is automagically some value that says what the type of file is. Classes are things that have variables and functions. If they get hired at a company it's because the company (a) needs someone for cheap or (b) doesn't understand how to evaluate the skill of a programmer. The programmer will introduce many problems in the code but it takes a long time for them to be noticed because (a) the other programmers are also at that skill level or (b) the site doesn't draw enough users/traffic/attention for anything big to get exploited or broken. Red pill programmers learn by finding out how things work. They see a website and want to make their own, then start learning how websites work. They might find the various options like PHP and .NET and Python and (for this discussion) choose PHP. They use WAMP because it provides the things they need and requires minimal configuration. When scripts work it's because they put what they've learned together into one cohesive unit; when things don't work they try to figure out why and then fix it. New subject matter requires some research: maybe a manual or documentation, maybe a forum or community, or maybe just playing around with it. Maybe they find working examples and take them apart to see how it is they work. And they do learn - maybe not everything, maybe not in depth, but they understand how things work conceptually rather than in terms of what lines of code are needed. Once introduced to the concept that users are malicious they will distrust stuff not because it's in $_GET or $_POST but because it comes from the user. Might wonder where the information in $_FILES comes from, and when they realize it's not from PHP they start wondering "then where?" From the user? So does that mean a malicious user can manipulate the file type? Oh they can? Oh, well then some code needs to change. Hears about SQL injection and how bad it is, and wonders if what they're doing is enough. How about some more direct comparisons? - Classes BPP: collections of variables and functions, classes can get other variables and functions from other classes if you "extend" them RPP: things or entities; OOP is very complicated, there's things like polymorphism and design patterns, and PHP supports a lot of it - MySQL (and databases in general) BPP: tables have columns and rows, use queries to do things; SQL injection is because a programmer didn't escape the quotes RPP: more things and entities, they're probably related to each other somehow, there are different types of queries for different things; SQL injection is because someone, somehow manipulated the query string - File uploading BPP: PHP gets uploaded files, type and name tell the file type and original name, you have to copy the files somewhere RPP: PHP gets uploaded files, you have to make sure the files are safe and then you can copy them somewhere - Validation/sanitization/other basic security principles BPP: regular expressions can check anything, JavaScript is good for doing it, I don't need to worry about security because $reason RPP: regular expressions are complicated, JavaScript is nice but I can't rely on it, I should worry about security regardless of whether I trust my users or not

No. But it could have something to do with that being a syntax error. Which bothers me because you said that code worked in 5.3.1. Which it couldn't possibly.

You can rename the file on the server to whatever you want. I even recommend it. Whatever name, whatever directory. What the user will see is what you show them. As long as you store the original information (eg, filename) somewhere then you can show it to them later. For example, download scripts. The URL can be anything because the (suggested) name of the downloaded file is given by your script in the Content-Disposition header.

What does "doesn't work" mean? Blank page? You get the failure message? Okay so it doesn't do what you want, but what does it do? Also, you're overwriting the $uniekpatient with the uploaded file. First you put the $inhoud stuff in there but then you move the uploaded file there as well. (Unless you actually have to,) you don't need to put $inhoud in a file. All that information is being stored in the database so you can look it up anytime you want. Another possible problem could be with permissions. You're putting the files in the same directory as this .php script (which is a bad idea - put them in a dedicated directory like uploads/ or something). On Linux-/Unix-based systems you need to have write permission on that directory. Try chmodding it to 0777.

cURL would be the best place to go. Check out the examples in the various functions' page; you'll need the CURLOPT_POST and CURLOPT_POSTFIELDS options at a minimum.

So where is $userLevel defined?

Well that's funny. Because when I click that link I posted I arrive immediately at Maybe your Internet isn't the same as my Internet...

What I meant was for you to click the link and read what it pointed to. That's why I put it there.

I think it would involve writing some code, but don't quote me on that.

Try REPLACE.

Wrong syntax. Use $this-> like you would for most everything else. But No. That's not what inheritance is about. The only time you would do this is if the user was a type of database. Which it isn't. If the user class needs access to database stuff then give it access to database stuff. Don't try to force an inheritance hierarchy that doesn't make sense.

Nothing says you have to use SimpleXML. You can build it normally like it was HTML (if that's what you're doing with it): '; ?> MRSS Playlist title); ?> description); ?> duration; ?> start; ?>

You don't have to change anything in that class. Instead of $db->foo use db::instance()->foo.

The "1969 error" (as I call it) happens when you give date() something that isn't a Unix timestamp, or when you give strtotime() something that it can't parse as a date string. If you want to reformat the date string and you can't store it as a timestamp to begin with, run it through strtotime() first. date("format", strtotime($date_string))

Depends on your code. Which is what, exactly?

Any idea what the "default" time for this is, if any? Most of my problems is that images are not updated as soon as i've uploaded them. Lets say that i do some minor changes on a picture in the header, the new one wont appear untill i make a hard refresh. What i've noticed though is that if i wait like 24 hours or so "without a hard refresh", the new picture will appear automatically. So it has to be some kind of timespan somewhere? I don't know for IIS, but I believe Apache uses ETags by default. Those don't use dates or times: 1. Browser requests something for the first time 2. Server sends it and includes an ETag header with an identifier 3. Next time, the browser asks the server for the same thing but includes a condition that says "only send it if the ETag is not $identifier" 4. If it changed the server sends it (and the new identifier), otherwise it responds saying there were no changes and the browser uses its cache What you're describing sounds like time-based caching (be that an Expires or something else). To find out what's really going on you need something like Firebug or Chrome's Inspector or something that lets you view HTTP request and response headers. It is not every day i change the .css file, but it happens some times When that day comes, is the code that i posted earlier a good choice then? That code is only good for PHP scripts. To fix it for normal files you'd configure the web server to use caching as you want. For Apache you can stick a FileETag All in a .htaccess. But again, what you do depends on what's going on with the server and why it's doing what it's doing.

For static files the web server (like Apache or IIS) should handle caching automatically. Sometimes they need a nudge in the right direction but they'll do it. That leaves the dynamic content (like PHP scripts). Often they won't specify caching behavior themselves, so without any advice to go on the browsers shouldn't be caching the pages and a Ctrl+F5 shouldn't be necessary. In my experience caching problems are almost always the result of the web server not handling caching for static files, like scripts and stylesheets, as you expect. Like they'll send Expires headers* that last a long time, or generate ETags** using limited information. Both of those can be fixed quite easily but you only need to do so if you discover a problem. Odds are you won't have problems, but just in case you should do a bit of testing early on and find out if there's anything to fix. * Tells the browser that it doesn't need to "refresh" until a certain date and time. Meanwhile they won't pull down new content - won't even try to. ** Identifiers generated by the server that change whenever the content changes, however you define that. For example, if an identifier depends solely on file size then browsers will only refresh if your edits also change the file size.

You really shouldn't be sticking that many items in an array... Use an insertion sort when you add to the array: keep it sorted and insert the new addresses into the right position. When you're doing that you can also check for a duplicate.

Since your code isn't really readable in its current state, if (quantity shipping = quantity * 7.00 } else { shipping = 2 * 7.00 + (quantity - 2) * 1.00 } [edit] But now it is. //get shipping for additional items above 3 if ($i $shipping = "0.00"; } else { $shipping = "1.00"; } Fix that.