requinix

My preferred way is to import the data into a temporary table then craft an INSERT... SELECT statement, or for more complex logic a loop+cursor with individual INSERTs.

A simple JOIN (query) can do this, like "SELECT city name, COUNT(need) FROM city table JOIN needs table ON city table's city = needs table's city GROUP BY city table's city"

Yes it's possible, but how you do it kinda depends on what this variable is and how you're using it.

Name each checkbox like <input type="checkbox" name="select[]" value="id of the image" /> Select Then array_filter((array)$_POST["select"], "ctype_digit") will be an array of all the IDs selected. The magic is the [] in the name which tells PHP to create an array instead of just a single string value. Don't forget to check isset($_POST["select"]) first: if none were checked (or the form wasn't submitted) then $_POST["select"] will not exist at all.

Flags aside, " ^ beginning of the string (sometimes line) (?:...) group but don't capture [a-z0-9_-] letters (including uppercase since you have /i), numbers, underscores, and hyphens | or ('x|y' means 'x or y') \. literal period (?!...) negative lookahead ('the following must not be ...') + one or more of the previous, which in this case applies to the first group Summed up, the expression matches any sequence of letters/numbers/underscores/hyphens/periods but won't allow two (or more) consecutive periods.

Pattern Modifiers

It doesn't look like the one disallowing direct access to index.php?code=xyz is working either. Can't test the one about hostnames because apparently you have a shared IP address (so if I try a different hostname the server won't know what to do with it). What happens if you have RewriteEngine On ErrorDocument 404 /error/404.php ErrorDocument 500 /error/500.php RewriteRule test /index.php?test [L,R] and you go to shortit.org/test?

There's two parts that deal with trailing slashes. # redirect to "this2" RewriteRule ^profiles/tutors/index\.php /%1/%2/?%3 [R=301,L,NE] That "/%1/%2/?%3" includes a trailing slash (just before the ?). The other is RewriteRule ^([0-9]+)/(.+)/$ /profiles/tutors/index.php?tutorCode=$1&tutorName=$2 [L,QSA] The "^([0-9]+)/(.+)/$" requires a trailing slash. It's as simple as removing the slashes. And fixing whatever links you output to not include them (if you haven't already).

...Maybe? # the next Rule only matches if there's a *.html file for the request RewriteCond %{REQUEST_FILENAME}.html -f # the next Rule only matches if the request isn't for a directory RewriteCond %{REQUEST_FILENAME} !-d # rewrite the request to include a .html suffix RewriteRule ^([^/.]+)/?$ /$1.html [N] # the earlier Conds do not apply to the Rules below # rewrite the request to include a .php suffix RewriteRule ^([^/.]+)/?$ /$1.php [L] # same as above but allow a parent folder RewriteRule ^([^/.]+)/([^/.]+)/?$ /$1/$2.php [L]

No, it isn't. What errors?

And your question is what?

Okay... Well, if you don't want the slash then change the two RewriteRules so that they use the URL format you want.

Well the only thing I can think of is with the last line. Try RewriteRule ^/?([a-zA-Z0-9]+)$ index.php?code=$1 [L] If that fixes it... I swear I'll never understand when those slashes come up.

Use a RewriteCond to see if the hypothetical file exists. Like RewriteCond %{REQUEST_FILENAME}.php -f Oh, and it's REQUEST_FILENAME, not _URI.

Can you post your entire .htaccess so I can check if I made some stupid mistake?

#1 thing to remember with mod_rewrite is that when a RewriteRule matches rewriting will keep going on with that new URL unless you explicitly stop it (like with a [L]). [edit] Annnd moved.

The problem is that rewriting won't stop when a rule matches and executes. Follow along: 1. I go to www.shortit.org/IlwU3g 2. The first RewriteRule matches and the URL is now /index.php?code=IlwU3g - But without a redirection - Rewriting continues! 3. The following RewriteCond and RewriteRule match so I'm redirected to shortit.org/index.php - RewriteRule does not match against the query string so the .* is just "index.php" - Rewriting stops because of the [L] flag In other words, you have the first Rule which adds a query string, but then you have the second Rule which strips it away. Here's how I would do this: "# First, the stuff I don't want # Only shortit.zxq.net and shortit.org are acceptable hostnames RewriteCond %{HTTP_HOST} !^(shortit.zxq.net|shortit.org)$ RewriteRule ^ http://shortit.org%{REQUEST_URI} [L,R=301] # Don't allow people to go to /index.php?code=xyz and send them to /xyz # I prefer looking at the exact request for things like this RewriteCond %{REQUEST_URI} ^/index\.php\?code=([a-zA-Z0-9]+)$ RewriteRule ^ /%1 [L,R=301] # Now stuff I do want # Non-existant requests like /xyz are shortcodes RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^([a-zA-Z0-9]+)$ index.php?code=$1 [L]" Ignore the quotes, code tags don't work that well yet. For the record, with that one "don't allow them to go to /index.php?code=xyz" I would actually just RewriteCond %{REQUEST_URI} ^/index\.php\?code=([a-zA-Z0-9]+)$ RewriteRule ^ index.php? [L] make it look like a normal request to /index.php (doesn't reveal anything about how your shortcodes are URL-rewritten).

I was going with the assumption that since the field is a TINYTEXT that it would contain text. Thus a textbox or textarea.

If you're simply talking about whether the field has a value and not about whether the form was submitted, the isset() stuff is partially redundant but mostly useless: $_POST['long_name'] will be an empty string already and thus isset() will always return true.

In terms of what I think you want to do, memory_get_peak_usage() might be more appropriate: tells you the maximum amount of memory PHP claimed rather than just what it has at the moment. [edit] No! Code blocks screw up ASCII art... I had a chart showing sample memory usage over time and how memory_get_usage() and memory_get_peak_usage() differ. Oh well. [/edit] Adding $real_usage=true shows you that PHP allocates memory in chunks - it doesn't mean your code is using that much memory but that PHP claimed so much for itself (and will give you parts of that as needed). As for the original question of why it uses more memory, I'm not intimately familiar enough with PHP's memory model to understand. But I could certainly make some fairly-educated guesses.

Besides actually needing to, you should change the checkbox names to something easier to deal with. Like <input type="checkbox" name="neighborhoods[scottsdale][top] value="SC" onclick="showBlock('area_Scottsdale', this.checked)"> <input id="ScChkbox0" name="neighborhoods[scottsdale][]" type="checkbox" value="Scottsdale 1"><label for="ScChkbox0"> Scottsdale 1</label> <input id="ScChkbox1" name="neighborhoods[scottsdale][]" type="checkbox" value="Scottsdale 2"><label for="ScChkbox1"> Scottsdale 2</label> ..... <input id="ScChkbox9" name="neighborhoods[scottsdale][]" type="checkbox" value="Scottsdale 10"><label for="ScChkbox9"> Scottsdale 10</label> Now $_POST["neighborhoods"] will look like array( "Scottsdale" => array( "top" => "SC", // checked Scottsdale 0 => "Scottsdale 1", // checked #1 1 => "Scottsdale 10" // checked #10 ) ) You can look at just the [number] items to see the neighborhoods but if they didn't check any then all you'll have is the [top]. You can do whatever you'd like with that. [edit] For instance, foreach ($_POST["neighborhoods"] as $place => $options) { // they checked $place if (count($options) == 1 && key($options) == "top") { // they didn't check any of the sub-things } else { // they checked some unset($options["top"]); // don't need this // implode() on $options would be a reasonable idea } }

No changes? Since apparently the city is required, where do you want it to show up in the new URL?

PHP sometimes does unusual and unexpected things with memory. Try using memory_get_peak_usage() instead.

Sigh. Won't work. ^ THIS Won't work.

Look at the error $_FILES['editcar_fileupload']['error'] to see if a file was actually uploaded (or if there was some other error). Error codes