Any but the most trivial project is going to have some hiccups along the way, particularly during the development/testing process, when these things happen obviously it’s easier for everyone involved if these can be dealt with as quickly and efficiently as possible. The ideal process would be as follows:

1. User finds a problem
2. User reports the problem to the developer
3. Developer sees the problem
4. Developer fixes the problem

The most important point here is that step 4 (fixing the bug) cannot happen before step 3 (seeing the bug), and that step 3 cannot happen unless step 2 (reporting the problem) provides enough information for the developer to see the problem.

If the report doesn’t have enough information, then the problem can’t be fixed, so all that will happen is that the developer will send questions back to the user, which wastes everybody’s time and delays getting the problem fixed.

As much detail as possible is useful in a bug report.  It is important to remember that there will often be multiple ways to do the same job, so something like “I can’t delete a page” doesn’t necessarily tell the developer what link you are clicking on, and this may be relevant.

It also may matter what account you are logged in with, or which records you are working with, so it is important to include usernames and record ids or urls where possible.  It may also be important which web browser you are using (e.g. Internet Explorer 6 or Firefox 3), as some problems will exist on some browsers but not others.

Ideal bug report format

An ideal bug report includes the following information:

1. Exact steps I take
2. What I expect to see
3. What I actually see.

Example report for a web project

For example:

Steps To Reproduce

1. Open Firefox 3.0 Browser
2. Go to http://www.example.com/admin
3. Login with username_x/password_y
4. Click the “Edit Page” button on Page number 15 in the list
5. Edit page form comes up
6. Enter title “Test Page” and content “Test page”
7. Click Save
8. Click “Return to list” to go back to the list of pages

What I would expect to see:

• I would expect to see page number 15 called “Test Page”

What I actually see:

• Page number 15 is called “Wrong Title”

Hopefully this bug report contains all the information the developer needs to reproduce the problem themselves and see it happening.

This is intended as a summary for non-technical users to help in ensuring bugs are reported more effectively, for a more complete investigation I found this much better, more thorough description of how to write a bug report by Simon Tatham author of the excellent PuTTY ssh client.

Also, the previous release fixed some problems with the method of including search forms in posts and pages.  To fix this bug though I have had to change the syntax for including presets in posts, please check the “settings/wp custom fields search” section of the site to see the new syntax.  The old method is now deprecated (meaning it works for now so that everyone has a chance to update, but I will remove it soon.)

Basically what was:

[wp-custom-fields-search 1]

Is now:

[ wp-custom-fields-search preset="1"]

There is one relatively major change to the way categories and tags work, it’s a technical detail really that I won’t bore you with the details of, but this change will allow the categories/tags functionality to work on some sites which couldn’t previously use it.  However there is a chance that this will break the same functionality on other sites, so please post comments here if this causes issues for you and I will consider switching back to the old method.

I haven’t posted about a release for a while so a quick summary of some of the other changes over the last few releases:

• Various bug fixes
• New hidden constant field type allows forms to be built with pre-specified search parameters
• Wordpress 2.8 compatibility (although there have still been some complaints about this, please let me know if anyone has a site with problems that I can test on)
• French translations (thanks to Pierre)
• Ability to search different post types (use this with the hidden constant field to set up page search)

You may also notice I’ve added in a paypal donate link, basically the reason that recent development has been a little slow is because I’ve been too busy working on paid projects.  If you like my work and you’d like to help me make a living from (and therefore spend more time) producing open source software then please consider donating.

There is more complete (although slightly out of date) documentation for the plugin here

So far we have two sites,  Bode Adediji Partnership, and Pacific Capital Properties , using the new system which allows agents to manage their property portfolios and provides users with structured search by location, price and property type.

Hopefully this will grow over time and eventually spread out to incorporating different business types in a similar style.

I strongly advise all users to upgrade as soon as possible.

This also includes the functionality to place searchforms in page and post content.  See the presets section (Settings > WP Custom Fields Search) for an example tag.  Thanks go to Ibrahim for the suggestion.

For instructions on using the plugin please see the 0.3 release notes

The blog admin is able to build a customised search form. It allows you to search by the standard post information and by custom fields and to choose what HTML form elements should be presented for each search field.

I originally developed this plugin for a client project. Basically the problem they had was that they were storing real estate data as wordpress posts with associated custom fields and they wanted to search for entries based on price, location and features which was not possible with the default wordpress search.

The plugin is now at point where I think it could be useful to other people although I’m aware that there are a lot of improvements that could be made. Please let me know if you have any suggestions or complaints and I will do my best to get them resolved.

You can download the plugin here.

System Requirements

I have tested with the following software versions, other versions may or may not work.

• PHP Versions 4.4.9 and 5.2.6
• Wordpress 2.5, 2.7 and 2.7 MU

Quick Start Guide

I will try to put more complete documentation together at some point but for now this is a quick start guide to building a search form.

1. Install the plugin. Download it here unzip it in your wp-content/plugins folder, then activate it in the plugins > installed page of your wordpress admin site.

Method 1: Add the search as a sidebar widget

1. Add the widget to the sidebar on which you want it to appear. Go to the appearance > widgets section of the admin page, in the list on the left find the widget “Custom Fields Search” and click the add button next to it. It should appear in the list on the right. Click save changes
2. You should now have a basic search form on the front of your site, to customise this further read on to see how to reconfigure your fields.

Method 2: Add the search code directly into your template

1. Go to the custom fields config page in your admin section, Settings > WP Custom Fields Search
2. Copy the example PHP code from this page into your template file.
3. You should now have a basic search form on the front of your site, to customise this further follow the instructions below for setting up fields.

Setting up the fields

Admin Screenshot

Each field has a number of settings which control the way the input appears to the user and the way the search is performed. Most of the settings are hidden when you first go to edit the widget and you will need to click the show/hide config button to get access to many of the parameters.

Label sets the label displayed next to the field, you can set this to whatever you want.

Data Type controls what type of data is being searched (i.e. what database table is being used). The standard options are “Post Field” for data such as post title and post content, from the standard wordpress post data, “Custom Field” for data from the custom fields, and “Category” to search on the categories a post is in.

Data Field makes a more specific selection from the data available. The drop down list should give some sensible options, or if you know the name of the database field you want to query you can type this in manually.

Widget controls what type of HTML input is created for the front end of the site. It should be fairly obvious what these do.

Some widgets will require extra options in the Widget Options field. At the moment this is just the drop down and radio button widgets which allow you to specify a list of values for the user to choose from. If you leave the options blank then they will be automatically populated with a list of all values currently in the database, this can be useful for fields like categories and tags, but is less useful for fields like title which would just generate an entry for every post in the blog. If you want to specify the values manually you can specify this as a comma separated list of values, ‘a,b,c’ for three options with values ‘a’, ‘b’ and ‘c’ respectively, or if you want to give ‘friendly’ labels to the user you can separate the value from the label using a colon as follows ‘a:Group A,b:Group B,c:Group C’.

The Compare field controls the way that the user input is compared to the data in the database. I would expect the most commonly used of these to be “equals” which requires an exact match between the user data and the database field (useful for category searches) and the “Words in” or “Phrase In” types which will search to see if the user input is a part of the data, rather than a full match, this is useful for things like searching the text of a post. The difference between ‘words’ and ‘phrase’ is that ‘words’ splits the input into a series of words and searches for these individually whereas ‘Phrase’ searches for all the words in sequence.

The “Less Than” and “More Than” comparisons ensure that the data is less than or more than the user input respectively. This is probably only relevant for numeric input but it can be used for strings as well and will search alphabetically. For numeric input it can help to also tick the “Numeric” checkbox as sometimes the database will be set up to compare numbers alphabetically (so that 10 is less than 2).

The “Range” comparison is a little more complicated and requires the user input to be of the form A-B to return results that are between A and B. This is primarily intended to be used for Drop-downs and radio buttons where the values can be set by the site administrator. If you specify the values for the dropdown like the following: “-10:Less Than 10,10-20:Between 10 and 20,20-:More than 20″, then the user will be presented with the options “Less Than 10″, “Betwen 10 and 20″ and “More than 20″ but the search will be done with the values “-10″,”10-20″ and “20-”. Again the numeric checkbox should be used for numeric data.

I hope that helps, please let me know if you have any trouble (or joy) with the plugin or if any of my instructions don’t make sense.

Using Presets

Presets are a new feature in version 0.3, they allow search forms to be configured separately from the sidebar widgets, the configured form doesn’t directly appear on the site but can be included in two ways.

Firstly, by copying and pasting the php code from the preset config page into a template file you can place a search form anywhere you want in your template.

Secondly, by using a preset as the basis for another search form.  When setting up a search form you have the option of selecting one of the presets from a dropdown list.  Selecting one will include all of the fields from this preset in your form.

Presets are configured in exactly the same way as the sidebar widget, you can find the presets in the “Settings > WP Custom Fields Search” section of your admin site.

Extending Custom Search

For developers, I’ve tried to build this in a modular way to allow extensions to be added, I will try to document this at some point in the future but if you can’t wait then the best places to get started would be to look at the filter ‘custom_search_get_classes’ in custom-search/custom-search.php and the Great Real Estate bridging code in custom-search/bridges/greatrealestate.php.

This plugin is at quite an early stage in development though so it is likely that future versions may not be compatible with the same extension interface and it is likely that any extensions will need altering when new versions are released..

Changelog

Since 0.2

• Various bug fixes
• Wordpress 2.5 compatibility
• Added in preset functionality

Since 0.1

• I’ve reworked the UI and added some more sensible default values, hopefully this should make it less daunting for new users.
• Fixed a few bugs.
• Added in textual descriptions of the search parameters (for themes which support this)

The blog admin is able to build a customised search form.  It allows you to search by the standard post information and by custom fields and to choose what HTML form elements should be presented for each search field.

I originally developed this plugin for a client project.  Basically the problem they had was that they were storing real estate data as wordpress posts with associated custom fields and they wanted to search for entries based on price, location and features which was not possible with the default wordpress search.

The plugin is now at point where I think it could be useful to other people although I’m aware that there are a lot of improvements that could be made.  Please let me know if you have any suggestions or complaints and I will do my best to get them resolved.

You can download the plugin here.

System Requirements

I have tested with the following software versions, other versions may or may not work.

• PHP Versions 4.4.9 and 5.2.6
• Wordpress 2.7

Quick Start Guide

I will try to put more complete documentation together at some point but for now this is a quick start guide to building a search form.

1. Install the plugin.  Download it here unzip it in your wp-content/plugins folder, then activate it in the plugins > installed page of your wordpress admin site.
2. Add the widget to the sidebar on which you want it to appear. Go to the appearance > widgets section of the admin page, in the list on the left find the widget “Custom Fields Search” and click the add button next to it.  It should appear in the list on the right.  Click save changes
3. You should now have a basic search from on the front of your site, to customise this further read on to see how to reconfigure your fields.

Setting up the fields

Admin Screenshot

Each field has a number of settings which control the way the input appears to the user and the way the search is performed.  Most of the settings are hidden when you first go to edit the widget and you will need to click the show/hide config button to get access to many of the parameters.

Label sets the label displayed next to the field, you can set this to whatever you want.

Data Type controls what type of data is being searched (i.e. what database table is being used).  The standard options are “Post Field” for data such as post title and post content, from the standard wordpress post data,  “Custom Field” for data from the custom fields, and “Category” to search on the categories a post is in.

Data Field makes a more specific selection from the data available.  The drop down list should give some sensible options, or if you know the name of the database field you want to query you can type this in manually.

Widget controls what type of HTML input is created for the front end of the site.  It should be fairly obvious what these do.

Some widgets will require extra options in the Widget Options field.  At the moment this is just the drop down and radio button widgets which allow you to specify a list of values for the user to choose from.  If you leave the options blank then they will be automatically populated with a list of all values currently in the database, this can be useful for fields like categories and tags, but is less useful for fields like title which would just generate an entry for every post in the blog.  If you want to specify the values manually you can specify this as a comma separated list of values, ‘a,b,c’ for three options with values ‘a’, ‘b’ and ‘c’ respectively, or if you want to give ‘friendly’ labels to the user you can separate the value from the label using a colon as follows ‘a:Group A,b:Group B,c:Group C’.

The Compare field controls the way that the user input is compared to the data in the database.  I would expect the most commonly used of these to be “equals” which requires an exact match between the user data and the database field (useful for category searches) and the “Words in” or “Phrase In” types which will search to see if the user input is a part of the data, rather than a full match, this is useful for things like searching the text of a post.  The difference between ‘words’ and ‘phrase’ is that ‘words’ splits the input into a series of words and searches for these individually whereas ‘Phrase’ searches for all the words in sequence.

The “Less Than” and “More Than” comparisons ensure that the data is less than or more than the user input respectively.  This is probably only relevant for numeric input but it can be used for strings as well and will search alphabetically.  For numeric input it can help to also tick the “Numeric” checkbox as sometimes the database will be set up to compare numbers alphabetically (so that 10 is less than 2).

The “Range” comparison is a little more complicated and requires the user input to be of the form A-B to return results that are between A and B.  This is primarily intended to be used for Drop-downs and radio buttons where the values can be set by the site administrator.  If you specify the values for the dropdown like the following: “-10:Less Than 10,10-20:Between 10 and 20,20-:More than 20″, then the user will be presented with the options “Less Than 10″, “Betwen 10 and 20″ and “More than 20″ but the search will be done with the values “-10″,”10-20″ and “20-”.  Again the numeric checkbox should be used for numeric data.

I hope that helps, please let me know if you have any trouble (or joy) with the plugin or if any of my instructions don’t make sense.

Extending Custom Search

For developers, I’ve tried to build this in a modular way to allow extensions to be added, I will try to document this at some point in the future but if you can’t wait then the best places to get started would be to look at the filter ‘custom_search_get_classes’ in custom-search/custom-search.php and the Great Real Estate bridging code in custom-search/bridges/greatrealestate.php.

This plugin is at quite an early stage in development though so it is likely that future versions may not be compatible with the same extension interface and it is likely that any extensions will need altering when new versions are released..

Changes since v0.1

• I’ve reworked the UI and added some more sensible default values, hopefully this should make it less daunting for new users.
• Fixed a few bugs.
• Added in textual descriptions of the search parameters (for themes which support this)

I originally developed this plugin for a client project.  Basically the problem they had was that they were storing structured data (real estate properties) but the default wordpress search didn’t allow them to search it in a structured way (by price and location).  The plugin I’ve built allows you to configure multiple search input fields, configure the behaviour of each field (eg what options appear in a dropdown) and configure what database fields each input corresponds to (eg post title, post content, a custom field called price).

The plugin is now at point where I think it could be useful to other people although I’m aware that there are a lot of improvements that could be made.  Please let me know if you have any suggestions or complaints and I will do my best to get them resolved.

You can download the plugin here.

System Requirements

Tested with:

• PHP Versions 4.4.9 and 5.2.6
• Wordpress 2.7

Quick Start Guide

I will try to put more complete documentation together at some point but for now this is a quick start guide to building a search form.

1. Install the plugin.  Download it here unzip it in your wp-content/plugins folder, then activate it in the plugins page of your wordpress admin site.
2. Add the widget to the sidebar on which you want it to appear.
3. Click edit and set-up the fields for your form. (More Info Below)

Setting up the fields

Each field has a number of settings which control the way the input appears to the user and the way the search is performed.

Label sets the label displayed next to the field, you can set this to whatever you want.

Data Type controls what type of data is being searched (i.e. what database table is being used).  The standard options are “Post Field” for data such as post title and post content, from the standard wordpress post data,  “Custom Field” for data from the custom fields, and “Category” to search on the categories a post is in.

Data Field makes a more specific selection from the data available.  The drop down list should give some sensible options, or if you know the name of the database field you want to query you can type this in manually.

Widget controls what type of HTML input is created for the front end of the site.  It should be fairly obvious what these do.  The inputs called “Auto Values” will automatically create options based on what is in the database.

Some widgets will require extra options in the Widget Options field.  At the moment this is just the drop down and radio button widgets (not the auto values ones) which require you to specify a list of values for the user to choose from.  You can specify this as a comma separated list of values, ‘a,b,c’ for three options with values ‘a’, ‘b’ and ‘c’ respectively, or if you want to give ‘friendly’ labels to the user you can separate the value from the label using a colon as follows ‘a:Group A,b:Group B,c:Group C’.

The Compare field controls the way that the user input is compared to the data in the database.  I would expect the most commonly used of these to be “equals” which requires an exact match between the user data and the database field (useful for category searches) and the “Words in” or “Phrase In” types which will search to see if the user input is a part of the data, rather than a full match, this is useful for things like searching the text of a post.  The difference between ‘words’ and ‘phrase’ is that ‘words’ splits the input into a series of words and searches for these individually whereas ‘Phrase’ searches for all the words in sequence.

The “Less Than” and “More Than” comparisons ensure that the data is less than or more than the user input respectively.  This is probably only relevant for numeric input but it can be used for strings as well and will search alphabetically.  For numeric input it can help to also tick the “Numeric” checkbox as sometimes the database will be set up to compare numbers alphabetically (so that 10 is less than 2).

The “Range” comparison is a little more complicated and requires the user input to be of the form A-B to return results that are between A and B.  This is primarily intended to be used for Drop-downs and radio buttons where the values can be set by the site administrator.  If you specify the values for the dropdown like the following: “-10:Less Than 10,10-20:Between 10 and 20,20-:More than 20″, then the user will be presented with the options “Less Than 10″, “Betwen 10 and 20″ and “More than 20″ but the search will be done with the values “-10″,”10-20″ and “20-”.  Again the numeric checkbox should be used for numeric data.

I hope that helps, please let me know if you have any trouble (or joy) with the plugin or if any of my instructions don’t make sense.

Further Development

For developers, I’ve tried to build this in a modular way to allow extensions to be added, I will try to document this at some point in the future but if you can’t wait then the best places to get started would be to look at the filter ‘custom_search_get_classes’ in custom-search/custom-search.php and the Great Real Estate bridging code in custom-search/bridges/greatrealestate.php.