A couple of hours ago I was playing around scraping some content from a website. All was going well until suddenly I couldn't get my script to fetch meaningful content. [...] The first thing I did was stop visiting the site for 15 minutes or so and then increase the time between requests. It briefly worked again but quickly stopped.

One simple change to his user agent string in his php.ini made the problem evaporate pointing to a user agent filtering happening on the remote side. His helpful hint involves two methods - one in just PHP and the other in cURL - to change the user agent that your scripts are sending. An even better sort of solution might be some sort of rotating array that would alternate between four or five strings to make things even more random.

I was under the impression that when the user hit stop, the script stopped. Which is: bad, and wrong. PHP doesn't detect that the user has terminated the connection, it has no clue, it obligingly continues processing along, until it attempts to send information to the user.

The "ignore_user_abort" configuration option in the php.ini controls some of this, allowing for you to specify whether or not the script should go ahead and finish out even after PHP has discovered that the client has been disconnected. There's also a function that allows you to specify the same thing on a script-by-script basis (in both PHP4 and PHP5).

I have found myself in a position where I am writing scripts that may need to upload fairly large files. My scripts were timing out, and I couldn't seem to figure out why. For the unitiated, there are some standard things that you usually do to both your php.ini and in your script in this situation [...] However, it turns out there are some other php.ini config variables that you may need to look at.

The "usual suspects" list includes changing the max_upload_size value and adjusting the script timeout. The other settings he mentions, though, are things like memory_limit, post_max_size and max_input_time to help increase the default times that PHP uses on most page executions.

In 30 August PHP Team have released new version PHP with number 5.2.4. We have tested this version and now we can say, that not all issues from PHP 5.2.3 are patched. It is possible bypass safe_mode, open_basedir and disabled_functions.

The issue he describes is the lack of a "mail.force_extra_parameters" setting in the php.ini still making it possible to exploit the mail() function to execute arbitrary PHP code.

Instead I have used a PHP class that allows me to send emails using a remote smtp server using an account on that server. This has been a good solution for my setup anyways. A few days ago a friend of mine was asked to investigate the very same problem for a client.

As it turns out, the solution to their problem was pretty simple - a conflict between the sendmail_from in the php.ini and the "From" passed into the mail function call. A simple ini_set resolved the issue and kept the spam filters from catching and blocking the message.

A co-worker here was going through similar problems with Zend Studio 5.5. He'd even gotten so frustrated he tried installing phpEclipse and in doing that installed Zend's debugger. Little did he know that by doing that he had enabled remote debugging support in Zend Studio 5.5 without the need for Zend Platform and we can still happily use APC.

Now the million dollar question is why doesn't Zend document or promote this fact? Sure, they want you to install and test drive their "PHP Application Server" but if you don't desire all of that why force it down our throat?

He points out a PDF that only barely mentions that this could happen but couldn't find much else. If you don't want this to happen to you, he provided a different method to enable the debugging easily through a few php.ini settings.

Htscanner reports error during module or request init (returns FAILURE), these errors may be fatal and stop the current executions. This behavior is not desired if you use it in a shell ((if you have only one system php.ini for both cli and cgi or if htscanner is compiled statically). This release brings a new ini settings to solve this problem, stop_on_error.

The solution involves changing the htscanner setting to 0 instead of 1 to return a "SUCCESS" message rather than the errors.

In the php.ini file used by the PHP5 executable, the include path is hosed. If you installed in the default location and are running Windows, you'll probably find the file at: C:Program FilesZendZendStudio-5.5.0binphp5php.ini

The problem is that the value of include_path isn't wrapped in quotes, making portions of it act like a comment and "hose" your directory path. Thankfully, it's a pretty simple fix - just quote the value and be on your merry way. It's one of those bugs that has the potential to be so small that it'd be very frustrating to find.

You may notice that the IDE does not load options specified in the php.ini and this makes customizing extensions impossible. I run into this problem today and looked over the source code of PHP plugin for it.

The solution he found was in an update he found to one of the Java files, pointing it to the correct location. Changing this changes the default setting for the editor.

His idea is that, with this setting on, the PHP installation would:

• disable display errors
• disable phpinfo()
• turn expose_php off
• make max_execution_time/memory_limit reasonable
• and possibly a few others that some developers forget to set correctly