dalecosp

My guess would be that the mbstring extension isn't installed.

That usually means calling htmlentities($_GET['somevar']) ... theory being that if they've tried to embed something funny (brackets, binary chars, etc.) they'll be converted into something relatively harmless by htmlentities. If you use SQL, you usually call some sort of escaping function instead (mysqli_real_escape_string, etc.) ... or you use prepared statements.

Probably. I tend to hard-code them as my code isn't for public consumption.

It could, I think. In theory, at least, it both checks for the existence of the file to be included, and guards against calling external resources if the server allows it.

Sounds like you're thinking pretty sharp; there are a couple of other things I can think of off top of the head re: security. Please note before I begin that I am not a security expert, and I don't play one on the WWW Passing the name of the included content in the GET string could *possibly* lead to other security issues if remote includes are allowed by the server. Consider if a spammer could send email to someone with a URL like "yoursite.com/script.php?include=evil_server.org/badscript". If they could infect someone like this, you'd have someone mad that their machine was compromised and likely blaming you. That's part of the reason that the file_exists() is in the code; you might one to go one better and do something like: $dir = `ls includes/`; $dir_list = explode("\n",$dir); array_pop($dir_list); // check if you need this; usually from `ls` we get an extra blank line. if (!in_array($dir_list,$requested_include)) { go_away_bad_haxxorz(); } The good news is that most PHP installations have the remote includes and remote urlfopen() calls disabled these days for reasons like these.

http://www.generateit.net/mod-rewrite/

Well, the first technical constraint would be the data type of the current "additional information/facts" column. How much data will it hold? Because you can CONCAT things in SQL: //let's add data about this person and delimit each statement with a semicolon ... update people_details_table set additional_info = concat(additional_info,'; ',$yet_another_fact) where id = $some_number; EDIT: speaking of "additional info", you seem to have posted the same question twice. Is it possible to undo that?

Well, that's a tad funny, since I got it from your attachment above I typically write a page so that when something is POSTed, it says, "your submission was accepted", "thanks for the info", "would you like to do another", "here are some pictures of cats", etc. It's kind of a programming rule; you take an action, the computer gives some indication of the result (unless it's a UNIX CLI program ...) I don't know the answer to that in this case; I would ask the author of "servlet.WebToWeb", whoever that may be ... someone @ salesforce, perhaps. That would be "curl_exec": It executes the cURL process based on the CURLOPTS that were set, and since RETURNTRANSFER is true, any output from the script that handles the POST (as you note, there might not be any), will be placed into the variable "$the_results".

Nice thread. The quest for deliverability is never-ending. Kudos to you for pushing so hard for it. SPF is an under-appreciated protocol. I would definitely look into it if you have the ability to publish records (it's not too hard to do). The official SPF lists are at openspf.org, I think ... I've found them to be quite helpful most of the time.

All this means, tell the boss you need the IT department to get on it, because Asynchronous Javascript and XML (AJAX), is taller cotton then plain PHP. You need to have PHP (or something like it) that you can write on the server-side, and Javascript (and there's nothing else like it) on the client-side, and be familiar with the DOM, which one of the Javascript/ECMA committee members has called "the worst API in the history of computing." Now, if they still are gonna task you with this, tell them it will be weeks, maybe a couple months before you can get it done, and you won't be working much on sales during that time. And we'll be around if you need to ask questions ... but we can't write it for ya.

That's pretty easy: include "includes/default_content.html"; //or whatever the name is ... ;-) Well, that's a tad different. First, a couple of concepts. PHP is a server side language, so, to do this solely with PHP, you would make your link somehow indicate to the server what the content was supposed to be, and the receiving script (whether that is $_SERVER['PHP_SELF'] (e.g., the script with the links on it in the first place), or some other script (say, "show_content.php") would look at the query_string and include content based on the parameters it sees there: //we're looking for "include" in the GET string... if (isset($_GET['include'])) { include "includes/".$_GET['include'].".html"; } else { include "includes/default_content.html"; } //NB: the above isn't terribly safe, and "include" is a really dumb name for a GET variable. This is for demo purposes only ... The Web 2.0 approach, and what I *might* hear you saying (but I'm not sure), is "how do I do this on the fly without reloading the page" (is that what you mean?), and the answer to that is Javascript and the DOM, which isn't what PHPFreaks is about, although none of us can escape the domination of the JS Overlords, and most of us are at least *getting* a clue about it. So, which is it, exactly, that you want to do? (Was I easy enough on ya?)

You don't paste the code directly; use your own variables ;)

I don't know about APC - it looks kind of heavyweight at first glance. Here's an outline of a cache theory I developed. It's fairly simple. At the top of a script that does "heavy" processing and outputs HTML, I define a $cachefile somewhere on the FS (typically we'll use /dev/shm for fast access, but it could be under /tmp or wherever). The script then checks the existence of $cachefile and the file's mtime(). If the file exists and is fresh, it's include()d and processing stops. Otherwise, the output is computed, added to a variable, and then echo'ed to the browser, after which it is rewritten to $cachefile. As for cron, the way I'd do this is:A script is written to product the HTML output. It's CLI or CGI-based and *outside* the document root. Cron runs the script at the appropriate time of day, once per day (if it's a daily thing, as you indicate). The site includes the generated HTML file. All of this is based on the theory that a simple PHP include() is going to use less CPU than a lot of other operations (DB calls, variable assembly, etc.). Hope this helps,

Alternatively, if it's a 24 hour thing, do you have cron( ? Maybe a cron script could render the page and it could be served statically the rest of the time?

Can you cache anything? I've used this approach to keep systems from using a lot of CPU munching on data which doesn't change too often (10 minutes, or 30 minutes, or an hour, etc.)

Wow, you've got 7M pounds? Could I have 100,000 or so? What's wrong with the way you're doing it? It appears to be working ...

What's the difference between these PC's ... Screen resolution, by any chance?

You're welcome!

Um ... sort of. http://php.net/manual/en/curl.installation.php Most installations of PHP have cURL enabled by the administrator when PHP is installed, but YMMV. Comments inline. //You have the data already; now let's feed it to cURL. $my_post_array = array( $first_name, $last_name, $phone, $from, $subject, $company, $city, $state, $zip, $machine, $message, $ocode ); //initialize a cURL handler ($ch) using your URL ($urlcode) $ch = curl_init($urlcode); //set cURL options curl_setopt_array($ch, array( CURLOPT_POST => 1, CURLOPT_POSTFIELDS => $my_post_array, CURLOPT_FOLLOWLOCATION => 1, CURLOPT_HEADER => 0, CURLOPT_RETURNTRANSFER => 1, ) ); //perform the POST action. You can use $the_results to see what the page said in response to your POST, //since the cURL options "RETURNTRANSFER" was set true. $the_results = curl_exec($ch); HTH,

Do you have shell access? top(1) is nice for looking at issues like this. You don't mention any database stuff. If you are running a DB, there are some tools (I'm thinking mysqltuner.pl for MySQL) that can help analyze issues with that subsystem. Log file analysis *might* help ... we have sites that get bot-bashed regularly. Of course, since it's a shared server, it could be that one of the other users is being bashed ...

I *think* you need to reset $dataArray for each new user; by not doing so you keep appending the new user data to the $dataArray and then you write it to the worksheet. if ($row['UserID'] != $uid) { $tn = $row['TeamName']; $dataArray = array(); HTH,

Well, I think you're making progress I don't see it ... the changed code, that is ... It sounds like more issues with the loop. You might try commenting your code, loops, etc. and see if you can find any glaring logic errors.

The canonical way is: <input type='hidden' name='id' value='<?php echo $id; ?>' />This has one potential problem; the user's ID number is then viewable in the browser's HTML source. Since you've already called session_start() in the script, I'd stick the ID in the $_SESSION array and then use that value when I process the query in update.php.

If I'm understanding correctly, you'd need code that would fetch the page at the URL, parse it for it's TITLE tag and various other attributes, and then display them. Should be possible.

Can't you use "soldOn", then? If so, this could be as simple as ORDER BY soldOn DESC LIMIT 1, right? (Forgive if I'm being thick ... my native language isn't SQL )