dalecosp

Yes, I suppose if all you're doing is d'loading a page, it's not. We do a lot of page parsing after the download, in VM's, and CPU does become an issue, particularly if we use threaded workers for the task(s). Might be fun to run as a socket server in a "while(1)" loop....

You must set the proper MIME type and format the message with a "unique" separator field to get HTML email.

If you have a URL, you can use something as simple as file_get_contents() to get page content. There are some quid pro quos --- PHP configuration must be set to allow this (see allow_url_fopen, I think). The next option is cURL, which is often used for this sort of this. Depending on your environment, there may be external programs that could be leveraged for this (for example, many 'Nix environments have the lynx browser installed, which can be called with "-dump" to give you a code dump of a page. Otherwise you're probably reduced to writing something yourself using socket functions. HTH,

Make sure you have a Reply-To; that might help you get the "I couldn't send this" responses from the system(s).

Mail delivery isn't guaranteed. Have you tried sending it to several different receiving addresses on different servers/services? Spammers have made "guaranteeing" mail-delivery much harder than it used to be....

I concur. Sounds like someone who's impressed with his own knowledge coded that, or else they're doing hyperactive future-proofing. d-m-Y seems good enough for me

Your problem doesn't necessarily seem strange, but you've not given us enough detail to even begin to investigate the issue.

This: if ($count % NUMCOLS == 0) { will only be TRUE if $count is 0, or $count is 4. In your "desired HTML" example, you only show two iterations; therefore you'll never close the slide-classed DIV. You should probably get a count of $courses and compare $count to count($courses).

As time required for processing is also your issue, I guess you could fork, or you could just write multiple handlers and have the UI call them all. I'm not sure if it matters; I guess the forking might be better if it's less front-end work. Either way, you are going to end up binding up 100% CPU, I'd imagine, unless you have significant machine resources or the app runs in a cluster/cloud. This stuff ain't too easy, is it?

I'm not sure I know enough about your system and requirements to say definitely "yea" or "nay" on that. Here's how one of my apps works. 1. The UI page is loaded. 2. The user picks a task. 3. Pressing the control for this task activates JS that makes an AJAX call to a PHP handler. Here's the handler, more or less: <?php //doit.php --- For a RESTful home page, this will call one of the *_doit.php files with appropriate GET string. $who = $_GET['doit']; $doitfile="doits/".$who."_doit.php"; echo "Running $doitfile\n"; //for the AJAX; this subsystem needs improved thought given to it. include "$doitfile"; ?> The script's echo output (see above comment) is returned and JS in the UI reads this into a "status" DIV. The $doitfile follows this same logic, echoing needed information when finished which also gets returned to the status div. The $doitfiles take anywhere from a couple minutes to a day or more to run, depending on what they're doing (and to $whom). Cron isn't involved. I've not forked anything either, but I've considered it (we currently have to run a big job or two over the weekend because there's no point in the user doing nothing for two days) ;) Hope this helps,

D'oh, too true! I need to ask the boss for more coal in the stove ... brain's apparently frozen. That would be the reason I have this: function mysqli_result($result,$row,$field) { if (@$result->num_rows==0) return 'unknown'; $result->data_seek($row); $one=$result->fetch_assoc(); $ret=$one[$field]; return trim($ret); }

Reading code is important, though; try not to feel overwhelmed. Grab a section of code, copy it into your IDE/editor, and add comments as you figure out what each line is doing. Then grab the next section and do the same. Once you've got a big section annotated in this way, go back and read over all *your* comments. It can be very enlightening and helpful.

http://www.phplivedocx.org/

Why does it need to be called from a browser? This doesn't seem like browser-related work. If you do need a web-based UI, it would be better to implement a RESTful interface and have the working script called via AJAX, then notify the UI when it's finished.

When you call "mysql_fetch_assoc", you're asking for an associative array, which is what you're getting. This would work with the old mysql_ functions you're using: $result = mysql_result(mysql_query("SELECT COUNT(*) FROM Draws")); You really *should* be using mysqli_ instead: $con = mysqli_connect($hostname, $username, $password, $database) or die("Unable to connect to MySQL"); $result = mysqli_query($con,"SELECT COUNT(*) FROM Draws"); $num_rows = $result->num_rows; echo "There are $num_rows results from your query.";

And, judging by the information in your thread title, #2 is the winner.

Changed them *how* ... or, to what? Looking at this page: http://www.yiiframework.com/doc/guide/1.1/en/database.dao I see a couple, maybe three, possibilities: 1] No PDO extension? 2] No PDO database driver? 3] Incorrect DNS or credentials.

Are we talking user interface here? This sentence: sounds a bit like that; and for web forms these days it's usually handled in Javascript (then double-checked in {PHP} after submission so it doesn't screw up the server). As to maximum values to store in an array ... I suppose there's a working limit. Do you have an alternate plan for storing these values? The thing to do would be test both implementations to see if there was any performance hit/gain from one or more of the proposed storage solutions.

Have your script print the SQL query to standard output/screen/debugger/log so you can actually read it. The syntax error is almost undoubtedly causing the boolean/resource error message.

The comments on the manual page for curl_setopt include this: <?php function _curl_parse_cookiefile($file) { $aCookies = array(); $aLines = file($file); foreach($aLines as $line){ if('#'==$line{0}) continue; $arr = explode("\t", $line); if(isset($arr[5]) && isset($arr[6])) $aCookies[$arr[5]] = $arr[6]; } return $aCookies; } ?> Props to "prohfesor@gmail" ...

I don't see your attachment, Brandon.

True, and thanks. cURL can sometimes be leveraged in this use case, as well, as you imply. The really knotty parts are things like cookie management (you'll typically have two you need to keep track of), and session management, which for some gadawful reason lots of people like to stick in the DB.

System logs? Windows tends to hide them, but you need to take a look. I'd go on a limb and suggest forgetting WAMP and looking instead at LAMP, or, even better, a BSD stack. 500-600 simultaneous connections to a Winbox is a classic recipe for brain-death and the reason that web clustering is a well-known practice instead of something only done by the top <1% of web sites.

These are sometimes called "bridge" addons/modules. You might look for one of those already written. I've written my own bridge between a site and vBulletin. Not for the timid, but if you've got some experience you should be able to hack something together fairly quickly.

Hmm. Not bad thoughts. A few points: 1. Disabling a form control could cause them to think the page is broken and leave. Better might be to simply have JS check the form fields and return false (plus an appropriate error message) when a field doesn't meet requirements. 2. Username/email check --- good. If you can accomplish this via JS and Ajax, that's industry-standard these days. Failing that, there's nothing *particularly* wrong with doing it only afterwards. You must do it at some point. 3. PHP now has filter_input() functions, so you might not have to write so many regexp checks: <?php if (!filter_input($_POST['email'],FILTER_VALIDATE_EMAIL) { //the email isn't valid my_bad_email_foo(); } 4. Password verification: what do you mean ... enforce a specific policy? That's a good idea. This is both right and wrong. Best practice: do both; Javascript on client for user-friendliness and PHP on server-side because of "user UNfriendliness" ;) One comment on your JS: I'm pretty sure you want the VALUE, not the HTML form object. Try: var validate_name = document.getElementById("username").value;