kicken

The SQL text syntax (ie the SELECT ... part) for the most part does not change. The only changes you would need to make to the query text is to change any variables to placeholders and then use ->prepare and ->execute rather than ->query to run the queries. Since the query in your original post does not contain and variables, you can just copy it verbatim into PDO's query method to run it. The code in your last post looks fine and should work ok.

No, the setting has been removed, not just disabled. The functionality you were using no longer exists. You could always just downgrade back to an older version of PHP if you're that desperate to get it back. Then work on your scripts to fix the problem and upgrade again a few months from now.

http://php.net/extract. However, you really need to fix the code, not just apply a band-aid solution. register_globals was removed for a reason, it is insecure and can lead to a number of issues.

$db is likely an instance of PDO, for example: $db = new PDO(...); Look in the PHP manual for the parameter information to build a correct function call.

Javascript likely won't help you. By default, javascript is restricted to same origin requests only. Unless your target website(s) specifically allow a cross-origin request, the browser will prevent your code from making such requests.

You don't. If your server needs to grab the page and parse it, your server's IP is the one that will be used. There isn't any way to send a request under the end-users IP. If what you are doing is allowed then you won't get blocked. If it is not allowed then you shouldn't be doing it and getting blocked is what should happen.

This is certainly the most common way of calling a function. It is perfectly acceptable as far as style and good practices go also. As you learn the language (or libraries) you will start to remember what parameters functions accept and in what order. When you do forget, there is always the manual also, just look it up. IDE's help a lot in this area by either showing you the function signature as you type or providing a quick link to such information. I don't think I've ever seen anything like this done really. The extra documentation is generally not necessary. I most cases you'd probably be passing variables anyway as opposed to constant values. So long as the variables are named well things will be understood. There is a probably a good chance of having variable conflicts/problems also if you start "naming" all your parameters when calling the function. This is often useful for functions which accept a large number of optional parameters. Rather than having to type out a bunch of defaults for parameters you don't want to specify you can just pass an array with the correct keys defined. Take a look for example at the Image function in TCPDF. Say you wanted to set the ALT text and BORDER on an image but don't care about all the rest of those parameters. To do that you end up with a function call looking like: $pdf->Image($file, $x, $y, $w, $h, '', '', '', false, 300, '', false, false, $border, false, false, false, $alt); Quite a nightmare to read, and unless you are very familiar with that library you'll be constantly looking up such functions in the manual. Using an array for all those optional parameters would make things a lot nicer: $pdf->Image($file, $x, $y, $w, $h, array( 'border' => $border , 'alt' => $alt ));

I would guess that you already have a subs table in your database which does not have the drone column defined. Drop the table before you run that SQL script.

Windows 7 - A necessity due to needing SQL Server, but it is a fine OS too. I don't feel any particular need to move to a linux distro or to even setup a dual-boot. Whatever I need/want to do with linux can be handled with a VPS or VirtualBox. VirtualBox - Great for testing things on other OS's or just different configurations. Edit+ - Has been my editor of choice for the last 7 years or so, pretty much the very first thing I install on any new system. I did recently pick up PHPStorm (their end of the world sale) and it is very nice, may replace Edit+ at some point as I learn more about using it. Most likely I'll keep Edit+ around though, it's a great general purpose editor, for things like logs, config files, etc. SVN - I like Subversion and it has served me well. I've not made any move toward git, nor do I really see any need to at this point. TortoiseSVN - Makes SVN nice and easy to use on windows, no need to fiddle around in command prompts. Putty - Great SSH client WinSCP - Great SFTP/SCP client GIMP - For what little graphics / photo editing I do, GIMP is my tool of choice. Pretty much all those tools make it onto my development systems. I'm not sure all of them would be "Can't work without" level of need, but certainly I prefer having them over not having them and would be rather bummed out if they were missing.

Yes. What is happening is not what you think is happening most likely. PHP does not support any sort of name-based parameters when calling a function. It is all handled by position and only position. What you're doing in that code is simply assigning the value to a variable prior to passing it into the function. It's functionally the same as just doing something like:$size = 120; $code = "id-010012F"; myfunction($size, $code); There's nothing really wrong with doing what you are doing (just be careful to not over-write needed variables) but there is nothing in PHP that is going to require the names match each other. As far as PHP is concerned the parameters do not have any names, just a position. Yes, passing an associative array would be the only way you could require that the names a function uses internally matches what a user passes into it.

Use concatenation rather than embedding the variable in the string. $returnHtml .= "<div class='imglabel'>".nl2br($row['product_description'])."</div>";

Have a separate row per phrase, but rather than select each translation individually, select all the translations for the target language at once and store them in an array. If you have a huge number of phrases you could further break things down by page or area (ie, separate front-end and back-end (admin) areas). Also you might check into something like gettext, then you don't have to use a bunch of ID numbers or constants as placeholders, you can just use the normal text.

Using javascript at all in the above example is rather pointless. Just use a normal submit button and remove all the javascript. By using JS to submit your form like that you are doing nothing other than unnecessarily limiting your site to only people who have JS enabled.

Don't use php -r to run a file, just do php yourfile.php. The -r flag is for passing code directly as a parameter which can get complicated quickly when you start involving quotes or multiple statements. Only use -r for quick one or two statement bits of code, eg: php -r 'echo dechex(123456);'

You use prepared statements and use a placeholder for the value. $stmt = $db->prepare('INSERT INTO dbname.table (input_xml) VALUES (?)'); $stmt->exec(array($xmlData));

You need to run values though urlencode before you stick them into the URL in your link.

What you'd do is search for indicators that each browser adds and have a list to map indicators to more friendly names. For example if the string contains MSIE then you'd map that to 'Internet Explorer'.

Have you tried installing the 2012 native client and had it fail? I do not see any note on the description for it suggesting it would not work. If it wont install, or is unstable, then I would say your diagnosis is probably accurate. Either stick with 5.3 or update to a supported OS.

Generally speaking, if you code using current best practices, and keep informed of changes that are coming then you shouldn't be faced with too many problems from version updates. If something is changing that affects you (such as back when register_globals was removed), there is usually plenty of time for you to adapt your code before it becomes a crisis. For example register_globals was pretty much depecated and on it's way out by 5.0 (though not officially til 5.3). It wasn't actually removed until 5.4 though. This means that anyone who was affected had at least 3 years official (8 years unofficial) warning before it became a problem. That is plenty of time to develop a plan of action and get your code updated. The same sort of thing is happening with the mysql_* functions right now. They have been unofficially deprecated for years, and have now been officially deprecated. It will probably be another year or so at least before they are officially removed though (and even longer before hosting companies remove support). There is no solution to ensure you scripts never have to be updated, aside from running your own hosting where you have control over your upgrades. The key is just to stay informed of what changes are happening so you provide your self the best possible time frame for updating your code when it is necessary. As mentioned though, ensuring you code using the latest best practices will help keep the amount of changing you do need to do to a minimum. A project I work on started with php 5.1 and has been running just fine on 5.4 with hardly any changes required as a result of an upgrade (a few minor new E_STRICT notices at 5.4 is all). I've not yet tested the 5.5 betas but a quick scan through the change list doesn't show anything that should be a problem, the code will probably continue to work just fine with no or minimal changes.

If your site has a single entry point where all requests run though, then you can wrap your code in a try/catch block and use exceptions for your errors. For example try { ProcessRequest(); } catch (Exception $e){ LogError($e); ShowErrorPage(); } ProcessRequest() would route the request to whatever page needs to handle it. If you have an error with the DB or something else then throw an exception. $sql = 'SELECT blah FROM foo'; $stmt = $db->query($sql); if (!$stmt){ throw new Exception('Failed to query database, '.$sql); } You can create your own exceptions by creating classes extending from the built in Exception class. Doing so will allow you to do more selective catch blocks as well as provide better error reporting.

Rather than try and re-implement cron, I'd just look at making an easier to use/manage interface on top of cron. A few php scripts that would list out all the cron jobs in a nice form, let you make any changes, and the save them back into cron.

Use something like memory_get_usage to determine how much memory your scripts are using, rather than look at something like the output of top (or other process list). The amount of memory reported by a process listing program can be mis-leading do to how things like shared libraries work. For example the PHP engine will need memory for the PHP executable itself + all the loaded extensions (GD, Mysql, Zip, etc). When you run multiple instances of PHP though, they all references the same shared library code, so only the core php executable gets duplicated and needs more memory. A process listing would show both as if they each had their own copy of the libraries loaded though. Just to maybe help explain better, lets throw some theoretical numbers in: Say your PHP executable needs 10MB of memory to be loaded and run. When it runs, it loads the following extensions w/ their own memory requirements: GD: 4MB MySQL: 7MB Zip: 3MB PDO: 9MB So the first instance of PHP that gets run needs to load up itself + the libraries into RAM, requiring a total of 33MB of memory. This is what would be reported by a tool like top that lists processes. The second instance of PHP you start needs to load a second copy of the PHP executable into RAM, but it can reference the already existing copies of the libraries. As such it only requires an additional 10MB of memory to run. A tool like top would still report it as using 33MB of memory though, counting the libraries again. So if you checked the process list you'd see two instances of PHP each using 33MB of memory for a total of 66MB used. In reality though there is only 43MB of memory being used, since the shared libraries are, as the name implies, shared between the two processes.

To get multiple rows out of a result set, you call the fetch function multiple times. This is commonly done using a while loop: while ($row = $result->fetch_assoc()){ //process this row } Each time you call fetch_assoc the next row in the result set is returned. When there are no more rows left, false is returned which will cause the loop to exit.

Best guess without looking at how the class is implemented: Future instances of SplFixedArray (or subclasses there of) re-use already allocated memory. Allocating a chunk of memory takes time as the system has to search for a block big enough to fulfill the request and also update allocation tables. There may also be some paging/swapping involved that slows things down. Since you are re-using the same variable name when you assign new instances of SplFixedArray and it's subclasses the previous instance can be destructed and it's memory released. The way PHP works though is it does not actually "release" the memory, it just goes into a pool that PHP itself will manage so that future allocations for variables won't (generally) have to allocate memory from the system, resulting in faster performance. So in your first loop, each time you make a bigger and bigger SplFixedArray class PHP will have to allocate from the system enough memory to handle that request. In your second loop though, all that memory is still allocated (just unused), allowing the new class instances to just quickly grab a chunk of memory and skip the allocation process.

could be some sort of mod_security filter that is setup on your server causing the request to be rejected. There is nothing special about echo in that context and no reason it shouldn't work just fine. Whatever causes it to fail must be something either with your script or the server configuration.