To block it is pretty straightforward. Just add the following to your .htaccess file:

RewriteEngine on
RewriteCond %{QUERY_STRING} ^[^=]*$
RewriteCond %{QUERY_STRING} %2d|\- [NC]
RewriteRule .? – [F,L]

This vulnerability effects any PHP based web site. So it doesn’t matter if you’re using WordPress, Drupal, Joomla or anything else. If your server is set up for PHP running via CGI, then you’re a potential security risk.

The guidelines to meet ADA accessibility:

1. Design your website design with a consistent and clean layout for both content and navigation throughout all pages.
2. Use clear and consistent language on your website.
3. Use sufficient color contrast in text and images on your website.
4. Your website should be designed using valid HTML and be able to pass W3C (World Wide Web consortium) tests for errors.
5. A person with disabilities should be able to navigate your website using just the keyboard.

Additionally, image alt tags (with correct text descriptions) must be used for all images and any visual content on your website. Alt tags also have to be manually evaluated and changed so that they make sense to someone with disabilities. This process is critical for ADA compliance.

ADA Accessibility online Testing

Once your website has been modified to comply with ADA guidelines, it must be re-tested. There are a number of online tools that can assist you in this process.

Free tool in Firefox: http://worldspace.deque.com/FireEyes/login/auth
Free tool in Windows Explorer: http://www.paciellogroup.com/node/18?q=node%2F22

Compliance testing also requires human testing by an ADA compliance expert.

You can enqueue CSS style sheets and javascript with similar APIs, as in: wp_register_style($handle, $src, $deps, $ver, $media) and wp_enqueue_style($handle, $src, $deps, $ver, $media). You can look up the WordPress Codex entry for wp_enqueue_script() for more information.

After enqueuing the stylesheet, you can add a conditional — for example, if you want something added for older IE versions, as in the following example:

wp_enqueue_style('ie7-style', get_template_directory_uri() . '/ie7.css');

global $wp_styles;
$wp_styles->add_data('ie7-style', 'conditional', 'lte IE 7');

This adds the conditional to the <link> tag so what gets rendered looks something like:

<!--[if lte IE 7]>
<link rel="stylesheet" href="http://mydomain.com/wp-content/themes/mytheme/ie7.css" type="text/css" media="all"/>
<![endif]-->

Personally, I try to avoid requiring conditionals but in some cases it’s unavoidable. This is a nice way to do it and still use the recommended WordPress APIs for your scripts, so your theme or plugin will work nicely with others.

What are Constants?

Many programming languages have the concept of a constant. This is like a variable, but once set it’s value never changes — making it a constant. You can go here for more information on defining Constants in PHP.

Where are They Used?

Constants can be used almost anywhere. However, they are most often declared early on in the processing of a PHP script. The reason for this is that if they’re not you may need to check to make sure if the constant exists before using it. This is easily done using the defined() function. An example of this can be found below.

WordPress declares most of its constants in the wp-config.php file. You can declare a constant in a plugin, which is loaded much later on in the WordPress bootstrap process, but if you do that you should definitely check to see if the constant has already been declared. Once declared, you cannot change the value of a constant — this is what makes them constant.

Why Would You Use Constants?

Using constants, you can reduce your plugin footprint. Since many parts of the WordPress core code make use of these, it can reduce the amount of code you need to write for some operations.

Constants are great for optimization. They can significantly increase speed as well as security.

Cautions

Only use constants if you have a good idea of what you’re doing and can properly keep track of changes to the Codex with new releases of WordPress.

Some constants may change when new major version upgrades are made.

WordPress Constants

Here are some of the constants and how they are used. There are probably a few that I missed. I’ll add to this as I find more.

Security Constants

These constants are declared in wp-config.php and are required for the normal operation of WordPress. All of these constants are 64 character random strings and are used for hashes, nonces and other security purposes. Each installation of WordPress should use different strings to ensure that your site is harder to “hack.” If you haven’t already changed your security keys, you can use WordPress’s online security key generator.

• AUTH_KEY — Used for authenticating a user and setting cookies.
• SECURE_AUTH_KEY — Used for authenticating a user and setting cookies under the https protocol.
• LOGGED_IN_KEY — Used for marking a user’s cookie data as logged in.
• NONCE_KEY — Used for creating Nonces, which are used as one-time values to ensure that humans are entering data in forms.
• AUTH_SALT — Used to “salt” the authentication data. Salts are random data added to passwords, keys and other data to make them harder to guess.
• SECURE_AUTH_SALT — Used to “salt” the secure authentication data.
• LOGGED_IN_SALT — Used to “salt” the logged in cookie data.
• NONCE_SALT — Used to “salt” the nonce data.

Database Constants

These are used to declare your database connection information. If you ever need to change your database password or location, you can effect this by editing your wp-config.php file and change these values:

• DB_NAME — The name of your database.
• DB_USER — The user name for your database connection.
• DB_PASSWORD — The password for your database connection.
• DB_HOST — The host name, or computer name where your database server is located.
• DB_CHARSET — The character set used when creating tables in your database. Unless you have a specific requirement for something else, this should have a value of ‘utf8′.
• DB_COLLATE — The collation (sorting) type to use for indexed data in your tables. This should be left empty unless you have a specific requirement otherwise.

Other wp-config.php Constants

These are the last few constants that are normally declared in wp-config.php:

• COOKIE_DOMAIN — Specifies the domain set in cookies for those with unusual domain configurations. This can help to prevent cookies being sent with requests for static content. Example: define(‘COOKIE_DOMAIN’, ‘www.staticdomain.com’);.
• WP_DEBUG — Sets WordPress’s “debug” mode on or off. Normally, this is set to false. Changing it to define(‘WP_DEBUG’, true); will turn on debug mode. This can be useful if you need to track down errors.
• WP_HOME — This overrides the configuration setting for the home url, but doesn’t change it permanently. This should include the http:// prefix, as in: define(‘WP_HOME’, ‘http://domain.com/optionalsubdirectory’);.
• WP_SITEURL — Declares the site’s URL. This defines the address where your WordPress code files reside. It should include the http:// prefix. An example would be: define(‘WP_SITEURL’, ‘http://mydomain.com’);.
• WPLANG — Used to localize your WordPress install. This should be left empty for a default language of American English. If you need to localize your WordPress installation, you need to change this and install a corresponding MO file for your language. For example, changing this to: define (‘WPLANG’, ‘de_DE’); will set your language to German.

Default Constants

These values are declared in the wp-includes/default-constants.php file. You to change these settings, add them to your wp-config.php file so they are declared before the wp-includes/default-constants.php file is loaded.

• ADMIN_COOKIE_PATH — Sets the cookie path for admin-based cookies. If not already defined, this will take the value: define(‘ADMIN_COOKIE_PATH’, SITECOOKIEPATH . ‘wp-admin’);
• FORCE_SSL_ADMIN — Enforces the use of SSL for Admin access. Normally, this is disabled. To force SSL for all Admin pages, you can: define(‘FORCE_SSL_ADMIN’, true);
• FORCE_SSL_LOGIN — Enforces the use of SSL for site logins. Normally, this is disabled. To force SSL for login requests, you can: define(‘FORCE_SSL_LOGIN’, true);
• SITECOOKIEPATH — Sets the cookie path for normal site cookies. If not set, this will take the value define(‘SITECOOKIEPATH’, preg_replace(‘|https?://[^/]+|i’, ”, get_option(‘siteurl’) . ‘/’ ) );
• WP_CONTENT_DIR — Sets the name of the content directory. Normally, this is ‘wp-content’. To change this, you can: define(‘WP_CONTENT_DIR’, ‘mycontentdirectory’); This can also be obtained by using plugin_dir_path()
• WP_CONTENT_URL — Sets the URL for the content directory references. if you change the WP_CONTENT_DIR, you will also need to change this to match the directory name for http requests.
• WP_DEBUG_DISPLAY — Controls display of errors. The default is to use the display_errors setting and not force errors to be displayed. To force errors to display, you can: define(‘WP_DEBUG_DISPLAY’, true);
• WP_DEBUG_LOG — Controls error logging to the file wp-content/debug.log. The default is no logging. To change this, you can: define(‘WP_DEBUG_LOG’, true);
• WP_DEFAULT_THEME — Sets the default theme. The current version of WordPress assumes a default theme of ‘twentyeleven’. If you want to change this, you can: define(‘WP_DEFAULT_THEME’, ‘mydefaulttheme’);
• WP_PLUGIN_DIR — Sets the directory for plugin files. The default is ‘plugins’. To change this, you can: define(‘WP_PLUGIN_DIR’, ‘/newplugindir’);
• WP_PLUGIN_URL — Sets the URL for the plugin directory. If you change the WP_PLUGIN_DIR, you will also need to change this to match the directory name for http requests. If you have compatibility issues with some plugins, you can set an additional value, as in: define(‘PLUGINDIR’, ‘/wpdir/wp-content/plugins’);.
• WPMU_PLUGIN_DIR — Sets the directory to store the Must Use plugins. The default location is /mu-plugins. To change this, you can: define(‘WPMU_PLUGIN_DIR’, ‘/requiredplugins’);
• WPMU_PLUGIN_URL — Sets the URL for the Must Use plugin directory. If you change the WPMU_PLUGIN_DIR, you will also need to change this to match the directory name for http requests.

Capability Settings

These can be used to control certain behaviors that users are allowed to perform. Some of these are confusing because you are turning “on” the ability to “disallow” a feature. So be careful on how you’re declaring these values. Most of these are used in the wp-includes/capabilities.php file, but if you want to change the settings, you should add your settings to your wp-config.php file.

• ALLOW_UNFILTERED_UPLOADS — Allows unfiltered uploads. You can: define(‘ALLOW_UNFILTERED_UPLOADS’, true); to enable users to upload files without filtering. Be careful: this is a potential security risk.
• DISALLOW_FILE_EDIT — Allows users to edit theme and plugin files. If you do not want your users to be able to edit these files, you can change this: define(‘DISALLOW_FILE_EDIT’, true);
• DISALLOW_FILE_MODS — Allows users to update theme and plugin files via the WordPress Repository. If you do not want your users to be able to update their WordPress install, you can change this: define(‘DISALLOW_FILE_MODS’, true);
• DISALLOW_UNFILTERED_HTML — Disables the ability to allow unfiltered HTML. Using define(‘DISALLOW_UNFILTERED_HTML’, false); will turn off the ability to allow unfiltered HTML.
• WP_CACHE — Enables the built-in WordPress caching capability. If you want to enable this caching, you can: define(‘WP_CACHE’, true);
• WP_USE_THEMES — Declared in /index.php. Tells WordPress whether or not use load it’s template engine. If you want access to WordPress APIs but don’t want or need the overhead of the template engine, define this to false: define(‘WP_USE_THEMES’, false);

Script Control

These settings control how scripts (Javascript and CSS) are handled by the system.

• COMPRESS_CSS — Compresses CSS. To enable CSS compression, you can: define(‘COMPRESS_CSS’, true);
• COMPRESS_SCRIPTS — Compresses scripts. To enable compression, you can: define(‘COMPRESS_SCRIPTS’, true);
• CONCATENATE_SCRIPTS — Concatenates Javascript and CSS files. To enable, you can define(‘CONCATENATE_SCRIPTS’, true);
• ENFORCE_GZIP — Forces gzip for compressoin of data sent to browsers. The default setting is to use the mod_deflate Apache module. If your host does not have this installed, you can: SCRIPT_DEBUG — Include the development (or non-minified) versions of all Javascript and CSS files. It also disabled compression and concatenation. To enable, you can: define(‘SCRIPT_DEBUG’, true);

Optimization Settings

These values can be used to control and optimize your WordPress install.

• AUTOSAVE_INTERVAL — Sets the interval for saving revisions while editing posts.
• CORE_UPGRADE_SKIP_NEW_BUNDLED — Enables skipping of theme and plugin updates when upgrading WordPress.
• DOING_AJAX — Set to TRUE when processing an AJAX request.
• EMPTY_TRASH_DAYS — Sets the number of days before trashed items are removed.
• IMAGE_EDIT_OVERWRITE — Allows overwriting images when editing them.
• MEDIA_TRASH — Enables the trash function for Media files.
• WP_MEMORY_LIMIT — Sets the memory limit used.
• WP_MAX_MEMORY_LIMIT — Controls the maximum memory size used. Some WordPress processes require more memory. This setting controls the upper limit used by these high memory use procedures.
• SHORTINIT — Turns on only the core WordPress functions. Often used when interfacing to other platforms.
• WP_POST_REVISIONS — Sets the maximum number of revisions to save. If set to FALSE it will be unlimited, an integer set the maximum number of revisions to save.

MultiSite Settings

These values control how WordPress MultiSite behaves.

• NOBLOGREDIRECT — Sets the URL to redirect visitors to when they request a non-existent MultiSite blog. The default is ‘%siteurl%’, which is the default site. If you wish to use a different location, you can: define(‘NOBLOGREDIRECT’, ‘mynewdomain.com’);
• WP_ALLOW_MULTISITE — Turns on MultiSite. Just enabling this using define(‘WP_ALLOW_MULTISITE’, true); does not by itself make your WordPress install a MultiSite install. It just starts the process. When you add this to your wp-config.php file, it turns on the Network menu in the Admin. This allows you to make certain choices and continue the setup process for your MultiSite install.
• WPMU_ACCEL_REDIRECT — When using Apache X-Sendfile for quicker loading, this helps you turn it on natively in WordPress for MultiSites. To enable, you can: define(‘WPMU_ACCEL_REDIRECT’, true);

Updated: May 4, 2012

define('DJ_POST_VIEW_COUNT', 'dj_post_view_count_meta');
function getPostViews($nPostId)
{
  $nCount = intval(get_post_meta($nPostId, DJ_POST_VIEW_COUNT, true));
  if ($nCount == 0)
  {
    delete_post_meta($nPostId, DJ_POST_VIEW_COUNT);
    add_post_meta($nPostId, DJ_POST_VIEW_COUNT, '0');
  }
  return ($nCount . ' View' . (($nCount == 1 ? '' : 's'));
}
function incrementPostViews($nPostId)
{
  $nCount = intval(get_post_meta($nPostId, DJ_POST_VIEW_COUNT, true));
  if ($nCount == 0)
  {
    delete_post_meta($nPostId, DJ_POST_VIEW_COUNT);
    add_post_meta($nPostId, DJ_POST_VIEW_COUNT, '1');
  } else {
    update_post_meta($nPostId, DJ_POST_VIEW_COUNT, ++$nCount);
  }
}

Then, in your single.php template file, add the following inside “the loop:”

// this adds to the post view count
incrementPostViews(get_the_ID());

Finally, wherever you want to display the counts, add this code:

// this displays the number of views for the current post
echo getPostViews(get_the_ID());

For the most part, I would say that code like this should be written into a WordPress plugin, rather than added to the functions.php file. However, since counting and displaying the number of views of a post is usually tightly integrated into the display of a post — which is the job of the theme, in this case it arguable as to whether or not it belongs in the functions.php file or a plugin. This is one of those situations where it just doesn’t matter all that much.

With just a little work, this could be turned into a plugin that would automatically add and display the post counts — without any changes to the theme files. Something like this could be added using the hooks provided in popular theme frameworks, such as Genesis or Thematic very easily. In that case, implementing this as a plugin would be the easier solution from a user perspective because there would be no changes to the theme files required at all.

But what if you have different widths for different pages? You need a way of indicating to the WordPress system of the page width that can change depending on the theme page being used. So here’s a small code sample that can detect different page templates and change the $content_width accordingly.

// set content width depending on page template
function dj_set_content_width()
{
  global $post;
  $sTemplate = 'default';
  if (isset($post) && isset($post->ID))
    $sTemplate = get_post_meta($post->ID, '_wp_page_template', TRUE);
  switch ($sTemplate)
  {
  case 'default':
  default:
    $nWidth = 584;             // default width (taken from twentyeleven theme
    break;
  case 'showcase.php':
    $nWidth = 480;
    break;
  case 'sidebar-page.php':
    $nWidth = 500;
    break;
  }
  // use additional conditions to set page width
  if (is_attachment())
    $nWidth = 584;            // use this width for attachment pages
  global $content_width;
  $content_width = $nWidth;   // set width to calculated value
}

add_action('wp_head', 'dj_set_content_width', 1);

The hook is on the ‘wp_head’ event, as this is the point in time that WordPress needs to know the width of the page. It does this at a priority of 1, so that other functions operating on the same hook will have the modified value already set.

The function determines the page width by looking at the selected page template, according to the _wp_page_template meta data value that WordPress uses to store which page template is used when displaying the page. The is the mechanism used by “standard” themes, such as Twentyeleven.

If you’re using a different theme framework, your page template may be stored in a different way. For example, the Genesis Framework uses the meta value _genesis_layout. If you’re using that framework, you will need to obtain the different value and modify the switch-case appropriately, checking for values like ‘content-sidebar-sidebar’.

As indicated on Line 22, you can also use additional theme test functions to enable different width on specific pages. Other test functions such as the is_author(), is_front_page(), is_404(), etc. can be added to the list.

With a little careful thinking and planning, you can achieve a theme that is very flexible in its ability to display images and videos and accommodate theme settings. You’ll run into some issues if you’re using a theme or framework that uses non-standard settings, but those are not too difficult to work through. Just be careful to fall back to a default width setting in the case that your page does not have this meta data set already.

function dj_nav_search_box($sItems, $args)
{
    ob_start();
    get_search_form();
    $searchform = ob_get_clean();

    $sItems .= '<li>' . $searchform . '</li>';

    return ($sItems);
}
add_filter('wp_nav_menu_items','dj_nav_search_box', 10, 2);

How does it work?

It works by adding a filter, ‘wp_nav_menu_items’. This filter allows modification of the navigation menus that are displayed and is run after the menus are constructed but before they are output.

Lines 3-5 use output buffering to capture the contents of the theme’s search form. On Line 7, the search form is added to the menu contents by adding it to the menu within <li> tags.

The only thing that’s left to do is styling. I noticed on one of my themes that I needed to set the text color to white because the text of the search form was showing as black text on a black background is the navigation menu. So adding a CSS class of #navmenu .screen-reader-text { color: white; } does the trick. Of course, your theme is probably different, so your class names would have to change.

To do this requires a few moving parts, including a Web Server (Apache is the most common web server on Linux platforms) with PHP support, and a database server (MySQL). Assuming you already have these parts installed and working, I will outline a few steps on how to configure a local development environment for WordPress (or any other PHP application) development.

Another alternative is to use a tool like XAMPP, which is an all-in-one Apache, MySQL, PHP solution. It’s great if you don’t want to deal with all the configuration intricacies and also provides tools for many of the steps discussed here. But if you’re like me and like knowing how all the pieces work, setting up your own Apache/MySQL servers is a good exercise.

First, I set up a host name. I like to use a host name that is very close to the host name of the ultimate install domain. So if your target domain is mywebsite.com, you can set up a local test domain as mywebsite.loc. I like to use “loc” for the top level domain. The reason for this is if I need to transfer the database from your local environment to the live host server, the TLD being the same length makes this a little bit easier. (More on that later.) Adding an entry to your hosts file will create the test domain on your local machine. It will look something like this:

127.0.0.1 mywebsite.loc

The next step is configuring Apache to recognize a virtual host for your newly created domain. On Windows, you can add something like the following to your httpd.conf file. On Linux, you can add a new file in your sites-available directory with the following:

# vv changes for local install
#  NameVirtualHost mywebsite.loc
<VirtualHost localhost:80>
  ServerName mywebsite.loc
#  ServerAlias mywebsite.loc
  DocumentRoot "{{install directory}}"
  <Directory "{{install directory}}">
    AllowOverride All
    Options Indexes FollowSymLinks
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>
# ^^ end of changes for local install

The {{install directory}} is where your PHP and other files will be located. It will of course be in different directories on Windows and Linux, but the directory can be almost anywhere.

Once the changes are made to your Apache configuration, you need to restart Apache for the changes to take effect.

After restarting Apache, you can copy your WordPress files (or whatever other PHP application you’re working on) to your {{install directory}}. Once the files are in place, you can use your MySQL tool to create a database for WordPress. This can be done from the command line with the following two commands:

CREATE DATABASE wordpress;
GRANT ALL ON wordpress.* TO username@localhost IDENTIFIED BY 'password';

Now you should be able to point your browser to http://mywebsite.loc and go through the normal WordPress installation steps. After you’ve done your work, tested your code and you’re ready to move to the live site, you can export the database to a text file. If you then change any references to mywebsite.loc to refer to mywebsite.com. Now you can import the modified SQL file into your database on the live site without the need for any other changes.

To change this, you can use the following code:

function dj_filter_title_text($title)
{
    $scr = get_current_screen();
    if ('press-release' == $scr->post_type)
        $title = 'Enter Title of Press Release';
    return ($title);

add_filter('enter_title_here', 'dj_filter_title_text');

This example assumes you’re building a Custom Post Type for press releases. Line 3 gets the screen object that is use to detect which post type is being used. Line 4 tests the screen for your Custom Post Type. In this case, we’re checking it against the ‘press-release’ post type. We only want to change the title for the post type that we’re targeting, so this test is necessary.

The last line adds our filter function, dj_filter_title_text() to the functions that will be called for the ‘enter_title_here’ filter.

That’s all there is to it.

This filter is available in WordPress version 3.1 and above.

There are four WordPress actions used for this and they are separated into two groups.

The first set of actions hook in to WordPress when it presents the user fields for viewing and editing. The hooks are: ‘show_user_profile’ and ‘edit_user_profile’. These can both be hooked up to the same callback function that outputs the HTML with the user fields.

The second set of action hooks are used when WordPress is saving the data fields displayed by the first callback. These hooks are: ‘personal_options_update’ and ‘edit_user_profile_update’. Like the first set, these can both be hooked up to the same callback function.

Here is some sample code that provides both callback functions and hooks in to all four actions:

define('DJ_TEXTDOMAIN', 'your_textdomain');

function dj_addCustomUserProfileData($user)
{
?>
    <h3><?php _e('Additional Profile Information', DJ_TEXTDOMAIN); ?></h3>
    <table class="form-table">
    <tr>
      <th>
        <label for="user_address"><?php _e('Address', DJ_TEXTDOMAIN); ?></label>
      </th>
      <td>
        <input type="text" name="user_address" id="user_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.', DJ_TEXTDOMAIN); ?></span>
      </td>
    </tr>
    </table>
<?php
}

function dj_saveCustomUserProfileData($user_id)
{
    if (!current_user_can('edit_user', $user_id))
        return (FALSE);
    // do validation, if needed
    if (isset($_POST['user_address']))
        update_usermeta($user_id, 'address', $_POST['user_address']);
}

add_action('show_user_profile', 'dj_addCustomUserProfileData');
add_action('edit_user_profile', 'dj_addCustomUserProfileData');
add_action('personal_options_update', 'dj_saveCustomUserProfileData');
add_action('edit_user_profile_update', 'dj_saveCustomUserProfileData');

You can add the above code any way you like, as either a plugin or added to your functions.php file. The code will display the appropriate edit fields for the user data you want to collect.

The code here is simple, but it gives a good example of how to implement your own system to collect custom user data and associate it with a user.