requinix

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.

Yes, you need to modify createMarker(). And load() too. createMarker() needs another parameter so it can know what the URL is. It could be passed the whole URL that it uses verbatim, or just an ID number which it turns into a URL. Doesn't matter. Then load() needs to grab that information from the XML (or wherever) and pass that to createMarker().

Use doubles for everything, then round all numbers to some maximum degree of precision. 1 + 2 might turn out to be 2.999999999978 so you round and end up with 3.

The code you posted... It has nothing to do with putting stuff into the database. Isn't that where the problem really is? Getting it into the database?

Let them classify themselves. Present three challenges ranked low, medium, and high, and open enrollment to everybody. I like to think the staff knows enough people well enough that we could tell when an A-rank coder solved the C-rank challenge. With that said, if there were badges respective of the challenge then that coder bragging about the "I can solve basic math equations" badge might not look for good for them.

Define "doesn't work".

This topic has been $verb->toPastTense() to mod_rewrite. http://www.phpfreaks.com/forums/index.php?topic=354538.0

mod_rewrite cannot do substitutions like that. Technically it can, but it's absolutely ridiculous and should not be done.

Not really. SMTP is a protocol for moving emails between servers. Programs use this protocol to send (and thus receive) email. There are many programs that handle either/both sides of that transaction. POP3 and IMAP are protocols for accessing stored emails. Both allow for retrieving email without deleting, both can keep or delete emails after the user has "deleted" them. IMAP is "better" because it has more features and fewer limitations.

The errors I see aren't syntax errors.

Math.random is the main part, the rest is just details.

Off the top of my sleep deprived head (I'm at 21 hours I think): SQL injection, XSS injection, cross-site request forgery, SSL, and encryption practices to start. There are also a few nuances with PHP like the downsides of loose typing, how form variables are strings, scalars versus arrays from forms and how PHP can barf on them.

Only include the conditions if you actually need them. // multiple statements $query = "SELECT ..."; if ($condition) $query .= " AND table.field LIKE '%foo%'"; // one big query $query = " SELECT ... " . ($condition ? "AND table.field LIKE '%foo%'" : "") . "

The LEFTness only influences the join condition - if a WHERE condition excludes something, it'll be excluded. Does it show up if you drop all the worthless LIKE '%%' conditions?

Can you describe your situation more? It almost sounds like you're being a bit paranoid.

Sometimes yes, sometimes no, and it depends on the system. Assume the worst: you'll have the same file open by multiple processes all doing different things at the same time. You can, however, lock the file and eliminate the guesswork.

You're a bit right but mostly wrong. static is an object-oriented thing, yes, but <?php blocks are not classes. If you're staying in the same file you don't need to "static" anything. The <?php blocks only control when PHP works; leaving one and entering another later won't affect your variables.