kicken

Unless you're doing something else that you didn't show, then that would be expected. Your sample script does not produce any output. Add echo $contents; to have it display the contents of the file.

The syntax your using requires PHP 5.4.0 or newer. A call to phpinfo will tell you what your using. If it's not new enough, then you need to change it to the older syntax, which is basically just using array( .. ) rather than [ .. ]. $return[] = array( "name" => $array["name"], "uf_id" => $array["uf_id"] );

It's not like this change is going through tomorrow. They probably won't be removed until 5.6 or maybe even 5.7, which are probably a good year or so away at least. Even after they are removed, most hosts will probably still offer them via older PHP version (some hosts still over PHP4!) or custom builds that enable it. The hosts don't want to send all their customers running after all, bad for business. I'd venture to guess that the hosts will probably keep the extension around for a good three or more years. Ultimately what this means is that anyone affected by this has between now and probably 2016'ish (or maybe longer even) to get their scripts updated or replaced. If they can't manage such an update with that much warning time, that is a personal failing. While they may not "deserve" to have their site go down, nobody is going to be feeling sorry for them.

Some google searching lead to http://www.tvmcalcs.com/tvm/formulas/regular_annuity_formulas that describes the actual math formulas behind the function. The one you're interested in is probably the third one: Periodic Payment when PV is known

I don't much like working on my laptop (way to spoiled by my dual 24" monitors) but I did figure if I got too tired of standing I could take the laptop and go work at the kitchen table for a while. Going to probably spend most of the night just trying to uncover my desk from all the stuff I have piled up on it so I can raise it lol. Such a slob I am. One potential problem I may face is the shelf I put above the desk. The way things are positioned now, once I raise it to a comfortable height my monitor probably won't fit where it currently is. I think I can work around that though.

Seems to be working good on my droid. Looks nicer too from what I remember of the previous version.

So, in light of my failing desk chair, and remembering talking about it before, I'm considering converting over to a standing desk. For those of you using one, any tips for how to best set things up or things to do to ease the transition?

Maybe, it depends on what implementation is in use. If it's using the mysql client libraries then it may work. If it's using PHP's mysql native driver (mysqlnd) though it won't, as indicated by the note: I would advise you just include the details within the script rather than try and rely on some feature that may or may not work. If you really want to keep the details out of the script, you can use PDO's aliasing feature and save the details into the php.ini file. The manual page for PDO's constructor has the details and an example. edit: On second look the aliasing doesn't let you define the user/pass in php.ini, only the dsn details like host, port, dbname.

Yes, you should use the newest jQuery. Your sample code is very basic and should work in almost any version. It works just fine in both 1.9 and 1.7 (tested w/ http://jsfiddle.net/MfTUf/)

That line will work. Just make sure you've included the jQuery library in your page. However, as Jessica said, inline JS code like that is generally not recommended.

You can get a basic certificate for free through http://www.startssl.com/. I did that for my personal site.

If you can't do the shared directory, some other options would be - A cron based rsync between the two servers on the images directory. - A cron based PHP script that will sync the two servers via FTP or something - Modify your upload script to ftp the file over. The cron solutions would not require you to modify any of the upload scripts/procedures but there'd be a delay of however long the cron task is. You'd also need to script the cron in a way that prevents it running several times concurrently. Modifying the upload script would let you only do the transfers when needed and may provide more immediate results, but requires changes to the code, which if you ever were able to move to a shared directory setup would have to be un-done. You'll also probably want to take steps to make sure the transfer to the other server happens in the background so the end-user isn't stuck waiting for the file to both upload then transfer.

It re-directs a bunch of search engine bots traffic to a different site. edit: since it checks referrer rather than user agent. Someone clicking a link in search results going to your site would get redirected to the other site instead.

There's no need to find the highest and lowest values, just leave the condition out of the where clause and it will grab everything: edit:added from unixtime SELECT YEAR(FROM_UNIXTIME(creation_date)) as year FROM customer_details You should also be using a while loop, not a do/while loop. You need to fetch the row first, then process it. A do/while loop works the other way and tries to process it then fetch it.

Not really, you just have to buy a certificate from some authority and then configure your server to use it. If your hosting your site through a company you'd give them the certificate and they will set it up for you. If you're doing it yourself you need a make a few small changes to Apache's configuration file. There are many guides on how to do that.

PHP does not read my.cnf. That is something specific to mysql's client tools, such as the mysql command line tool.

It might, if it involves a DNS change. I'm not sure how the redirect is implemented in your case. I'm not very familiar with cPanel either.

Just put that JS code on it's own line. Anything outside of PHP tags is used as it is pretty much: while ($reqarray=mysql_fetch_assoc($rrr)){ ?> errors += checkText(formname, '<?php echo $reqarray['var_name'];?>', '<?php echo $progarray[$progname];?>'); <?php } You should also use json_encode() for echoing out your PHP variables, that why the are properly escaped for JS output: while ($reqarray=mysql_fetch_assoc($rrr)){ ?> errors += checkText(formname, <?php echo json_encode($reqarray['var_name']); ?>, <?php echo json_encode($progarray[$progname]);?> ); <?php }

Are you running any sort of video or audio streaming? A streaming client may be sending a bunch of range requests to download the data which would cause the 206 responses. You should try and figure out which URL(s) specifically are generating that response, then figure out why.

A .txt file is not a program. You should be targeting a .exe file such as notepad.exe. You can pass a parameter to open the file if you want, eg: exec('C:\windows\notepad.exe c:\test.txt'); If you have apache (or whatever server) running as a windows service, then by default it will not have the ability to access your desktop. This means that if you try and open a GUI program it will not appear on your desktop for you to interact with. I can't remember for sure what happens but I believe the service has it's own virtual desktop it would open up on. There is a way to allow the service to interact with the desktop, I do not remember the way to set it up though. A google search should be able to point you in the proper direction.

Prepared statements don't affect how joins work, they only affect how you use values in the query. When you use a placeholder, you should not put quotes around it. Like this: $db->prepare(" SELECT * FROM Comments INNER JOIN Users ON Comments.UserID = Users.ID WHERE Comments.ParentCommentID = :id "); The placeholder token will be recognized and the proper value used in it's place automatically. When you put quotes around it, rather than treating it as a placeholder it gets treated as the literal string ':id'.

Yes, they will. See Request for Comments: ext/mysql deprecation for the PHP Dev's opinions on the matter. Whether ISP's continue to offer a version of PHP that has them is up to them, they can do what they want. I would guess most hosts would probably keep the option to run php 5.3/5.4/5.5 w/ t he mysql extension enabled for quite a while. That's no excuse to keep using something that has been deprecated though. If you're having issues with MySQLi then you could try using PDO and see if that works any better for you. Otherwise try posting your code for someone to review and see if there are any issues.

First, make sure your form has an ID on it. <form id="yourform"> Then you just get a reference to that form using getElementById() and call it's .submit() method. document.getElementById('yourform').submit(); Just changing the location (document.location='blah';[/) like you did does not submit any of the form details, so your processing script would not have an of the data it needs to do it's job.

Ah, is it yet another forum bug? Seems so. Though, disabling emoticons in the options fixes it.

Normally the results of a query are stored on the server. Whenever you fetch() it will ask the server for the next row. The server will then send that row's data over to the script. When you store_result() then the entire result set is copied over to the script and stored in an internal buffer. Then when you fetch() it just pulls the row out of that buffer rather than having the ask the server. Storing the result will cause your script to use more memory as it has to hold the entire set of results. However it also enables things like data seeking and free's up your connection to the server so you can run other queries if needed. PHP will handle all the cleanup for you when the script ends. Unless your writing a long-running script or a script which will be processing A LOT of data, there isn't generally any need to free the result set manually.