requinix

Use FTP or whatever you have to create that file yourself. Put a 0 in it. Then change its permissions (chmod) to 0666 (=readable and writable for everybody) and try your script again.

$var = fopen('$myfile,\'r+\''); Reconsider that.

There might be a bottleneck downloading the file from FTP. Can you tell how fast that connection is? Is it about 8KB/s? When you're downloading the file yourself, does the speed vary or is it constant?

Probably because the $time->toAtom() function does it that way intentionally. Look at its code. Let me reiterate: there's nothing wrong with what it's doing (provided it's not doing anything wrong). Whether it shows noon UTC or 2pm UTC+2 doesn't really matter.

This is okay but this is not

Then unset it in the php.ini and let it pick up the timezone from the computer. If that doesn't work (or I'm just misunderstanding you) then set date.timezone according to this list (basically, pick whichever city is closest and in the same timezone with the same DST rules).

Huh. How about the timezone for the computer?

Too bad it won't work properly on input like This is okay but this is not

Your various img and script srcs, link and whatever else hrefs all need to be absolute. Right now they have relative URLs like Or maybe ../path. Whatever. Those are all relative paths and they're relative to the current page. Go into enough subdirectories and the paths will break. Change them to include a leading slash: That way they'll always come out of the same place regardless of the current page.

I'm also really tired so my normal inhibitions are... well... not there. Stuff with forms, assigning stuff that doesn't exist, !$x versus empty($x), it's all very confusing and can take a while to get a handle on. The code bits look different and represent two different things, it's just that in this case they both arrive at the same results.

Probably nothing. What does echo date("r"); output? If it uses the right timezone then you have to adjust whatever $time->toAtom is.

That computation is fine. var P27_max_convert = ((parseFloat(P27_max) * parseFloat(1000)) / parseFloat(0.00) / parseFloat(12)); This one isn't. (And if you're wondering, isNaN() does not check for infinity.)

"Z" represents UTC and is valid shorthand for its timezone. As long as the time is correct for UTC (it was converted from the local timezone properly) you're fine and there's nothing wrong.

Just feel like making a bit of a correction: 1. They do not "exist" if they weren't submitted (eg, the form wasn't submitted). That's because $_POST[foo] doesn't exist, resolves to null, gets assigned to whatever variables, which then (a) don't "exist" because they have a null value, thus (b) aren't isset(), and so © are empty(). They only exist if they were submitted with any value at all, but the best part is doing !$foo will create problems when it shouldn't - like if $foo="0". That's true for empty() too actually. 2. OP has to do empty() on what's in $_POST or else PHP can/will fire undefined offset warnings during the assignments. 3. The two bits of quoted code are identical. They do exactly the same thing. There is no difference.

You can't give a value to a SELECT. Mark the appropriate option as the default, so class17select="selected='selected'".

Sessions are cleaned up periodically by PHP or the system (depending on the setup). Until then the session is always accessible by anyone who has the session ID and at any time.

No. You shouldn't really be doing that at all. Autoloading only happens when you try to reference a class (like instantiating it or something else I forget) and if the class's file hasn't been included it. If you require() the file then try to instantiate it the autoloading stuff won't fire - it's already been loaded. Your class files should just have the class definition with very few exceptions. Make an autoloader using spl_register_autoload() (__autoload() is deprecated) that includes the appropriate file when the class is requested. Then every time you need the class you try to use it. And if you only want one instance of a class around then you should be using a Singleton, not a pre-instantiated class.

I've never heard the term "design method", but a design pattern is basically just a way of solving a fairly common problem. For example, have you ever wanted to make a class that stores a bunch of data so it's all available in one place? There's a design pattern for that. Ever wanted to make sure that only one instance of a class exists and others can't be created? There's a design pattern for that too. Ever seen a really complicated class and felt like making another class that's much easier to use? Guess what? Google it. There's a ton of information out there on the subject.

Thanks for the heads-up thorpe. brooksh, if you didn't see, the code is not malicious. It's quite simple and could not cause the 100% usage you're seeing.

Great. Then let them enter whatever they want and you htmlentities() or htmlspecialchars() it before you display it anywhere. (And yes, I realize there is no "onhover" event. I wasn't trying to be precise )

It's complicated. Can you post the whole file unedited?

The fact of the matter is that it can be very difficult to sanitize arbitrary HTML. strip_tags() will remove tags you don't want but it won't do anything about attributes; even if you allowed only tags someone could use You could use regular expressions to deal with most of this by making sure there aren't any invalid tags #?b[^>]+># (if this matches then there's a tag with something inside it), but all you're accomplishing is allowing for BBCode tags that use s instead of []s. Which isn't bad, it's just that you've gone full circle. Either way you need to do something with the comment form if you want to allow some kind of markup.

Besides finding some library that does the session+database stuff already, not really.

Compare the output of phpinfo() on the two hosts. Normally these white page issues are because of syntax errors, and if it's happening after a migration then it's quite likely that the PHP versions and/or configurations don't match.

They don't disallow it - they can't, there's no way to. But they can tell you that using the normal session is pointless, and it is for the reasons they stated. Except you can use sessions in a database instead. Since all the cloud servers can access the database they can also share the session information. Normal sessions are handled with files and PHP just reads and writes variables and values in them. So instead of files you configure PHP (by writing code) to use a database instead. The rest of the session stuff with $_SESSION and session_start() still applies without any changes, but behind the scenes PHP goes through some custom code for loading and saving.