requinix

UTF-8 is fine. There are others but this one is the most common. As for how it impacts your code, I don't know. Functions like strlen() and substr() stop working correctly, HTML pages need the encoding specified, and your database tables have to change - for starters.

Right now, www.cleep.us "works" (does not show the GoDaddy page) for me. A CNAME says "this website can be accessed at whatever server [iP address] hosts X". So right now your DNS says The browser then has to look up where that server is (I get 24.179.144.72). Next the browser starts sending HTTP requests. It'll send a request for "www.cleep.us" to 24.179.144.72. If that server does not know how to host "www.cleep.us" then it'll probably (a) complain that it doesn't know how to host that website, or (b) show whatever it considers to be the "default" website. In this situation it does the latter, which is the most common choice. So, what are you trying to do? What do you mean "it should have to know"?

Spend a minute trying to convince them that it's a stupid idea. Because it is. I, for one, would not at all be surprised if said print button didn't always work in all clients. Imagine how frustrated users would be if they clicked this button and it did absolutely nothing...

Does the server hosting stats.weblyize.com know that it should also host www.whatever? Have you waited long enough for the DNS changes to propagate? Also, it'd help to know the domain name (means we could test it ourselves).

Probably. What do you mean by "load another form"?

This manual page covers everything. Also, whenever you're in the PHP manual, try to read the user comments too. They can give insights, workarounds, and explanations that the manual proper doesn't.

It's not suicide, but it is inadvisable to use limited character encodings (like Latin1). You might as well start using it now so you don't run the risk of having to switch to it later.

You are paraphrasing your problem. Please don't. What is the actual code that's failing? Could it be that you're trying to put variables into singly-quoted strings? Because that doesn't work.

That's not a URL. That's some HTML with a bit of PHP code sprinkled in. What is the actual URL that is failing? The one that shows up in your browser's address bar.

If that other PHP file is also on your server you can just include() it. It'll have access to $_POST and everything.

What is the URL that is failing?

Oh. Sorry about not getting around to this within the 35 minutes you had allotted me, but I'm sure somebody else knows what I was thinking of doing.

Well, I can reduce that big if block into two conditions to check and a bit of math, but I have no idea what you're asking for.

I've seen some arguments against it but most of them deal with distributed libraries using it (eg, Prototype), adding unofficial functionality that's added officially later (eg, getElementsByClassName), or sticking stuff into the "wrong" prototype (eg, Prototype and getElementsByClassName+each). In cases where the code is just for myself and I'm adding simple functionality to something that won't change or won't have a different implementation then I don't see a problem. Maybe I just don't see all of it? Take hiding an element. Node.hide() is very cut and dry: take this Node and hide it visually. A NodeList.each() is a bit iffier: the first argument is very likely going to be a function, except that function could run in the Node's scope and/or take an argument for the Node. But even then you can NodeList.prototype.each = function(obj) { var self = obj || this; It's extra coding but you gain a handy function.

forecastday is actually an array of objects. You can (and should) foreach over it.

You mean like jQuery's insertAfter()? existingelement.parentNode.insertBefore(newelement, existingelement.nextSibling);

For a static image the basic strategy is to draw the needle on top of a background image. Depending on the needle the drawing can be easy or difficult. For a rising needle, look to canvas/SVG first using the same basic "drawing a needle on top" idea. Those can handle it quite easily and should cover most browsers. It would also mean you could, say, fire off occasional AJAX queries to see how the figure has changed since it was first loaded and move the needle accordingly. On a different note: IMO a speedometer doesn't quite have the same connotations of saving money: one is about going faster while the other is about spending slower. It's the same way a thermometer wouldn't be appropriate: rising temperatures versus falling costs (not to mention that thermometers are most often used in fundraising-type situations). If you'd like more ideas could you describe what these people are saving money on?

On content_option_id too? What does EXPLAIN SELECT (the rest of the query...) show?

That puts all kind of weird images in my head... The database design sounds quite simple. You'll want two tables: one for regions and one for these savings. The regions table is so that you don't have to try to parse or format or recognize names that people enter - they just pick one from a list. The table provides that list. The savings table has columns for a date, the user's name, a foreign key to the regions table (to identify the region), and an amount in pounds. Querying those tables is also very easy and can provide everything you've mentioned. But what's a "speedo type dial image" and a "speedo type gauge"?

Do you have indexes on the appropriate columns?

How did you make fire?

You're already putting the ID number in the URL - you can identify the product precisely. Why does it matter if the name isn't exactly right?

The problem is elsewhere. What's the code for inserting into the database?

if (!$option_id = '') { Also, that is bad form. You should use if ($option_id != '') { (which would have prevented the accidental assignment too)

Only if you're already using sessions for something else (which I expect you are). Abstract that out. Use a Registry for all the settings, then have your code use that Registry. Then your code won't care about where the settings actually come from. For the sake of making things easier, I'd forgo the usual pattern and just go with a bunch of static variables. class Settings { public static $SETTING1; public static $SETTING2; public static $SETTING3; private function __construct() {} public static function load() { if (!defined("SID")) session_start(); if (empty($_SESSION["app settings"])) { // load settings from file and into $_SESSION } $s = $_SESSION["app settings"]; // shorthand Settings::$SETTING1 = $s["setting1"]; Settings::$SETTING2 = $s["setting2"]; Settings::$SETTING3 = $s["setting3"]; } } Settings::load(); Then Settings::$SETTING1 to grab a setting. Since you're effectively caching the settings, I'd put in some mechanism for automatically reloading the settings in case they change. I suggest looking at the file modification time.