kicken

All you need to do is make sure you send the correct Content-type and Content-length using header, then use readfile to output the video contents. Then you just point your video player at the URL for your PHP file and it should all work fine.

You have to enable the MSSQL extension by loading the appropriate .dll via php.ini. This extension however is deprecated and is not even included with PHP in 5.3 and above. Since you are on a windows server, what you should be using is the SQLSRV extension which is available either as a set of functions or as a PDO driver. Have a read over the Requirements and Installation pages in the manual to find out how to get it and set it up.

My best guess would be that the method you are using to test the scripts makes it so that when using X-Sendfile the server has to read the file from disk, but when testing readfile it's reading from a memory cache loaded by the previous X-Sendfile test. Other than that, I would think you should be seeing roughly the same speed either way. I've not used X-Sendfile so I'm not very familiar with it. Are there any configuration settings that might need tweaking?

You can't really. You could do things like check for the HTTP_X_REQUESTED_WITH header which jQuery sets for ajax requests and if it's not present, kill the script. All someone would have to do though is add that header to fool your script and access it directly. For someone who would even want to try and access that script directly, adding that header would be trivial.

Depending on what exactly the scripts do, you may not *need* to convert them to PHP 5, but giving them a once over for any potential security issues may be a good idea. Going from PHP 3 to PHP 5, some of your biggest potential problems would be - register_globals no longer exists, and was commonly used back then. All your input variables will need converted to the new super global arrays which will mean going through each script, identifying the input variables, and converting them. - The long arrays ($HTTP_*_VARS) are also no longer available. If the original developer wisely used them, you will need to convert them to the new super globals as well, but a simple find/replace would probably cover this (eg find HTTP_GET_VARS, replace with _GET). - ereg* functions need to be converted to preg_* functions - split/join functions need to be converted to either preg_split/explode and implode The best way to handle trying to update scripts is to just take all the code, setup a new test server with your desired PHP/Mysql/Apache versions and a test site configured, jack up PHP's error_reporting to E_ALL and start browsing the test site. As you encounter PHP errors fix them. Once you fix all the PHP errors, do another pass or to ensuring that the site functions properly. When all seems well, put the new code live with the new software.

Because you need some way for the client to report back what their unique session ID is. You do this either via a cookie (best method) or by appending the session ID as a URL parameter/hidden form input. HTTP is stateless. There is no way at all for you to identify individual clients without passing some kind of unique identifier between the server and the client. This need to pass some identifying information around is exactly what cookies were designed for.

I've used it with explode a few times when parsing things, but that's about it. list($key,$value) = explode("\t", $dataLine, 2);

Use mysqli_fetch_row rather than mysqli_fetch_assoc. list requires that the array be numerically indexed rather than associative to work properly. Alternativly you could just sip the list stuff all together and just stick with mysqli_fetch_assoc. Just assign the result of the function to $data rather than listing out each member.

Use a nested foreach loop to go through and build your attributes string, then output the input with the class and other attributes. foreach ($buttons as $class=>$attrs){ $attrString = ''; foreach ($attrs as $name=>$value){ //...build $attrString } //output the tag } Note your $buttons = array($buttons['back'], $buttons['save'], ...) bit is unnecessary. Your initial buttons array is already sufficient for outputting the tags using a loop.

trigger_error is just use to help log errors. It has nothing to do with handling them. Also, as mentioned for things where PHP already provides error messages like on failure of mysql_connect, it is entirely unnecessary. Where you might use it is in your own classes or functions to provide error reporting when necessary. For example, I've made a few classes before that use cURL to download a file then parse the contents. I used trigger_error to report things like the cURL download failing or the reason why parsing the file contents failed. Whether you use trigger_error at all or not though, you still need to make sure your code can handle such errors by checking the functions return value and acting accordingly. As for the chances of something like mysql_connect or mysql_query failing, it's > 0% so you need to handle it. In an ideal world these operations would never fail, but the world is far from perfect. Network problems, file corruption, hardware failures, etc all can cause these to fail at any time.

You use whichever one you feel is appropriate for the situation. For example if the error is minor and doesn't cause any real problems (or not really an error, but inefficient or something) then E_USER_NOTICE would be appropriate. E_USER_WARNING would be for more serious errors that will prevent something from working properly, but is not bad enough to necessitate killing the script. For example if the DB connect fails, then you can't run any queries. The script itself could continue and handle the error by skipping the DB queries or generating an error page. E_USER_ERROR would be for something that is a legit show stopper and the script cannot possibly continue. Something on this level would probably be rare in the user context. I can't think of any particular example where one might use E_USER_ERROR. Note that trigger_error is not a replacement for proper checking of return values. It's just a convenient way to log a message when an error occurs. If you're trying to call mysqli_connect and it fails for instance, you'd still check the return value such as: $conn = mysqli_connect(...) or trigger_error('Failed to connect to MySQL', E_USER_WARNING); if (!$conn){ //abort or return or whatever to handle it }

What are the permissions and owner/group for /dev/ttyACM0? What groups are you a member of? Can you run the necessary chmod with PHP before opening the file? Note that if you are running this via apache which your error message indicates, you need to consider the user that apache is executing the script as, not what your login user is when determining the permissions and groups. For example, you'd need to add apache's user to the dialup / uucp groups, not yourself.

There is no wildcard character. You have to change your condition to either substring out a prefix and match that to '/articles/' or use preg_match and a regex to test the value. eg: if (substr($requestURI, 0, 10) == '/articles/')or if (preg_match('#^/articles/\d+#', $requestURI))

A lot of PHP's early/basic functions use the same name and parameter lists as their C equivalents. They are like simple wrappers around the C functions to allow them to be used from within PHP. This makes it so someone with knowledge of C can easily jump into PHP, but conversely it results in odd conventions like this. As the language was being built in the early days there was less standardization/planning as well so whoever would add a particular extension/function would often just use whatever their personal style was when deciding the name/parameters of the functions. As a result, you end up with a bunch of mixed styles such as runonsfornames, or using_underscores_for_separators or ($needle,$haystack) rather than ($haystack,$needle) etc. While it'd be nice if all this got re-done to follow a more consistent standard, such a job is not really practical due to backwards compatibility concerns. As such you just need to either remember all the tiny variations or just keep the manual at your fingertips so you can look up the functions when you can't remember.

I'd suspect that somehow your $this->_url[1] variable is equal to '<', so when PHP runs that line it is looking for a class named '<'. How you are managing to get to that line with that value I am not sure, but if you add some debugging echo's/var_dump's at various points in the code you may find out. As for the "If i wasn't checking my logs for errors, i wouldn't be aware of this as it doesn't stop anything running" bit, I'd suspect that you have some HTML in your site somewhere causing a request to be made in the background and that background request is triggering the error. Check your server's access logs for requests that occur at the same time frame as your errors to try and pin down which request causes the error. Copy the URL being requested from your logs and re-run them in your browser one by one while monitoring the error log until you find the one which triggers the error.

Use a regex of the possible operators. preg_split('#(>=?|<=?|!?=)#', $str); That would cover >, >=, <, <=, =, !=

If all you want to do is see if the files exist or not, and don't need any of the other info stat returns, then use file_exists instead.

What's the warning that you are getting? What's the code you're using?

.on accepts space-separated event list as well. .bind is also not recommended (use .on instead) but has not been removed as of yet.

Don't use readfile if you want to manipulate the contents before outputting it. Use file_get_contents to download the page into a variable, do whatever changes you want to do, then just echo the variable out.

I think this is something that may have been true in the early days of prepared statements, but is less true now that the tech has evolved. For example MySQL will use the first set of parameter values when optimizing the plan. SQL server will do that as well, in addition to storing multiple plans and re-evaluating them if the data statistics change dramatically. This is basically what PDO is when PDO::ATTR_EMULATE_PREPARES is set to true. Under that setup PDO will parse the query and substitute the values itself rather than using the DB's native prepared statements api/syntax.

You're probably not using the proper version of jQuery. If you check the documentation you can see that the live method was removed in 1.9, so you'd either need to use an older version or update your code to be compatible with the newer versions.

Basically all you do is send a HTML Email that contains an image tag, eg: <html><body><img src="http://example.com/image.php"></body></html> Then you have your image.php script generate whatever content you want them to see as an image using the GD functions.

Pretty much. By using prepared statements you are keep the data entirely separate from the query text so there is no possibility of the two getting confused. Unlike what is commonly believed, the data does not just get escaped and inserted into the SQL where the placeholder is. Rather, what happens is the database will see that placeholder, then refer to a separate list of values to find the value which should be used in place of that placeholder. You still will want to do all your normal validations depending on the data. If the input is supposed to be a date, validate it to make sure it really is a date for example. Same for emails, urls, numbers, etc. The prepared statements just make it so the data won't cause and problems with the interpretation of your query. It's still up to you to keep out the bad/invalid data.

The best you can do is reference a dynamically generated image, as mentioned in your first post, and also include a "Can't read this email? Click here" link. Most email clients disallow by default anything that would require an external request (such as loading an image) because it's a common way for spammers to verify if an email is real or not. Your recipients would have to configure their clients to allow your image to be displayed, or just click the link to go to the webpage version of your email.