So far, I've always liked to recommended BackPress. But even a well-maintained standard is feasible, with all its advantages in the context of the philosophy of updates. WordPress reduces initializing to a minimum, if the constant SHORTINIT is set.

The wp-settings.php of WordPress is the key.

// Stop most of WordPress from being loaded if we just want the basics.
if ( SHORTINIT )
	return false;

Thus, the loading process is much slimmer and files that are loaded later, must be integrated via a Plugin or Theme functions. The ability is worth it and not infrequently, the part of WordPress in some projects is so small compared to your own developments, that this is worth to do.

Activating in wp-config.php via define( 'SHORTINIT', TRUE ); is done quickly and you can start the test, but note: the globals $wp, $wp_query, $wp_the_query was set as NULL.

The function to store the entries is fb_save_custom_user_profile_fields() and here it is important to check the rights of each active user, only if the rights are available, in this case for editing users (edit_user), then data may be stored.
The actual saving of data takes place via update_usermeta().

It can pass all kinds of fields of course, the input field is just an example. It is advisable to outsource the functions in a Plugin, an alternative is also the functions.php of the Theme, but is certainly not the best way.

Each function of the small sample was referred to two hooks. Because WordPress differentiate between editing of user profiles and update personal data. This is done using the constant IS_PROFILE_PAGE. On default this constant is on TRUE and so would the hooks show_user_profile and personal_options_update be enough to bring in new fields and save them. But this can vary depending on the installation and this way the admin cannot maintain these new fields. In particular, two more hooks are needed. Otherwise there might be many cases, where the admin has to maintain data which the user doesn't even see in his profile.

function fb_add_custom_user_profile_fields( $user ) {
?>
	<h3><?php _e('Extra Profile Information', 'your_textdomain'); ?></h3>

	<table class="form-table">
		<tr>
			<th>
				<label for="address"><?php _e('Address', 'your_textdomain'); ?>
			</label></th>
			<td>
				<input type="text" name="address" id="address" value="<?php echo esc_attr( get_the_author_meta( 'address', $user->ID ) ); ?>" class="regular-text" /><br />
				<span class="description"><?php _e('Please enter your address.', 'your_textdomain'); ?></span>
			</td>
		</tr>
	</table>
<?php }

function fb_save_custom_user_profile_fields( $user_id ) {

	if ( !current_user_can( 'edit_user', $user_id ) )
		return FALSE;

	update_usermeta( $user_id, 'address', $_POST['address'] );
}

add_action( 'show_user_profile', 'fb_add_custom_user_profile_fields' );
add_action( 'edit_user_profile', 'fb_add_custom_user_profile_fields' );

add_action( 'personal_options_update', 'fb_save_custom_user_profile_fields' );
add_action( 'edit_user_profile_update', 'fb_save_custom_user_profile_fields' );

Fortunately WordPress defines two constants which can help you to simplify things nonetheless: WP_PLUGIN_DIR and WP_PLUGIN_URL. These constants point to the plugin directory of the respective WordPress installation. They are defined since WordPress 2.6 and supporting older versions is most likely unnecessary
.
To make your plugins accessible to all your installed WordPress versions you simply move them to a central directory and define the constants accordingly:

define( 'WP_PLUGIN_DIR', '/var/www/plugins' ); // or with XAMPP C:/xampp/htdocs/plugins
define( 'WP_PLUGIN_URL', 'http://localhost/plugins' );

In this example the plugins reside in the directory 'plugins' in the root directory of the webserver. If you now define the above constants in every WordPress installation you have easy access to them to test your code with every version.

(Thanks to John Blackbourn on the wp-hackers list for having the idea.)

Hint for Multisite-Users

Also usable for WordPress Multisite

define( 'WPMU_PLUGIN_DIR', '/var/www/multisite-plugins' );
define( 'WPMU_PLUGIN_URL', 'http://localhost/multisite-plugins' );

WordPress provides a simple method to ensure that all stylesheets and scripts are reloaded from the source when they have changed by providing a version parameter:

wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
wp_enqueue_style( $handle, $src, $deps, $ver, $media);

You can increase the $ver parameter every time you've changed the files:

wp_enqueue_script( 'my_script', 'my_script.js', '', '0.11' );
wp_enqueue_style( 'my_style', 'my_style.css', '', '0.11' );

The URL of the stylesheet/script will be changed to '.../my_script.js?ver=0.11' so that every caching system detects the changed file and reloads it from its source and the user always gets the recent version.

But to change the version number manually every time in the development stage would be a bit tedious and you're a programmer, right? So let's automate this:

wp_enqueue_script( 'my_script', 'my_script.js', '', time() );
wp_enqueue_style( 'my_style', 'my_style.css', '', time() );

The value of time() changes every second so the version ID of the file changes constantly and it's reloaded from the source and not from some cache.

It's a bit disadvantageous that you have to substitute the time based version parameter by a "real" version number every time you deploy your code since the actual user still should have the benefits of cached scripts and stylesheets. Let's extend the idea:

define ('VERSION', '1.1');

function version_id() {
  if ( WP_DEBUG )
    return time();
  return VERSION;
}

wp_enqueue_script( 'my_script', 'my_script.js', '', version_id() );
wp_enqueue_style( 'my_style', 'my_style.css', '', version_id() );

This way you can make sure that in your development environment everything is reloaded from source all the time but a productive server takes advantage of caches.

/**
 * Remove a top level admin menu
 *
 * @param string $menu_slug The slug of the menu
 * @return array|bool The removed menu on success, False if not found
 */
remove_menu_page( $menu_slug )

/**
 * Remove an admin submenu
 *
 * @param string $menu_slug The slug for the parent menu
 * @param string $submenu_slug The slug of the submenu
 * @return array|bool The removed submenu on success, False if not found
 */
remove_submenu_page( $menu_slug, $submenu_slug ) {

It's easy to remove menu entries and it is not necessary anymore to read the arrays $menu and $submenu. Until now you had to search for them in the array and remove them via unset() from the array. Alternatively you were also able to find the entry on the basis of a key - the above new features make this unnecessary and as a parameter value only the "slug" is passed, which can be found in the link or the URL of the backend. A small example, where we remove the entries to the comments and the submenu-page discussion will show the new possibilities.

function fb_remove_menu_entries () {
	// with WP 3.1 and higher
	if ( function_exists( 'remove_menu_page' ) ) {
		remove_menu_page( 'edit-comments.php' );
		remove_submenu_page( 'options-general.php', 'options-discussion.php' );
	} else {
		// unset comments
		unset( $GLOBALS['menu'][25] );
		// unset menuentry Discussion
		unset( $GLOBALS['submenu']['options-general.php'][25] );
	}
}
add_action( 'admin_menu', 'fb_remove_menu_entries' );

The above code provides a simple solution, removed the two entries and also has a fallback for WordPress, smaller version 3.1. It is also conceivable that the removal is also connected with user rights

if ( function_exists( 'remove_menu_page' ) && ! current_user_can( 'manage_options' ) ) {

so it would be possible to optimize the menu explicitly for a user. Alternatively, the plug Adminimize helps and facilitates the job via admin area.
You can also read about this topic on Justin's post, but my post was an older draft and now was published - the topic is worth it.

The function can be expanded, for example, with queries on rights of the logged users or various other requirements.

In the first snippet the output on the frontend is always filtered, only your backend is_admin() and your feed is_feed() keeps untouched. The filter is placed in the example at 15 minutes and these are aligned with the setting of WordPress, so that the time zone will be considered. The 15 minutes will be converted into seconds and subtracted from the value.

<code>
function publish_later_on_frontend( $where ) {

	if ( is_admin() || is_preview() || is_feed() )
		return $where;

	$offset =  15; // minutes
	$offset = ( get_option( 'gmt_offset' ) * 3600 ) - ( $offset * 60 ); // gmt offset of WP options minus custom time
	$where .= " AND post_date < '" . gmdate( 'Y-m-d H:i:s', ( time() + $offset ) ) . "'";

	return $where;
}
add_filter( 'posts_where', 'publish_later_on_frontend' );
</code>

Another brief example will allow all users logged, with minimum rights to read current_user_can('read') - so subscribers, to read the contents. All other visitors will get the content presented 10 days later.

<code>
function publish_later_on_frontend( $where ) {

	if ( is_admin() || is_preview() || is_feed() || current_user_can('read') )
		return $where;

	$offset =  10; // days
	$offset = ( get_option( 'gmt_offset' ) * 3600 ) - ( $offset * 24 * 60 * 60 ); // gmt offset of WP options minus custom time
	$where .= " AND post_date < '" . gmdate( 'Y-m-d H:i:s', ( time() + $offset ) ) . "'";

	return $where;
}
add_filter( 'posts_where', 'publish_later_on_frontend' );
</code>

Alternatives with SQL-Statement:

// with INTERVAL
$where .= " AND post_date < NOW() - INTERVAL 5 MINUTE"; // DAY, HOUR

// with strtotime()
$where .= " AND post_date < FROM_UNIXTIME(" . strtotime("-5 day"). ")";

Well - any other ideas? Then let us know in our comment area. I'm happy to see any improvements to the code, especially in the area of calculation with time.

Adding the input field

As an example we will add an input field asking for the city the commenter lives in. Additionally the field will be marked as mandatory.

To add an additional input field you have to modify the comment form defaults by setting a filter for the function comment_form_defaults:

add_filter( 'comment_form_defaults', 'change_comment_form_defaults');

For adding the new input field after the email field you need to extend the default "Email" input field:

function change_comment_form_defaults( $default ) {
    $commenter = wp_get_current_commenter();
    $default[ 'fields' ][ 'email' ] .= '<p class="comment-form-author">' .
        '<label for="city">'. __('City') . '</label>
        <span class="required">*</span>
        <input id="city" name="city" size="30" type="text" /></p>';
    return $default;
}

Basically this is the same markup used to create the author field with modified values for label, name, and id and "<span class="required">*</span>" added to mark the field as mandatory (only visually).

Storing the data in the database

Storing the value of the new field is quite simple since WordPress already contains a table in the database called commentmeta for storing exactly this type of data called meta data.
The usage of this table is straightforward since WordPress provides the two functions add_comment_meta() and get_comment_meta():

add_comment_meta($comment_id, $meta_key, $meta_value, $unique = false)
get_comment_meta( $comment_id, $meta_key, $single = false )

To store the meta data together with the other comment data an action needs to be added:

add_action( 'comment_post', 'save_comment_meta_data' );

function save_comment_meta_data( $comment_id ) {
    add_comment_meta( $comment_id, 'city', $_POST[ 'city' ] );
}

To make the city field mandatory the script needs to check if the user had entered some text before the data is stored. WordPress provides a filter named preprocess_comment which can be used to verify the data:

add_filter( 'preprocess_comment', 'verify_comment_meta_data' );

function verify_comment_meta_data( $commentdata ) {
    if ( ! isset( $_POST['city'] ) )
        wp_die( __( 'Error: please fill the required field (city).' ) );
    return $commentdata;
}

The data is not actually processed but it is tested if the field $_POST['city'] contains any data. If there is no data the script will die with an error message otherwise the comment data will be returned unaltered.
Alternative ist the Action Hook pre_comment_on_post usable.

Retrieving and displaying the data

To retrieve the data from the database WordPress provides the function get_comment_meta. To avoid to modify the theme template the city name is attached to the author name by using the filter get_comment_author_link:

add_filter( 'get_comment_author_link', 'attach_city_to_author' );

function attach_city_to_author( $author ) {
    $city = get_comment_meta( get_comment_ID(), 'city', true );
    if ( $city )
        $author .= " ($city)";
    return $author;
}

Advanced usage

You might have noticed that both functions add_comment_meta() and get_comment_meta() contain parameters that haven't been explained yet, namely $unique and $single.

The $unique parameter controls whether you can add multiple data field with the same key name for the same comment_id. But why would you want do such a thing?
Let's assume you want to allow the user to add multiple cities separated by commas. Surely you can store the whole string in a single table row but that would make the data hard to handle if you want to use it in a different context and it simply conflicts with basic database principles. So the input data will be split and each city is stored in its own dataset:

function save_comment_meta_data( $comment_id ) {
    $cities = explode( ',', $_POST[ 'city' ] );
    foreach ( $cities as $city )
       echo add_comment_meta( $comment_id, 'city', $city, false );
}

If the user enters e.g. three city names all three are stored with the keyname city. If the parameter unique would have been set to true only the first city would have been stored because the parameter prevents the storage attempts of the last two city names.

When retrieving the data with get_comment_meta the parameter $single comes into view. If it is set to false the function does not return a single value but an array of values.

function attach_city_to_author( $author ) {
    $cities = get_comment_meta( get_comment_ID(), 'city', false );
    if ( $cities ) {
        $author .= ' ( ';
        foreach ( $cities as $city )
            $author .= $city . ' ';
        $author .= ')';
    }
    return $author;
}

Modifying the meta data

There might be situations where you want to change the meta data stored in the database. As expected WordPress provides a function for this called update_comment_meta():

update_comment_meta( $comment_id, $meta_key, $meta_value, $prev_value );

To modify a value you use the function the same way you use add_comment_meta:

$new_city = "Timbuktu";
update_comment_meta( $comment_id, 'city', $new_city );

If the $meta_key does not exist the function adds the meta data to the database. But what is the parameter $prev_value used for?
As noticed above you can store more than one value with the same meta key for a single comment. The code snippet above would change all values with the key 'city'. If you set the parameter $prev_value to the value that is to be modified the function will do exactly what is intended:

$old_city = "Berlin";
$new_city = "Timbuktu";
update_comment_meta( $comment_id, 'city', $new_city, $old_city );

Behind the scenes

The structure of the commentmeta table is quite simple:

The meta_id is an auto-incremented ID and comment_id is of course the ID of the comment. The actual data is stored in the meta_key and meta_value fields, containing the keyname (in our case 'city') and the actual value (the name of the city the user entered). Example:

The comments with the ID 76 and 77 contain meta data with only one value assigned to the key 'city' whereas the comment with the ID 78 got three different values with the same key.

Look it up

If you want to look up the {add|get|update}_meta_data functions in the core you can find them in .../wp-includes/comment.php.
The default values of the comment form which are modified above are defined in ../wp-includes/comment-form.php in the function comment_form().

Source code

Download the complete sources of the examples above:

• via Gist: Single value meta data
• via Gist: Multi value meta data

In the most common scenario the user is not logged in, is allowed to comment on the article and the comments are not closed:

There are six hooks available:

• comment_form_before
• comment_form_top
• comment_form_before_fields
• comment_form_after_fields
• comment_form
• comment_form_after

You might have noticed that the hooks comment_form and comment_form_after seem to be anchored almost at the same point but depending on the user's role and discussion settings they are not always available so you should take care which hook you are using in your code.

User logged in
If you are logged in you have fewer hooks available since the name, email and URL input fields are not needed. The missing hooks are

• form_comment_before_fields
• form_comment_after fields

User is not logged and "Users must be registered and logged in to comment" activated
If your blog is configured that only registered users can comment, an unregistered user will see this comment form and additionally the hook comment_form_must_log_in_after is available. Please notice that in this case the hook comment_form is left out.

Comments closed
If the comments on the post are closed you have only one hook left (comment_form_closed) since the form is not displayed at all:

In the field of PHP development, I've always looked at several solutions, played with different options and in the end I'm sitting in front of a browser with IDE, XDebug or some of my own extensions. In Firefox I have used FirePHP in various areas, more information about it can be found in this article. Alternatively I also wrote about the debugConsole. Therefore it was natural to browse for a solution in the environment of Chromium. You will be able to find some interesting topics about it and I would like to introduce php-console and show how to integrate it in WordPress via Plugin.

PHP Console is extension for Lagger and class PhpConsole, that displays PHP errors/debug messages in Google Chrome console and in notification popups.

This statement says it all, after integration of the class you can see nice results. Via Plugin I solved to include the class, which can also included manually at the required spot of the relevant files.

You can check out all the features of the extension at the project site, documentation and download are also available on the project site.

Here are some insights of the output and maybe it makes you want to test it or even more.

In the first screenshot you see the ouput of the PHP errors, which are shown in the console. You can also get the results after loading the page as a popup, see last screenshot. Therefore are settings of the extension via context menu available.

Alternatively an output in log, which I created explicitly as an example via Plugin. So it makes it possible to control the output.

In the last screenshot a complete overview, including a popup - you have a nice overview of all PHP messages so you won't forget anyhting while developing.

Here is my little Plugin (alternatively at Github for download including all files and folders), whereas I put the class PhpConsole.php of the php-Console in the folder inc. The output in log of the console will be controlled via the function debug(); It is possible to provide a name so you can read the analysis easier. This Plugin is also compatible to my php web hosting, if you'll ask.

<?php
/*
Plugin Name: php-console
Plugin URI: http://bueltge.de/
Text Domain: php-console
Domain Path: /languages
Description: <a href="http://code.google.com/p/php-console/">php-console</a> - Google Chrome extension for displaying PHP errors/exceptions/debug messages in browser console or notification popups
Author: Frank Bültge
Version: 0.0.1
Author URI: http://bueltge.de/
Donate URI: http://bueltge.de/wunschliste/
License: GNU v3
Last change: 29.03.2011
*/ 

/* load php-console functionality */
require_once('inc/PhpConsole.php');
PhpConsole::start( TRUE, TRUE, dirname(__FILE__) );

class Wp_Php_Console {

	public function __construct() {

		$this->messages();

		$this->get_contents( 'GNU GENERAL PUBLIC LICENSE' );
	}

	public function messages() {
		global $wpdb, $pagenow;

		debug( $pagenow, 'Var Pagenow' );
		$sql = "SELECT * FROM $wpdb->options";
		debug( $sql, 'sql-options' );
	}

	public function get_contents( $string ) {

		$content = file_get_contents( '../license.txt', NULL, NULL, 0, 100 );
		$pos = strpos( $content, $string );

		debug( $pos , 'Position' );
		if ( ! $pos )
			debug( $content, 'Content' );
	}
}
new Wp_Php_Console();

?>

In our first code example the IDs are set in the array. The filter is only working if it is the search is_search and if you are not ! in the backend is_admin.

// search filter
function fb_search_filter($query) {

    if ( !$query->is_admin && $query->is_search) {
        $query->set('post__not_in', array(40, 9) ); // id of page or post
    }

    return $query;
}
add_filter( 'pre_get_posts', 'fb_search_filter' );

If you like to exclude the subpage of a page, then you can add it to the ID.

// search filter
function fb_search_filter($query) {

    if ( !$query->is_admin && $query->is_search) {
        $pages = array(2, 40, 9); // id of page or post
        // find children to id
        foreach( $pages as $page ) {
            $childrens = get_pages( array('child_of' => $page, 'echo' => 0) );
        }
        // add id to array
        for($i = 0; $i < sizeof($childrens); ++$i) {
            $pages[] = $childrens[$i]->ID;
        }
        $query->set('post__not_in', $pages );
    }

    return $query;
}
add_filter( 'pre_get_posts', 'fb_search_filter' );

There are many possibilities and I hope I was able to give you a starting point if you like to exclude posts and pages in your search.