On WebReference.com today Ryan Butler has written up a tutorial of a simple search feature that can be integrated into any site (with their content in a MySQL database).

In this article, you'll learn how to create a searchable form feature that will query a database table and display current staff member information. During the analysis you'll learn how to do the following: create a database table that will hold current staff listings, create a search form and use PHP, in coordination with Structured Query Language (SQL) to capture information entered by the visitor and append the information to display the results we want to show.

They give you the files for the project and work through each, showing how to make the database, put information in and connect to the database to run the query. He opts for the LIKE functionality in the WHERE clause to find the term as a wildcard in the FirstName field. It's not the most efficient, but it can be useful.

Jacob Santos has posted a list of things that he both likes and dislikes about one of Zend's beta offerings - Zend Neon.

I've been using Zend Studio Neon for the past three weeks and I have to say, for something that is free (beta software) it is quite good. Compared to using VS 2005, Zend Studio Neon has its advantages, since Visual Studio doesn't handle PHP well. Zend Studio Neon also has areas that I didn't like.

His likes included the fact that it's not Eclipse (technically) and that it supports PHPUnit and PHPDocumentor out of the box. Dislikes included the fact that it might not be free in the future and that it lacks FTP support.

Brian Moon has posted today about his editor fo choice for PHP work - jEdit and some of the benefits he thinks it has for other developers.

I keep trying all the latest and greatest editors out there. I fought with Eclipse and have tried the newer more PHP centric offerings built on Eclipse. I recently tried out Komodo Edit for a week. I had tried the Komodo IDE when it came out for Mac a while back. But, I just keep coming back to jEdit.

He's broken it down into two (well, really three) different sections - the likes and dislikes followed by things that he "doesn't care about but you might" (including Subversion and CVS support).

On the I/O Reader blog, there's two different posts that take two sides of the spectrum when it comes to what to like and dislike about PHP, both lists of features of the the language:

• 15 Cool Things About PHP That Most People Overlook - a list including the Reflection API, the Standard PHP Library, type hinting and the "magic" functions.
• 12 Things You Should Dislike About PHP - this list includes things like naming conventions, that _tostring doesn't work as (he) expected, magic quotes and register globals and safe mode

Both have their valid points and it's interesting to see how many of the points made in the first article he goes back on and mentions specific instances where it doesn't work as expected. Some of the comparisons seem a bit like he's comparing PHP to his experience in another language and not objectively on PHP's features alone.

The roScripts website has a new tutorial that anyone just starting out to create a search engine with PHP and MySQL should get their hands...er eyes on. It steps through the creation of a simple PHP-based search engine, showing multiple methods to achieve the goal.

The right search engine on your website won't bring you more traffic but it will help your visitors to better locate things so it will keep them on your pages. A good search engine implemented can increase your hits with almost 30% and this is tested. I'm not talking just to have a tutorial.

The different methods the show how to implement include:

• using a straight LIKE on each word entered
• paring down those results using ORs on other columns too
• implementing the Porter Stemmer algorithm
• finding matches that contain the term but not only one part of it
• Full-text searches

It's a good overview of some of the basic steps to getting your own search up and running, but some of them, when applied to sites with larger amounts of data behind them, wouldn't be useful at all (slowness mainly).

Giving your users a tool to find relevant invormation from the vast ocean that is the content of your site isn't easy sometimes. Even with the powerful combination of PHP and MySQL, it can be difficult to find what you're looking for. Wolfgang Drews shares in some of this frustration in his new blog post.

Using MySQL most of you will be familiar with this: searching in textfields for keywords is quite uncomfortable when using other table handler then MyISAM. If you use MyISAM, you can utilise the Fulltext-Search with MATCH … AGAINST. Otherwise you are thrown back to "simple" string comparison functions (LIKE). Not really satisfying. As this won't change with the 5.1er Version of MySQL, i have to search for another solution.

His other suggestions include the use of two other tables (terms in one, references back to content in another) or an external search option, such as the Zend Framework's implementation of the lucene functionality - Zend_Search.

According to the reasons listed here, PHP isn't good for much more than just the smallish, more personal sites. It was originally written back in 2004, but has just been recently updated (April 2006) with a more current state of PHP.

I have been developing in PHP for six years now. PHP is very easy to program in. But PHP also has some serious flaws. Below I give some reasons why you have to do some serious thinking before implementing a large scale web application in PHP.

Some of the reasons they give include:

• Many PHP-modules are not thread safe
• Non-standard date format characters
• No Unicode

It's interesting to see how many of these reasons seem to be more of a preference than a real standard, and the "crippled for commercial reasons" comments are very interesting. Also, several of these will be addressed in the next version of PHP, version 6.

Mike Lively has taken a big step in his PHP development process, a move to using unit tests for his resulting code. In this new blog post he describes the experience - mainly how much he's enjoying it.

I have spent alot of time in testing using SimpleTest and I have also given some time to test-more.php. However, up until just recently I had honestly never used PHPUnit before. The big motivational factor for me (other than to try something new) was to see how the code coverage feature was coming along.

I would have to say that after a few weeks of tinkering with it I am impressed.

He mentions some of the notable features he's used as well as some of his surprisng finds along the way:

Using the framework is an absolute breeze and there is excellent documentation [...]. The most impressive part of this experience in my mind was how runnable the software is straight out of CVS.

PHP Magazine has posted their results from a poll they took after the "PHP Developers Meeting" that happened in Paris about what developers would like to see in PHP6.

Following release of the PHP Developers Meeting in Paris (November 11th and 12th, 2005), the International PHP Magazine polled the community to find out What they were looking our for, the most, in PHP 6?

The results of the poll suggest almost an equal weightage to all of the points noted in the developer meeting minutes. Of the 809 members polled, 15-20% of the respondents were looking out for OO functionality changes, functionality cleanup, performance boost, Security enhancements, and unicode support, in that order. Only 7% were keen to see additions made to the PHP engine. Less than 3% clicked on the "others" option.

The votes were pretty close, with "Functionality" only barely edging out "Performance Boost". "OO Functionality Changes", however, topped the list with points to spare.