If you have tried debugging and failed, don't fret—there are still support options where you might find your solution.
The first place to check should always be the PHP documentation , available online from http://www.php.net/manual. The manual contains documentation on all PHP functions, as well as various usage examples, and also user comments. Very often it's the user comments that are most helpful, because people recount problems they've experienced in the past and how they got around them. The PHP manual is an excellent resource that should help you deepen your understanding of all aspects of the language.
There are several mailing lists that focus specifically on PHP, the most popular of which are hosted by the PHP web site itself. Visit http://www.php.net/mailing-lists.php to see a list of possibilities. You will most likely want the general mailing list, as it includes hundreds of questions and answers being sent each day.
Before you post:
Read the list for a while to get a flavor of how to ask questions and to make sure the list covers the right area for your question.
Make sure you have HTML mail disabled in your email client; only plain-text emails are accepted.
Never attach files to your email.
If you are having a problem, give a code example showing the problem in the simplest way. It helps people more if you say what you expected to get as output, what you did get, as well as other information such as what version of PHP you have, etc.
Do not post to the Internals list unless you really know what you are doing. This list is not for questions about how to install PHP, how to use a certain function, or why a script does not work—it is for the actual developers of PHP to discuss code changes and new releases of PHP. You do not need to post to this list asking whether you can use or redistribute PHP—the answer is "yes."
One of the fastest ways to get answers about PHP is to use one of the two popular PHP IRC channels. They both regularly have 200-300 people on there who program in PHP, of which between 10 and 20 are chatting away about something. Peak activity times are evenings in U.S. EST (five hours behind GMT).
If you have an IRC client installed (such as the Firefox extension ChatZilla: https://addons.mozilla.org/extensions/moreinfo.php?id=16), connect to Efnet (see http://efnet.org) or FreeNode (see http://freenode.net) and go to channel #php. Note that both channels (EFNet #php and FreeNode #php) have very strict rules: do not ask to ask (that is, do not say, "Can I ask a question about XYZ?"—just ask), do not post more than two lines of code into the channel at one time, do not start evangelistic fights over Perl/Java/etc., and so on. Be sure to check the channel rules as you enter, or you may find yourself kicked out for breaking them.
A word of warning: don't believe everything you hear about PHP in IRC channels, particularly if the person talking isn't a channel operator. Many people come and go, and they aren't necessarily experienced enough to give authoritative answers.
Furthermore, be prepared to show people your code when on IRC. A popular site is http://www.pastebin.com, which lets you paste your PHP code online and pass the URL out to other people on IRC so that they can look at it and discuss potential fixes with you directly.
Going along to one of the PHP events around the world is a great way to meet up with your peers and share ideas, solutions, and learn new things. These conferences are usually a mix of general discussion between attendees, a sponsor expo where you can see companies involved in the PHP arena, and tutorials where you can listen to lectures from luminaries in various fields about new developments in PHP.
If you're only going to go to one conference, I'd recommend you make it O'Reilly's Open Source Convention: it covers a variety of programming languages and platforms, but PHP always puts on a good show there. If not that, then consider either the International PHP Conference (http://www.phpconference.com) or the Zend PHP Conference (http://zend.kbconferences.com), which cover more detailed topics due to their specific focus on PHP.
If you've never been to a big conference before, here are some hints: take a spiral-bound half-page (A5) notepad with you for writing, a selection of cheap pens (you'll lose most of them, but should get freebies to replace them while at the conference), some small snacks to keep you going between meals, business cards, a USB thumb drive (memory stick), and, of course, a WiFi-compatible laptop. Apple laptops are becoming increasingly prevalent, but anything that supports 802.11b/g is good.
If you're not into the conference scene, user groups might be more your style. Most parts of the world already have Linux user groups (LUGs) where you can ask for help on everything from setting up your Apache server to debugging scripts—there are usually people there who are skilled in PHP, too. Some cities also have PHP user groups that are, obviously, more helpful for direct PHP-related questions.
The best place to look for PHP user group information is directly on the PHP site itself: the PHP events calendar (http://www.php.net/cal.php) is regularly updated and should provide you with all the information you need.
If you are convinced you have found a problem with PHP, it is quite possible you are correct and should notify the developers. Note that many hundreds of "bogus bugs" have been reported in the past, which are usually the result of people not reading the manual correctly or otherwise missing a flaw in their code. If you think you have found a problem, follow these steps before you submit a bug:
Go to http://snaps.php.net and download the latest PHP snapshot for your machine. Take a backup of your existing installation, then install the snapshot—this essentially gives you the bleeding-edge version of PHP. If your problem still exists, go to step 2.
Go to IRC and ask people there to reproduce the problem. It is possible that the problem lies in your PHP configuration, DBMS, operating system, or any other of a dozen potential culprits. If the problem is reproduced by others on IRC, then go to step 3.
At this point you have almost certainly got a bug. However, before you send it off to the developers, you must reproduce your problem using the shortest possible chunk of code. While it is possible that your 3000-line masterpiece does show up a bug in PHP, it is also very hard for other developers to verify the problem. Take out every line that does not stop the bug from appearing—the shorter your script, the faster others can pick it up and reproduce the problem.
You should now clearly be able to see what sequence of events causes the bug to show itself. You now need to make sure the bug has not been reported before, so go to http://bugs.php.net and search for it.
If there is no record of a bug like yours existing, you can file a bug report from the same URL. Try to be as descriptive as possible, as your bug report will be mailed off to everyone on the PHP Internals mailing list for analysis.
Once your bug has been submitted, you will be notified as to its progress. All being well, it will be fixed immediately, but you may find that the developers need to ask you a few questions before they can get to work.
Finally, developers will fix your bug and a new version of PHP will be available on http://snaps.php.net for you to download and try out. If the bug has been fixed, write back and say it is working fine so that the bug can be signed off. The most common problem when fixing a bug is no feedback—a possible fix has been applied, but the original finder hasn't gotten back to say it's fixed. Don't let this be you!
Get PHP in a Nutshell now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
